Архитектура¶
В этой главе описывается архитектура Tarantool Data Grid.
Основные архитектурные компоненты TDG изображены на схеме ниже.
![Архитектурная диаграмма](https://www.tarantool.io/en/tdg/latest/_images/architecture.png)
Как видно из схемы, различные аспекты работы TDG разделены по
соответствующим кластерным ролям: Storage
, Connector
, Runner
и
Core
. Каждый экземпляр (узел) в кластере может иметь одну или более ролей.
Подробнее о кластерных ролях рассказывается в разделе Кластерные роли.
Хранение данных: Tarantool¶
Для хранения данных в TDG используется распределённое хранилище Tarantool. Его функциональность включает:
хранение данных в оперативной памяти;
репликацию данных в рамках набора реплик (replicaset);
шардирование данных (сегментирование, sharding) по разным экземплярам.
Таким образом, TDG обеспечивает “из коробки” распределённое, высокопроизводительное, отказоустойчивое и масштабируемое хранение данных.
Кроме того, в TDG доступны другие функции хранения данных, такие как:
Описание модели данных в формате Apache Avro;
Проверка данных на целостность и соответствие модели, а также ремонтная очередь для объектов, не прошедших проверку.
Возможность хранения истории изменений (версионирование).
Доступ к данным: GraphQL и REST API¶
Для доступа к данным TDG используются два основных способа: GraphQL и REST API.
Оба способа поддерживают запросы с использованием индексов (первичных, вторичных и составных), операторы сравнения, множественные условия и другие возможности выборки данных.
Точки доступа создаются автоматически на основе модели данных и доступных сервисов. Эти сервисы также можно вызывать через GraphQL и REST API.
Исполнение бизнес-логики: Lua¶
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). Каждый экземпляр получает роли того набора реплик, в который он входит. В каждом наборе реплик все экземпляры взаимозаменяемы: на них хранится одно и то же состояние. Таким образом обеспечивается резервирование и устойчивость к сбоям.
![Архитектура кластерных ролей](https://www.tarantool.io/en/tdg/latest/_images/arch-cluster-roles.png)
Роль Core¶
Роль core
используется для выполнения собственных функций TDG.
Экземпляры с этой ролью обеспечивают управление моделью данных, сервисами, настройками
безопасности и доступа и другими функциями. На этих экземплярах хранится внутренняя
информация TDG и не хранятся пользовательские данные.
В кластере может быть только один набор реплик с ролью core
.
Роль Storage¶
Роль storage
используется для хранения пользовательских данных. На экземплярах
с этой ролью создаются спейсы
Tarantool в соответствии с моделью данных.
Объединение экземпляров storage
в наборы реплик обеспечивает шардирование
и репликацию данных: каждый набор реплик хранит своё подмножество данных (shard),
и это подмножество реплицируется на все экземпляры набора реплик.
Количество наборов реплик Storage определяется объемом хранимых данных.
Роль Runner¶
Роль runner
используется для выполнения пользовательской
бизнес-логики. На этих экземплярах с помощью
встроенного в Tarantool Lua-интерпретатора выполняются загруженные в TDG
пользовательские скрипты: сервисы, задачи, обработчики входящих и исходящих данных.
Экземпляры runner
не хранят состояние и используются только для исполнения кода.
Таким образом, они все эквивалентны, и объединение в наборы реплик не влияет на их
функциональность.
Роль Connector¶
Роль connector
используется для сетевого взаимодействия с внешними системами.
На экземплярах с этой ролью создаются адреса (endpoints) для обращения к кластеру
через GraphQL и REST API, а также коннекторы для подключения
по различным протоколам: HTTP (JSON или SOAP), Apache Kafka или iproto.
Экземпляры connector
не хранят состояние и используются только для внешних подключений.
Таким образом, они все эквивалентны, и объединение в наборы реплик не влияет на их
функциональность.