Обзор сервисов распространения метаданных
Сервисы распространения метаданных — это три взаимосвязанные подсистемы кластера YDB, которые доставляют служебную информацию между узлами: StateStorage, Board и SchemeBoard. Все они построены на распределённом кворумном сервисе с детерминированным размещением реплик.
Эта статья даёт обзор назначения сервисов без погружения во внутренние идентификаторы и механизмы ядра. Подробное описание для разработчиков ядра — в разделе Подсистемы распространения метаданных. Инструкции по конфигурированию — в Конфигурирование подсистем распространения метаданных.
Зачем нужны сервисы распространения метаданных
Кластер YDB — распределённая система, в которой могут одновременно работать миллионы таблеток на тысячах узлов. Компонентам кластера нужно знать:
- где работает лидер конкретной таблетки и как к нему обратиться (StateStorage);
- какие узлы предоставляют сервисы, например точки подключения для клиентов (Board);
- какова актуальная схема базы данных (SchemeBoard).
Распространять эти данные с одного узла кластера плохо — это создает высокую нагрузку и проблемы при выходе из строя этого узла. Поэтому метаданные распределяются по множеству узлов кластера с помощью трёх специализированных подсистем.
StateStorage
StateStorage хранит актуальное состояние таблеток: кто сейчас лидер, поколение и шаг выбора лидера, список реплик. По id таблетки через этот сервис можно узнать текущий id актора, что позволяет взаимодействовать с ним через акторную систему.
Примечание
Данные в StateStorage волатильны: они хранятся в памяти реплик и восстанавливаются при перезапуске. Это не долговременное хранилище.
Board
Board — сервис публикации и подписки на метаданные в формате «путь → набор записей». Основное применение — хранение эндпоинтов баз данных: узлы публикуют адреса, клиенты и другие компоненты подписываются на изменения.
SchemeBoard
SchemeBoard распространяет метаданные схемы: таблицы, индексы, топики, права доступа. Узлы баз данных используют его как кеш схемы, чтобы не обращаться к SchemeShard при каждом запросе.
Сравнение сервисов
| Характеристика | StateStorage | Board | SchemeBoard |
|---|---|---|---|
| Назначение | Состояние таблеток и лидерство | Публикация служебных метаданных | Распространение схемы |
| Тип данных | Состояние лидера таблетки | Пары путь → полезная нагрузка | Описания схемных объектов |
| Ключ | Идентификатор таблетки | Путь (строка) | Путь к объекту схемы |
| Основные потребители | Компоненты взаимодействия с таблетками | gRPC-прокси, клиенты | Узлы баз данных |
Общий принцип
Все три сервиса используют один архитектурный подход: запись адресуется по ключу, набор реплик для ключа вычисляется детерминированно, операции выполняются по кворуму. Это обеспечивает масштабируемость и отказоустойчивость при роллинг-рестартах и выходе из строя стоек.
Детали (кольца реплик, кворум, смена конфигурации, размещение по доменам отказа) описаны в статье Подсистемы распространения метаданных.
Связанные материалы
- Подсистемы распространения метаданных — подробное описание для контрибьюторов ядра.
- Конфигурирование подсистем распространения метаданных.
- Self Heal State Storage.
- Режим bridge.
- Топология кластера.
- Глоссарий.