Разбираемся с инструментом расчёта ресурсов Milvus
Введение
Выбор оптимальной конфигурации для вашего развертывания Milvus критически важен для оптимизации производительности, эффективного использования ресурсов и управления затратами. Независимо от того, создаете ли вы прототип или планируете производственное развертывание, правильный подбор размера вашего экземпляра Milvus может стать разницей между стабильно работающей векторной базой данных и той, которая испытывает проблемы с производительностью или приводит к ненужным затратам.
Чтобы упростить этот процесс, мы обновили наш инструмент подбора размера Milvus, удобный калькулятор, который генерирует рекомендуемые оценки ресурсов на основе ваших конкретных требований. В этом руководстве мы покажем, как пользоваться инструментом, и предоставим более глубокое понимание факторов, влияющих на производительность Milvus.
Как использовать инструмент подбора размера Milvus
Этим инструментом подбора размера очень легко пользоваться. Просто выполните следующие шаги.
Посетите страницу инструмента подбора размера Milvus.
Введите ваши ключевые параметры:
Количество векторов и размерностей на вектор
Тип индекса
Размер данных скалярного поля
Размер сегмента
Предпочитаемый режим развертывания
Просмотрите сгенерированные рекомендации по ресурсам
инструмент подбора размера milvus
Давайте рассмотрим, как каждый из этих параметров влияет на ваше развертывание Milvus.
Выбор индекса: баланс между хранилищем, стоимостью, точностью и скоростью
Milvus предлагает различные алгоритмы индексации, включая HNSW, FLAT, IVF_FLAT, IVF_SQ8, ScaNN, DiskANN и другие, каждый из которых имеет свои компромиссы в использовании памяти, требованиях к дисковому пространству, скорости запросов и точности поиска.
Вот что вам нужно знать о наиболее распространенных вариантах:
индекс
HNSW (Hierarchical Navigable Small World)
Архитектура: Сочетает skip lists с графами Navigable Small Worlds (NSWs) в иерархической структуре
Производительность: Очень быстрые запросы с отличными показателями полноты поиска
Использование ресурсов: Требует больше всего памяти на вектор (самая высокая стоимость)
Лучше всего подходит для: Приложений, где скорость и точность критически важны, а ограничения памяти менее значимы
Техническое примечание: Поиск начинается с самого верхнего слоя с наименьшим количеством узлов и проходит вниз через всё более плотные слои
FLAT
Архитектура: Простой исчерпывающий поиск без аппроксимации
Производительность: 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, при схожих показателях recall
DiskANN: гибридный дисково/оперативный индекс, который идеально подходит, когда необходимо поддерживать большое количество векторов с высоким recall и можно принять немного большую задержку (~100 мс). Он балансирует использование памяти и производительность, удерживая в памяти только часть индекса, тогда как остальная часть остается на диске.
Индексы на основе GPU:
GPU_CAGRA: это самый быстрый из GPU-индексов, но он требует inference-карту с памятью GDDR, а не с памятью HBM
GPU_BRUTE_FORCE: исчерпывающий поиск, реализованный на GPU
GPU_IVF_FLAT: GPU-ускоренная версия IVF_FLAT
GPU_IVF_PQ: GPU-ускоренная версия IVF с Product Quantization
HNSW-PQ/SQ/PRQ:
HNSW_SQ: очень высокая скорость запросов, ограниченные ресурсы памяти; допускает незначительный компромисс в recall rate.
HNSW_PQ: средняя скорость запросов; очень ограниченные ресурсы памяти; допускает незначительный компромисс в recall rate
HNSW_PRQ: средняя скорость запросов; очень ограниченные ресурсы памяти; допускает незначительный компромисс в recall rate
AUTOINDEX: по умолчанию использует HNSW в open-source Milvus (или более производительные проприетарные индексы в Zilliz Cloud, управляемом Milvus).
Бинарные, разреженные и другие специализированные индексы: для конкретных типов данных и сценариев использования. Подробнее см. эту страницу документации по индексам.
Размер сегмента и конфигурация развертывания
Сегменты — это фундаментальные строительные блоки внутренней организации данных Milvus. Они функционируют как фрагменты данных, которые обеспечивают распределенный поиск и балансировку нагрузки в вашем развертывании. Этот инструмент расчета размеров Milvus предлагает три варианта размера сегмента (512 МБ, 1024 МБ, 2048 МБ), при этом 1024 МБ используется по умолчанию.
Понимание сегментов крайне важно для оптимизации производительности. В качестве общего ориентира:
Сегменты 512 МБ: лучше всего подходят для query nodes с 4–8 ГБ памяти
Сегменты 1 ГБ: оптимальны для query nodes с 8–16 ГБ памяти
Сегменты 2 ГБ: рекомендуются для query nodes с памятью >16 ГБ
Совет разработчика: меньшее количество более крупных сегментов обычно обеспечивает более высокую производительность поиска. Для крупномасштабных развертываний сегменты 2 ГБ часто обеспечивают лучший баланс между эффективностью памяти и скоростью запросов.
Выбор системы очереди сообщений
При выборе между Pulsar и Kafka в качестве вашей системы обмена сообщениями:
Pulsar: рекомендуется для новых проектов благодаря меньшим накладным расходам на topic и лучшей масштабируемости
Kafka: может быть предпочтительнее, если в вашей организации уже есть экспертиза или инфраструктура Kafka
Корпоративные оптимизации в Zilliz Cloud
Для production-развертываний со строгими требованиями к производительности Zilliz Cloud (полностью управляемая и корпоративная версия Milvus в облаке) предлагает дополнительные оптимизации индексирования и квантизации:
Предотвращение Out of Memory (OOM): продвинутое управление памятью для предотвращения сбоев из-за нехватки памяти
Оптимизация compaction: улучшает производительность поиска и использование ресурсов
Многоуровневое хранилище: эффективно управляйте горячими и холодными данными с помощью подходящих compute units
Стандартные compute units (CU) для часто используемых данных
CU многоуровневого хранилища для экономичного хранения редко используемых данных
Для подробных вариантов корпоративного sizing посетите документацию по тарифным планам сервиса Zilliz Cloud.
Расширенные советы по конфигурации для разработчиков
Несколько типов индексов: инструмент расчета размеров ориентирован на один индекс. Для сложных приложений, которым требуются разные алгоритмы индексации для различных коллекций, создавайте отдельные коллекции с пользовательскими конфигурациями.
Выделение памяти: При планировании развертывания учитывайте требования к памяти как для векторных данных, так и для индекса. HNSW обычно требует в 2–3 раза больше памяти, чем исходные векторные данные.
Тестирование производительности: Перед окончательным утверждением конфигурации проведите бенчмарк ваших конкретных шаблонов запросов на репрезентативном наборе данных.
Соображения масштабирования: Учитывайте будущий рост. Проще начать с немного большими ресурсами, чем перенастраивать позже.
Заключение
Инструмент расчета размеров Milvus предоставляет отличную отправную точку для планирования ресурсов, но помните, что у каждого приложения есть уникальные требования. Для оптимальной производительности вам потребуется тонко настроить конфигурацию с учетом характеристик вашей конкретной рабочей нагрузки, шаблонов запросов и потребностей масштабирования.
Мы постоянно улучшаем наши инструменты и документацию на основе отзывов пользователей. Если у вас есть вопросы или нужна дополнительная помощь с расчетом размеров вашего развертывания Milvus, обратитесь к нашему сообществу на GitHub или Discord.
Ссылки
Fendy FengFendy Feng is the Technical Marketing Writer at Zilliz. She has extensive experience developing and enhancing the impact of open-source projects in various global markets by producing high-quality, tailored content. Before joining Zilliz, Fendy worked as a Content Strategist at PingCAP, a fast-growing E-Series startup renowned for its open-source distributed SQL database.
Ken ZhangKen Zhang is a Senior Product Manager at Zilliz, leading the development of the Milvus vector database by setting its strategic direction and key features. Prior to Zilliz, he served as a kernel engineer at SAP HANA and enhanced his product management skills at PingCAP. Ken holds a master's degree from Fudan University and has over eight years of experience specializing in database development and big data infrastructure management.
Читать далее
Notion's Vector Search Is Excellent. Their Next Problem Is Harder.
Notion solved vector search scaling in two years. The next bottleneck — offline context engineering, unified data, and the real-time/offline gap — is harder.
Why Not All VectorDBs Are Agent-Ready
Explore why choosing the right vector database is critical for scaling AI agents, and why traditional solutions fall short in production.
Building RAG Pipelines for Real-Time Data with Cloudera and Milvus
explore how Cloudera can be integrated with Milvus to effectively implement some of the key functionalities of RAG pipelines.