На прошлой неделе Elastic опубликовал сравнение, в котором Qdrant оказался примерно в 7 раз медленнее DiskBBQ — проприетарного механизма в Enterprise-версии Elasticsearch.
Qdrant не остался в стороне и ответил очень язвительно.
Ниже прямой перевод.
Окей, Elastic.
Ты сам этого захотел.
Вы ведь сделали бенчмарк, чтобы показать, что ваша платная премиум-функция лучше open-source решения, верно?
Вы опубликовали сравнение с Qdrant, так? Что ж… тогда поехали.
На прошлой неделе Elastic выпустил бенчмарк, в котором показал, что Qdrant работает в 7 раз медленнее, чем DiskBBQ.
Впечатляющий результат.
Но он становится еще более впечатляющим, если учесть, что этого удалось добиться, отключив наш асинхронный дисковый скорер, проигнорировав двухэтапную схему поиска, которую мы специально рекомендуем для таких сценариев, а затем измерив скорость неограниченного последовательного чтения с диска.
(Спойлер: она невысокая. Именно поэтому мы и реализовали все остальные механизмы.)
Поэтому мы запустили тот же датасет, с той же целевой полнотой поиска (recall) и той же загруженной моделью — но уже с Qdrant, действительно настроенным для работы с диском.
Результат: в два раза выше пропускная способность, в два раза ниже задержка, при этом используются узлы с в три раза меньшим количеством CPU и RAM. Даже на нашей самой маленькой конфигурации — 2 vCPU и 8 ГБ памяти — мы превзошли опубликованные Elastic результаты, полученные на кластере с 7 vCPU и 26 ГБ памяти.
И еще: DiskBBQ — это функция, доступная только в Enterprise-версии Elastic. Для ее нормальной работы требуется более 20 ГБ оперативной памяти на каждый pod, чтобы JVM чувствовала себя комфортно. Наша более экономичная по памяти альтернатива распространяется по лицензии Apache 2.0.
Полное описание методологии и набор для воспроизведения результатов — в публикации.
Тестируйте нас как угодно — только сначала прочитайте документацию.
Войны бенчмарков выходят на новый уровень.
И, наблюдать за ними иногда интереснее, чем за релизами самих продуктов 😃
@tldr_data
