Описание архитектуры

Кластер TCS может включать в себя следующие компоненты:

• Узлы Storage – для хранения данных и обработки запросов на чтение/запись
• Узлы Scheduler – для маршрутизации запросов на экземпляры Storage
• Узлы Coordinator – для управления переключением в случае сбоя экземпляров Storage
• etcd – для хранения и управления конфигурацией кластера
• Tarantool Cluster Manager (TCM) – для мониторинга и управления кластером
• Common Identity and Access Management (CIAM) – для управления доступом к кластеру

Состав кластера TCS зависит от режима работы кластера: проксированный или шардированный.

В проксированном режиме типовой кластер TCS состоит из следующих компонентов:

• Storage: один набор реплик из нескольких узлов (1 мастер-экземпляр + 1 или больше экземпляров-реплик), развернутый на 1 или более серверах – для хранения данных и обработки запросов на чтение/запись
• Scheduler: (необязательно без шардирования) один набор реплик из 1 и более узлов -- для маршрутизации запросов на экземпляры Storage
• Coordinator: (необязательно) по 1 экземпляру на каждый сервер с развернутыми экземплярами Storage -- для управления переключением в случае сбоя экземпляров Storage
• (необязательно) etcd – для хранения и управления конфигурацией кластера
• (необязательно) Tarantool Cluster Manager (TCM) – для мониторинга и управления кластером

В шардированном режиме кластер TCS состоит из аналогичных компонентов, но со следующими отличиями:

• в кластере может быть больше одного набора реплик с узлами типа Storage
• наличие набора реплик с узлами типа Scheduler становится обязательным

Наборов реплик с экземплярами Scheduler и Storage может быть несколько.

Любой набор реплик TCS можно разворачивать как на одном сервере, так и на нескольких серверах.

Клиентское приложение может устанавливать соединение с любым экземпляром в наборе реплик (Scheduler или Storage), по любому поддерживаемому TCS протоколу (HTTP, JDBC/ADBC). Однако тип экземпляров, доступных клиентам для прямого подключения, зависит от режима работы кластера TCS:

• в режиме проксирования – Scheduler (если они присутствуют в кластере) и Storage
• в режиме шардирования – только Scheduler

Все запросы принимаются в формате SQL.

Для обработки запросов на экземплярах Storage используется одинаковая логика. Конвейер обработки запроса включает в себя:

• парсер SQL-запросов
• кеш физических планов (для аналитических расчетов)
• планировщик с оптимизатором
• исполнитель плана запроса

В режиме шардирования тот же конвейер обработки действует также на экземплярах Scheduler.

В набор реплик Storage входят экземпляры двух видов:

• мастер-экземпляр (может быть только один)
• экземпляры-реплики (любое количество от 0 до 30)

Все экземпляры Storage в наборе реплик работают с одинаковым набором данных, поскольку все экземпляры-реплики связаны процессом непрерывной репликации с мастер-экземпляром. Других видов движения данных, кроме репликации, между экземплярами нет.

Запросы на чтение данных могут обрабатываться на всех экземплярах. Запросы на запись/изменение данных – только на мастер-экземпляре. Поэтому при установлении прямого соединения с экземпляром Storage из клиентского приложения следует явно выбирать экземпляр Storage, на котором будут выполняться запросы в рамках сессии. Если для обработки запроса на чтение/модификацию данных выбран экземпляр-реплика, то в ответ вернется ошибка.

Экземпляры Scheduler осуществляют автоматическую маршрутизацию запросов на экземпляры Storage.

Экземпляры Scheduler являются stateless-компонентами, т.е. хранение данных на экземплярах Scheduler не осуществляется.

В одном наборе реплик может быть любое количество узлов типа Scheduler (от 1 до 31).

Для отказоустойчивости в кластер TCS рекомендуется добавлять координаторы обработки сбоев (failover coordinator) из расчета 1 экземпляр Coordinator на каждый сервер с развернутыми экземплярами Storage. Один координатор должен быть активным, остальные – пассивными.

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

Между собой координаторы связаны через etcd, получая мета-информацию об активном координаторе.

