Copy glossary

updated

1 files changed, 224 insertions, 0 deletions

diff --git a/ydb/docs/ru/core/concepts/glossary.md b/ydb/docs/ru/core/concepts/glossary.md
new file mode 100644
index 00000000000..c4e1114f0da
--- /dev/null
+++ b/ydb/docs/ru/core/concepts/glossary.md
@@ -0,0 +1,224 @@
+# Глоссарий
+### Внешние ссылки на основные понятия
+
+* [Strict Consistency – https://en.wikipedia.org/wiki/Consistency_model](https://en.wikipedia.org/wiki/Consistency_model)
+* [Serializable isolation – https://en.wikipedia.org/wiki/Isolation_%28database_systems%29#Serializable](https://en.wikipedia.org/wiki/Isolation_%28database_systems%29#Serializable)
+* [Actor model – https://en.wikipedia.org/wiki/Actor_model](https://en.wikipedia.org/wiki/Actor_model)
+* [Replicated state machine – https://en.wikipedia.org/wiki/State_machine_replication](https://en.wikipedia.org/wiki/State_machine_replication)
+* [Paxos - https://en.wikipedia.org/wiki/Paxos_(computer_science)](https://en.wikipedia.org/wiki/Paxos_(computer_science))
+* [Raft - https://en.wikipedia.org/wiki/Raft_(algorithm)](https://en.wikipedia.org/wiki/Raft_(algorithm))
+
+### Actor Model
+**Actor System** - реализация [Actor Model](https://en.wikipedia.org/wiki/Actor_model) в системе.
+
+**Actor (Актор)** - C++ класс реализующий абстракцию [Актора](https://en.wikipedia.org/wiki/Actor_model).
+
+**Actor Service (Акторный Сервис)** - актор, который имеет well-known имя, обычно запускается в единственном экземпляре на ноде.
+
+**ActorID** - уникальный идентификатор таблетки в кластере.
+
+**(Actor System) Interconnect** - сетевой программный слой а также внутренняя сеть кластера. Внутри системы акторы взаимодействуют друг с другом через Interconnect.
+
+
+
+### Tablet
+**Tablet (Таблетка)** - так в системе называется абстракция, которая отвечает за относительно небольшой (до единиц гигабайт) сегмент пользовательских или системных данных. Например, пользовательская таблица представляет собой одну или несколько таблеток, каждая таблетка отвечает за непрерывный диапазон первичных ключей таблицы и данных им соответствующих. Таблетки могут отвечать за пользовательские метаданные, например, за список пользовательских таблиц, за системные метаданные и т.п.
+
+Таблетка представляет собой набор данных, за который отвечает эта таблетка, и конечный автомат, через который состояние таблетки (данные) меняется. Таблетка является отказоустойчивой сущностью -- данные таблетки хранятся в распределенном BlobStorage, который переживает отказ дисков и нод. Данные в таблетке меняются консистентным образом -- инфраструктура системы обеспечивает наличие не более одной сущности (лидера), через которую проводятся изменения данных таблетки. За обработку команд отвечает некоторый вышеуказанный конечный автомат.
+
+Таблетка решает ту же задачу, что алгоримы [Paxos](https://en.wikipedia.org/wiki/Paxos_(computer_science)) и [Raft ](https://en.wikipedia.org/wiki/Raft_(algorithm)) в ряде других систем, а именно задачу [распределенного консенсуса](https://en.wikipedia.org/wiki/Consensus_(computer_science)). С технической точки зрения реализацию таблетки проще всего описать как RSM (Replicated State Machine) over shared log - состояние таблетки полностью описывается упорядоченным логом команд, хранящимся в распределенном и отказоустойчивом хранилище.
+
+Во время выполнения конечный автомат таблетки обслуживают три актора:
+
+1. общетаблеточная часть обеспечивающая консистентность лога и восстановление при сбоях;
+1. executor -- абстракция локальной базы, а именно структур данных и кода, которые обеспечивают работу с хранимыми таблеткой данными;
+1. актор с пользовательским кодом, который реализует специфичную логику конкретного типа таблетки.
+
+Таблетка является базовым строительным блоком системы. Хранение всевозможных данных для всего спектра задач обычно реализуется через специальный тип таблетки. Обычно, в системе запущено множество (тысячи, десятки тысяч, а может быть, даже миллионы) таблеток, выполняющих различную функцию. Таблетки идентифицируются при помощи **TabeltID** -- 64-х битного числа, назначаемого при создании таблетки.
+
+Так как таблетка хранит свое состояние в BlobStorage, вышеуказанные акторы, через которые происходит работа с данными таблетки, могут быть запущены (технически) на любом узле кластера. Вышеуказанные акторы называют **Tablet Leader (Мастер таблетки)**.
+
+### Tablet Leader
+**Tablet Leader (Лидер таблетки)** - текущий активный лидер таблетки, именно он принимает команды, упорядочивает их и подтверждает внешнему миру. В каждый момент времени существует не более одного лидера.
+  
+### Tablet Candidate
+**Tablet Candidate** - если таблетка осталась без лидера, то кандидат -- это один их участников выборов, желающий стать лидером. В случае успеха выборов кандидат становится лидером таблетки.
+  
+### Tablet Follower
+**Tablet Follower** или **Hot standby** - копия лидера, проигрывающая принятый лидером лог команд (с некоторым отставанием). Tаблетка может иметь 0 или более фолловеров. Фолловеры решают по большей степени две задачи:
+  
+* в случае смерти лидера фолловеры являются предпочтительными кандидатами в лидера, т.к. могут перейти в лидера гораздо быстрее остальных кандидатов -- им потребуется проиграть меньше лога;
+* фолловеры могут брать на себя некоторую нагрузку лидера на чтение (отвечая на запросы чтения с некоторым отставанием).
+  
+### Tablet Generation
+**Tablet Generation** - число, идентифицирующее реинкарнацию лидера таблетки. Меняется только при выборе нового лидера и всегда растет.
+  
+### Tablet Local Database
+**Tablet Local Database** или **локальная база** -- структуры данных и код, которые обеспечивают работу с хранимыми таблеткой данными. Очень грубо, состояние локальной базы представлено набором таблиц очень похожих на реляционные таблицы. Модификация состояния локальной базы производится локальными транзакциями таблетки, генерируемыми пользовательским актором таблетки.
+
+### Виды таблеток
+
+#### Scheme Shard
+**Scheme Shard** - таблетка хранящая схему базы данных, а именно:
+
+* метаданные про пользовательские таблицы;
+* метаданные про пользовательские топики и т.п.
+
+Существует такое понятие как **Root Scheme Shard (Рутовый Scheme Shard)**, который хранит информацию о созданных в кластере базах данных.
+
+#### KV Tablet
+**KV Tablet** - таблетка реализующая простое отображение key->value, где key и value -- это строки. Также имеет ряд специфических возможностей (например, блокировки).
+
+#### PQ Tablet
+**PQ Tablet** - таблетка реализующая понятие топика. Состоит из партиций, которые похожи на партиции [Apache Kafka](https://kafka.apache.org). Сокращение PQ -- от persistent queue.
+  
+#### DataShard
+**DataShard** - таблетка хранящая сегмент данных построчной пользовательской таблицы. Исходная построчная пользовательская таблица разбивается на сегменты по непрерывным диапазонам первичного ключа таблицы. За каждый такой диапазон называемый партицией отвечает таблетка DataShard. Таблетка DataShard хранит данные построчно, что эффективно для OLTP-нагрузки.
+
+#### Column Shard
+**ColumnShard** - таблетка хранящая сегмент данных поколоночной пользовательской таблицы.
+
+#### TxAllocator
+**TxAllocator** - системная таблетка, обеспечивающая выделение уникальных в рамках кластера идентификаторов транзакций. Обычно кластер имеет несколько таких таблеток, из которых TxProxy заранее выделяет и кеширует диапазоны для локальной выдачи внутри одного процесса.
+
+#### Coordinator
+**Coordinator (Координатор)** - системная таблетка, обеспечивающая глобальную упорядоченность транзакций. Задача координатора назначить логическое время PlanStep для каждой транзакции, планируемой через этот координатор. Для каждой транзакции выбирается строго один координатор (выбирается хешированием для конкретного TxId).
+  
+#### Mediator
+**Mediator (Медиатор)** - системная таблетка, распространяющая запланированные Координатором транзакции на участников транзакций (обычно, DataShards). Медиаторы обеспечивают продвижение глобального времени. С каждым участником транзакций ассоциирован ровно один Медиатор.
+
+#### BlobStorage Controller
+**BlobStorage Controller** - системная таблетка, которая хранит информацию о конфигурации BlobStorage. Запущена в единственном экземпляре на кластере.
+
+#### Hive
+**Hive** - системная таблетка, позволяющая запускать и управлять другими таблетками. В системе есть ряд системных служебных таблеток, которые должны быть подняты для нормального функционирования системы. Такие таблетки поднимается при помощи **Bootstrapper**. Остальные таблетки создаются и поднимаются при помощи Hive. Например, если мы создаем (глобальную) таблицу в системе, для которой нужно создать и запустить несколько DataShards, то их созданием и запуском занимается Hive (по команде от SchemeShard).
+
+Hive позволяет минимизировать конфликты кандидатов в лидера таблетки при запуске. Он также занимается балансировкой нагрузки на кластер -- выбирает на какой ноде лучше запустить данную таблетку. При создании таблеток Hive взаимодействует с **BlobStorage Controller** для назначения **Blobstorage групп** каналам таблеток. Непосредственно запуск таблеток на нодах осуществляет через запущенный на каждой ноде сервис Local.
+
+### Infrastructure
+#### Local
+**Local** - акторный сервис, запущенный на каждой ноде. Непосредственно управляет таблетками на своей ноде, взаимодействует с Hive. Регистрируется в Hive и получает команды на запуск таблеток.
+  
+#### Bootstrapper
+**Bootstrapper** - базовый механизм запуска таблеток, применяется для служебных таблеток (например для Hive, BlobStorage Controller, корневого Scheme Shard). Остальные таблетки поднимаются таблеткой Hive.
+  
+#### TabletPipe
+**TabletPipe** - виртуальное соединение, которое можно установить с таблеткой. Включает в себя resolve лидера таблетки по TabletID. Рекомендуемый способ работы с таблеткой. Термин **установить pipe к таблетке** используется для описания процесса резолва (поиска) таблетки в кластере и установки виртуального канала общения с ней.
+  
+#### StateStorage
+**StateStorage** - распределенный сервис, который хранит информацию о таблетках, а именно:
+
+* информацию о текущем лидере таблетки или его отсутствии;
+* информацию о фолловерах таблетки;
+* информацию о поколении и шаге таблетки (generation:step).
+
+StateStorage используется как Name Service для резолва таблеток, т.е. получение ActorID по TabletID. Также StateStorage используется в процессе поднятия лидера таблетки.
+
+Информация в StateStorage волатильна, то есть теряется при выключении питания или рестарте процесса. Дело в том, что в State Storage (несмотря на название сервис не является хранилищем, данные на диске хранятся только в BlobStorage) содержит только информацию, которая не обязана быть durable и легко восстановима. Тем не менее, StateStorage хранит информацию на нескольких нодах для переживания сбоя конкретного узла, через этот сервис можно собирать кворум, что используется для поднятия лидера таблетки. Однако из-за своей природы сервис работает в режиме best effort, например гарантия отсутствия нескольких лидеров таблеток обеспечивается через протокол выбора лидера на BlobStorage, а не StateStorage.
+
+#### Compaction
+**Compaction** - внутренний процесс перестройки данных хранимых в виде [LSM Tree](https://en.wikipedia.org/wiki/Log-structured_merge-tree). Данные в VDiskе и Локальной базе таблетки организованы в виде LSM Tree. Поэтому различают **VDisk compaction** и **Tablet compaction**. Процесс Compaction, обычно, достаточно ресурсоемкий, поэтому прилагаются усилия для того, чтобы минимизировать накладные расходы с ним связанные (не запускать множество параллельных процессов Compaction и т.п.).
+
+#### gRPC Proxy
+  **gRPC Proxy** - базовая клиентская прокси системы для пользовательских запросов. Клиентские запросы попадают в систему через [gRPC](https://grpc.io) Proxy, далее используются внутренние механизмы выполнения этих запросов и передачи сообщений (Interconnect). Предоставляет интерфейс в терминах request-response и bidirectional streaming.
+    
+### Blob Storage
+**Blob Storage или Distributed Storage** - это распределенное отказоустойчивое хранилище данных, обеспечивающее хранение бинарных записей, называемых LogoBlob, адресуемых по специального вида идентификаторам, называемым LogoBlobID. Фактически BlobStorage является Key-value-хранилищем, отображающим LogoBlobID в строку размером до 10MB. BlobStorage состоит из множества BS-групп (BlobStorage-групп), каждая из которых является независимым хранилищем. Наиболее близкой аналогией к BS-группе является распределенный RAID массив.
+
+Blob Storage хранит иммутабельные данные, то есть по конкретному ключу LogoBlobID хранится неизменяемый блоб. Интерфейс Blob Storage является весьма специфичным, он удобен только для использования таблетками, которые хранят в Blob Storage свои данные и лог изменений. Данные в Blob Storage удаляются при помощи специальных команд-барьеров. Из-за специфики своего интерфейса (нет мутаций) Blob Storage можно реализовать без имплементации **распределенного консенсуса**. Более того, Blob Storage является как раз тем кирпичиком, при помощи которого таблетка реализует распределенный консенсус.
+
+#### LogoBlob
+  **LogoBlob** - бинарные иммутабельные данные, снабженые уникальным идентификатором, имеющим специальную структуру, хранимые в Blob Storage. Размер блоба ограничен на уровне VDiskов и выше по стеку. На данный момент максимальный размер блоба, который готовы обрабатывать VDiskи составляет 10 Mb.
+
+#### LogoBlobID
+**LogoBlobID** - идентификатор LogoBlob в Blob Storage. Имеет структуру вида ```[TabletID, Generation, Step, Channel, Cookie, BlobSize, PartId]```. Ключевыми элементами LogoblobID являются:
+  
+* TabletID - идентификатор таблетки, которой принадлежит LogoBlob;
+* Generation - поколение таблетки, в котором блоб был записан;
+* Channel - канал таблетки, в который записан LogoBlob;
+* Step - инкрементирующийся счетчик, обычно в рамках поколения таблетки. Можно говорить об отношении порядка между блобами одной таблетки в одном канале, следующие LogoblobID обычно больше предыдущих за счет увеличивающегося Step;
+* Cookie - уникальный идентификатор блоба в рамках одного Step. Cookie обычно используется, когда необходимо написать несколько блобов в рамках одного Step;
+* BlobSize - размер Logoblob;
+* PartId - идентификатор куска блоба. Особенно важен когда исходный LogoBlob разбивается на куски при помощи erasure coding, и куски записываются на соответствующие VDisk-и BS-группы.
+
+#### Erasure Сoding
+**Erasure coding** - способ кодирования данных, при котором данные дополняются избыточностью и разбиваются на несколько фрагментов, обеспечивающий возможность восстановления исходных данных при потере одного или нескольких фрагментов. Широко используется в системе в противовес популярной репликации с 3-мя репликами. Например, наиболее популярная схема 4+2 обеспечивает такую же надежность как 3 реплики, при этом избыточность составляет 1.5 против 3-х.
+
+#### PDisk
+**PDisk (Physical Disk)**) - компонент управляющий физическим диском (устройством). Иначе говоря, PDisk - это подсистема, реализующая разновидность файловой системы поверх блочных устройств (или файлов имитирующих блочное устройство). PDisk обеспечивает контроль целостности данных (erasure кодирование групп секторов для восстановления данных при единичных bad-секторах, контроль целостности за счет checksums), прозрачное шифрование всех данных на диске, транзакционность операций с диском (подтверждение записи строго после fsync).
+
+PDisk содержит планировщик, который обеспечивает разделение полосы пропускания блочного устройства между несколькими клиентами (VDisk-ами). PDisk разделяет блочное устройство на чанки (размером порядка 128 мегабайт, допускаются чанки меньшего размера), каждым чанком единовременно может владеть не более 1 VDisk-а.  Также PDisk поддерживает recovery-log, общий для служебных записей PDiskа и всех VDisk-ов.
+  
+#### Yard
+  **Yard** - историческое название интерфейса к PDiskу. Позволяет VDisk-ам читать и писать данные в чанки и лог, резервировать чанки, удалять чанки, а также транзакционно получать и возвращать владение чанками. В некотором приближении можно считать Yard синонимом PDiskа.
+
+#### VDisk
+**VDisk (Virtual Disk)** - компонент, который обеспечивает хранения логоблобов BS-группы на PDiskе. VDisk хранит свои данные на PDiskе. Одному VDiskу соответствует один PDisk, но к одному PDiskу, обычно, привязано несколько VDiskов. В отличие от PDiskа, который скрывает за собой чанки и лог, VDisk предоставляет интерфейс на уровне LogoBlob и LogoBlobID типа: записать LogoBlob, прочитать данные по LogoBlobID, удалить набор LogoBlob по специальной команде. VDisk входит в BS-группу. Сам VDisk локален, но множество VDiskов входящих в BS-группу обеспечивают надежное хранение данных. VDiskи в группе синхронизируют данные между собой и реплицируют данные в случае потери. Очень грубо, набор VDiskов в BS-группе образуют распределенный RAID.
+
+#### VDisk Skeleton
+**Skeleton** - актор, обеспечивающий интерфейс к VDiskу (сам VDisk состоит из множества акторов). С некоторой погрешностью Skeleton можно считать синонимом VDiskа.
+  
+**SkeletonFront** - актор, который является проксирующим актором к Skeleton, обеспечивает контроль потока сообщений, поступающих в Skeleton.
+
+#### BlobStorage Group
+**BlobStorage Group** -- группа VDisk-ов на разных машинах, предназначенная для отказоустойчивого хранения данных (LogoBlob). Очень грубо - распределенный RAID.
+  
+  BS-группы бывают:
+  
+* Статическими. Сконфигурированная при помощи конфигурационного файла группа во время первоначального разворачивания кластера. Группа предназначена строго для хранения данных системных таблеток (BlobStorage Controller, Hive и так далее). Эта группа существует на протяжении всего времени жизни кластера. Изменение конфигурации этой группы сложно, хотя и возможно.
+* Динамическими. Группа, управлением конфигурацией которой осуществляет BlobStorage Controller. Динамические группы -- самый массовый сегмент BS-групп. Предназначены для хранения основного объема данных.
+
+#### BlobStorage Proxy
+**Blob Storage Proxy (BS Proxy, DS Proxy)** - играет роль библиотеки для выполнения операций с Blob Storage. Пользователем DS Proxy являются таблетки, которые пишут в/читают из Blob Storage. DS Proxy скрывает от пользователя распределенную натуру Blob Storage, задача DS Proxy сделать запись на кворум VDiskов, при необходимости делая повторы, контролируя поток записей/чтения, чтобы не перегрузить VDiskи.
+
+Технически DS Proxy реализована как акторный сервис, запускаемый **Warden** на каждой ноде для каждой BS-группы, обрабатывающий все запросы к группе (запись, чтение и удаление логоблобов, блокировка группы). При записи данных DS Proxy осуществляет erasure-кодирование данных разделяя LogoBlob-ы на part-ы, которые затем рассылаются на соответствующие VDiskи. При чтении DS Proxy осуществляет обратный процесс, получая part-ы от VDisk-ов и восстанавливая  LogoBlob-ы из них.
+
+#### Blob Storage Node Warden
+**Blob Storage Node Warden** (BS_NODE) - акторный cервис на каждой ноде кластера, запускающий на старте PDisk, VDisk и BlobStorage Proxy статических групп Blob Storage, а также взаимодействующий с BlobStorage Controller для запуска PDisk, VDisk и BlobStorage Proxy динамических групп. Запуск BlobStorage Proxy динамических групп происходит по запросу: Node Warden обрабатывает "не доставленные" сообщения к DS Proxy, запуская соответствующие DS Proxy и получая конфигурацию групп от BlobStorage Controller.
+
+#### Fail Realm
+**Fail Realm**. Группа Blob Storage представляет собой набор VDisk-ов, объединенных в один или более Fail Realm. Fail Realm содержит один или более Fail Domain. Коррелированный отказ двух VDisk-ов в рамках одного Fail Realm выше, чем отказ двух VDisk-ов из разных Fail Realm. По факту Fail Realm обычно соответствует понятию ЦОД или Availability Zone (AZ) в реальной жизни.
+
+#### Fail Domain
+**Fail Domain**. Группа Blob Storage представляет собой набор VDisk-ов, объединенных в один или более Fail Realm. Fail Realm содержит один или более Fail Domain. Коррелированный отказ двух VDisk-ов в рамках одного Fail Domain выше, чем отказ двух VDisk-ов из разных Fail Domain. По факту Fail Domain обычно соответствует понятию стойки (rack) в реальной жизни.
+
+#### Availability domain
+**Availability domain** - задумана как локализованная независимая сущность внутри системы. Условно - ЦОД или кросс-ЦОД инсталляция. Фактически, на данный момент не используется.
+
+#### Channel
+**Channel** - логический мост между таблеткой и Blob Storage. Таблетка может писать данные в разные Channel, а Channel отображается на конкретную BS-группу. Наличие нескольких Channel позволяет таблетке:
+
+* Записать данных больше, чем может хранить одна BS-группа;
+* Хранить разные LogoBlob на разных BS-группах, то есть с разным erasure encoding или на разных media (HDD, SSD).
+
+### Distributed Transactions
+**Distributed Transactions** - в системе реализована подсистема выполнения распределенных транзакций. Распределенные транзакции реализуются поверх слоя таблеток (обычно, хранящих данные, например Data Shards). Дело в том, что реализация Локальной базы вместе с инфраструктурой таблеток позволяют выполнять Локальные транзакции с уровнем serializable на уровне данных, хранящися в одной таблетке. Однако для транзакционного изменения данных, хранящихся в разных таблетках, необходим другой механизм.
+  
+Механизм распределенных транзакций, реализованный в системе, является вариацией на тему [Deterministic Transactions](http://cs-www.cs.yale.edu/homes/dna/papers/transactions-wodet11.pdf). Этот механизм позволяет выполнять ограниченный набор транзакций, для которых известен read и write набор ключей. Более сложные транзакции реализуются поверх Deterministic Transactions с использованием оптимистических блокировок (optimistic locks), а именно, транзакция состоит из нескольких deterministic transactions, которые берут блокировки на участниках транзакций и проверяют их на коммите.
+
+Далее описываются понятия, которые используются для выполнения deterministic transaction:
+  
+* **Prepare stage** - фаза, на которой регистрируется тело транзакции на всех шардах-участниках;
+* **Execute stage** - фаза, на которой происходит выполнение запланированной транзакции и формирование ответа. В некоторых случаях (например, тразнакции затрагивающие только один шард или консистентное чтение из снепшота) вместо prepare и execute проводится немедленное выполнение транзакции и формирование ответа;
+* **Dirty operations** - в случае readonly транзакций - похож на read uncommitted в базах данных - можно прочитать данные, которые еще не были закоммичены на диск. В случае write транзакций - сформировать ответ сразу после планирования, а не дожидаясь коммита выполнения транзакции на диск;
+* **RW set** - набор шардов, которые будут участвовать в выполнении распределенной транзакции. Состоит из объединения read-set - шардов, на которых будет проводится только чтение данных и write-set - шардов, в которых будут проводится модификации;
+* **ReadSet data** - данные, которые шарды-участники пересылают в процессе выполнения транзакции (например, метаданные снепшота данных в схемной транзакции копирования таблиц), в случае data транзакций могут содержать информацию о состоянии оптимистических блокировок, готовности шарда к коммиту или решении об отмене транзакции;
+* **Transaction proxy** (TX_PROXY) - сервис, который оркестрирует выполнение многих распределённых транзакций (последовательное выполнение фаз, планирование, агрегация результатов), а в случае прямой оркестрации другими акторами (например kqp data транзакций) используется для кеширования и выделения уникальных txid;
+* **Transaction flags (TxFlags)** - битовая маска флагов, которые тем или иным способом модифицируют выполнение транзакции;
+* **Transaction ID (txid)** - уникальный идентификатор, назначаемый каждой транзакции при её приеме;
+* **Transaction order ID** - уникальная идентификатор, назначаемый каждой транзакции при её планировании;
+* **PlanStep, Step** - логическое время, на которое планируется набор транзакций для выполнения;
+* **Mediator time** - логическое время, до которого (включительно) шард-участник должен знать весь план выполнения, используется для продвижения времени при отсутствии транзакций на конкретном шарде, определения возможности чтения из снепшота.
+
+
+### Data Model and User Interface
+#### Global Scheme
+**Global Scheme (Глобальная схема) или Схема базы данных** - схема данных хранящихся в базе данных. Система представляет собой набор таблиц и некоторых других сущностей, например топиков. Метаданные об этих сущностях и представляют собой глобальную схему. Термин используется в противовес **Local Scheme (Локальная схема)**, который используется для обозначения схемы данных внутри таблетки. Пользователь системы никогда не видит локальную схему, он работает только с глобальной схемой.
+
+#### MiniKQL
+**MiniKQL** - язык, позволяющий выразить одну deterministic transaction системы. Представляет собой функциональный, строго типизированный язык. Концептуально, язык описывает граф чтения из базы, проведения вычислений над прочитанными данными и запись результатов в базу и/или в специальный документ представляющий результат запроса (показывается пользователю). Транзакция MiniKQL должна явно задавать свой read set (читаемые данные) и предполагает детерминированность выбора веток выполнения (например нет random).
+  
+MiniKQL является низкоуровневым языком. Конечные пользователи системы видят только запросы на языке **YQL**, который в своей реализации опирается на MiniKQL.
+  
+#### YQL
+**YQL (YDB Query Language)** - высокоуровневый язык для работы с системой, является диалектом SQL.