Home
Blog
Представляем инструмент Milvus Sizing Tool: Расчет и оптимизация ресурсов развертывания Milvus

Представляем инструмент Milvus Sizing Tool: Расчет и оптимизация ресурсов развертывания Milvus

Tutorials

April 11, 2025

Ken Zhang, Fendy Feng

Введение

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

Чтобы упростить этот процесс, мы переработали наш инструмент Milvus Sizing Tool- удобный калькулятор, который генерирует рекомендуемые оценки ресурсов на основе ваших конкретных требований. В этом руководстве мы расскажем вам о том, как пользоваться этим инструментом, и предоставим более подробную информацию о факторах, влияющих на производительность Milvus.

Как использовать инструмент определения размеров Milvus

Пользоваться этим инструментом очень просто. Просто выполните следующие действия.

Перейдите на страницу Milvus Sizing Tool.
Введите ключевые параметры:
- Количество векторов и размеры одного вектора
- Тип индекса
- Размер данных скалярного поля
- Размер сегмента
- Предпочтительный режим развертывания
Просмотрите сгенерированные рекомендации по ресурсам

milvus sizing tool инструмент определения размеров milvus

Давайте рассмотрим, как каждый из этих параметров влияет на развертывание Milvus.

Выбор индекса: Баланс между хранением, стоимостью, точностью и скоростью

Milvus предлагает различные алгоритмы индексов, включая HNSW, FLAT, IVF_FLAT, IVF_SQ8, ScaNN, DiskANN и другие, каждый из которых имеет свои компромиссы в использовании памяти, требованиях к дисковому пространству, скорости запросов и точности поиска.

Вот что вам нужно знать о наиболее распространенных вариантах:

index индекс

HNSW (Hierarchical Navigable Small World)

Архитектура: Сочетает списки пропусков с графами Navigable Small Worlds (NSWs) в иерархической структуре.
Производительность: Очень быстрые запросы с отличными показателями запоминания
Использование ресурсов: Требует больше всего памяти на вектор (самая высокая стоимость)
Лучше всего подходит для: Приложения, для которых важны скорость и точность, а ограничение памяти не так важно.
Техническое примечание: Поиск начинается с самого верхнего слоя с наименьшим количеством узлов и идет вниз через все более плотные слои.

ПЛОСКИЙ

Архитектура: Простой исчерпывающий поиск без аппроксимации
Производительность: 100% отзыв, но очень медленное время выполнения запроса (O(n) для размера данных n).
Использование ресурсов: Размер индекса равен размеру исходных векторных данных
Лучше всего подходит для: Небольшие наборы данных или приложения, требующие идеального отзыва.
Техническое примечание: Выполняет полный расчет расстояния между вектором запроса и каждым вектором в базе данных

IVF_FLAT

Архитектура: Разделяет пространство векторов на кластеры для более эффективного поиска
Производительность: Средне-высокий отзыв при умеренной скорости запроса (медленнее, чем HNSW, но быстрее, чем FLAT)
Использование ресурсов: Требует меньше памяти, чем FLAT, но больше, чем HNSW.
Лучше всего подходит для: Сбалансированные приложения, в которых некоторое количество отзывов можно обменять на лучшую производительность.
Техническое примечание: Во время поиска рассматриваются только кластеры nlist, что значительно сокращает вычисления.

IVF_SQ8

Архитектура: Применяет скалярное квантование к IVF_FLAT, сжимая векторные данные.
Производительность: Средний отзыв при средне-высокой скорости запроса
Использование ресурсов: Сокращение потребления диска, вычислений и памяти на 70-75 % по сравнению с IVF_FLAT.
Лучше всего подходит для: Среды с ограниченными ресурсами, где точность может быть немного снижена.
Техническое примечание: Сжимает 32-битные значения с плавающей точкой до 8-битных целых значений.

Дополнительные параметры индекса: ScaNN, DiskANN, CAGRA и др.

Для разработчиков со специальными требованиями Milvus также предлагает:

