Обзор системы хранения Milvus и методов оценки и оптимизации её производительности
Добро пожаловать в наше исследование Milvus, векторной базы данных с открытым исходным кодом, известной своей впечатляющей горизонтальной масштабируемостью и молниеносной производительностью. В основе Milvus лежит надежная система хранения, критически важный фундамент для надежного сохранения данных и хранения. Эта система включает несколько ключевых компонентов: метахранилище, брокер логов и объектное хранилище.
В этом руководстве мы подробно рассмотрим архитектуру Milvus, разберем ее ключевые компоненты хранения и изучим эффективные методы оценки их производительности.
Обзор архитектуры Milvus
Milvus использует распределенную архитектуру, которая обеспечивает разделение хранения и вычислений и поддерживает горизонтальную масштабируемость вычислительных узлов. Эта схема организована в четыре ключевых уровня: уровень доступа, служба координатора, рабочие узлы и хранилище, каждый из которых масштабируется независимо и оптимизирован для аварийного восстановления.
Milvus Architecture Overview.png
Уровень доступа: Этот фронтенд-уровень состоит из прокси без состояния, которые обрабатывают пользовательские запросы и оптимизируют ответы, выступая в роли основного пользовательского интерфейса системы.
Уровень координатора: Выступая в роли центрального командного центра системы, служба координатора управляет распределением задач, топологией кластера, балансировкой нагрузки и управлением данными между рабочими узлами.
Рабочие узлы: Это исполнители, которые обрабатывают команды Data Manipulation Language (DML) под руководством службы координатора.
Хранилище: Этот уровень, являющийся основой сохранности данных, включает метахранилище, брокер логов и объектное хранилище, обеспечивая целостность и доступность данных.
Компоненты хранения Milvus
Milvus использует три основных компонента хранения для обеспечения целостности и доступности данных: метахранилище, объектное хранилище и брокер логов.
Метахранилище
Метахранилище в Milvus хранит снимки метаданных, такие как схемы коллекций, статусы узлов и контрольные точки потребления сообщений. Учитывая необходимость высокой доступности, строгой согласованности и поддержки транзакций, Milvus использует etcd в качестве решения для метахранилища. Etcd — это надежное распределенное хранилище ключ-значение, имеющее решающее значение для распределенных систем внутри Milvus. Оно выполняет такие задачи, как регистрация сервисов и проверки работоспособности, наряду с сохранением метаданных.
Объектное хранилище
Объектное хранилище в Milvus отвечает за хранение файлов снимков логов, индексных файлов для скалярных и векторных данных, а также промежуточных результатов запросов. Milvus интегрирует MinIO для объектного хранения благодаря его высокой производительности и совместимости с Kubernetes, что обеспечивает бесперебойную работу в облачных средах, таких как AWS S3 и Azure Blob Storage.
Брокер логов
Брокер логов в Milvus использует систему pub-sub с возможностями воспроизведения. Он необходим для сохранения потоковых данных, выполнения надежных асинхронных запросов, уведомлений о событиях и возврата результатов запросов. Он также обеспечивает целостность инкрементальных данных при восстановлении рабочих узлов после системных сбоев. В зависимости от развертывания, Milvus использует разные инструменты брокера логов. В установках Milvus Cluster используются Pulsar or Kafka, тогда как автономные версии Milvus обычно используют RocksDB.
Как оценивать и оптимизировать производительность хранилища Milvus
Постоянная оценка и улучшение производительности хранилища имеют решающее значение.
Etcd: хранилище метаданных Milvus
Etcd — это надежное распределенное хранилище ключ-значение, разработанное для распределенных систем. В Milvus etcd является хранилищем метаданных, которое хранит важные данные, такие как схемы коллекций, статусы узлов и контрольные точки потребления сообщений.
Задержка записи на диск критически важна для производительности etcd; низкая скорость диска может значительно увеличить задержку запросов и поставить под угрозу стабильность системы. Мы рекомендуем поддерживать не менее 500 последовательных IOPS (операций ввода-вывода в секунду) для оптимальной производительности в производственных средах, обеспечивая, чтобы 99% длительностей fdatasync оставались ниже десяти миллисекунд. Хотя etcd обычно требует лишь умеренной пропускной способности диска, увеличение этой пропускной способности может заметно сократить время восстановления. Поэтому мы рекомендуем базовую пропускную способность диска не менее 100MB/s для производственных сред.
Чтобы проверить, соответствует ли ваше хранилище этим критериям, рассмотрите возможность проведения оценки производительности с помощью Fio, инструмента для тестирования дисков. Ниже приведено руководство по использованию Fio для оценки производительности вашего хранилища.
Сначала убедитесь, что Fio установлен в вашей системе. Затем выполните следующую команду, указав каталог, в который смонтировано ваше хранилище, в качестве каталога test-data. Этот каталог должен находиться под точкой подключения вашего хранилища.
fio --rw=write --ioengine=sync --fdatasync=1 --directory=test-data --size=22m --bs=2300 --name=mytest
Проверьте результаты, чтобы убедиться, что 99% длительности fdatasync составляет менее 10ms, а IOPS записи превышает 500. Если эти условия выполнены, производительность вашего хранилища достаточна.
Ниже приведен пример выходных результатов:
Jobs: 1 (f=1): [W(1)][100.0%][w=1771KiB/s][w=788 IOPS][eta 00m:00s]
mytest: (groupid=0, jobs=1): err= 0: pid=703: Mon Jul 25 08:36:48 2022
write: IOPS=967, BW=2173KiB/s (2225kB/s)(220MiB/103664msec); 0 zone resets
clat (nsec): min=1903, max=29662k, avg=287307.76, stdev=492386.04
lat (nsec): min=1981, max=29662k, avg=287583.67, stdev=492438.10
clat percentiles (usec):
| 1.00th=[ 3], 5.00th=[ 4], 10.00th=[ 4], 20.00th=[ 5],
| 30.00th=[ 6], 40.00th=[ 9], 50.00th=[ 233], 60.00th=[ 343],
| 70.00th=[ 437], 80.00th=[ 553], 90.00th=[ 701], 95.00th=[ 742],
| 99.00th=[ 1172], 99.50th=[ 2114], 99.90th=[ 6390], 99.95th=[ 8455],
| 99.99th=[15533]
bw ( KiB/s): min= 1630, max= 2484, per=100.00%, avg=2174.66, stdev=193.65, samples=207
iops : min= 726, max= 1106, avg=968.37, stdev=86.19, samples=207
lat (usec) : 2=0.03%, 4=16.49%, 10=27.68%, 20=3.21%, 50=0.71%
lat (usec) : 100=0.27%, 250=2.65%, 500=24.64%, 750=20.40%, 1000=2.57%
lat (msec) : 2=0.82%, 4=0.30%, 10=0.18%, 20=0.03%, 50=0.01%
fsync/fdatasync/sync_file_range:
sync (usec): min=309, max=21848, avg=741.93, stdev=489.64
sync percentiles (usec):
| 1.00th=[ 392], 5.00th=[ 437], 10.00th=[ 474], 20.00th=[ 529],
| 30.00th=[ 578], 40.00th=[ 619], 50.00th=[ 660], 60.00th=[ 709],
| 70.00th=[ 742], 80.00th=[ 791], 90.00th=[ 988], 95.00th=[ 1369],
| 99.00th=[ 2442], 99.50th=[ 3523], 99.90th=[ 6915], 99.95th=[ 8586],
| 99.99th=[11994]
При развертывании кластера Milvus в облачных средах выбор подходящего типа блочного хранилища для etcd имеет решающее значение из-за его чувствительности к производительности диска. Облачные провайдеры предлагают различные варианты блочного хранилища, каждый из которых имеет отличительные характеристики производительности, подходящие для разных рабочих нагрузок.
Ниже приведены рекомендуемые типы томов и показатели производительности от различных облачных провайдеров.
| Облачный провайдер | Тип тома | SIZE | IOPS | P99 sync |
| AWS | gp3 | 20Gi | 660 | 4.3ms |
| GCP | pd-ssd | 20Gi | 1262 | 1.3ms |
| Azure | PremiumV2 | 20Gi | 705 | 2.6ms |
| Aliyun | cloud_essd | 20Gi | 1137 | 3.5ms |
Вы также можете использовать Fio, чтобы подтвердить, что выбранное блочное хранилище соответствует эталонным показателям производительности, необходимым для оптимальной работы etcd в вашем развертывании Milvus.
MinIO: инструмент объектного хранилища Milvus
MinIO — это высокопроизводительное, нативное для Kubernetes решение объектного хранилища, оптимизированное для облачно-нативных рабочих нагрузок. Milvus использует MinIO для хранения файлов моментальных снимков логов, файлов индексов как для скалярных, так и для векторных данных, а также промежуточных результатов запросов.
Производительность объектного хранилища, такого как MinIO, в первую очередь оценивается по пропускной способности ввода-вывода, а не по IOPS. Эта метрика существенно влияет на различные операции в Milvus, такие как загрузка коллекций, построение индексов и вставка данных. На пропускную способность MinIO влияет множество факторов, включая пропускную способность сети, настройку производительности ядра Linux и производительность отдельных дисковых накопителей. Производительность дисков особенно важна.
Мы можем использовать команду dd для измерения производительности одного накопителя. DD — это Unix-инструмент, который копирует данные из одного файла в другой побитово. Он предоставляет различные параметры для управления размером блока при каждом чтении и записи.
В приведенном ниже примере при тестировании одного NVMe-накопителя с размером блока 16MB параметр O_DIRECT для 64 итераций обеспечивает производительность записи более 2GB в секунду на накопитель.
$ dd if=/dev/zero of=/mnt/drive/test bs=16M count=64 oflag=direct
64+0 records in
64+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 0.443096 s, 2.4 GB/s
В том же примере при тестировании одного NVMe-накопителя с размером блока 16MB параметр O_DIRECT для 64 итераций обеспечивает производительность чтения более 5GB в секунду на накопитель.
$ dd of=/dev/null if=/mnt/drive/test bs=16M count=64 iflag=direct
64+0 records in
64+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 0.187263 s, 5.7 GB/s
Чем выше производительность чтения и записи вашего дискового накопителя, тем лучше общая пропускная способность MinIO. Для оптимальных результатов мы рекомендуем использовать SSD- или NVMe-накопители в качестве дисков хранения в настройке MinIO. Эти накопители могут эффективно поддерживать требования высокой пропускной способности для операций MinIO. Избегайте использования устройств SAN/NAS для хранилища MinIO. Такие конфигурации часто приводят к проблемам с параллелизмом и узким местам производительности, которые могут снижать эффективность и отзывчивость системы.
Pulsar/Kafka: инструменты брокера логов Milvus
Как упоминалось выше, Milvus использует разные инструменты брокера логов, адаптированные к конкретным режимам развертывания. Кластерные установки Milvus используют Pulsar или Kafka, тогда как автономные версии Milvus обычно используют RocksDB.
И Pulsar, и Kafka спроектированы для поддержки постоянного хранения сообщений и обеспечения высокой пропускной способности для потребителей сообщений. Их производительность критически зависит от типа используемого дискового хранилища, поскольку они опираются на последовательные операции дискового ввода-вывода.
Для Pulsar высокопроизводительные диски необходимы для journal-файлов BookKeeper, чтобы обеспечить целостность и долговечность данных; SSD с низкой задержкой особенно полезны для этой цели. И Pulsar Ledgers, и Kafka оптимизированы для эффективного использования диска, задействуют кэш файловой системы и хорошо работают с HDD и SSD. Однако для приложений, чувствительных к задержкам, или крупномасштабных развертываний SSD обеспечивают значительные преимущества в производительности.
Для оптимизации производительности используйте несколько дисковых устройств для Pulsar и Kafka. В частности, для Pulsar использование отдельных дисков для журнала и общего хранилища позволяет bookies изолировать задержку операций записи от операций чтения. Чтобы обеспечить оптимальную задержку, не используйте одни и те же накопители для хранения данных, логов приложений или другой активности файловой системы ОС. Эти накопители можно настроить как единый том с помощью RAID, либо каждый накопитель можно отформатировать и смонтировать как отдельный каталог. Сетевое хранилище (NAS) следует избегать из-за его более низкой производительности, более высоких и более изменчивых задержек, а также потенциальной роли единой точки отказа.
Резюме
Наше углубленное исследование системы хранения Milvus дает всестороннее представление о ее архитектуре и компонентах, подчеркивая их роли в поддержке крупномасштабного управления данными и анализа. Мы подробно рассмотрели три основных компонента хранения Milvus — метахранилище, объектное хранилище и брокер журналов — и предложили стратегии для оценки и повышения их производительности.
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.
Jay ZhuJay Zhu is the Senior Software Engineer and tech leader of the DevOps & Infrastructure team at Zilliz. He specializes in DevOps, cloud-native technologies, and Kubernetes projects. Additionally, Jay is actively involved in developing and maintaining various open-source projects, including Milvus, Milvus-helm, and Milvus-operator.
Читать далее
Announcing the General Availability of Single Sign-On (SSO) on Zilliz Cloud
SSO is GA on Zilliz Cloud, delivering the enterprise-grade identity management capabilities your teams need to deploy vectorDB with confidence.
Democratizing AI: Making Vector Search Powerful and Affordable
Zilliz democratizes AI vector search with Milvus 2.6 and Zilliz Cloud for powerful, affordable scalability, cutting costs in infrastructure, operations, and development.
How to Build RAG with Milvus, QwQ-32B and Ollama
Hands-on tutorial on how to create a streamlined, powerful RAG pipeline that balances efficiency, accuracy, and scalability using the QwQ-32B and Milvus.