Планирование емкости#

Предусловия#

При настройке кластера Platform V Vector DB (далее - Vector DB) необходимо определить оптимальное соотношение оперативной памяти и дискового пространства. Оптимальная конфигурация зависит от нескольких факторов:

• количество векторов и их размерность;

• объем данных полезной нагрузки и индексов;

• какие данные будут храниться в памяти, а какие на диске;

• настройки репликации кластера;

• факт использования квантования и его настройки.

Пререквизиты:

• Доступ к серверу: SSH или физический доступ.

• Установленный продукт: сервер должен быть запущен (кроме операций с файлами данных).

• Исходный код: скрипты находятся в /src/bin/ репозитория продукта.

• Rust: установленный компилятор для сборки утилит.

Привилегии:

• Файловая система: права на чтение/запись в storage_path.

• API-ключ: обязателен ключ с правами admin для большинства операций.

• Сетевой доступ: доступность API-порта (порт по умолчанию 6333).

Ключевые требования:

• Доступ к метрикам (API, Prometheus).

• Данные о размере коллекций.

Последовательность выполнения#

Расчет объема оперативной памяти#

Часто используемые данные следует хранить в оперативной памяти для более быстрого доступа. Если необходимо сохранить все векторы в памяти для оптимальной производительности, можно использовать следующую приблизительную формулу расчета:

\(\text{memory_size} = \text{number_of_vectors} * \text{vector_dimension} * 4_{bytes} * 1.5\)

Коэффициент 1,5 обеспечивает дополнительный запас в 50% учитывает метаданные (например, индексы и версии точек) и временные сегменты, создаваемые во время оптимизации.

Допустим, необходимо хранить один миллион векторов с размерностью 1024:

\(\text{memory_size} = 1000000 * 1024 * 4_{bytes} * 1.5\)

Размер памяти составляет примерно 6 144 000 000 байт, или около 5,72 ГБ.

В зависимости от сценария использования большие наборы данных могут выиграть за счет снижения требований к объему памяти благодаря использованию квантования.

Расчет размера полезной нагрузки#

Это всегда индивидуально. Размер полезной нагрузки зависит от структуры и содержимого данных. Например:

• Текстовые поля занимают место в зависимости от длины и кодировки (например, большой фрагмент текста против нескольких слов).

• Числа с плавающей запятой имеют фиксированный размер - 8 байт для int64 или float64.

• Бинарные поля обычно занимают 1 байт.

Самый простой способ рассчитать объем полезной нагрузки — воспользоваться калькулятором размеров JSON.

Расчет общего объема полезной нагрузки аналогичен расчетам для векторов. Необходимо умножить его на 1,5 из-за процессов индексации на стороне сервера.

\(\text{total_payload_size} = \text{number_of_points} * \text{payload_size} * 1.5\)

Предположим, необходимо хранить один миллион записей с полезной нагрузкой формата JSON объемом 5 КБ каждая:

\(\text{total_payload_size} = 1000000 * 5_{KB} * 1.5\)

Общий объем полезной нагрузки составляет приблизительно 5 000 000 байт, или около 4,77 ГБ.

Выбор между диском и памятью#

Для достижения максимальной производительности рекомендуется хранить только часто запрашиваемые данные в оперативной памяти. Остальное следует выгружать на диск. Например, дополнительные поля полезной нагрузки, которые не используются для фильтрации, могут храниться на диске.

Только индексированные поля следует хранить в оперативной памяти. Можно узнать больше о хранении полезной нагрузки в разделе Хранение.

Конфигурация, ориентированная на хранение#

Если цель заключается в обработке больших объемов векторов при средней задержке поиска, рекомендуется настроить хранилище с отображением памяти (память, отображаемая на файловой системе (mmap)). В этой конфигурации векторы хранятся на диске в файлах с отображением памяти, а кешируются в оперативной памяти только наиболее часто запрашиваемые векторы.

Доступный объем оперативной памяти существенно влияет на производительность поиска. Как правило, если сохраняется вдвое меньше векторов в оперативной памяти, задержка поиска увеличится примерно вдвое.

Скорость диска также имеет решающее значение.

Конфигурация, ориентированная на подгруппы#

Если сценарий предполагает разделение векторов на несколько коллекций или подгрупп на основе значений полезной нагрузки (например, выполнение запросов поиска для множества пользователей, каждый со своим подмножеством векторов), рекомендуется использовать хранилище с отображением памяти.

В этом сценарии в оперативную память будут закешированы только активные подмножества векторов, что позволит быстро выполнять запросы для самых последних и активных пользователей. Оцените необходимый объем памяти следующим образом:

\(\text{memory_size} = \text{number_of_active_vectors} \text{vector_dimension}* 4_{bytes} * 1.5\)

Подробнее о разбиении данных описано в документации по разделению ресурсов между пользователями (многопользовательский режим).

Масштабирование дискового пространства#

Кластеры, поддерживающие векторный поиск, требуют значительно большего объема дискового пространства по сравнению с другими системами поиска.

Когда свободного места на диске становится мало, масштабирование дает следующие преимущества:

• Большие объемы данных: поддерживает большие объемы данных, что может повысить релевантность и качество результатов поиска.

• Повышенная эффективность индексирования: позволяет использовать продвинутые стратегии индексирования, такие как HNSW.

• Кеширование: повышает скорость работы за счет увеличения объема доступной оперативной памяти, позволяя кэшировать чаще запрашиваемые данные.

• Резервное копирование и избыточность: обеспечивает возможность создания резервных копий с большей частотой, что является важным преимуществом для обеспечения безопасности данных.

Всегда помните о необходимости добавить дополнительно 50% от размера вектора. Это учтет такие вещи, как индексы и вспомогательные данные, используемые при операциях вставки, удаления и поиска векторов. Таким образом, оценочный объем памяти с учетом метаданных составит:

\(\text{total_vector_size} = \text{number_of_dimensions} * 4_{bytes} * 1.5\)

Результат#

• Формулы расчета:

  • Для векторов: memory_size = number_of_vectors * vector_dimension * 4 bytes * 1.5.

  • Для полезной нагрузки: total_payload_size = number_of_points * payload_size * 1.5. Формулы учитывают индексы, версии точек и временные сегменты.

• Выбор хранилища:

  • In-memory: рекомендуется для часто запрашиваемых данных (низкая задержка).

  • Memmap: подходит для больших коллекций (экономия RAM за счет диска).

  • On-disk: используется для редко запрашиваемых или больших полей (например, изображений).

• Примеры:

  • Хранение 1 млн векторов размерностью 1024 требует ~5,72 ГБ RAM.

  • Полезная нагрузка объемом 5 КБ на 1 млн записей займет ~4,77 ГБ.

• Риски и решения:

  • Недостаток RAM: применение mmap и удаление старых данных.

  • Недостаток дискового пространства: масштабирование кластера или архивация данных.