Глоссарий YDB

Эта статья представляет собой обзор терминов и определений, используемых в YDB и её документации. Он начинается с ключевых терминов, с которыми полезно ознакомиться на раннем этапе работы с YDB, а остальная часть статьи содержит более продвинутые термины, которые могут быть полезны в дальнейшем.

Ключевая терминология

Этот раздел описывает термины, которые полезны любому человеку, работающему с YDB, независимо от его роли и сценария использования.

Кластер

Кластер или cluster YDB представляет собой набор взаимосвязанных узлов YDB, которые обмениваются данными для выполнения пользовательских запросов и надёжного хранения данных. Эти узлы формируют одну из поддерживаемых топологий кластера, что напрямую влияет на его характеристики надёжности и производительности.

Кластеры YDB являются мультитенантными (многопользовательскими) и могут содержать несколько изолированных баз данных.

База данных

Как и в большинстве систем управления базами данных, база данных в YDB представляет собой логический контейнер для других сущностей, таких как таблицы. Однако в YDB пространство имён внутри баз данных иерархическое, как в виртуальных файловых системах, и таким образом директории позволяют более структурированно организовывать сущности.

Ещё одной важной характеристикой баз данных YDB является то, что им обычно выделяются отдельные вычислительные ресурсы. Как следствие, создание дополнительной базы данных обычно выполняется снаружи системы инженерами DevOps или автоматизацией, а не через SQL-запрос.

Узел

YDB узел или node — это серверный процесс, выполняющий исполняемый файл под названием ydbd. На одном физическом сервере или виртуальной машине могут работать несколько узлов YDB, что является обычной практикой. Таким образом, в контексте YDB узлы не являются синонимами хостов.

Так как YDB использует подход раздельных слоёв хранения и вычислений (storage and compute separation), ydbd имеет несколько режимов работы, определяющих тип узла. Доступные типы узлов описаны ниже.

Узел базы данных

Узлы базы данных (также известные как тенантные узлы, узлы вычислений, database nodes, tenant nodes или compute nodes) обрабатывают пользовательские запросы, адресованные конкретной логической базе данных. Их состояние находится только в оперативной памяти и может быть восстановлено из распределённого хранилища. Совокупность узлов баз данных заданного кластера YDB можно считать вычислительным слоем этого кластера. Таким образом, добавление узлов баз данных и выделение им дополнительных ресурсов (CPU и RAM) — это основные способы увеличения вычислительных ресурсов базы данных.

Основная роль узлов базы данных — запуск различных таблеток и акторов, а также приём входящих запросов по сети.

Узел хранения

Узлы хранения или storage nodes являются узлами с состоянием, отвечающими за долгосрочное хранение фрагментов данных. Совокупность узлов хранения заданного кластера YDB называются распределённым хранилищем и могут рассматриваться как слой хранения этого кластера. Таким образом, добавление дополнительных узлов хранения и их дисков — это основные способы увеличения ёмкости хранилища и пропускной способности ввода/вывода кластера.

Гибридный узел

Гибридный узел — это процесс, который одновременно выполняет обе роли узла базы данных и узла хранения. Гибридные узлы часто используются в целях разработки. Например, вы можете запустить контейнер с полнофункциональным YDB, содержащим только один процесс ydbd в гибридном режиме. В производственных окружениях они используются редко.

Статический узел

Статические узлы или static nodes конфигурируются вручную во время первоначальной инициализации или перенастройки кластера. Как правило, они выполняют роль узлов хранения, но технически возможно настроить их и в качестве узлов баз данных.

Динамический узел

Динамические узлы или dynamic nodes добавляются и удаляются из кластера на ходу. Они могут выполнять только роль узлов базы данных.

Распределённое хранилище

Распределённое хранилище, Distributed storage, Blob storage или BlobStorage — это распределённый отказоустойчивый слой хранения данных в YDB. Оно имеет специализированный API, предназначенный для хранения неизменяемых фрагментов данных таблетки.

Множество терминов, связанных с реализацией распределённого хранилища, рассматриваются ниже.

Группа хранения

Группа хранения, группа распределённого хранилища, storage group или группа Blob storage — это место для надёжного хранения данных, аналогичное RAID, но использующее диски нескольких серверов. В зависимости от выбранной топологии кластера группы хранения используют различные алгоритмы для обеспечения высокой доступности, аналогично стандартным уровням RAID.

Распределённое хранилище обычно управляет большим количеством относительно небольших групп хранения. Каждую группу можно назначить конкретной базе данных для увеличения ёмкости дискового пространства и пропускной способности ввода/вывода, доступных для этой базы данных.

Статическая группа

Статическая группа или static group — это специальная группа хранения, созданная во время изначального развёртывания кластера. Её основная роль заключается в хранении данных системных таблеток, которые можно рассматривать как метаданные уровня всего кластера.

Статическая группа может требовать особого внимания во время крупного обслуживания кластера, такого как вывод зоны доступности из эксплуатации.

Динамическая группа

Обычные группы хранения, которые не являются статическими, называются динамическими группами или dynamic group. Их называют динамическими, потому что они могут быть созданы и удалены на лету во время работы кластера.

Пул хранения

Пул хранения или storage pool — это набор устройств хранения данных со схожими характеристиками. Каждому пулу хранения присваивается уникальное имя в рамках кластера YDB. Технически, каждый пул хранения состоит из множества физических дисков (PDisk). Каждая группа хранения создаётся в определённом пуле хранения, который определяет характеристики производительности группы хранения через выбор соответствующих устройств хранения. Обычно отдельные пулы хранения создают для устройств разных типов (например, NVMe, SSD и HDD) или для конкретных моделей этих устройств, обладающих различной ёмкостью и скоростью доступа.

