Развенчиваем расхождения в результатах бенчмарков: 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 — ценный инструмент для тех, кто ищет беспристрастные оценки, предоставляющий стандартизированные оценки векторных баз данных. По мере развития технологий в этой сфере мы подчеркиваем необходимость ясных, прозрачных и совместных усилий по бенчмаркингу. Разработчики должны иметь доступ к правдивым и точным бенчмаркам или проводить собственные тесты на своих данных, чтобы принимать обоснованные решения при выборе векторной базы данных.