etcd позволяет централизованно хранить конфигурацию кластера и управлять ей. На основе etcd построено управление кластером с помощью ATE и TCM.

Рекомендованный вариант установки TCS – с файлом конфигурации, хранящимся в etcd. См. подробнее Первичная установка системы.

Для тестовых целей возможна установка кластера TCS с локальным файлом конфигурации.

TCM (Tarantool Cluster Manager) предоставляет веб-интерфейс, который позволяет отслеживать состояние набора реплик TCS, а также управлять конфигурацией кластера (как альтернатива etcd). Взаимодействие TCM с конфигурацией кластера TCS идет только через etcd. См. подробнее Управление кластером с помощью TCM.

CIAM (Common Identity and Access Management) — это централизованная и унифицированная система управления идентификацией и доступом (IAM), выступающая в качестве базовой платформы безопасности для всех сервисов и приложений в рамках экосистемы продуктов VK Tech.

В связке с CIAM, TCS полноценно поддерживает аутентификацию с помощью JWT-токенов (JSON Web Token) и соответствует модели Сервера ресурсов (Resource Server).

На стороне TCS поддерживаются следующие режимы аутентификации:

• no (по умолчанию) – аутентификация выключена. Этот режим предназначен для тестирования. Для промышленной эксплуатации TCS он не подходит.
• simple – разрешены только запросы от клиентов, которые предоставляют данные базовой авторизации (общую для всех клиентов пару логин:пароль, указанную в конфигурации). Этот режим нужен для тестирования самого механизма аутентификации, а также для локальной разработки, когда нецелесообразно настраивать полноценную аутентификацию с помощью CIAM. Для промышленной эксплуатации TCS этот режим также не подходит.
• ciam – аутентификация пользователя производится с помощью OAuth2-продвайдера, входящего в состав CIAM. В этом режиме CIAM аутентифицирует каждого пользователя и выдает ему токен, который пользователь должен прикладывать ко всем запросам к TCS.

Аутентификация в режимах simple и ciam осуществляется для запросов на все HTTP-адреса, кроме /metrics (используется для мониторинга) и /routing_map (на стороне Scheduler).

Единый механизм проверки JWT-токенов (OAuth2/OIDC Bearer-аутентификация) реализован во всех компонентах TCS (Scheduler, Storage):

• Подпись токена валидируется через JWKS (JSON Web Key Set) в составе CIAM.
• Проверяются обязательные стандартные параметры полезной нагрузки (claims) в токенах, которые передают информацию о токене и его владельце: iss, aud, exp, sub.
• При успешной проверке формируется корректный AuthContext. Невалидные токены приводят к отказу в доступе.

Пользователи могут получить токены либо напрямую через CIAM (не привлекая TCS), либо указав свои учетные данные (логин:пароль) в запросе к TCS. Дальнейшее взаимодействие TCS и CIAM происходит по следующим сценариям:

• TCS при старте запрашивает в CIAM список выданных ключей JWK (JSON Web Key).
• Если клиент в запросе указывает полученный от CIAM токен, то TCS сначала проверяет его ключ в локальном списке. Если ключ на стороне TCS не найден, то TCS запрашивает обновление базы ключей в CIAM.
• Если клиент в запросе к TCS указывает свои учетные данные, то TCS запрашивает токен в CIAM по указанным учетным данным. Токен пользователю не возвращается.
• Когда в CIAM происходит ротация ключей, то при очередной аутентификации CIAM выписывает клиенту токен, подписанный ключом, про который информации в TCS еще нет. Когда такой клиент делает запрос в TCS, то TCS запрашивает обновление базы ключей в CIAM.

Tarantool Column Store – колоночная транзакционно-аналитическая СУБД, построенная на платформе Tarantool Enterprise Edition. TCS наследует от Tarantool базовые возможности хранения и масштабирования:

• данные хранятся в оперативной памяти;
• хранение персистентно;
• доступны механизмы репликации и шардирования.

TCS относится к гибридному классу систем хранения HTAP (Hybrid transactional/analytical processing). Хранилище данных реализовано средствами in-memory СУБД Tarantool. Для работы с данными в колоночном формате используется движок обработки данных MemCS. Такая архитектура позволяет добиться оптимальной производительности аналитических запросов (OLAP) наряду с характерной для Tarantool высокой производительностью при транзакционной нагрузке (OLTP).

