Дезагрегация систем хранения данных и вычислений

Следуя принципу дезагрегации плоскости данных и плоскости управления, Milvus состоит из четырех уровней, которые являются взаимно независимыми с точки зрения масштабируемости и аварийного восстановления.

Уровень доступа

Состоящий из группы прокси-серверов без статического управления, уровень доступа является передним уровнем системы и конечной точкой для пользователей. Он проверяет запросы клиентов и сокращает возвращаемые результаты:

• Прокси сам по себе не имеет статусов. Он обеспечивает единый адрес сервиса, используя компоненты балансировки нагрузки, такие как Nginx, Kubernetes Ingress, NodePort и LVS.
• Поскольку в Milvus используется архитектура массивно-параллельной обработки (MPP), прокси агрегирует и обрабатывает промежуточные результаты, прежде чем вернуть клиенту окончательные результаты.

Координатор

Координатор служит мозгом Milvus. В любой момент времени во всем кластере активен ровно один координатор, который отвечает за поддержание топологии кластера, планирование всех типов задач и обеспечение согласованности на уровне кластера.

Ниже перечислены некоторые задачи, решаемые координатором:

• Управление DDL/DCL/TSO: Обрабатывает запросы языка определения данных (DDL) и языка управления данными (DCL), такие как создание или удаление коллекций, разделов или индексов, а также управление временными метками Oracle (TSO) и выдачей временных тикеров.
• Управление потоковыми службами: Связывает журнал Write-Ahead Log (WAL) с потоковыми узлами и обеспечивает обнаружение сервисов для потоковой службы.
• Управление запросами: Управляет топологией и балансировкой нагрузки для узлов запросов, а также предоставляет и управляет представлениями запросов для маршрутизации запросов.
• Управление историческими данными: Распределяет автономные задачи, такие как уплотнение и построение индексов, между узлами данных, а также управляет топологией сегментов и представлений данных.

Рабочие узлы

Руки и ноги. Рабочие узлы - это немые исполнители, выполняющие указания координатора. Рабочие узлы не имеют статусов благодаря разделению хранения и вычислений и могут способствовать масштабированию системы и аварийному восстановлению при развертывании на Kubernetes. Существует три типа рабочих узлов:

Потоковый узел

Потоковый узел служит в качестве "мини-мозга" на уровне кристалла, обеспечивая гарантии согласованности на уровне кристалла и восстановление после сбоев на основе базового хранилища WAL. При этом узел потоковой обработки также отвечает за запросы к растущим данным и генерирует планы запросов. Кроме того, он также занимается преобразованием растущих данных в закрытые (исторические) данные.

Узел запросов

Узел запросов загружает исторические данные из объектного хранилища и обеспечивает запрос исторических данных.

Узел данных

Узел данных отвечает за автономную обработку исторических данных, такую как уплотнение и построение индексов.

Хранилище

Хранилище - это костяк системы, отвечающий за сохранность данных. Оно включает в себя метахранилище, брокер журналов и объектное хранилище.

Метахранилище

Метахранилище хранит снимки метаданных, таких как схема коллекции и контрольные точки потребления сообщений. Хранение метаданных требует чрезвычайно высокой доступности, высокой согласованности и поддержки транзакций, поэтому Milvus выбрал etcd для метахранилища. Milvus также использует etcd для регистрации и проверки работоспособности сервисов.

Объектное хранилище

В объектном хранилище хранятся файлы моментальных снимков журналов, индексные файлы для скалярных и векторных данных, а также промежуточные результаты запросов. Milvus использует MinIO в качестве объектного хранилища и может быть легко развернут на AWS S3 и Azure Blob, двух самых популярных и экономически эффективных сервисах хранения данных в мире. Однако объектное хранилище имеет высокую задержку доступа и тарифицируется по количеству запросов. Чтобы повысить производительность и снизить затраты, Milvus планирует реализовать разделение данных "холодный-горячий" в пуле кэша на базе памяти или SSD.

Хранилище WAL

Хранение журнала с опережающей записью (WAL) - основа долговечности и согласованности данных в распределенных системах. Перед фиксацией любого изменения оно сначала записывается в журнал, что гарантирует, что в случае сбоя вы сможете восстановить именно то, на чем остановились.

К распространенным реализациям WAL относятся Kafka, Pulsar и Woodpecker. В отличие от традиционных дисковых решений, Woodpecker использует "облачный" дизайн с нулевым диском, который записывает данные непосредственно в объектное хранилище. Такой подход легко масштабируется в зависимости от ваших потребностей и упрощает работу, устраняя накладные расходы на управление локальными дисками.

Заранее регистрируя каждую операцию записи, уровень WAL гарантирует надежный общесистемный механизм восстановления и согласованности - независимо от того, насколько сложной становится ваша распределенная среда.

Что дальше

• Подробнее об архитектуре Milvus читайте в разделе Основные компоненты.