ScaNN: на 20% быстрее на CPU, чем HNSW, с аналогичными показателями запоминания.
DiskANN: гибридный индекс на основе диска и памяти, который идеально подходит для поддержки большого количества векторов с высокой скоростью запоминания и может работать с немного большей задержкой (~100 мс). Он балансирует между использованием памяти и производительностью, сохраняя только часть индекса в памяти, в то время как остальная часть остается на диске.
Индексы на базе GPU:
- GPU_CAGRA: это самый быстрый из GPU-индексов, но для него требуется карта обработки выводов с памятью GDDR, а не с памятью HBM.
- GPU_BRUTE_FORCE: Исчерпывающий поиск, реализованный на GPU
- GPU_IVF_FLAT: Ускоренная на GPU версия IVF_FLAT
- GPU_IVF_PQ: ускоренная на GPU версия IVF с квантованием по продукту
HNSW-PQ/SQ/PRQ:
- HNSW_SQ: Очень высокоскоростной запрос, ограниченные ресурсы памяти; допускает незначительный компромисс в скорости отзыва.
- HNSW_PQ: среднескоростной запрос; очень ограниченные ресурсы памяти; допускает незначительный компромисс в скорости запоминания.
- HNSW_PRQ: среднескоростной запрос; очень ограниченные ресурсы памяти; допускает незначительный компромисс в скорости запоминания.
- AUTOINDEX: По умолчанию HNSW в Milvus с открытым исходным кодом (или использует более производительные собственные индексы в Zilliz Cloud, управляемом Milvus).
Двоичные, разреженные и другие специализированные индексы: Для конкретных типов данных и случаев использования. Дополнительные сведения см. на этой странице документации по индексам.

Размер сегмента и конфигурация развертывания

Сегменты - это фундаментальные строительные блоки внутренней организации данных Milvus. Они функционируют как фрагменты данных, которые обеспечивают распределенный поиск и балансировку нагрузки в вашем развертывании. Инструмент определения размера сегментов Milvus предлагает три варианта размера сегментов (512 МБ, 1024 МБ, 2048 МБ), при этом по умолчанию используется 1024 МБ.

Понимание сегментов очень важно для оптимизации производительности. В качестве общего руководства:

512 МБ сегментов: лучше всего подходят для узлов запросов с 4-8 ГБ памяти.
Сегменты по 1 ГБ: Оптимально для узлов запросов с 8-16 ГБ памяти
Сегменты по 2 ГБ: Рекомендуется для узлов запросов с памятью >16 ГБ.

Обзор для разработчиков: Меньшее количество сегментов большого размера обычно обеспечивает более высокую производительность поиска. Для крупномасштабных развертываний сегменты по 2 ГБ часто обеспечивают оптимальный баланс между эффективностью использования памяти и скоростью выполнения запросов.

Выбор системы очереди сообщений

Выбор между Pulsar и Kafka в качестве системы обмена сообщениями:

Pulsar: Рекомендуется для новых проектов из-за меньших накладных расходов на тему и лучшей масштабируемости.
Kafka: Может быть предпочтительнее, если у вас уже есть опыт работы с Kafka или инфраструктура в вашей организации.

Оптимизации для предприятий в Zilliz Cloud

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

Предотвращение выхода из памяти (OOM): Продуманное управление памятью для предотвращения аварийных ситуаций, связанных с выходом за пределы памяти.
Оптимизация уплотнения: Повышает производительность поиска и эффективность использования ресурсов
Многоуровневое хранение: Эффективное управление "горячими" и "холодными" данными с помощью соответствующих вычислительных блоков
- Стандартные вычислительные блоки (CU) для часто используемых данных
- Многоуровневые модули хранения данных для экономичного хранения редко используемых данных.

Для получения подробной информации о размерах корпоративных систем ознакомьтесь с документацией по планам обслуживания Zilliz Cloud.

Советы по расширенной конфигурации для разработчиков

Несколько типов индексов: Инструмент определения размера ориентирован на один индекс. Для сложных приложений, требующих различных алгоритмов индексации для разных коллекций, создайте отдельные коллекции с пользовательскими конфигурациями.
Распределение памяти: При планировании развертывания учитывайте требования к памяти как векторных данных, так и индексов. HNSW обычно требует в 2-3 раза больше памяти, чем необработанные векторные данные.
Тестирование производительности: Перед окончательной настройкой конфигурации проведите сравнительный анализ конкретных шаблонов запросов на репрезентативном наборе данных.
Учет масштаба: Учитывайте будущий рост. Проще начать с чуть больших ресурсов, чем потом перестраивать конфигурацию.

Заключение

Инструмент Milvus Sizing Tool является отличной отправной точкой для планирования ресурсов, но помните, что каждое приложение имеет уникальные требования. Для достижения оптимальной производительности вам потребуется точная настройка конфигурации с учетом особенностей рабочей нагрузки, шаблонов запросов и потребностей в масштабировании.

Мы постоянно совершенствуем наши инструменты и документацию на основе отзывов пользователей. Если у вас есть вопросы или вам нужна дополнительная помощь в определении размера развертывания Milvus, обращайтесь к нашему сообществу на GitHub или Discord.