Ниже объясняются детали реализации основных механизмов TCS:

• Колоночное хранение и блоки хранения;
• Чтение данных и буфер дельт;
• Доступ к данным;
• Вытеснение данных;
• Охлаждение данных;
• Режимы работы кластера.

Основное хранилище данных TCS работает с данными в колоночном формате.

Ключевое отличие колоночных СУБД от реляционных СУБД с табличным хранением -- использование колонки в качестве единицы хранения вместо таблицы. В реляционной СУБД все поля одного объекта хранятся рядом в виде одной строки таблицы. В свою очередь, в колоночной рядом располагаются все значения одного поля таблицы, а поля одного объекта разнесены по соответствующим колонкам и не хранятся вместе.

Использование колоночного формата позволяет оптимизировать работу TCS под нагрузкой, характерной для аналитических задач (OLAP), то есть при большом количестве запросов на чтение и вычисление агрегатов.

В TCS значения каждой колонки разделены на блоки одинакового размера. Размер одного блока - 8192 значения, он неизменяем.

Как гибридное решение, TCS предполагает работу под транзакционной нагрузкой на запись. Для консистентности чтения данных в таких условиях TCS использует представления для чтения (read view) – снимки хранилища данных в конкретный момент времени.

В каждый момент времени в TCS существует одно актуальное представление на чтение. Оно обновляется раз в rv_update_ms миллисекунд. Когда приходит запрос на чтение данных, для него используется актуальное представление.

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

Изменения данных, которые появляются в TCS в результате операций INSERT, UPDATE, DELETE, TRUNCATE, записываются в основное хранилище, но не учитываются в последнем созданном представлении. Таким образом, пользующиеся текущим представлением запросы не видят самые новые изменения. Для решения этой проблемы применяется специальный механизм — буфер дельт (delta buffer). Благодаря этому механизму система при обращении к представлению для чтения динамически подменяет в нем устаревшие записи на самые свежие версии из буфера дельт: добавляет в результат запроса данные, отсутствующих в текущем представлении на чтение, заменяет устаревшие данные на актуальные, фильтрует удаленные данные.

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

Доступ к данным осуществляется по протоколам SQL Arrow Flight и HTTP. Запросы по всем протоколам принимаются в формате SQL.

В зависимости от режима работы кластера, запросы можно отсылать:

• напрямую на узлы-хранилища (Storage) – они обрабатывают все виды запросов к данным;
• через узлы-маршрутизаторы (Scheduler) – они автоматически перенаправляют запросы на узлы Storage.

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

Вытеснение данных из TCS выполняется автоматически по мере заполнения хранилища, либо по истечении времени хранения данных.

См. подробнее раздел Вытеснение данных в Руководстве пользователя.

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

Охлаждение данных настраивается потаблично, с использованием механизма TTL (Time to Live). Он обеспечивает автоматическое удаление или перемещение данных по истечении заданного времени.

"Горячие" данные хранятся в основной таблице. До записи устаревших данных на диск (flush), они удаляются из основной таблицы и накапливаются в промежуточной таблице (limbo). Данные в limbo считаются уже вытесненными ("охлаждеными"). После вытеснения из limbo данные сохраняются на локальный или сетевой диск. Во время всех этих перемещений обеспечивается консистентность данных: они не дублируются и не пропадают.

В TCS оддерживаются следующие режимы чтения "горячих" и "охлажденных" данных:

• fallback (по умолчанию) – сначала пытаться читать "горячие" данные из памяти, если там пусто – читать "охлажденные" данные с диска и из промежуточной таблицы (limbo).

• skip – не читать "охлажденные" данные с диска и из промежуточной таблицы (limbo). Это режим чтения только "горячих" данных, когда запрос обращается исключительно к оперативной памяти. В этом случае обеспечивается минимальная задержка (единицы миллисекунд), но холодные данные остаются невидимыми. Этот режим идеален там, где важно только "здесь и сейчас".

