Развенчиваем расхождения в результатах бенчмарков: 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 — ценный инструмент для тех, кто ищет беспристрастные оценки, предоставляющий стандартизированные оценки векторных баз данных. По мере развития технологий в этой сфере мы подчеркиваем необходимость ясных, прозрачных и совместных усилий по бенчмаркингу. Разработчики должны иметь доступ к правдивым и точным бенчмаркам или проводить собственные тесты на своих данных, чтобы принимать обоснованные решения при выборе векторной базы данных.
Читать далее
My Wife Wanted Dior. I Spent $600 on Claude Code to Vibe-Code a 2M-Line Database Instead.
Write tests, not code reviews. How a test-first workflow with 6 parallel Claude Code sessions turns a 2M-line C++ codebase into a daily shipping pipeline.
Zilliz Named "Highest Performer" and "Easiest to Use" in G2's Summer 2025 Grid® Report for Vector Databases
Zilliz shines in G2's Summer 2025 Grid® Report as both "Highest Performer" and "Easiest to Use," solving the performance-usability dilemma.
AI Agents Are Quietly Transforming E-Commerce — Here’s How
Discover how AI agents transform e-commerce with autonomous decision-making, enhanced product discovery, and vector search capabilities for today's retailers.