Актор

Модель акторов — это один из основных подходов к параллелизму выполнения, используемый в YDB. В этой модели акторы или actor — это легковесные процессы в пользовательском пространстве, которые могут иметь и изменять своё частное состояние, но могут влиять друг на друга только косвенно через обмен сообщениями. YDB имеет собственную реализацию этой модели, которая описана ниже.

В YDB акторы с надёжно сохраняемым состоянием называются таблетками.

Таблетка

Таблетка — это один из основных строительных блоков и абстракций YDB. Она представляет собой сущность, ответственную за относительно небольшой сегмент пользовательских или системных данных. Обычно таблетка управляет объёмом данных до нескольких гигабайт, однако некоторые типы таблеток могут обрабатывать и больший объём.

Например, строковая пользовательская таблица управляется одной или несколькими таблетками типа DataShard, причём каждая таблетка отвечает за непрерывный диапазон первичных ключей и соответствующих им данных.

Конечным пользователям, отправляющим запросы в кластер YDB для выполнения, не нужно знать подробностей о таблетках, их видах или принципах работы, но это может быть полезно, например, для оптимизации производительности.

Технически таблетки являются акторами с состоянием, надёжно сохранённым в распределённом хранилище. Это состояние позволяет таблетке продолжать работу на другом узле базы данных, если предыдущий вышел из строя или перегружен.

Подробности реализации таблеток и связанные термины, а также основные типы таблеток, рассматриваются ниже.

Распределённые транзакции

YDB реализует транзакции (transactions) на двух основных уровнях:

Эти механизмы позволяют YDB обеспечивать строгую согласованность.

Многоверсионное управление параллелизмом

Многоверсионное управление параллелизмом, multi-version concurrency control или MVCC — это метод, используемый YDB для одновременного доступа нескольких параллельных транзакций к базе данных без взаимных помех. Он описан более подробно в отдельной статье Многоверсионное управление конкурентным доступом (MVCC).

Топология

YDB поддерживает несколько топологий кластера (или topology), описанных более подробно в отдельной статье Топология кластера YDB. Ниже объяснены несколько связанных терминов.

Зоны доступности и регионы

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

Регион — это большая географическая область, содержащая несколько зон доступности. Расстояние между зонами доступности в одном регионе должно составлять около 500 км или менее. YDB выполняет записи данных в каждую зону доступности в регионе синхронно, обеспечивая разумную задержку и бесперебойную работу в случае отказа одной из зон доступности.

Стойка

Стойка, серверная стойка, rack или server rack — это оборудование, используемое для организации размещения нескольких серверов. Серверы в одной стойке с большей вероятностью могут стать недоступными одновременно из-за проблем на уровне стойки, связанных с электропитанием, охлаждением и т. д. YDB может учитывать информацию о том, какой сервер находится в какой стойке, при размещении каждого фрагмента данных в средах, основанных на физических серверах.

Таблица

Таблица или table — это структурированный фрагмент информации, организованный в строки и колонки. Каждая строка представляет собой одну запись или элемент, а каждая колонка — это конкретный атрибут или поле с определённым типом данных.

Существуют два основных подхода к представлению табличных данных в оперативной памяти или на дисках: строковый (строка за строкой) и колоночный (колонка за колонкой). Выбранный подход сильно влияет на характеристики производительности операций с этими данными: первый больше подходит для транзакционных нагрузок (OLTP), а второй — для аналитических (OLAP). YDB поддерживает оба подхода.

Строковая таблица

Строковые таблицы или row-oriented tables хранят данные для всех или большинства колонок каждой строки физически рядом друг с другом. Они описаны более подробно в Строковые таблицы.

Колоночная таблица

