Развенчиваем расхождения в результатах бенчмарков: Milvus против Qdrant
С ростом популярности GenAI на рынке появляется всё больше векторных баз данных. В начале прошлого года мы представили VectorDB Bench, чтобы дать представление о производительности новых технологий векторных баз данных.
Недавно разработчики, глубоко вовлечённые в эту область, обратились к нам в Zilliz, стремясь понять существенные расхождения между результатами бенчмарков Qdrant и нашими выводами в VectorDB Bench. В частности, им требовалось разъяснение по поводу низкой производительности Milvus в результатах бенчмарка Qdrant. В ответ на эти запросы наша инженерная команда в Zilliz начала комплексное расследование, чтобы выявить первопричины этих расхождений.
В этой записи блога представлен подробный технический анализ различий в бенчмарках с особым вниманием к расхождению в производительности Milvus. Без дальнейших задержек давайте углубимся в детали этого расследования.
Причина №1: устаревшая версия Milvus
Расхождения в результатах бенчмарков в первую очередь связаны с разными версиями Milvus, использованными при тестировании. Отчёт о бенчмарке Qdrant, основанный на Milvus v2.1 и опубликованный 10 августа 2022 года, не в полной мере отражает значительные улучшения, внесённые в более поздних версиях. Ознакомьтесь с сырыми данными из этого отчёта. С тех пор Milvus претерпел существенные улучшения.
В Milvus v2.2.1 мы обновили векторный движок (также известный как Knowhere) и пересмотрели стратегию параллелизма. Последующие обновления в v2.2.3 принесли дальнейшие улучшения производительности поиска. В нашем white paper подчёркиваются эти достижения, демонстрируя, что Milvus 2.2.3 в четыре раза быстрее, чем Milvus 2.0, по производительности запросов (задержка и пропускная способность) и масштабируемости (коллекции миллиардного масштаба и несколько реплик).
После этого v2.2.9 улучшила производительность фильтрованного поиска. В v2.2.12 мы представили более высокую эффективность поиска с минимальными накладными расходами для больших значений top-K, улучшили производительность записи в сценариях с включённым partition-key или несколькими партициями, а также оптимизировали использование CPU для более крупных машин. Кроме того, v2.3.2 ознаменовала значительное повышение производительности за счёт минимизации копирования данных во время загрузки и улучшенных массовых вставок.
Эти непрерывные улучшения существенно преобразили возможности Milvus. В результате бенчмарки, основанные на Milvus 2.1, больше не отражают точно текущую производительность технологии. Чтобы лучше понять новейшие возможности Milvus, разработчикам рекомендуется обратиться к VectorDB Bench, который использует Milvus 2.3 для тестирования.
Причина №2: неправильное использование Milvus
Бенчмарк Qdrant по производительности Milvus частично обусловлен тем, что он использовал только Growing Segments. Как следует из названия, Milvus оптимизирует работу с двумя типами сегментов: Growing и Sealed Segments. Growing Segments продолжают получать данные, пока не достигнут заранее заданного порога. Эти сегменты отдают приоритет быстрому вводу данных и используют стратегию поиска полным перебором, что приводит к более низкой производительности запросов.
С другой стороны, Sealed Segments больше не получают данные и, следовательно, имеют индекс, что приводит к значительному приросту производительности. Milvus автоматически запечатывает Growing Segments, когда достигается предопределенный порог, тем самым позволяя этим данным также получать прирост производительности при использовании с индексом.
Бенчмарк Qdrant был сосредоточен только на использовании Growing Segments, что естественным образом привело к заявленной более низкой производительности. Сосредоточение только на Growing Segments отличается от того, как Milvus используется в реальных приложениях, и нивелирует смысл стратегии сегментов, содержащейся в Milvus.
Кроме того, чтобы помочь пользователям сбалансировать свежесть данных и эффективность поиска, Milvus v2.3 представил поддержку индекса IVF-FLAT для растущих индексов. Кроме того, Milvus v2.3.4 представил индекс Binlog для Growing Segments. Это обновление позволяет использовать в этих сегментах продвинутые индексы, такие как IVF или Fast Scan, потенциально повышая производительность поиска до десяти раз. В результате это улучшение функции сделало предыдущие результаты бенчмарка Qdrant еще менее релевантными.
Причина #3: оптимизация Qdrant, ориентированная на бенчмарки
Исключительная производительность Qdrant в бенчмарках по сравнению с другими поставщиками обусловлена использованием сверхкрупных сегментов для бенчмаркинга. Хотя эта стратегия обеспечила заметные результаты в бенчмарках, ее применимость в реальном мире вызывает вопросы. В векторных базах данных размер сегментов имеет решающее значение. Фокус Qdrant на крупных сегментах повысил показатели бенчмарков, но может поставить под угрозу операционную гибкость в повседневном использовании.
Эффективные векторные базы данных должны справляться с разнообразными рабочими нагрузками и меняющимися требованиями к данным. Сверхкрупные сегменты, будучи эффективными в бенчмарках, могут испытывать трудности с разнообразными запросами, типичными для реальных ситуаций. Они усложняют управление и могут повысить требования к ресурсам.
Хотя оптимизации Qdrant, ориентированные на бенчмарки, такие как сверхкрупные сегменты, демонстрируют впечатляющую производительность, их практичность в динамичных реальных средах вызывает опасения. Это ставит под вопрос общую релевантность таких результатов бенчмарков в фактических развертываниях векторных баз данных.
Заключительные мысли: путь к справедливым и обоснованным решениям
Когда речь идет о векторных базах данных, надежный и всесторонний бенчмаркинг жизненно важен. VectorDB Bench, созданный Zilliz, предоставляет разработчикам данные о производительности в реальных условиях. Признавая сложность достижения абсолютной беспристрастности в бенчмарках, мы делимся своими инсайтами, чтобы обогатить коллективные знания в этой области.
ANN Benchmark — ценный инструмент для тех, кто ищет беспристрастные оценки, предоставляющий стандартизированные оценки векторных баз данных. По мере развития технологий в этой сфере мы подчеркиваем необходимость ясных, прозрачных и совместных усилий по бенчмаркингу. Разработчики должны иметь доступ к правдивым и точным бенчмаркам или проводить собственные тесты на своих данных, чтобы принимать обоснованные решения при выборе векторной базы данных.
Читать далее
Build Multimodal Search for 3D Assets with Tripo and Zilliz Cloud
Generate 3D assets with Tripo, then search them by text, image, and metadata with multimodal embeddings and Zilliz Cloud.
A Few Notes from Databricks Data + AI Summit 2026: Why the Data Layer Matters Again
James Luan shares notes from Databricks Data + AI Summit 2026 on why production AI is pushing the data layer back to the center of infrastructure.
Zilliz Cloud Delivers Better Performance and Lower Costs with Arm Neoverse-based AWS Graviton
Zilliz Cloud adopts Arm-based AWS Graviton3 CPUs to cut costs, speed up AI vector search, and power billion-scale RAG and semantic search workloads.