Эталонные архитектуры Milvus
В этом блоге рассматриваются некоторые часто задаваемые вопросы о выделении ресурсов для Milvus в зависимости от конкретных сценариев использования. Эти вопросы включают:
Сколько ресурсов CPU и памяти требуется для Milvus, исходя из определенного количества пользователей или запросов в секунду (RPS)?
Сколько ресурсов CPU и памяти требуется для Milvus, исходя из разных соотношений READ и WRITE?
Понимание характеристик вашей рабочей нагрузки
Первый шаг при выделении ресурсов для Milvus — понять характеристики вашей рабочей нагрузки. Эти факторы играют ключевую роль в определении вычислительной мощности и требований к памяти Milvus.
Ниже приведен пример списка эталонных архитектур на основе пакетов Linux, где RPS означает Requests Per Second:
До 20 RPS или 1 000 пользователей API: 20 RPS, Web: 2 RPS, Git (Pull): 2 RPS, Git (Push): 1 RPS
До 40 RPS или 2 000 пользователей API: 40 RPS, Web: 4 RPS, Git (Pull): 4 RPS, Git (Push): 1 RPS
До 60 RPS или 3 000 пользователей API: 60 RPS, Web: 6 RPS, Git (Pull): 6 RPS, Git (Push): 1 RPS
До 100 RPS или 5 000 пользователей API: 100 RPS, Web: 10 RPS, Git (Pull): 10 RPS, Git (Push): 2 RPS
До 200 RPS или 10 000 пользователей API: 200 RPS, Web: 20 RPS, Git (Pull): 20 RPS, Git (Push): 4 RPS
До 500 RPS или 25 000 пользователей API: 500 RPS, Web: 50 RPS, Git (Pull): 50 RPS, Git (Push): 10 RPS
До 1000 RPS или 50 000 пользователей API: 1000 RPS, Web: 100 RPS, Git (Pull): 100 RPS, Git (Push): 20 RPS
Оценка требований к ресурсам
Чтобы оценить требования к ресурсам для Milvus, нам нужно сделать несколько предположений:
Чтения: каждый веб-запрос и Git pull является операцией READ.
Записи: каждый Git push считается операцией WRITE.
Объем и соотношение чтений/записей: предполагается, что для Milvus они такие же, как соотношение чтения/записи API-вызовов на количество пользователей.
Запросы в секунду (QPS): должны соответствовать требованию API RPS (запросов в секунду) на количество пользователей.
Нам также нужно оценить размер данных на один запрос чтения/записи. Мы предположим распространенный сценарий использования GenAI:
Размерность вектора: 1024 числа с плавающей точкой
Размер в байтах на число с плавающей точкой: 4 КБ
Top_k (количество возвращаемых векторов): 10 векторов на поисковый запрос
Размер коллекции (таблицы базы данных): 1 миллион векторов на запрос записи
Тип индекса базы данных: HNSW
На основе этих предположений мы можем выполнить примерный расчет, чтобы оценить размер данных на чтение или запись. Предположим, что размерность вектора равна 1024, и каждый вектор занимает 1024 * 4 байта = 4 КБ. Предположим типичное значение top_k = 10 векторов на чтение. При этих предположениях:
Каждая операция чтения Milvus обрабатывает около 40 КБ данных.
По оценке, каждая операция записи Milvus включает 40 МБ данных.
Milvus предлагает функциональность как insert (создать полностью новую коллекцию), так и upsert (изменить несколько строк) (подробнее см. в блоге Milvus insert, upsert, delete). Мы завысим оценку и будем считать, что каждая операция WRITE — это вставка целой коллекции, а не upsert всего нескольких строк.
Базам данных необходимо учитывать не только размер данных, но и скорость поиска и вставки. Мы будем предполагать, что коллекция индексируется с использованием популярного индекса HNSW, который имеет время поиска в нотации Big-O, O(log n).
С учетом этих предположений, вот наше преобразование веб-пользователей/RPS/чтений/записей в уровни архитектуры QPS/размера данных векторной базы данных:
До 1,000 пользователей = 20 QPS с 1 миллионом векторов
До 2,000 пользователей = 40 QPS с 1 миллионом векторов
До 3,000 пользователей = 60 QPS с 1 миллионом векторов
До 5,000 пользователей = 100 QPS с 2 миллионами векторов
До 10,000 пользователей = 200 QPS с 4 миллионами векторов
До 25,000 пользователей = 500 QPS с 10 миллионами векторов
До 50,000 пользователей = 1000 QPS с 20 миллионами векторов
Нагрузочное тестирование и бенчмаркинг
Чтобы обеспечить точность наших оценок ресурсов, мы провели нагрузочное тестирование и бенчмаркинг уровней архитектуры на VectorDBBench. Мы предполагали размеры по умолчанию для Segment, Partition, Shard, Data node, Query node и Index node самой архитектуры Milvus.
Благодаря возможностям автоскейлинга Milvus, производительность линейно зависит от размера данных и ресурсов кластера! Ниже приведена таблица с рекомендуемыми размерами ресурсов Milvus и Zilliz Cloud (полностью управляемый Milvus) для различных объемов данных и требований QPS.
В таблице ниже показана емкость данных в миллионах векторов размерности 1024. Ресурсы Milvus указаны в нескольких CPU и ГБ памяти. Для сравнения стоимости мы показываем размеры ресурсов Zilliz Cloud, указанные в Compute Units (cu), в типах performance или capacity.
Таблица рекомендуемых размеров ресурсов Milvus и Zilliz по уровням User/RPS
| Пользователи | Емкость данных | QPS benchmarked | Требуемый RPS | Ресурс Milvus | Ресурс Zilliz |
| 3,000 | 1m_1024d векторов | 1200 | 60 | 8CPU, 32G | 1cu-perf |
| 3,000 | 1m_1024d векторов | 2400 | 60 | 16CPU, 64G | 2cu-perf |
| 3,000 | 1m_1024d векторов | 3600 | 60 | 24CPU, 96G | 4cu-perf |
| 10,000 | 3.7m_1024d векторов | 360 | 200 | 16CPU, 64G | 2cu-cap |
| 10,000 | 3.7m_1024d векторов | 700 | 200 | 64CPU, 256G | 4cu-cap |
| 25,000 | 10m_1024d векторов | 600 | 500 | 196CPU, 768G | 12cu- cap |
| 250,000 | 100m_1024d векторов | 6000 | 5000 | 19200CPU, 76800G | 1200cu- cap |
Таблица рекомендуемых размеров ресурсов Milvus и Zilliz по количеству уровней Users/RPS. Масштабирование Milvus линейно относительно размера данных и требуемого QPS.
Из приведенной выше таблицы следует, что когда размер данных и QPS должны достигнуть определенного порога, запуск Milvus из Zilliz Cloud может быть более экономически эффективным, чем локально.
Заключение
Понимая характеристики вашей рабочей нагрузки, оценивая требования к ресурсам на основе предположений и используя инструменты нагрузочного тестирования и бенчмаркинга, такие как VectorDBBench, вы можете уверенно выделить необходимые ресурсы для вашего развертывания Milvus.
Обратитесь к нашему руководству по подбору размера кластера для более глубокого изучения. Помните: по мере развития вашей рабочей нагрузки важно регулярно пересматривать и корректировать распределение ресурсов, чтобы поддерживать максимальную производительность.
Ссылки
HNSW: https://github.com/nmslib/hnswlib/blob/master/ALGO_PARAMS.md
Архитектура Milvus: https://docs.gitlab.com/ee/administration/reference_architectures/
Блог Milvus Packaging Dependencies: https://zilliz.com/blog/Milvus-server-docker-installation-and-packaging-dependencies
Блог Milvus Sizing Tool: https://medium.com/@zilliz_learn/demystifying-the-milvus-sizing-tool-2c0afe7fe963
Шарды, партиции, сегменты: https://zilliz.com/blog/sharding-partitioning-segments-get-most-from-your-database
Типы CU в Zilliz Cloud: https://docs.zilliz.com/docs/cu-types-explained#evaluate-performance
Инструмент VectorDBBench для бенчмаркинга Milvus, Zilliz Cloud и многих других основных векторных баз данных
Читать далее
Why We Built Vector Lakebase: Rethinking Unstructured Data Architecture for AI
Vector Lakebase: a unified, lake-native data foundation for AI workloads — and an answer to what happens after vector databases succeed.
Vector Databases vs. Spatial Databases
Use a vector database for AI-powered similarity search; use a spatial database for geographic and geometric data analysis and querying.
Multimodal Pipelines for AI Applications
Learn how to build scalable multimodal AI pipelines using DataVolo and Milvus. Discover best practices for handling unstructured data and implementing RAG systems.