Архитектура

В этой главе описывается архитектура Tarantool Data Grid.

Основные архитектурные компоненты TDG изображены на схеме ниже.

Как видно из схемы, различные аспекты работы TDG разделены по соответствующим кластерным ролям: Storage, Connector, Runner и Core. Каждый экземпляр (узел) в кластере может иметь одну или более ролей. Подробнее о кластерных ролях рассказывается в разделе Кластерные роли.

Для хранения данных в TDG используется распределённое хранилище Tarantool. Его функциональность включает:

• хранение данных в оперативной памяти;
• репликацию данных в рамках набора реплик (replicaset);
• шардирование данных (сегментирование, sharding) по разным экземплярам.

Таким образом, TDG обеспечивает "из коробки" распределённое, высокопроизводительное, отказоустойчивое и масштабируемое хранение данных.

Кроме того, в TDG доступны другие функции хранения данных, такие как:

• Описание модели данных в формате Apache Avro;
• Проверка данных на целостность и соответствие модели, а также ремонтная очередь для объектов, не прошедших проверку.
• Возможность хранения истории изменений (версионирование).

Для доступа к данным TDG используются два основных способа: GraphQL и REST API.

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

Точки доступа создаются автоматически на основе модели данных и доступных сервисов Эти сервисы также можно вызывать через GraphQL и REST API.

TDG предоставляет возможность хранения и исполнения пользовательской бизнес-логики, например, валидации или преобразования данных.

Для добавления необходимой бизнес-логики нужно реализовать её в виде функций на языке Lua и загрузить их в TDG.

Загруженные функции можно использовать несколькими способами:

• Вызывать извне. Для этого нужно добавить их в конфигурацию доступных сервисов. Такие сервисы доступны для вызова через GraphQL, REST API или iproto (бинарный протокол Tarantool).
• Привязать к коннектору. В этом случае функции будут вызываться при каждом взаимодействии через этот коннектор, например, при поступлении нового объекта.
• Выполнять по расписанию. Для этого в TDG есть планировщик задач, который позволяет настроить автоматическое выполнение пользовательской бизнес-логики.

Для обмена данными с внешними системами в TDG используются коннекторы. Коннекторы бывают двух типов: входящие (input) для получения данных извне и исходящие (output) для отправки данных из TDG.

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

• Apache Kafka;
• Oracle Database и другие базы данных, поддерживающие ODBC;
• HTTP;
• Файлы;
• Бинарный протокол Tarantool (iproto).

TDG предоставляет инструменты для управления различными техническими функциями, в том числе:

• топологией кластера;
• моделью данных;
• сервисами;
• коннекторами;
• настройками безопасности.

Для управления конфигурацией TDG доступны два способа:

• Веб-интерфейс (WebUI) позволяет управлять TDG в визуальном режиме в браузере;
• Конфигурационные файлы позволяют хранить и распространять конфигурации в виде готовых артефактов.

Для мониторинга и расследования инцидентов TDG предоставляет метрики кластера в формате Prometheus. Метрики доступны для получения через REST API и визуализации в Grafana.

Встроенные инструменты безопасности TDG позволяют настроить доступ к различным функциям для пользователей и внешних систем. Для этого используется ролевая модель доступа. Роли могут быть приписаны как к профилям (для настройки доступа пользователей), так и к токенам приложений – средству авторизации приложений для взаимодействия с TDG. Для расследования инцидентов безопасности доступен журнал аудита.

Экземпляры TDG в кластере выполняют те или иные функции в соответствии с назначенными им кластерными ролями. Каждый экземпляр может иметь одну или несколько ролей.

В TDG существует четыре основных кластерных роли:

• Core: настройка и администрирование.
• Storage: проверка и хранение данных.
• Runner: исполнение бизнес-логики с помощью кода на Lua.
• Connector: обмен данными с внешними системами.

Еще одна кластерная роль, failover-coordinator, позволяет включать режим восстановления после сбоев с сохранением состояния (stateful failover). Подробности можно найти в документации Tarantool Cartridge.

Кластерные роли назначаются наборам реплик (replica set). Каждый экземпляр получает роли того набора реплик, в который он входит. В каждом наборе реплик все экземпляры взаимозаменяемы: на них хранится одно и то же состояние. Таким образом обеспечивается резервирование и устойчивость к сбоям.

Роль core используется для выполнения собственных функций TDG. Экземпляры с этой ролью обеспечивают управление моделью данных, сервисами, настройками безопасности и доступа и другими функциями. На этих экземплярах хранится внутренняя информация TDG и не хранятся пользовательские данные.

В кластере может быть только один набор реплик с ролью core.

Роль storage используется для хранения пользовательских данных. На экземплярах с этой ролью создаются спейсы Tarantool в соответствии с моделью данных.

Объединение экземпляров storage в наборы реплик обеспечивает шардирование и репликацию данных: каждый набор реплик хранит своё подмножество данных (shard), и это подмножество реплицируется на все экземпляры набора реплик.

Количество наборов реплик Storage определяется объемом хранимых данных.

Роль runner используется для выполнения пользовательской бизнес-логики. На этих экземплярах с помощью встроенного в Tarantool Lua-интерпретатора выполняются загруженные в TDG пользовательские скрипты: сервисы, задачи, обработчики входящих и исходящих данных.

Экземпляры runner не хранят состояние и используются только для исполнения кода. Таким образом, они все эквивалентны, и объединение в наборы реплик не влияет на их функциональность.

Роль connector используется для сетевого взаимодействия с внешними системами. На экземплярах с этой ролью создаются адреса (endpoints) для обращения к кластеру через GraphQL и REST API, а также коннекторы для подключения по различным протоколам: HTTP (JSON или SOAP), Apache Kafka или iproto.

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