Эталонные архитектуры 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 и многих других основных векторных баз данных
Читать далее
What Is a Vector Lakebase?
A Vector Lakebase is a unified, lake-native data architecture for AI that combines vector-database-grade serving with open lake storage, reusable lake-level indexes, and a shared semantic layer.
Zilliz Cloud Audit Logs Goes GA: Security, Compliance, and Transparency at Scale
Zilliz Cloud Audit Logs are now GA, giving enterprises real-time visibility, compliance-ready trails, and stronger security across AWS, GCP, and Azure.
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.