• union – читать параллельно и "горячие" данные из памяти, и "охлажденные" данные с диска и из промежуточной таблицы (limbo), объединяя результаты. Поддерживаются любые агрегации (MAX, MIN, COUNT, AVG, SUM) по всему массиву данных. Этот режим подходит, например, для квартальных отчетов или аналитики по полной истории.

См. подробнее раздел Охлаждение данных в Руководстве пользователя.

Кластер TCS может работать в одном из двух режимов: проксирования или шардирования.

В режиме проксирования:

• Массив данных хранится в единственном наборе реплик Storage в кластере.
• Запросы от клиентов могут автоматически перенаправляться на узлы Storage с помощью узлов Scheduler.
• При необходимости возможно отсылать запросы напрямую на конкретный узел Storage.

В режиме шардирования:

• В разных наборах реплик Storage хранятся разные части общего массива данных.
• С помощью узлов Scheduler, запросы от клиентов автоматически перенаправляются на узлы Storage с учетом разбиения данных на шарды.
• Отсылать запросы напрямую на конкретный узел Storage запрещено.

Модель данных в TCS создается и изменяется с помощью инструкций SQL DDL.

TCS использует табличную модель данных, характерную для большинства СУБД, использующих SQL:

• Данные хранятся в таблицах;
• Один хранимый объект формирует одну строку таблицы;
• Структура таблицы определяется набором ее столбцов – колонок;
• Каждая колонка содержит данные одного типа.

Список поддерживаемых типов данных приведен в разделе Типы данных.

Для логической организации таблиц в TCS используется понятие схемы (schema) -- именованного пространства хранения таблиц. Каждая таблица может содержаться только в одной схеме. Имена таблиц в разных схемах могут повторяться. Схемы агрегируются в каталоги – аналоги баз данных.

Таким образом, полная иерархия хранения данных в TCS выглядит так:

 
каталог.схема.таблица

По умолчанию используется каталог tcs и схема public.

Например:

• Запрос CREATE TABLE a(i int) создаcт таблицу tcs.public.a.
• Запрос CREATE TABLE my_schema.a(i int) создаcт таблицу tcs.my_schema.a.
• Запрос SELECT * FROM customers вернет выборку из таблицы tcs.public.customers.

В TCS используются примитивные типы данных Apache Arrow. Поддерживаются следующие типы:

См. также Типы данных SQL.

Десятичные числа в TCS задаются в формате Apache Arrow и имеют следующие характеристики:

• ширина в битах (bit width): 128 или 256 бит
• масштаб (scale)
• точность (precision)

Ширина (bit width) может быть задана явно (decimal128 или decimal256), либо вычисляться автоматически на основании точности (precision).

Для чисел с явно заданной шириной (bit width) используются соответствующие значения точности (precision):

• для decimal128 точность = 38
• для decimal256 точность = 76

Точность (precision) также может быть задана явно или неявно:

• Если она задана явно (например, decimal(3, 2), здесь точность = 3), то:

  1. Выполняется следующая проверка для точности:

     1 <= precision <= 76

  2. Точность сводится к:

     • 38 (если указанное значение точности <= 38)
     • 76 (если указанное значение точности > 38)

• Если она задана неявно (например, decimal128(2)), то точность уже известна, исходя из ширины (например, для decimal128 используется точность = 38).

Масштаб (scale) может быть задан только явно. Например, decimal(3, 2) (здесь масштаб = 2).

Для масштаба всегда выполняется следующая проверка:

0 <= scale <= precision

Пример SQL-инструкции с десятичными числами:

 
CREATE TABLE t (    d1 decimal128  (9),    d2 decimal256  (1),    d3 decimal (4,  3),    d4 decimal (39, 2),)

где:

• decimal128(9)

  • bit width = 128
  • scale = 9
  • precision = 38

• decimal256(1)

  • bit width = 256
  • scale = 1
  • precision = 76

• decimal(4, 3)

  • bit width = 128
  • scale = 3
  • precision = 38 (поскольку 4 <= 38)

• decimal(39, 2)

  • bit width = 256
  • scale = 2
  • precision = 76 (поскольку 39 > 38)

TCS не поддерживает хранение массивов (данных типа array), но разрешает передачу массива в запросе. См. например функцию array_concat.