Обзор архитектуры Milvus
Milvus - это облачная векторная база данных с открытым исходным кодом, предназначенная для высокопроизводительного поиска сходства в массивных векторных массивах данных. Построенная на базе популярных библиотек векторного поиска, таких как Faiss, HNSW, DiskANN и SCANN, она позволяет использовать приложения искусственного интеллекта и сценарии поиска неструктурированных данных. Прежде чем продолжить, ознакомьтесь с основными принципами поиска по вкраплениям.
Диаграмма архитектуры
Следующая диаграмма иллюстрирует высокоуровневую архитектуру Milvus, демонстрируя ее модульную, масштабируемую и облачную конструкцию с полностью дезагрегированными слоями хранения и вычислений.
Архитектура_диаграммы
Архитектурные принципы
Milvus следует принципу дезагрегации плоскости данных и плоскости управления, состоящему из четырех основных уровней, которые являются взаимно независимыми с точки зрения масштабируемости и аварийного восстановления. Эта архитектура с общим хранилищем и полностью дезагрегированными уровнями хранения и вычислений позволяет горизонтально масштабировать вычислительные узлы, а также реализовать Woodpecker в качестве WAL-уровня с нулевым диском для повышения эластичности и снижения эксплуатационных накладных расходов.
Благодаря разделению потоковой обработки на Streaming Node и пакетной обработки на Query Node и Data Node, Milvus достигает высокой производительности при одновременном удовлетворении требований к обработке данных в реальном времени.
Детальная архитектура уровней
Уровень 1: уровень доступа
Состоящий из группы нестационарных прокси-серверов, уровень доступа является передним уровнем системы и конечной точкой для пользователей. Он проверяет запросы клиентов и сокращает возвращаемые результаты:
- Прокси сам по себе не имеет статусов. Он обеспечивает единый адрес сервиса, используя компоненты балансировки нагрузки, такие как Nginx, Kubernetes Ingress, NodePort и LVS.
- Поскольку в Milvus используется архитектура массивно-параллельной обработки (MPP), прокси агрегирует и обрабатывает промежуточные результаты, прежде чем вернуть клиенту окончательные результаты.
Уровень 2: Координатор
Координатор служит мозгом Milvus. В любой момент времени во всем кластере активен ровно один координатор, который отвечает за поддержание топологии кластера, планирование всех типов задач и обеспечение согласованности на уровне кластера.
Ниже перечислены некоторые задачи, решаемые координатором:
- Управление DDL/DCL/TSO: Обрабатывает запросы языка определения данных (DDL) и языка управления данными (DCL), такие как создание или удаление коллекций, разделов или индексов, а также управление временными метками Oracle (TSO) и выдачей временных тикеров.
- Управление потоковыми службами: Связывает журнал Write-Ahead Log (WAL) с потоковыми узлами и обеспечивает обнаружение сервисов для потоковой службы.
- Управление запросами: Управляет топологией и балансировкой нагрузки для узлов запросов, а также предоставляет и управляет представлениями запросов для маршрутизации запросов.
- Управление историческими данными: Распределяет автономные задачи, такие как уплотнение и создание индексов, между узлами данных, а также управляет топологией сегментов и представлений данных.
Уровень 3: рабочие узлы
Руки и ноги. Рабочие узлы - это немые исполнители, которые выполняют указания координатора. Рабочие узлы не имеют статических данных благодаря разделению хранения и вычислений и могут способствовать масштабированию системы и аварийному восстановлению при развертывании на Kubernetes. Существует три типа рабочих узлов:
Потоковый узел
Потоковый узел служит "мини-мозгом" на уровне сервера, обеспечивая гарантии согласованности на уровне сервера и восстановление после сбоев на основе базового хранилища WAL. Кроме того, Streaming Node отвечает за запросы к растущим данным и генерирует планы запросов. Кроме того, он также занимается преобразованием растущих данных в закрытые (исторические) данные.
Узел запросов
Узел запросов загружает исторические данные из объектного хранилища и обеспечивает запрос исторических данных.
Узел данных
Узел данных отвечает за автономную обработку исторических данных, такую как уплотнение и построение индексов.
Уровень 4: Хранилище
Хранилище - это костяк системы, отвечающий за сохранение данных. Оно включает в себя метахранилище, брокер журналов и хранилище объектов.
Метахранилище
Метахранилище хранит снимки метаданных, таких как схема коллекции и контрольные точки потребления сообщений. Хранение метаданных требует чрезвычайно высокой доступности, высокой согласованности и поддержки транзакций, поэтому Milvus выбрал etcd для метахранилища. Milvus также использует etcd для регистрации и проверки работоспособности сервисов.
Объектное хранилище
В объектном хранилище хранятся файлы моментальных снимков журналов, индексные файлы для скалярных и векторных данных, а также промежуточные результаты запросов. Milvus использует MinIO в качестве объектного хранилища и может быть легко развернут на AWS S3 и Azure Blob, двух самых популярных и экономически эффективных сервисах хранения данных в мире. Однако объектное хранилище имеет высокую задержку доступа и тарифицируется по количеству запросов. Чтобы повысить производительность и снизить затраты, Milvus планирует реализовать разделение данных "холодный-горячий" в пуле кэша на базе памяти или SSD.
Хранилище WAL
Хранение журнала с опережающей записью (WAL) - основа долговечности и согласованности данных в распределенных системах. Перед фиксацией любого изменения оно сначала записывается в журнал, что гарантирует, что в случае сбоя вы сможете восстановить именно то, на чем остановились.
К распространенным реализациям WAL относятся Kafka, Pulsar и Woodpecker. В отличие от традиционных дисковых решений, Woodpecker использует "облачный" дизайн с нулевым диском, который записывает данные непосредственно в объектное хранилище. Такой подход легко масштабируется в зависимости от ваших потребностей и упрощает работу, устраняя накладные расходы на управление локальными дисками.
Заранее регистрируя каждую операцию записи, уровень WAL гарантирует надежный общесистемный механизм восстановления и согласованности - независимо от того, насколько сложной становится ваша распределенная среда.
Поток данных и категории API
API Milvus классифицируются по функциям и следуют определенным путям в архитектуре:
| Категория API | Операции | Примеры API | Архитектурный поток |
|---|---|---|---|
| DDL/DCL | Схема и контроль доступа | createCollection, dropCollection, hasCollection, createPartition | Уровень доступа → Координатор |
| DML | Манипулирование данными | insert, delete, upsert | Уровень доступа → Потоковый рабочий узел |
| DQL | Запрос данных | search, query | Уровень доступа → пакетный рабочий узел (узлы запросов) |
Пример потока данных: операция поиска
- Клиент отправляет запрос на поиск через SDK/RESTful API
- Балансировщик нагрузки направляет запрос к доступному прокси на уровне доступа
- Прокси использует кэш маршрутизации для определения целевых узлов; обращается к координатору, только если кэш недоступен
- Прокси направляет запрос на соответствующие узлы потоковой передачи, которые затем координируются с узлами запросов для поиска запечатанных данных, выполняя поиск растущих данных локально
- Узлы запросов загружают запечатанные сегменты из хранилища объектов по мере необходимости и выполняют поиск на уровне сегментов
- Результаты поиска подвергаются многоуровневой редукции: узлы запросов сокращают результаты по нескольким сегментам, узлы потоковой передачи сокращают результаты от узлов запросов, а прокси сокращает результаты от всех узлов потоковой передачи перед возвращением клиенту
Пример потока данных: вставка данных
- Клиент отправляет запрос на вставку с векторными данными
- Уровень доступа проверяет и пересылает запрос на узел потоковой обработки
- Потоковый узел регистрирует операцию в хранилище WAL для долговечности
- Данные обрабатываются в реальном времени и становятся доступными для запросов
- Когда сегменты достигают емкости, потоковый узел запускает преобразование в закрытые сегменты
- Узел данных обрабатывает уплотнение и строит индексы поверх закрытых сегментов, сохраняя результаты в хранилище объектов.
- Узлы запросов загружают вновь созданные индексы и заменяют соответствующие растущие данные
Что дальше
- Изучите основные компоненты для получения подробной информации о реализации
- Узнайте о рабочих процессах обработки данных и стратегиях оптимизации
- Поймите модель согласованности и гарантии транзакций в Milvus