For "Single tenant LAION 100M" below, we refer to the "Laion 100m" (Нажмите, чтобы скопировать S3 URI) Dataset (100M * 768 float dense vectors).
For "Multitenant Cohere 10M" Dataset below, we refer to the "Cohere Large" (Нажмите, чтобы скопировать S3 URI) Dataset (10M * 768 float dense vectors). All data are randomly splitted across 1000 tenants.
Линии Парето затрат
Линии затрат Парето показывают, сколько устойчивых QPS может обеспечить каждая облачная векторная база данных при заданных операционных расходах. Они сочетают в себе измеренные результаты поиска и публичные модели ценообразования.
Рабочая нагрузка
Один арендатор LAION 100M
Базис затрат
Query only
Период затрат
Price order
Стоимость по сравнению с QPS по ПаретоQuery only - Лучше меньше, да лучше - USD / hour
Примечания:Все тесты проводятся в AWS us-west-2. Все указанные здесь расходы основаны на стоимости каждого продукта в этом регионе.
Cloud Insert Case
В данном случае измеряется жизненный цикл записи-обслуживания: сколько времени требуется для завершения вставки больших данных, когда их можно надежно искать и когда фоновая индексация полностью справляется с задачей.
Примечания:Как именно мы определяли понятия "вставленный", "доступный для поиска", "полностью проиндексированный", смотрите в исходном коде VectorDBBench для каждого клиента. Для основной интуиции:
CloudPayloadSearchCase и MultitenantSearchCase
В этом примере измеряется поведение запросов после того, как облачные данные уже загружены и доступны для поиска. В нем сравниваются пиковая одновременная QPS, задержка P99 и запоминание при различных полезных нагрузках ответа, селективности скалярных фильтров и режимах аренды, так что график показывает как пропускную способность, так и качество результата, а не только скорость.
Режим
Один арендатор LAION 100M
Фильтр
нефильтрованный
Полезная нагрузка
ids only
Латентность
Максимальный параллелизм Задержка P99
Стоимость дисплея
topK = 100
Задержка векторного поиска и QPSнефильтрованный - ids only - Максимальный параллелизм P99
ПродуктМаксимальный параллелизм Задержка P99Максимальный параллелизм QPSотзыв@10Стоимость запроса при максимальном QPS
Zilliz Cloud Capacity 32CU
2,000 байты/запрос
158 ms
786.1
отзыв@10 0.9728
n/a
Turbopuffer
2,000 байты/запрос
2.34 s
395.7
отзыв@10 0.9321
n/a
Zilliz Cloud Capacity 12CU
2,000 байты/запрос
299 ms
376
отзыв@10 0.9723
n/a
Turbopuffer Pinned
2,000 байты/запрос
3.30 s
68.2
отзыв@10 0.9321
n/a
Zilliz Cloud Tiered 4CU
2,000 байты/запрос
5.57 s
49.2
отзыв@10 0.9510
n/a
Pinecone Serverless
2,000 байты/запрос
4.85 s
4.6
отзыв@10 0.9609
n/a
CloudColdLatency Case
В этом случае измеряется первый запрос после холодного периода простоя в сравнении с нагретым траекторией запроса в постоянном режиме. Он изолирует поведение холодного старта от нормальной пропускной способности поиска, поэтому график показывает, есть ли у продукта существенный штраф за прогрев после бездействия.
Режим
нефильтрованный
Cold / Warm Latencyнефильтрованный
Zilliz Cloud Capacity 12CU
55 / 54 ms
Turbopuffer Pinned
64 / 45 ms
Zilliz Cloud Tiered 4CU
122 / 57 ms
Pinecone Serverless
271 / 60 ms
Turbopuffer
2048 / 322 ms
Соотношение холодного и теплогоменьше - лучше
Zilliz Cloud Capacity 12CU
1.01×
Turbopuffer Pinned
1.42×
Zilliz Cloud Tiered 4CU
2.16×
Pinecone Serverless
4.52×
Turbopuffer
6.36×
Примечания:
Мы отмечаем, что, хотя у некоторых продуктов соотношение "холодный/теплый" может быть более значительным на уровне p99 процентиля, это обычно указывает на проблемы с дрожанием сети при последующих запросах и не может быть полностью воспроизведено. Поэтому мы придерживаемся более точного определения холодной/теплой задержки, то есть первого запроса в каждом раунде.
Время, когда коллекция продукта становится холодной, довольно неоднозначно, поскольку большинство продуктов не предлагают публичных API для предоставления такой информации. Чтобы имитировать реальные производственные условия, для бенчмарков холодной задержки мы обеспечиваем ожидание не менее 24 часов с момента последних операций над продуктами, чтобы коллекции стали как можно более холодными.