Колоночные таблицы, column-oriented table или columnar table хранят данные для каждой колонки отдельно. Они оптимизированы для построения агрегатов по небольшому числу колонок, но менее подходят для доступа к конкретным строкам, так как строки нужно восстанавливать из их ячеек на лету. Они описаны более подробно в {#T}.

Первичный ключ

Первичный ключ или primary key — это упорядоченный список колонок, значения которых однозначно идентифицируют строку. Он используется для создания первичного индекса таблицы. Он задаётся пользователем YDB при создании таблицы и существенно влияет на производительность операций с этой таблицей.

Руководство по выбору первичных ключей представлено в Выбор первичного ключа.

Первичный индекс

Первичный индекс, индекс первичного ключа, primary index или primary key index — это основная структура данных, используемая для нахождения строк в таблице. Он создаётся на основе выбранного первичного ключа и определяет физический порядок строк в таблице; таким образом, у каждой таблицы может быть только один первичный индекс. Первичный индекс является уникальным.

Вторичный индекс

Вторичный индекс или secondary index — это дополнительная структура данных, используемая для нахождения строк в таблице, обычно когда это нельзя эффективно сделать с помощью первичного индекса. В отличие от первичного индекса, вторичные индексы управляются независимо от основных данных таблицы. Таким образом, у таблицы может быть несколько вторичных индексов для различных сценариев. Возможности YDB в отношении вторичных индексов описаны в отдельной статье Вторичные индексы. Вторичный индекс может быть как уникальным, так и неуникальным.

Семейство колонок

Семейство колонок, группа колонок, column family или column group — это функция, позволяющая хранить подмножества колонок строковой таблицы отдельно в отдельном семействе или группе. Основной сценарий использования — хранение части колонок на других типах дисков (перенос менее важных колонок на HDD) или с другими настройками компрессии. Если рабочая нагрузка требует многих семейств колонок, рассмотрите возможность использования колоночных таблиц.

Время жизни

Время жизни, time to live или TTL — это механизм для автоматического удаления старых строк из таблицы асинхронно в фоновом режиме. Он описан в отдельной статье Time to Live (TTL).

Представление

Представление или view — это способ сохранить запрос и обращаться к его результатам как к настоящей таблице. Само представление не хранит данных, кроме текста запроса. Запрос, хранящийся в представлении, выполняется при каждом SELECT из него, генерируя возвращаемый результат. Любые изменения в таблицах, на которые ссылается представление, немедленно отражаются в результатах чтения из него.

Представления бывают пользовательские и системные.

Пользовательские представления

Пользовательские представления создаются пользователем с помощью команды CREATE VIEW. Они описаны более подробно в Представления (VIEW).

Системные представления

Системные представления предназначены для отслеживания состояния базы данных. Эти таблицы доступны из корня дерева базы данных и используют системный префикс пути .sys. Они описаны более подробно в Системные представления базы данных.

Топик

Очередь сообщений используется для надёжной асинхронной связи между различными системами посредством передачи сообщений. YDB предоставляет инфраструктуру, обеспечивающую семантику "exactly once" (ровно один раз) в таких коммуникациях. С её использованием можно добиться гарантии отсутствия потерянных сообщений и случайных дубликатов.

Топик, тема, topic — это именованная сущность в очереди сообщений, предназначенная для взаимодействия писателей и читателей.

Несколько терминов, связанных с топиками, приведены ниже. Как работают топики YDB объясняется более подробно в отдельной статье Топик.

Партиция

Для целей горизонтального масштабирования топики разделяются на отдельные элементы, называемые партициями или partitions. Таким образом, партиции являются единицей параллелизма внутри топики. Сообщения внутри каждой партиции упорядочены.

Однако подмножества данных, управляемые одним data shard или column shard, также могут называться партициями.

Смещение

Смещение или offset — это порядковый номер, идентифицирующий сообщение внутри партиции.

Писатель

Писатель, производитель или producer — это сущность, записывающая новые сообщения в топик.

Читатель

Читатель, потребитель или consumer — это сущность, читающая сообщения из топика.

Захват изменений данных

Захват изменений данных, change data capture или CDC — это механизм, позволяющий подписываться на поток изменений в конкретной таблице. Технически он реализован поверх топиков. Он описан более подробно в отдельной статье Change Data Capture (CDC).

Поток изменений

Поток изменений — упорядоченный список изменений таблицы, помещенный в топик.

Экземпляр асинхронной репликации

Экземпляр асинхронной репликации — это именованная сущность, хранящая настройки асинхронной репликации (настройки подключения, список реплицируемых объектов и т.д.). Также с его помощью можно получить информацию о состоянии асинхронной репликации: прогресс первоначального сканирования, отставание, ошибки и т.д.

Реплицируемый объект

Реплицируемый объект — объект (например, таблица), для которого настроена асинхронная репликация.

Объект-реплика

Объект-реплика — «зеркальная копия» реплицируемого объекта, автоматически созданная экземпляром асинхронной репликации. Как правило, доступен только для чтения.

Узел координации

Узел координации или coordination node — это объект схемы, который позволяет клиентским приложениям создавать семафоры для координации своих действий. Узлы координации применяются для реализации распределённых блокировок, обнаружения сервисов, выбора лидера и других сценариев. Более подробно об узлах координации.

Семафор

Семафор — это объект внутри узла координации, который предоставляет механизм синхронизации для распределённых приложений. Семафоры могут быть постоянными или временными и поддерживают операции создания, захвата, освобождения и мониторинга. Более подробно о семафорах в YDB.

Пул ресурсов

Пул ресурсов или resource pool — объект схемы, который описывает ограничения, накладываемые на ресурсы (CPU, RAM и т.п.) доступные для выполнения запросов в этом пуле ресурсов. Запрос всегда выполняется в каком-то пуле ресурсов. По умолчанию все запросы выполняются в пуле ресурсов с именем default, который не накладывает каких-либо ограничений. Подробнее об использовании пулов ресурсов можно узнать в статье Workload Manager — управление потреблением ресурсов.

Классификатор пулов ресурсов

Классификатор пулов ресурсов или resource pool classifier — объект, предназначенный для управления распределением запросов между пулами ресурсов. Он описывает правила, по которым для каждого запроса выбирается пул ресурсов. Эти классификаторы глобальны для всей базы данных и применяются ко всем запросам, поступающим в неё. Подробнее об их использовании можно узнать в статье Workload Manager — управление потреблением ресурсов.

YQL

YQL (YDB Query Language) — это высокоуровневый язык для работы с системой. Он является диалектом ANSI SQL. Существует много материалов, посвящённых YQL, включая туториал, справочник и рецепты.

Федеративные запросы

Федеративные запросы или federated queries — это функциональность, позволяющая выполнять запросы к данным, хранящимся в системах, внешних по отношению к кластеру YDB.

Ниже объяснены несколько терминов, связанных с федеративными запросами. Как работают федеративные запросы в YDB объясняется более подробно в отдельной статье Федеративные запросы.

Внешний источник данных

Внешний источник данных, внешнее подключение, external data source или external connection — это метаданные, описывающие, как подключиться к поддерживаемой внешней системе для выполнения федеративных запросов.

Внешняя таблица

Внешняя таблица или external table — это метаданные, описывающие конкретный набор данных, который можно извлечь из внешнего источника данных.

Секрет

Секрет или secret — это конфиденциальные метаданные, требующие особого обращения. Например, секреты могут использоваться в определениях внешних источников данных и представляют собой такие сущности, как пароли и токены.

Папка

Как и в файловых системах, папка, каталог, folder или directory является контейнером для других сущностей. В случае YDB, эти сущности могут быть таблицами (включая внешние таблицы), топиками, другими папками и т.д.

Оптимизатор запросов

Оптимизатор запросов — набор компонентов YDB, отвечающих за преобразование логического представления запроса в конкретный физически исполнимый план получения запрошенного результата. Основная цель оптимизатора — выбрать среди всех возможных планов выполнения запроса достаточно эффективный с точки зрения прогнозируемого времени исполнения и потребления ресурсов кластера. Он описан более подробно в отдельной статье Оптимзация запросов в YDB.

Продвинутая терминология

Этот раздел объясняет термины, которые полезны для YDB контрибьюторов и пользователей, желающих глубже понять, что происходит внутри системы.

Реализация акторов

Система акторов

Система акторов или actor system — это C++ библиотека с реализацией акторной модели для нужд YDB.

Акторный сервис

Акторный сервис или actor service — это актор, который имеет известное имя и обычно выполняется в единственном экземпляре на узле.

ActorId

ActorId — это уникальный идентификатор актора или таблетки в кластере.

Интерконнект акторной системы

Интерконнект акторной системы, интерконнект, actor system interconnect или interconnect — это внутренний сетевой слой кластера. Все акторы взаимодействуют друг с другом в системе через интерконнект.

Локал

Локал или local — это акторный сервис, работающий на каждом узле. Он напрямую управляет таблетками на своём узле и взаимодействует с Hive. Он регистрируется в Hive и получает команды на запуск таблеток.

Реализация таблеток

Таблетка или tablet — это актор с постоянным состоянием. Она включает набор данных, за которые эта таблетка отвечает, и конечный автомат, через который изменяются данные (или состояние) таблетки. Таблетка является отказоустойчивой сущностью, поскольку данные таблетки хранятся в распределённом хранилище, которое переживает сбои дисков и узлов. Таблетка автоматически перезапускается на другом узле в случае отказа или перегрузки предыдущего. Данные в таблетке изменяются последовательно, так как инфраструктура системы гарантирует, что нет более одного лидера таблетки, через которого выполняются изменения данных таблетки.

Таблетка решает ту же задачу, что и алгоритмы Paxos и Raft в других системах, а именно задачу распределённого консенсуса. С технической точки зрения реализация таблетки может быть описана как реплицированная машина состояний (Replicated State Machine, RSM) поверх общего журнала, поскольку состояние таблетки полностью описывается упорядоченным журналом команд, хранящимся в распределённом и отказоустойчивом хранилище.

Во время выполнения машина состояний таблетки управляется тремя компонентами:

  1. Общая таблеточная часть обеспечивает согласованность журнала и восстановление в случае сбоев.
  2. Исполнитель или executor — это абстракция локальной базы данных, а именно структуры данных и код, которые организуют работу с данными, хранимыми таблеткой.
  3. Актор с пользовательским кодом, реализующим специфическую логику конкретного типа таблетки.

В YDB существует несколько видов специализированных таблеток, хранящих всевозможные данные для различных задач. Многие функции YDB, такие как таблицы и топики, реализованы как разные виды таблеток. Таким образом, повторное использование инфраструктуры таблеток является одним из ключевых средств расширяемости YDB как платформы.

Обычно в кластере YDB работает на порядки больше таблеток по сравнению с процессами или потоками, которые другие системы использовали бы для кластера аналогичного размера. В кластере YDB легко могут одновременно работать сотни тысяч и миллионы таблеток.

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

Лидер таблетки

Лидер таблетки или tablet leader — это текущий активный лидер данной таблетки. Лидер таблетки принимает команды, назначает им порядок и подтверждает их внешнему миру. Гарантируется, что в любой момент времени существует не более одного лидера для каждой таблетки.

Кандидат таблетки

Кандидат таблетки или tablet candidate — это один из участников выборов, который хочет стать лидером данной таблетки. Если кандидат выигрывает выборы, он становится лидером таблетки.

Подписчик таблетки

Подписчик таблетки, горячий резерв, tablet follower или hot standby — это копия лидера таблетки, которая применяет журнал команд, принятых лидером (с некоторой задержкой). У таблетки может быть ноль или больше подписчиков. Подписчики выполняют две основные функции:

  • В случае завершения или отказа лидера подписчики являются предпочтительными кандидатами на роль нового лидера, так как они могут стать лидером намного быстрее, чем другие кандидаты, поскольку они применили большую часть журнала.
  • Подписчики могут отвечать на запросы только для чтения, если клиент явно выбирает опциональный расслабленных режим транзакций, допускающий устаревшие чтения (stale reads).

Поколение таблетки

Поколение таблетки или tablet generation — это номер, идентифицирующий реинкарнацию лидера таблетки. Он меняется только при выборе нового лидера и всегда увеличивается.

Локальная база данных таблетки

Локальная база данных таблетки, локальная база данных, tablet local database или local database — это набор структур данных и связанного кода, которые управляют состоянием таблетки и хранимыми ей данными. Логически состояние локальной базы данных представлено набором таблиц, очень похожих на реляционные таблицы. Модификация состояния локальной базы данных осуществляется локальными транзакциями таблетки, создаваемыми пользовательским актором таблетки.

Каждая таблица локальной базы данных хранится как LSM-дерево.

Log-structured merge-tree

Log-structured merge-tree или LSM-дерево — это структура данных, разработанная для оптимизации производительности записи и чтения в системах хранения. Она используется в YDB для хранения таблиц локальной базы и данных VDisks.

MemTable

Все данные, записанные в таблицы локальной базы, изначально хранятся в структуре данных в оперативной памяти, называемой MemTable. Когда MemTable достигает заданного размера, она сбрасывается на диск как неизменяемая структура данных SST.

Sorted string table

Sorted string table или SST — это неизменяемая структура данных, которая хранит строки таблицы, отсортированные по ключу, что облегчает эффективный поиск ключей и работу с диапазонами ключей. Каждая SST состоит из непрерывной серии маленьких страниц данных, обычно размером около 7 КиБ каждая, что дополнительно оптимизирует процесс чтения данных с диска. Обычно SST представляет собой часть LSM-дерева.

Пайп таблетки

Пайп таблетки, tablet pipe или TabletPipe — это виртуальное соединение, которое может быть установлено с таблеткой. Оно включает поиск лидера таблетки по TabletID. Это рекомендуемый способ работы с таблеткой. Термин открыть пайп к таблетке описывает процесс разрешения (поиска) таблетки в кластере и установления с ней виртуального канала связи.

TabletID

TabletID — это уникальный идентификатор таблетки в рамках кластера.

Bootstrapper

Bootstrapper — это основной механизм запуска таблеток, используемый для системных таблеток (например, для Hive, DS controller, корневого SchemeShard). Hive инициализирует остальные таблетки.

Общий кеш

Общий кеш или shared cache — это актор, который хранит страницы данных, недавно прочитанные из распределённого хранилища. Кеширование этих страниц снижает количество операций ввода-вывода с диска и ускоряет получение данных, повышая общую производительность системы.

Контроллер памяти

Контроллер памяти или memory controller— это актор, который управляет лимитами памяти YDB.

Типы таблеток

Таблетки можно рассматривать как фреймворк для создания надёжных компонентов, работающих в распределённой системе. Многие компоненты YDB реализованы с использованием этого фреймворка, они перечислены ниже.

Scheme shard

Scheme shard или SchemeShard — это таблетка, которая хранит схему базы данных, включая метаданные пользовательских таблиц, топиков и т.д.

Кроме того, существует корневой scheme shard, который хранит информацию о базах данных, созданных в кластере.

Data shard

Data shard или DataShard — это таблетка, которая управляет сегментом строковой пользовательской таблицы. Логическая пользовательская таблица делится на сегменты по непрерывным диапазонам первичного ключа таблицы. За каждый такой диапазон отвечает отдельная таблетка DataShard. Сам диапазон также называется партицией. Таблетка DataShard хранит данные построчно, что эффективно для OLTP нагрузок.

Column shard

Column shard или ColumnShard — это таблетка, которая хранит сегмент данных колоночной пользовательской таблицы.

KV Tablet

KV Tablet, key-value tablet или таблетка ключ-значение — это таблетка, которая реализует простое отображение ключ->значение, где ключи и значения — это строки. У неё также есть несколько специфических функций, таких как блокировки.

PQ Tablet

PQ Tablet или persistent queue tablet — это таблетка, которая реализует концепцию топика. Каждый топик состоит из одного или нескольких разделов, и каждый раздел управляется отдельным экземпляром таблетки PQ.

TxAllocator

TxAllocator, аллокатор транзакций или transaction allocator — это системная таблетка, которая выделяет уникальные идентификаторы транзакций (TxID) в кластере. Обычно в кластере имеется несколько таких таблеток, из которых transaction proxy предварительно выделяет и кэширует диапазоны для локального выпуска в рамках одного процесса.

Координатор

Координатор или coordinator — это системная таблетка, обеспечивающая глобальный порядок транзакций. Задача координатора заключается в присвоении логического времени PlanStep каждой транзакции, спланированной через этого координатора. Каждой транзакции назначается ровно один координатор, выбранный путём хеширования её TxId.

Медиатор

Медиатор — это системная таблетка, которая распределяет транзакции, спланированные координаторами, между участниками транзакций (обычно это DataShards). Медиаторы обеспечивают продвижение глобального времени. Каждый участник транзакции ассоциируется ровно с одним медиатором. Медиаторы позволяют избежать необходимости в полном наборе соединений между всеми координаторами и всеми участниками всех транзакций.

Hive

Hive — это системная таблетка, отвечающая за запуск и управление другими таблетками. Её обязанности включают перемещение таблеток между узлами в случае отказа или перегрузки узла.

Система управления кластером

Система управления кластером, cluster management system или CMS — это системная таблетка, отвечающая за управление информацией о текущем состоянии кластера YDB. Эта информация используется для выполнения постепенных перезапусков кластера без воздействия на пользовательские нагрузки, обслуживания, переконфигурации кластера и т.д.

Слот

Слот в YDB может использоваться в двух контекстах:

  • Слот — это часть ресурсов сервера, выделенная для запуска одного узла YDB. Обычный размер слота — 10 процессорных ядер и 50 ГБ оперативной памяти. Слоты используются, если кластер YDB развернут на серверах или виртуальных машинах с достаточными ресурсами для размещения нескольких слотов.
  • Слот VDisk или VSlot — это доля PDisk, которая может быть выделена одному из VDisk.

Хранилище состояния

Хранилище состояния, state storage или StateStorage — это распределённый сервис, который хранит информацию о таблетках, а именно:

  • Текущий лидер таблетки или его отсутствие.
  • Подписчики таблетки.
  • Поколение и шаг таблетки (generation:step).

Хранилище состояния используется как служба для разрешения имён таблеток, то есть для получения ActorId по TabletID. StateStorage также используется в процессе выбора лидера таблетки.

Информация в хранилище состояния является волатильной. Таким образом, она теряется при отключении питания или перезапуске процесса. Несмотря на название, этот сервис не является постоянным долгосрочным хранилищем. Он содержит только информацию, которую легко восстановить и которая не должна быть долговечной. Однако хранилище состояния хранит информацию на нескольких узлах, чтобы минимизировать влияние отказов узлов. Через этот сервис также можно собрать кворум, который используется для выбора лидеров таблеток.

Из-за своей природы сервис хранилища состояния работает по принципу максимально возможных усилий. Например, отсутствие нескольких лидеров таблеток гарантируется через протокол выбора лидеров на распределённом хранилище, а не на хранилище состояния.

Компакшн

Компакшн, комактизация или compaction — это внутренний фоновый процесс перестройки данных LSM-дерева. Данные в VDisk и локальных базах данных организованы в виде LSM-деревьев. Поэтому различают компакшн VDisk и таблеточный компакшн. Процесс компакшна обычно довольно ресурсоёмкий, поэтому принимаются меры по минимизации накладных расходов, связанных с ним, например, путём ограничения числа одновременно исполняемых компакшнов.

gRPC-прокси

gRPC-прокси или gRPC proxy — это прокси-система для внешних пользовательских запросов. Клиентские запросы поступают в систему по протоколу gRPC, затем компонент прокси переводит их во внутренние вызовы для выполнения этих запросов, передаваемых через интерконнект. Этот прокси предоставляет интерфейс как для запросов-ответов, так и для двунаправленной потоковой передачи данных.

Реализация распределённого хранилища

Распределённое хранилище — это распределённый отказоустойчивый слой хранения данных, который сохраняет бинарные записи, называемые LogoBlob, адресуемые с помощью определённого типа идентификатора, называемого LogoBlobID. Таким образом, распределённое хранилище является хранилищем ключ-значение, которое сопоставляет LogoBlobID строке размером до 10 МБ. Распределённое хранилище состоит из множества групп хранения, каждая из которых является независимым репозиторием данных.

Распределённое хранилище сохраняет неизменяемые данные, при этом каждый неизменяемый блок данных идентифицируется определённым ключом LogoBlobID. API распределённого хранилища очень специфичен, предназначен только для использования таблетками для хранения их данных и журналов изменений. Таким образом, оно не предназначено для хранения данных общего назначения. Данные в распределённом хранилище удаляются с помощью специальных команд барьера. Из-за отсутствия мутаций в его интерфейсе распределённое хранилище может быть реализовано без реализации распределённого консенсуса. Распределённое хранилище является лишь одним из компонентов, который таблетки используют для реализации распределённого консенсуса.

LogoBlob

LogoBlob — это набор двоичных неизменяемых данных, идентифицируемый LogoBlobID и хранящийся в распределённом хранилище. Размер блока данных ограничен на уровне VDisk и выше по стэку. В настоящее время максимальный размер блока данных, который могут обработать VDisk, составляет 10 МБ.

LogoBlobID

LogoBlobID — это идентификатор LogoBlob в распределённом хранилище. Он имеет структуру вида [TabletID, Generation, Step, Channel, Cookie, BlobSize, PartID]. Основные элементы LogoBlobID:

  • TabletID — это ID таблетки, которой принадлежит LogoBlob.
  • Generation — это поколение таблетки, в котором был записан блок данных.
  • Channel — это канал таблетки, на котором записан LogoBlob.
  • Step — это инкрементный счётчик, обычно в пределах поколения таблетки.
  • Cookie — это уникальный идентификатор блока данных в пределах одного Step. Cookie обычно используется при записи нескольких блоков данных в один Step.
  • BlobSize — это размер LogoBlob.
  • PartID — это идентификатор части блока данных. Он важен, когда оригинальный LogoBlob разбивается на части с использованием кодирования с исправлением ошибок, и части записываются на соответствующие VDisk и группы хранения.

Репликация

Репликация — это процесс, обеспечивающий наличие достаточного количества копий (реплик) данных для поддержания желаемых характеристик доступности кластера YDB. Обычно используется в геораспределённых кластерах YDB.

Кодирование с исправлением ошибок

Кодирование с исправлением ошибок или erasure coding — это метод кодирования данных, при котором исходные данные дополняются избыточностью и разделяются на несколько фрагментов, обеспечивая возможность восстановления исходных данных в случае потери одного или нескольких фрагментов. Он широко используется в кластерах YDB с одной зоной доступности в отличии от репликации с 3 репликами. Например, наиболее популярная схема erasure coding 4+2 обеспечивает ту же надёжность, что и три реплики, с избыточностью пространства 1.5 против 3.

PDisk

PDisk, physical disk или физический диск — это компонент, который контролирует физический дисковый накопитель (блочное устройство). Другими словами, PDisk — это подсистема, которая реализует абстракцию, аналогичную специализированной файловой системе поверх блочных устройств (или файлов, эмулирующих блочное устройство для целей тестирования). PDisk обеспечивает контроль целостности данных (включая кодирование с исправлением ошибок групп секторов для восстановления данных на отдельных повреждённых секторах, контроль целостности с помощью контрольных сумм), прозрачное шифрование всех данных на диске и транзакционные гарантии дисковых операций (подтверждение записи строго после fsync).

PDisk содержит планировщик, который обеспечивает совместное использование пропускной способности устройства между несколькими клиентами (VDisk). PDisk делит блочное устройство на блоки, называемые слотами (размером около 128 мегабайт; разрешены и меньшие блоки). В каждый момент времени не более одного VDisk может владеть каждым слотом. PDisk также поддерживает журнал восстановления, общий для записей службы PDisk и всех VDisk.

VDisk

VDisk, virtual disk или виртуальный диск — это компонент, который реализует хранение данных распределённого хранилища LogoBlob на PDisk. VDisk хранит все свои данные на PDisk. Один VDisk соответствует одному PDisk, но обычно несколько VDisk связаны с одним PDisk. В отличие от PDisk, который скрывает блоки и журналы за собой, VDisk предоставляет интерфейс на уровне LogoBlob и LogoBlobID, например запись LogoBlob, чтение данных LogoBlobID и удаление набора LogoBlob с помощью специальной команды. VDisk является членом группы хранения. Сам VDisk является локальным, но многие VDisk в данной группе обеспечивают надёжное хранение данных. VDisk в группе синхронизируют данные друг с другом и реплицируют данные в случае потерь. Набор VDisk в группе хранения образует распределённый RAID.

Yard

Yard — это название API PDisk. Он позволяет VDisk читать и записывать данные в блоки и журналы, резервировать блоки, удалять блоки и транзакционно получать и возвращать владение блоками. В некоторых контекстах Yard можно считать синонимом PDisk.

Skeleton

Skeleton — это актор, который предоставляет интерфейс к VDisk.

SkeletonFront

SkeletonFront — это прокси-актор для Skeleton, который контролирует поток сообщений, поступающих в Skeleton.

Контроллер распределённого хранилища

Контроллер распределённого хранилища, distributed storage controller, DS-controller или DS-контроллер управляет динамической конфигурацией распределённого хранилища, включая информацию о PDisk, VDisk и группах хранения. Он взаимодействует с node warden для запуска различных компонентов распределённого хранилища. Он взаимодействует с Hive для выделения каналов таблеткам.

Прокси

Прокси распределённого хранилища, DS-прокси, BS-прокси, distributed storage proxy, DS-proxy или BS-proxy выполняет роль клиентской библиотеки для выполнения операций с распределённым хранилищем. Пользователями DS-прокси являются таблетки, которые записывают и читают из распределённого хранилища. DS-прокси скрывает распределённую природу распределённого хранилища от пользователя. Задача DS-прокси — запись в кворум VDisk, выполнение повторных попыток при необходимости и контроль потока записи/чтения для предотвращения перегрузки VDisk.

Технически DS-прокси реализован как акторный сервис, запускаемый node warden на каждом узле для каждой группы хранения, обрабатывающий все запросы к группе (запись, чтение и удаление LogoBlob, блокировка группы). При записи данных DS-прокси выполняет кодирование с исправлением ошибок данных, разделяя LogoBlob на части, которые затем отправляются соответствующим VDisk. DS-прокси выполняет обратный процесс при чтении, получая части от VDisk и восстанавливая из них LogoBlob.

Node warden

Node warden или BS_NODE — это сервис акторов на каждом узле кластера, запускающий PDisks, VDisks и DS прокси статических групп хранения при запуске узла. Также он взаимодействует с DS контроллером для запуска PDisk, VDisk и DS прокси динамических групп. DS прокси динамических групп запускается по запросу: node warden обрабатывает «недоставленные» сообщения к DS прокси, запускает соответствующие DS прокси и получает конфигурацию групп от DS контроллера.

Область отказа

Область отказа или fail realm — это набор доменов отказа, которые могут выйти из строя одновременно по общей причине. Коррелированный сбой двух VDisks в одной и той же области отказа более вероятен, чем сбой двух VDisk из разных областей отказа.

Примером области отказа является набор оборудования, размещённый в одном дата-центре, или зоне доступности, который может выйти из строя целиком вследствие природной катастрофы, масштабного отключения электропитания или другого подобного события.

Домен отказа

Домен отказа или fail domain — это набор оборудования, который может выйти из строя одновременно. Коррелированный сбой двух VDisk в пределах одного домена отказа более вероятен, чем сбой двух VDisk из разных доменов отказа. В случае разных доменов отказа вероятность одновременного сбоя также зависит от того, принадлежат ли рассматриваемые домены одной области отказа или разным.

Примером домена отказа является набор дисков, подключённых к одному серверу, поскольку все диски конкретного сервера могут оказаться недоступными при отказе блока питания сервера или сетевого контроллера. Обычно к общему домену отказа относят все серверы, размещённые в одной серверной стойке, поскольку проблемы с электропитанием или сетевыми подключениями на уровне стойки приводят к недоступности всего размещаемого в ней оборудования. Таким образом, типичный домен отказа соответствует серверной стойке (если cluster настроен с учётом топологии размещения оборудования в стойках) или отдельному серверу.

Сбои уровня домена отказа автоматически обрабатываются YDB без остановки кластера.

Канал распределённого хранилища

Канал распределённого хранилища, канал, distributed storage channel, DS channel или channel — это логическое соединение между таблеткой и группой распределённого хранилища. Таблетка может записывать данные в различные каналы, и каждый канал отображается на определённую группу хранения. Наличие нескольких каналов позволяет таблетке:

  • Записывать больше данных, чем может содержать одна группа хранения.
  • Хранить различные LogoBlob в различных группах хранения, с различными свойствами, такими как кодирование с исправлением ошибок или на различных носителях (HDD, SSD, NVMe).

Реализация распределённых транзакций

Ниже объяснены термины, связанные с реализацией распределённых транзакций. Сама реализация описана в отдельной статье DataShard: распределённые транзакции.

Детерминированные транзакции

Распределённые транзакции YDB вдохновлены исследовательской работой Building Deterministic Transaction Processing Systems without Deterministic Thread Scheduling Александра Томсона и Дэниела Дж. Абади из Йельского университета. В статье введено понятие детерминированной транзакционной обработки или deterministic transaction processing, которое позволяет эффективно обрабатывать распределённые транзакции. Оригинальная статья накладывала ограничения на виды операций, которые могут выполняться таким образом. Поскольку эти ограничения мешали реальным пользовательским сценариям, YDB развила свои алгоритмы для их выполнения, используя детерминированные транзакции в качестве этапов выполнения пользовательских транзакций с дополнительной оркестрацией и блокировками.

Оптимистичные блокировки

Как и во многих других системах управления базами данных, запросы YDB могут накладывать блокировки на определённые фрагменты данных, такие как строки таблиц, чтобы гарантировать, что параллельные изменения не приведут их в несогласованное состояние. Однако YDB проверяет эти блокировки не в начале транзакций, а при попытках их коммита (фиксации). Первый подход называется пессимистичными блокировками или perssimistic locking (например, используется в PostgreSQL), а второй — оптимистичными блокировками или optimistic locking (используется в YDB).

Этап подготовки

Этап подготовки — это фаза транзакции, во время которой тело транзакции регистрируется на всех участвующих шардах.

Этап выполнения

Этап выполнения — это фаза транзакции, в ходе которой запланированная транзакция исполняется и генерируется ответ.

В некоторых случаях, вместо подготовки и выполнения, транзакция немедленно выполняется и генерируется ответ. Например, это происходит для транзакций, затрагивающих только один шард или для согласованных чтений из снимка данных (snapshot).

Грязные операции

В случае только для чтения транзакций, аналогично "read uncommitted" в других системах управления базами данных, может потребоваться чтение данных, которые ещё не были зафиксированы на диске. Это называется грязными операциями или dirty operations.

Набор чтения-записи

Набор чтения-записи, RW-набор, read-write set или RW-set — это набор данных, который будет участвовать в выполнении распределённой транзакции. Он объединяет данные набора чтения, которые будут считываться, и набор записи, для которого будут выполняться модификации.

Набор чтения

Набор чтения, ReadSet данные, read set или ReadSet data — это то, что пересылают участвующие шарды во время выполнения транзакции. В случае транзакций с данными он может содержать информацию о состоянии оптимистичных блокировок, готовности шарда к коммиту или решение отменить транзакцию.

Транзакционные прокси

Транзакционные прокси, transaction proxy или TX_PROXY — это сервис, который оркестрирует выполнение многих распределённых транзакций: последовательные фазы, выполнение фаз, планирование и агрегацию результатов. В случае прямой оркестрации другими акторами (например, KQP data transactions), он используется для кэширования и выделения уникальных TxID.

Флаги транзакции

Флаги транзакции, transaction flags или TxFlags — это битовая маска флагов, которые каким-то образом изменяют выполнение транзакции.

Идентификатор транзакции

Идентификатор транзакции или TxID — это уникальный идентификатор, назначаемый каждой транзакции при её принятии YDB.

Идентификатор порядка транзакции

Идентификатор порядка транзакции или transaction order id — это уникальный идентификатор, назначаемый каждой транзакции во время планирования. Он состоит из PlanStep и Transaction ID.

Планируемый шаг

Планируемый шаг, шаг, PlanStep или Step — это логическое время, на которое запланировано выполнение набора транзакций.

Время медиатора

Во время выполнения распределённых транзакций, время медиатора, медиаторное время или mediator time — это логическое время, до которого (включительно) шард-участник должен знать весь план выполнения. Оно используется для продвижения времени при отсутствии транзакций на конкретном шарде, чтобы определить, может ли он читать из снимка (snapshot).

MiniKQL

MiniKQL — это язык, который позволяет выразить одну детерминированную транзакцию в системе. Это функциональный, строго типизированный язык. Концептуально язык описывает граф чтения из базы данных, выполнения вычислений над прочитанными данными и записи результатов в базу данных и/или в специальный документ, представляющий результат запроса (для показа пользователю). Транзакция MiniKQL должна явно задавать свой набор чтения (читаемые данные) и предполагать детерминированный выбор ветвей выполнения (например, отсутствует случайность).

MiniKQL — это язык низкого уровня. Конечные пользователи системы видят только запросы на языке YQL, который опирается на MiniKQL в своей реализации.

KQP

KQP — это компонент YDB, отвечающий за оркестрацию выполнения пользовательских запросов и генерацию окончательного ответа.

Глобальная схема

Глобальная схема, схема базы данных, global scheme, global schema или database schema — это схема всех данных, хранящихся в базе данных. Она состоит из таблиц и других сущностей, таких как топики. Метаданные об этих сущностях называются глобальной схемой. Термин используется в противоположность локальной схеме или local schema, которая относится к схеме данных внутри таблетки. Пользователи YDB никогда не видят локальную схему и работают только с глобальной схемой.

KiKiMR

KiKiMR — это устаревшее название YDB, использовавшееся до того, как он стал продуктом с открытым исходным кодом (open source). Оно всё ещё может встречаться в исходном коде, старых статьях и видео и т.д.

Предыдущая
Концепции
Следующая
Соединение с БД