Примечание к набору данных:

  1. For "Single tenant LAION 100M" below, we refer to the "Laion 100m" (Нажмите, чтобы скопировать S3 URI) Dataset (100M * 768 float dense vectors).
  2. 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 может обеспечить каждая облачная векторная база данных при заданных операционных расходах. Они сочетают в себе измеренные результаты поиска и публичные модели ценообразования.
Рабочая нагрузка
Базис затрат

Период затрат
Price order
Стоимость по сравнению с QPS по ПаретоQuery only - Лучше меньше, да лучше - USD / hour
Примечания:Все тесты проводятся в AWS us-west-2. Все указанные здесь расходы основаны на стоимости каждого продукта в этом регионе.

Непрерывный загруз данных и актуальность результатов поиска

Скопировать ссылку на этот раздел
В данном случае измеряется жизненный цикл записи-обслуживания: сколько времени требуется для завершения вставки больших данных, когда их можно надежно искать и когда фоновая индексация полностью справляется с задачей.
Стоимость дисплея
Набор данныхLAION 100M
ВставленоС возможностью поискаПолностью индексированныйЗапись стоимости
Zilliz Cloud Capacity 12CU
размер партии = 1,000
2.9 hr
0 ms
7.0 min
$9.12
размер партии = 5,000
3.1 hr
0 ms
1.8 min
$9.25
размер партии = 10,000
3.2 hr
0 ms
1.9 min
$9.5
Zilliz Cloud Tiered 4CU
размер партии = 1,000
4.1 hr
0 ms
10.3 min
$6.3
размер партии = 5,000
4.1 hr
0 ms
9.6 min
$6.29
размер партии = 10,000
4.1 hr
0 ms
10.9 min
$6.34
Turbopuffer
размер партии = 1,000
53.5 hr
0 ms
3.4 min
$304
размер партии = 5,000
1.9 hr
6.6 hr
2.4 min
$302
размер партии = 10,000
1.8 hr
6.4 hr
2.0 min
$302
Pinecone Serverless
размер партии = 1,000
111.7 hr
0 ms
42 ms
$1,180
размер партии = 5,000
71.4 hr
0 ms
1 ms
$1,180
размер партии = 10,000
72.4 hr
0 ms
127 ms
$1,180
Примечания:Как именно мы определяли понятия "вставленный", "доступный для поиска", "полностью проиндексированный", смотрите в исходном коде VectorDBBench для каждого клиента. Для основной интуиции:

Одно- и многопользовательский поиск с полезной нагрузкой

Скопировать ссылку на этот раздел
В этом примере измеряется поведение запросов после того, как облачные данные уже загружены и доступны для поиска. В нем сравниваются пиковая одновременная QPS, задержка P99 и запоминание при различных полезных нагрузках ответа, селективности скалярных фильтров и режимах аренды, так что график показывает как пропускную способность, так и качество результата, а не только скорость.
Режим
Фильтр
Полезная нагрузка
Латентность
Стоимость дисплея
topK = 100
Задержка векторного поиска и QPSнефильтрованный - ids only - Максимальный параллелизм P99
ПродуктМаксимальный параллелизм Задержка P99Максимальный параллелизм QPSотзыв@10
Zilliz Cloud Capacity 32CU
2,000 байты/запрос
158 ms
786.1
отзыв@10 0.9728
Turbopuffer
2,000 байты/запрос
2.34 s
395.7
отзыв@10 0.9321
Zilliz Cloud Capacity 12CU
2,000 байты/запрос
299 ms
376
отзыв@10 0.9723
Turbopuffer Pinned
2,000 байты/запрос
3.30 s
68.2
отзыв@10 0.9321
Zilliz Cloud Tiered 4CU
2,000 байты/запрос
5.57 s
49.2
отзыв@10 0.9510
Pinecone Serverless
2,000 байты/запрос
4.85 s
4.6
отзыв@10 0.9609

Задержка при холодном запуске

Скопировать ссылку на этот раздел
В этом случае измеряется первый запрос после холодного периода простоя в сравнении с нагретым траекторией запроса в постоянном режиме. Он изолирует поведение холодного старта от нормальной пропускной способности поиска, поэтому график показывает, есть ли у продукта существенный штраф за прогрев после бездействия.
Режим
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×
Примечания:
  1. Мы отмечаем, что, хотя у некоторых продуктов соотношение "холодный/теплый" может быть более значительным на уровне p99 процентиля, это обычно указывает на проблемы с дрожанием сети при последующих запросах и не может быть полностью воспроизведено. Поэтому мы придерживаемся более точного определения холодной/теплой задержки, то есть первого запроса в каждом раунде.
  2. Время, когда коллекция продукта становится холодной, довольно неоднозначно, поскольку большинство продуктов не предлагают публичных API для предоставления такой информации. Чтобы имитировать реальные производственные условия, для бенчмарков холодной задержки мы обеспечиваем ожидание не менее 24 часов с момента последних операций над продуктами, чтобы коллекции стали как можно более холодными.