Потоковый сервис
Streaming Service - это концепция внутреннего модуля системы потоковой передачи данных Milvus, построенного на основе журнала записи вперед (WAL) для поддержки различных функций, связанных с потоковой передачей данных. К ним относятся вход/подписка потоковых данных, восстановление состояния кластера после сбоев, преобразование потоковых данных в исторические и запросы к растущим данным. Архитектурно служба потоковой передачи данных состоит из трех основных компонентов:
Распределенная потоковая дуга
Координатор потоковой передачи: Логический компонент в узле координатора. Он использует Etcd для обнаружения сервисов, чтобы найти доступные потоковые узлы, и отвечает за привязку WAL к соответствующим потоковым узлам. Он также регистрирует сервис для отображения топологии распределения WAL, позволяя клиентам потоковой передачи узнать соответствующий узел потоковой передачи для данного WAL.
Кластер потоковых узлов: Кластер рабочих узлов потоковой обработки, отвечающих за все задачи потоковой обработки, такие как добавление WAL, восстановление состояния и запрос растущих данных.
Потоковый клиент: Внутренне разработанный клиент Milvus, который инкапсулирует основные функции, такие как обнаружение сервисов и проверка готовности. Он используется для инициирования таких операций, как запись сообщений и подписка.
Сообщение
Потоковый сервис - это потоковая система, управляемая журналом, поэтому все операции записи в Milvus (такие как DML и DDL) абстрагируются как сообщения.
Каждое сообщение получает поле Timestamp Oracle (TSO) от Streaming Service, которое указывает порядок сообщения в WAL. Порядок сообщений определяет порядок операций записи в Milvus. Это позволяет восстановить последнее состояние кластера из журналов.
Каждое сообщение принадлежит определенному VChannel (виртуальному каналу) и поддерживает определенные инвариантные свойства в рамках этого канала для обеспечения согласованности операций. Например, операция Insert всегда должна происходить перед операцией DropCollection на том же канале.
Порядок сообщений в Milvus может выглядеть следующим образом:
Порядок сообщений
Компонент WAL
Для поддержки крупномасштабной горизонтальной масштабируемости WAL в Milvus представляет собой не один файл журнала, а композит из нескольких журналов. Каждый журнал может независимо поддерживать потоковую функциональность для нескольких VChannels. В любой момент времени компоненту WAL разрешено работать ровно на одном потоковом узле, причем это ограничение обеспечивается как механизмом ограждения базового хранилища wal, так и координатором потоковой передачи.
Дополнительные возможности компонента WAL включают:
Управление жизненным циклом сегмента: Основываясь на политике, такой как состояние памяти/размер сегмента/время простоя сегмента, WAL управляет жизненным циклом каждого сегмента.
Поддержка базовых транзакций: Поскольку каждое сообщение имеет ограничение по размеру, компонент WAL поддерживает простой уровень транзакций для обеспечения атомарной записи на уровне VChannel.
Высококонкурентная удаленная запись в журнал: Milvus поддерживает удаленные очереди сообщений сторонних производителей в качестве хранилища WAL. Для уменьшения задержки в пути (RTT) между узлом потоковой передачи и удаленным хранилищем WAL, чтобы повысить пропускную способность записи, служба потоковой передачи поддерживает одновременную запись в журнал. Он поддерживает порядок сообщений с помощью синхронизации TSO и TSO, и сообщения в WAL считываются в порядке TSO.
Буфер опережения записи: После записи сообщений в WAL они временно сохраняются в буфере опережения записи. Это позволяет выполнять хвостовое чтение журналов без извлечения сообщений из удаленного хранилища WAL.
Поддержка нескольких хранилищ WAL: Woodpecker, Pulsar, Kafka. При использовании Woodpecker в режиме нулевого диска мы можем устранить зависимость от удаленного хранилища WAL.
Recovery Storage
Компонент Recovery Storage всегда запускается на узле потоковой передачи, на котором расположен соответствующий компонент WAL.
Он отвечает за преобразование потоковых данных в персистентные исторические данные и их хранение в объектном хранилище.
Он также обрабатывает восстановление состояния in-memory для компонента WAL на потоковом узле.
Хранилище восстановления
Делегатор запросов
Делегатор запросов работает на каждом потоковом узле и отвечает за выполнение инкрементных запросов на одном шарде. Он генерирует планы запросов, направляет их на соответствующие узлы запросов и агрегирует результаты.
Кроме того, Query Delegator отвечает за трансляцию операций Delete другим Query Nodes.
Делегатор запросов всегда сосуществует с компонентом WAL на одном потоковом узле. Но если коллекция настроена на мультирепликацию, то на других потоковых узлах будет развернуто N-1 делегаторов.
Время жизни WAL и ожидание готовности
Отделяя вычислительные узлы от хранилища, Milvus может легко передавать WAL с одного потокового узла на другой, добиваясь высокой доступности потокового сервиса.
время жизни WAL
Ожидание готовности
Когда WAL будет перемещаться на новый потоковый узел, клиент обнаружит, что старый потоковый узел отклоняет некоторые запросы. Тем временем WAL будет восстановлен на новом потоковом узле, и клиент будет ждать, пока Wal на новом потоковом узле будет готов к обслуживанию.
ждать готовности