Анонсируем VDBBench 1.0: бенчмаркинг VectorDB с открытым исходным кодом на ваших реальных производственных рабочих нагрузках
Большинство бенчмарков векторных баз данных тестируют статические данные и заранее построенные индексы. Но production-системы работают иначе — данные непрерывно поступают, пока пользователи выполняют запросы, фильтры фрагментируют индексы, а характеристики производительности резко меняются при конкурентных нагрузках чтения/записи.
Сегодня мы выпускаем VDBBench 1.0, open-source бенчмарк, изначально разработанный для тестирования векторных баз данных в реалистичных production-условиях: потоковая загрузка данных, фильтрация по метаданным с различной селективностью и конкурентные рабочие нагрузки, выявляющие реальные узкие места системы.
Скачать VDBBench 1.0 → | Посмотреть таблицу лидеров →
Почему текущие бенчмарки вводят в заблуждение
Будем честны — в нашей индустрии наблюдается странное явление. Все говорят о том, что «не надо подгонять бенчмарки», но многие при этом участвуют именно в таком поведении. С тех пор как рынок векторных баз данных взорвался в 2023 году, мы видели множество примеров систем, которые «прекрасно показывают себя в бенчмарках», но «катастрофически проваливаются» в production, тратя впустую время инженеров и подрывая доверие к проектам.
Мы сами наблюдали этот разрыв. Например, Elasticsearch заявляет о скоростях запросов на уровне миллисекунд, но за кулисами ему может потребоваться более 20 часов только на оптимизацию индекса. Какая production-система может терпеть такой простой?
Проблема возникает из трех фундаментальных недостатков:
Устаревшие наборы данных: Многие бенчмарки по-прежнему полагаются на устаревшие наборы данных вроде SIFT (128 измерений), тогда как современные embeddings варьируются от 768 до 3 072 измерений. Характеристики производительности систем, работающих с векторами 128D и 1024D+, принципиально различаются — паттерны доступа к памяти, эффективность индекса и вычислительная сложность кардинально меняются.
Метрики тщеславия: Бенчмарки фокусируются на средней задержке или пиковом QPS, создавая искаженную картину. Система со средней задержкой 10 мс, но P99-задержкой в 2 секунды создает ужасный пользовательский опыт. Пиковая пропускная способность, измеренная за 30 секунд, ничего не говорит об устойчивой производительности.
Чрезмерно упрощенные сценарии: Большинство бенчмарков тестируют базовые рабочие процессы «записать данные, построить индекс, выполнить запрос» — по сути, тестирование уровня «Hello World». Реальный production включает непрерывную загрузку данных при одновременном обслуживании запросов, сложную фильтрацию по метаданным, фрагментирующую индексы, и конкурентные операции чтения/записи, конкурирующие за ресурсы.
Что нового в VDBBench 1.0?
VDBBench не просто развивает устаревшие философии бенчмаркинга — он перестраивает саму концепцию с нуля, руководствуясь одним принципом: бенчмарк ценен только тогда, когда он предсказывает реальное поведение в production.
Мы разработали VDBBench так, чтобы точно воспроизводить реальные условия по трем критически важным направлениям: аутентичность данных, паттерны рабочих нагрузок и методологии измерения производительности.
Давайте подробнее рассмотрим, какие новые возможности появились.
🚀 Переработанная панель мониторинга с визуализациями, релевантными для production
Большинство бенчмарков фокусируются только на сырых выходных данных, но важно то, как инженеры интерпретируют эти результаты и действуют на их основе. Мы переработали UI, сделав приоритетом ясность и интерактивность, — чтобы вы могли выявлять разрывы в производительности между системами и быстро принимать инфраструктурные решения.
Новая панель мониторинга визуализирует не только показатели производительности, но и связи между ними: как QPS деградирует при разных уровнях селективности фильтров, как recall колеблется во время потоковой загрузки и как распределения задержек выявляют характеристики стабильности системы.
Панель мониторинга VDBbench
Мы повторно протестировали основные платформы векторных баз данных, включая Milvus, Zilliz Cloud, Elastic Cloud, Qdrant Cloud, Pinecone и OpenSearch, с их последними конфигурациями и рекомендуемыми настройками, убедившись, что все данные бенчмарков отражают текущие возможности. Все результаты тестирования доступны в VDBBench Leaderboard.
🏷️ Фильтрация по тегам: скрытый убийца производительности
Реальные запросы редко выполняются изолированно. Приложения сочетают векторное сходство с фильтрацией по метаданным («найти обувь, которая выглядит как на этом фото, но стоит меньше $100»). Такой фильтрованный векторный поиск создает уникальные проблемы, которые большинство бенчмарков полностью игнорируют.
Фильтрованные поисковые запросы вносят сложность в двух критически важных областях:
Сложность фильтра: больше скалярных полей и сложных логических условий повышают вычислительные требования и могут вызывать недостаточную полноту и фрагментацию графового индекса.
Селективность фильтра: это тот самый «скрытый убийца производительности», который мы неоднократно проверяли в production. Когда условия фильтрации становятся высокоселективными (отфильтровывая 99%+ данных), скорость запросов может колебаться на порядки, а полнота может становиться нестабильной, поскольку индексным структурам трудно работать с разреженными наборами результатов.
VDBBench систематически тестирует различные уровни селективности фильтрации (от 50% до 99,9%), предоставляя всесторонний профиль производительности при этом критически важном production-паттерне. Результаты часто выявляют резкие провалы производительности, которые никогда не проявились бы в традиционных бенчмарках.
Пример: В тестах Cohere 1M Milvus сохранял стабильно высокую полноту на всех уровнях селективности фильтрации, тогда как OpenSearch демонстрировал нестабильную производительность с существенными колебаниями полноты при разных условиях фильтрации — во многих случаях опускаясь ниже 0,8 полноты, что неприемлемо для большинства production-сред.
Рисунок: QPS и полнота Milvus и OpenSearch при разных уровнях селективности фильтрации (тест Cohere 1M).
🌊 Потоковое чтение/запись: за пределами тестирования статических индексов
Production-системы редко могут позволить себе роскошь статических данных. Новая информация непрерывно поступает, пока выполняются поисковые запросы, — сценарий, в котором многие в остальном впечатляющие базы данных ломаются под двойным давлением поддержания производительности поиска и обработки непрерывных записей.
Потоковые сценарии VDBBench имитируют реальные параллельные операции, помогая разработчикам понять стабильность системы в средах с высокой конкурентностью, в частности то, как запись данных влияет на производительность запросов и как производительность меняется по мере роста объема данных.
Чтобы обеспечить справедливые сравнения между разными системами, VDBBench использует структурированный подход:
Настроить контролируемые скорости записи, отражающие целевые production-нагрузки (например, 500 строк/сек, распределенных по 5 параллельным процессам)
Запускать поисковые операции после каждых 10% загрузки данных, чередуя последовательный и конкурентный режимы
Записывать комплексные метрики: распределения задержек (включая P99), устойчивый QPS и точность полноты
Отслеживать изменение производительности со временем по мере роста объема данных и нагрузки на систему
Такое контролируемое, инкрементальное нагрузочное тестирование показывает, насколько хорошо системы сохраняют стабильность и точность при продолжающейся загрузке данных, — то, что традиционные бенчмарки редко фиксируют.
Пример: В потоковых тестах Cohere 10M Pinecone поддерживал более высокие QPS и полноту на протяжении всего цикла записи по сравнению с Elasticsearch. Примечательно, что производительность Pinecone значительно улучшилась после завершения загрузки, демонстрируя высокую стабильность при длительной нагрузке, тогда как Elasticsearch показывал более непредсказуемое поведение во время фаз активной загрузки.
Рисунок: QPS и полнота Pinecone по сравнению с Elasticsearch в потоковом тесте Cohere 10M (скорость загрузки 500 строк/с).
VDBBench идет еще дальше, поддерживая необязательный этап оптимизации, позволяя пользователям сравнивать производительность потокового поиска до и после оптимизации индекса. Он также отслеживает и сообщает фактическое время, затраченное на каждый этап, предлагая более глубокое понимание эффективности системы и ее поведения в условиях, близких к production.
Рисунок: QPS и Recall Pinecone по сравнению с Elasticsearch в потоковом тесте Cohere 10M после оптимизации (скорость загрузки 500 строк/с)
Как показали наши тесты, Elasticsearch превзошел Pinecone по QPS — после оптимизации индекса. Но когда ось x отражает фактически прошедшее время, становится ясно, что Elasticsearch потребовалось значительно больше времени, чтобы достичь этой производительности. В production эта задержка имеет значение. Это сравнение выявляет ключевой компромисс: пиковая пропускная способность против времени до готовности обслуживания.
🔬 Современные наборы данных, отражающие текущие AI-нагрузки
Мы полностью переработали наборы данных, используемые для бенчмаркинга векторных баз данных. Вместо устаревших тестовых наборов, таких как SIFT и GloVe, VDBBench использует векторы, сгенерированные современными моделями эмбеддингов, такими как OpenAI и Cohere, которые лежат в основе сегодняшних AI-приложений.
Чтобы обеспечить релевантность, особенно для таких сценариев использования, как Retrieval-Augmented Generation (RAG), мы выбрали корпуса, отражающие реальные корпоративные и доменно-специфические сценарии:
| Корпус | Модель эмбеддингов | Размерности | Размер | Сценарий использования |
|---|---|---|---|---|
| Wikipedia | Cohere V2 | 768 | 1M / 10M | Общая база знаний |
| BioASQ | Cohere V3 | 1024 | 1M / 10M | Доменно-специфический (биомедицинский) |
| C4 | OpenAI | 1536 | 500K / 5M | Обработка текста веб-масштаба |
| MSMarco V2 | udever-bloom-1b1 | 1536 | 1M / 10M / 138M | Крупномасштабный поиск |
Эти наборы данных лучше имитируют современные высокообъемные, высокоразмерные векторные данные, обеспечивая реалистичное тестирование эффективности хранения, производительности запросов и точности извлечения в условиях, соответствующих современным AI-нагрузкам.
⚙️ Поддержка пользовательских наборов данных для отраслевого тестирования
Каждый бизнес уникален. Финансовой отрасли может понадобиться тестирование, сосредоточенное на эмбеддингах транзакций, тогда как социальные платформы больше интересуют векторы поведения пользователей. VDBBench позволяет проводить бенчмаркинг на ваших собственных данных, сгенерированных вашими конкретными моделями эмбеддингов для ваших конкретных нагрузок.
Вы можете настраивать:
Размерности векторов и типы данных
Схему метаданных и шаблоны фильтрации
Объем данных и шаблоны загрузки
Распределения запросов, соответствующие вашему production-трафику
В конце концов, ни один набор данных не расскажет историю лучше, чем ваши собственные production-данные.
Как VDBBench измеряет то, что действительно важно в production
Дизайн метрик, ориентированный на production
VDBBench отдает приоритет метрикам, отражающим реальную производительность, а не только лабораторные результаты. Мы переработали бенчмаркинг вокруг того, что действительно важно в production-средах: надежность под нагрузкой, характеристики хвостовой задержки, устойчивую пропускную способность и сохранение точности.
P95/P99-задержка для реального пользовательского опыта: Средняя/медианная задержка скрывает выбросы, которые раздражают реальных пользователей и могут указывать на базовую нестабильность системы. VDBBench фокусируется на хвостовой задержке, такой как P95/P99, показывая, какой производительности фактически достигнут 95% или 99% ваших запросов. Это критически важно для планирования SLA и понимания пользовательского опыта в худшем случае.
Устойчивая пропускная способность под нагрузкой: Система, которая хорошо работает 5 секунд, не подходит для production. VDBBench постепенно увеличивает конкурентность, чтобы найти максимальное устойчивое количество запросов в секунду вашей базы данных (
max_qps) — а не пиковое число в коротких идеальных условиях. Эта методология показывает, насколько хорошо ваша система выдерживает нагрузку с течением времени, и помогает с реалистичным планированием емкости.Баланс полноты поиска и производительности: Скорость без точности бессмысленна. Каждое значение производительности в VDBBench сопровождается измерениями полноты поиска, поэтому вы точно знаете, какой релевантностью жертвуете ради пропускной способности. Это позволяет проводить честные, корректные сравнения систем с совершенно разными внутренними компромиссами.
Методология тестирования, отражающая реальность
Ключевая инновация в дизайне VDBBench — разделение последовательного и конкурентного тестирования, что помогает зафиксировать, как системы ведут себя при разных типах нагрузки, и выявляет характеристики производительности, важные для различных сценариев использования.
Разделение измерения задержки:
serial_latency_p99измеряет производительность системы при минимальной нагрузке, когда одновременно обрабатывается только один запрос. Это представляет лучший сценарий для задержки и помогает определить базовые возможности системы.conc_latency_p99отражает поведение системы в реалистичных условиях высокой конкурентности, когда несколько запросов поступают одновременно и конкурируют за системные ресурсы.
Двухфазная структура бенчмарка:
Последовательный тест: Запуск 1 000 запросов в одном процессе, который устанавливает базовую производительность и точность, сообщая как
serial_latency_p99, так и полноту поиска. Эта фаза помогает определить теоретический потолок производительности.Тест конкурентности: Имитирует производственную среду при устойчивой нагрузке с несколькими ключевыми инновациями:
Реалистичная симуляция клиентов: Каждый тестовый процесс работает независимо, со своим собственным подключением и набором запросов, избегая вмешательства общего состояния, которое могло бы исказить результаты
Синхронизированный старт: Все процессы начинаются одновременно, гарантируя, что измеренный QPS точно отражает заявленные уровни конкурентности
Независимые наборы запросов: Предотвращает нереалистично высокие показатели попаданий в кэш, которые не отражают разнообразие производственных запросов
Эти тщательно структурированные методы гарантируют, что значения max_qps и conc_latency_p99, сообщаемые VDBBench, являются одновременно точными и релевантными для продакшена, предоставляя значимые сведения для планирования производственной мощности и проектирования системы.
Начало работы с VDBBench 1.0
VDBBench 1.0 представляет фундаментальный сдвиг в сторону бенчмаркинга, релевантного для продакшена. Охватывая непрерывную запись данных, фильтрацию по метаданным с различной селективностью и потоковые нагрузки при конкурентных паттернах доступа, он обеспечивает наиболее близкое на сегодняшний день приближение к реальным производственным средам.
Разрыв между результатами бенчмарков и реальной производительностью не должен быть игрой в догадки. Если вы планируете развернуть векторную базу данных в продакшене, стоит понять, как она работает за пределами идеализированных лабораторных тестов. VDBBench имеет открытый исходный код, прозрачен и разработан для поддержки содержательных, корректных сравнений.
Не поддавайтесь впечатляющим цифрам, которые не превращаются в ценность для продакшена. Используйте VDBBench 1.0, чтобы тестировать сценарии, важные для вашего бизнеса, на ваших данных и в условиях, отражающих вашу фактическую рабочую нагрузку. Эра вводящих в заблуждение бенчмарков в оценке векторных баз данных подходит к концу — пора принимать решения на основе данных, релевантных для продакшена.
Попробуйте VDBBench на собственных рабочих нагрузках: https://github.com/zilliztech/VectorDBBench
Посмотрите результаты тестирования основных векторных баз данных: VDBBench Leaderboard
Есть вопросы или хотите поделиться своими результатами? Присоединяйтесь к обсуждению на GitHub или свяжитесь с нашим сообществом в Discord.
Читать далее
Zilliz Cloud Now Available in AWS Asia Pacific (Seoul)
Zilliz Cloud is now available in AWS Seoul — low-latency vector search, in-country data residency, and one-step migration for Korean AI teams. 31 regions across 5 clouds.
Introducing Zilliz Cloud Global Cluster: Region-Level Resilience for Mission-Critical AI
Zilliz Cloud Global Cluster delivers multi-region resilience, automatic failover, and fast global AI search with built-in security and compliance.
Cosmos World Foundation Model Platform for Physical AI
NVIDIA's Cosmos platform enables safe, digital twin training of GenAI models for physical applications, overcoming data scarcity and safety challenges.