Реализация платформы X3 для транзакционных и аналитических нагрузок

Платформа MariaDB X3 решает задачи бизнес-проектирования, интегрируя:

MariaDB Server, ведущую открытую базу данных для предприятий;
MariaDB ColumnStore, колонную базу данных для оперативной аналитической обработки; и
MariaDB MaxScale, самый передовой прокси-сервер баз данных в мире.

MariaDB Server обеспечивает работу веб-сайтов и приложений в качестве современной реляционной базы данных. MariaDB Platform X3 расширяет возможности MariaDB Server, включая:

Транзакционные нагрузки (OLTP);
Аналитические нагрузки (OLAP); и
Комбинирование этих нагрузок в гибридных транзакционных и аналитических запросах (HTAP).

Данное руководство предназначено для DBA, разработчиков и операторов, помогая вам развернуть платформу X3 для запросов HTAP, открывая возможность анализа событий по мере их возникновения. Также это развертывание может масштабироваться от небольшого кластера, представленного в примерах ниже, для обработки большего количества транзакций, более объемной аналитической обработки и высокой доступности.

Маршрутизация запросов и потоковая передача данных платформы X3

При развертывании MariaDB Platform X3 для HTAP веб- и мобильные сервисы отправляют запросы в MariaDB MaxScale. В свою очередь, MaxScale распределяет эти запросы в зависимости от их назначения: транзакционные запросы отправляются в MariaDB Server для OLTP-нагрузок, а аналитические — в MariaDB ColumnStore для OLAP-операций.

В заднем плане изменения, внесенные в MariaDB Server, отправляются через MaxScale адаптеры потоковой передачи данных в ColumnStore, обеспечивая актуальность данных в ColumnStore.

platform-x3-routing-streaming-small

Масштабирование платформы X3

MariaDB Platform X3 может работать на отдельных серверах, но по мере усложнения приложения и увеличения нагрузки на базу данных каждый компонент может быть масштабирован в соответствии с потребностями вашей инфраструктуры.

platform-x3-scaleout

Для OLTP-операций наше примерное развертывание Platform X3 начинается с четырёх MariaDB Servers, настроенных как один мастер и три ведомых сервера, синхронизированные друг с другом в кластере репликации MariaDB. При масштабировании OLTP вы можете увеличить количество MariaDB Servers, что обеспечит высокую доступность, резервные копии репликации и отказ от работы.

Для OLAP-операций в нашем примере используется пять узлов MariaDB ColumnStore, два из которых настроены как модули пользователей (UM), а три как модули производительности (PM). При масштабировании OLAP вы можете увеличить количество UM для обработки большего количества входящих запросов или увеличить количество PM для лучшей обработки этих запросов.

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

Примеры использования

Пример розничного магазина

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

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

Пример розничного банка

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

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

В этом сценарии запросы, отображающие информацию о счете и общих транзакциях, являются OLTP-операциями. Отчеты, анализирующие транзакции, выполняемые клиентом по индивидуальным счетам или банком по всем клиентам, являются OLAP-операциями.

Пример Интернета Вещей

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

На техническом уровне покупка пачки или контейнера молока инициирует OLTP-запрос, а отчет об уровне запасов — OLAP-запрос. Данные OLTP используются для ведения журнала, а анализ данных OLAP обеспечивает понимание потерь продукции, моделей пополнения запасов и отказов оборудования.

Пример развертывания

В следующих разделах подробно описывается, как реализовать пример развертывания Platform X3 для HTAP. Первые шаги охватывают установку и развертывание серверов; следующие — конфигурацию для Репликации, Потоковой передачи данных и Сети трафика приложения, и, наконец, Тестирование с OLTP и OLAP запросами и операциями DML.

Развертывание MariaDB Servers

В нашем примере развертывания используется четыре сервера MariaDB Server для обработки OLTP-нагрузок, которые мы назвали Server-1 до Server-4. Они показаны слева на диаграмме нашего примера развертывания, в оранжевом цвете. В качестве движка хранения на этих серверах используется InnoDB.

Эти четыре сервера работают с MariaDB Server 10.3, установленными в соответствии с инструкциями на странице: Получение и обновление MariaDB.

Развертывание MariaDB ColumnStore Servers

В нашем примере развертывания используется пять серверов MariaDB ColumnStore для обработки OLAP-нагрузок. Два из этих серверов работают как серверы модулей пользователей, названные UM-1 и UM-2, и принимают трафик приложений от MaxScale. Другие три работают как серверы модулей производительности, названные PM-1 до PM-3, и выполняют распределённую обработку запросов.

На этих серверах установлена MariaDB ColumnStore 1.2.2 и установлена с помощью метода установки без root-пользователя и без распределённой установки, в соответствии с инструкциями на странице: Подготовка и установка MariaDB ColumnStore.

Развертывание MariaDB MaxScale Servers

В нашем примере развертывания используется два сервера MariaDB MaxScale. Первый сервер, названный MaxScale-1, обрабатывает потоковую передачу данных от серверов MariaDB Server на серверы MariaDB ColumnStore. Второй, названный MaxScale-2, выборочно проксирует трафик приложений на соответствующие серверы для OLTP и OLAP нагрузок.

На этих серверах установлена MariaDb MaxScale 2.3.1, установленная в соответствии с инструкциями на странице: Установка MariaDB MaxScale.

Настройка репликации

После установки программного обеспечения сервера на соответствующих хостах мы можем начать их настройку для использования. Для начала, наше примерное развертывание предполагает синхронизацию данных четырёх MariaDB Servers с помощью MariaDB Replication. Это позволяет обеспечить высокую доступность при OLTP-операциях, резервное копирование репликации и переключение на резервный сервер.

В MariaDB Replication один сервер работает как мастер, получая все записи от приложения и реплицируя изменения в кластере. Остальные серверы работают как ведомые, получая чтения от приложения и принимая записи только от сервера-мастера.

Для нашего примера развертывания Server-1 работает как мастер репликации, а Server-2 до Server-4 работают как ведомые сервера репликации.

Настройка `Server-1` (мастер)

Добавьте следующие строки в раздел [mysqld] файла /etc/my.cnf.d/server.cnf.

[mysqld]
server_id        = 1
log_bin          = mariadb-bin
binlog_format    = ROW
gtid_strict_mode = 1
log_error
log-slave-updates

При потоковой передаче данных из MariaDB Server в ColumnStore для анализа, MaxScale требует, чтобы сервера форматировали события двоичного журнала по каждой строке, изменённой операцией, а не по каждой операции. Таким образом, при развертывании кластера для HTAP, убедитесь, что системная переменная binlog_format на серверах MariaDB всегда имеет значение ROW.

Дополнительную информацию о этих и других системных переменных сервера см. на странице Системные переменные сервера.

Настройка `Server-2` (ведомый)

Добавьте следующие строки в раздел [mysqld] файла /etc/my.cnf.d/server.cnf:

[mysqld]
server_id        = 2
log-bin          = mariadb-bin
binlog-format    = ROW
gtid_strict_mode = 1
log_error
log-slave-updates

Настройка `Server-3` (ведомый)

Добавьте следующие строки в раздел [mysqld] файла /etc/my.cnf.d/server.cnf:

[mysqld]
server_id        = 3
log-bin          = mariadb-bin
binlog-format    = ROW
gtid_strict_mode = 1
log_error
log-slave-updates

Настройка `Server-4` (ведомый)

Добавьте следующие строки в раздел [mysqld] файла /etc/my.cnf.d/server.cnf:

[mysqld]
server_id        = 4
log-bin          = mariadb-bin
binlog-format    = ROW
gtid_strict_mode = 1
log_error
log-slave-updates

Перезапуск `Server-1` до `Server-4`

Перезапустите все четыре MariaDB Servers. Войдите на каждый сервер (Server-1, Server-2, Server-3 и Server-4), и выполните команду перезапуска systemctl на каждом сервере:

# systemctl restart mariadb.service

Создание пользователя репликации на `Server-1`

Когда серверы MariaDB работают как реплицируемые серверы, они реплицируют данные через клиентские подключения к мастер-серверу. Для того, чтобы эти серверы установили клиентские подключения, создайте пользователя репликации на мастер-сервере, Server-1, и предоставьте пользователю соответствующие привилегии для получения данных.

Подключитесь к мастер-серверу MariaDB через клиента:

$ mysql -u root -p -h <Server-1-ip> -P 3306

После подключения сбросьте мастер:

RESET MASTER;

Затем создайте пользователя репликации для MaxScale и серверов MariaDB-slave и предоставьте пользователю соответствующие привилегии:

CREATE USER 'repl'@'%' IDENTIFIED BY 'pass';
GRANT REPLICATION SLAVE ON *.* TO 'repl';
GRANT SELECT ON mysql.user TO 'repl';
GRANT SELECT ON mysql.db TO 'repl';
GRANT SELECT ON mysql.tables_priv TO 'repl';
GRANT SELECT ON mysql.roles_mapping TO 'repl';
GRANT SHOW DATABASES ON *.* TO 'repl';
GRANT REPLICATION CLIENT ON *.* TO 'repl';

Дополнительную информацию о репликации MariaDB см. в статье Настройка производительности с репликацией MariaDB.

Настройка и запуск репликации на `Server-2` по `Server-4`

На каждом сервере MariaDB-slave в вашей системе настройте его на репликацию данных с мастер-сервера и запустите процесс репликации. Выполните следующие действия на каждом сервере-следующем сервере (т. е. Server-2 по Server-4).

Сначала подключитесь к серверу-следующему серверу:

$ mysql -u root -h <slave-server-ip> -P 3306 -p

Если репликация в настоящее время выполняется, сбросьте мастер, чтобы вы могли обновить его конфигурацию:

RESET MASTER;

Выполните операцию CHANGE MASTER TO для настройки репликации со Server-1:

CHANGE MASTER TO
       MASTER_HOST='Server-1-ip',
       MASTER_USER='repl',
       MASTER_PASSWORD='pass';

Затем запустите реплицируемый сервер:

START SLAVE;

Вы можете проверить работу репликации с помощью оператора SHOW SLAVE STATUS.

SHOW SLAVE STATUS;

Настройка для потоковой передачи данных

В развертываниях HTAP единственные запросы, отправляемые в MariaDB ColumnStore, — это запросы, специфичные для рабочих нагрузок OLAP, которые не включают записи. Чтобы обновить ColumnStore новыми данными, записанными на серверах MariaDB, настройте MaxScale на сервере back-end, чтобы передавать записи в ColumnStore.

Настройка MaxScale

В нашем примере развертывания сервер MaxScale отвечает за передачу данных между серверами MariaDB и кластером MariaDB ColumnStore. На сервере MaxScale-1 отредактируйте файл конфигурации /etc/maxscale.cnf, добавив следующие строки, чтобы настроить его для потоковой передачи данных в ColumnStore с помощью Avro Listener.

Сначала настройте маршрутизатор репликации. Установите его так, чтобы он использовал конкретный server_id и двоичный журнал:

[replication-router]
type                    = service
router                  = binlogrouter
user                    = repl
password                = pass
server_id               = 5
master_id               = 1
Binlogdir               = /var/lib/maxscale
Mariadb10-compatibility = 1
filestem                = mariadb-bin

Затем настройте прослушиватель репликации:

[replication-listener]
type     = listener
service  = replication-router
protocol = MySQLClient
port     = 6603

MaxScale теперь слушает подключения к конфигурации на порту 6603. Это позволяет клиенту MariaDB настроить репликацию с помощью команд, аналогичных тем, которые управляют реплицируемым сервером. Он использует только имя пользователя и пароль для проверки подлинности подключения к конфигурации (креденциалы для подключения к серверу указаны в конфигурации ниже).

Далее настройте маршрутизатор для службы Avro.

[avro-router]
type    = service
router  = avrorouter
source  = replication-router
avrodir = /var/lib/maxscale

Это генерирует JSON-файлы из двоичных журналов, полученных от мастер-сервера MariaDB, и сохраняет их в каталоге avodir (т. е. /var/lib/maxscale/) с помощью маршрутизатора репликации.

Затем настройте прослушиватель для службы Avro, чтобы использовать определенный порт:

[avro-listener]
type     = listener
service  = avro-router
protocol = cdc
port     = 4001

После этого сохраните файл и перезапустите MaxScale, чтобы применить новую конфигурацию:

# sudo systemctl restart maxscale

Наконец, с помощью утилиты maxctrl создайте пользователя для Avro Router, чтобы отслеживать изменения данных. Этот пользователь обрабатывает потоковую передачу данных, которые MaxScale извлекает с серверов MariaDB в ColumnStore.

# maxctrl call command cdc add_user avro-router cdcuser cdc

Дополнительную информацию о маршрутизаторе Avro см. в разделе: Avro Router.

Настройка MaxScale как сервера-следующего сервера

Когда сервер MaxScale передает данные в MariaDB ColumnStore, он извлекает их с мастер-сервера с помощью того же процесса, который используют серверы-следующие серверы в MariaDB Replication. По сути, он работает как реплицируемый сервер, только вместо записи данных локально он передает записи в модули пользователей ColumnStore.

Подключитесь к MaxScale с помощью MariaDB Client. В отличие от подключения к серверам MariaDB ранее, используйте порт 6603 (который вы настроили выше в файле /etc/maxscale.cnf в качестве порта прослушивателя репликации).

$ mysql -h <MaxScale-1-ip> -P 6603 -u repl -p

Выполните операцию CHANGE MASTER TO для использования хоста мастер-сервера MariaDB (т. е. IP-адреса сервера-1) и порта для клиентских подключений (по умолчанию 3306). Установите имя пользователя и пароль, определенные для маршрутизатора репликации в /etc/maxscale.cnf выше.

CHANGE MASTER TO MASTER_HOST='<Server-1-ip>',
       MASTER_PORT=3306, 
       MASTER_USER='repl', 
       MASTER_PASSWORD='pass', 
       MASTER_LOG_FILE='mariadb-bin.000001';

Затем запустите сервер-следующий сервер:

START SLAVE;

После запуска процесса реплицируемого сервера на MaxScale вы можете проверить его с помощью оператора SHOW SLAVE STATUS, так же, как и при проверке состояния сервера-следующего сервера MariaDB.

SHOW SLAVE STATUS;

Если ошибок нет, MaxScale-1 сейчас работает как сервер-следующий сервер к Server-1.

Настройка пользователя CDC

На мастер-сервере MariaDB (т. е. Server-1) создайте пользователя для службы CDC. CDC Data Adapter выполняет аутентификацию с этим пользователем при получении данных с серверов MariaDB.

Подключитесь с помощью MariaDB Client к Server-1:

$ mysql -u root -p -h <Server-1-ip>

Затем выполните следующие операторы, чтобы создать пользователя CDC и предоставить ему необходимые привилегии:

CREATE USER 'cdcuser'@'%' IDENTIFIED BY 'cdc';
GRANT REPLICATION SLAVE ON *.* TO 'cdcuser';
GRANT SELECT ON mysql.user TO 'cdcuser';
GRANT SELECT ON mysql.db TO 'cdcuser';
GRANT SELECT ON mysql.tables_priv TO 'cdcuser';
GRANT SELECT ON mysql.roles_mapping TO 'cdcuser';
GRANT SHOW DATABASES ON *.* TO 'cdcuser';
GRANT REPLICATION CLIENT ON *.* TO 'cdcuser';

Установка адаптера потоковой передачи данных CDC

Адаптер потоковой передачи данных CDC MaxScale позволяет вам передавать двоичные события журналов с серверов MariaDB в кластеры MariaDB ColumnStore. Для его использования установите пакеты ColumnStore Bulk Write SDK и MaxScale CDC Adapter на выделенном хосте или на любом сервере MaxScale, который вы хотите использовать для потоковой передачи данных (MaxScale-1 в нашем примере развертывания).

Загрузки доступны по адресу: Загрузки.

Обратите внимание, что эти пакеты конфликтуют с установками ColumnStore. Не устанавливайте их ни на один из ваших серверов ColumnStore.

Чтобы установить ColumnStore Bulk Write SDK, загрузите пакет RPM из MariaDB, затем установите выпуски EPEL и зависимости пакетов с помощью YUM:

$ wget https://downloads.mariadb.com/Data-Adapters/mariadb-columnstore-api/1.2.2/centos/x86_64/7/Mariadb-columnstore-api-1.2.2-1-x86_64-centos7-cpp.rpm
$ sudo yum install epel-release
$ sudo yum install -y libuv libxml2 snappy python34
$ sudo yum install -y  mariadb-columnstore-api-1.2.2-1-x86_64-centos7-cpp.rpm

Чтобы установить адаптер CDC Data Adapter, загрузите пакет RPM из MariaDB, затем установите его с помощью YUM:

$ wget https://downloads.mariadb.com/Data-Adapters/mariadb-streaming-data-adapters/cdc-data-adapter/1.2.2/centos-7/mariadb-columnstore-maxscale-cdc-adapters-1.2.2-1-x86_64-centos7.rpm
$ sudo yum install -y mariadb-columnstore-maxscale-cdc-adapters-1.2.2-1-x86_64-centos7.rpm

Дополнительную информацию об установке адаптера см. в разделе Установка адаптеров.

Настройка адаптера CDC Data Adapter

После установки адаптера CDC Data Adapter вы можете настроить его для передачи данных в MariaDB ColumnStore. Это делается путем копирования файла конфигурации Columnstore.xml с одного из узлов ColumnStore на сервер MaxScale-1, где адаптер CDC Data Adapter может его использовать.

$ scp root@columnstore-host:/home/mysql/columnstore/etc/Columnstore.xml \
      ~/Columnstore.xml
$ sudo mv Columnstore.xml /etc

Обратите внимание, что установка MaxScale и адаптера CDC Data Adapter от имени root создает каталог /var/lib/mxs_adapter/. Если вы планируете запускать mxs_adapter как пользователя, не являющегося root, убедитесь, что пользователь может читать и записывать в этот каталог. Если нет, измените права доступа на права доступа вашего пользователя. Например,

$ sudo chown ec2-user /var/lib/mxs_adapter

Наконец, проверьте брандмауэр и SELinux. ColumnStore использует порты от 8600 до 8630, а также порты 8700 и 8800. Адаптер CDC Data Adapter использует те же порты для потоковой передачи данных с MaxScale-1 в ColumnStore. Проверьте каждый сервер, чтобы убедиться, что брандмауэр не блокирует эти порты. Кроме того, убедитесь, что SELinux имеет политику, разрешающую эти подключения, или что он работает в режиме разрешения.

Проверка потоковой передачи данных

После установки и настройки MaxScale и адаптера CDC Data Adapter вы можете выполнить проверки, чтобы убедиться, что он правильно настроен и может взаимодействовать и передавать данные с серверов MariaDB в кластер MariaDB ColumnStore. С помощью утилиты mxs_adapter вы можете подключиться к MaxScale и протестировать потоковую передачу данных.

Для тестирования этой функции сначала необходимо создать таблицы для хранения данных, передаваемых адаптером CDC Data Adapter. Сначала подключитесь к мастер-серверу MariaDB, Server-1, и создайте таблицу InnoDB для хранения тестовых данных:

CREATE TABLE test.t6(a INT, b INT) ENGINE=InnoDB;

Затем подключитесь к одному из модулей пользователей и создайте таблицу ColumnStore с тем же именем и схемой:

CREATE TABLE test.t6(a INT, b INT) ENGINE=ColumnStore;

Для потоковой передачи данных с серверов MariaDB в ColumnStore, запустите утилиту mxs_adapter. С сервера MaxScale-1 выполните следующую команду:

$ mxs_adapter -c /etc/ColumnStore.xml -u cdcuser -p cdc \
  	-h localhost -P 4001 -r 2 -d -n -z test t6

Используйте имя пользователя и пароль для пользователя CDC, созданного в предыдущем разделе. В конфигурации MaxScale порт 4001 задан для сервиса прослушивания.

Последние два аргумента говорят ему о передаче данных из таблицы t6 в базе данных test. Если вы хотите передать несколько таблиц, замените эти аргументы опцией -f, которая указывает путь к файлу списка таблиц. Файл должен иметь формат: имя базы данных и имя таблицы через табуляцию, по одной таблице на строку. Например,

$ cat tbl.lst
test t6
test t7
test t8

При запуске потоковой передачи данных утилита mxs_adapter начинает выводить сообщения в stdout. По мере добавления данных на серверы MariaDB вы можете проверить этот вывод, чтобы увидеть потоковую передачу двоичных событий в ColumnStore.

Для проверки этого начните вставлять данные в таблицу test.t6 на сервере Server-1. Это мастер-сервер в репликации MariaDB и единственный, принимающий операции записи.

INSERT INTO test.t6 VALUES (1,1);

INSERT INTO test.t6 VALUES (1,2);

INSERT INTO test.t6 VALUES (1,3);

INSERT INTO test.t6 VALUES (1,4);

INSERT INTO test.t6 VALUES (1,5);

Затем выполните операцию SELECT , чтобы увидеть какие данные доступны на серверах MariaDB для операций OLTP:

SELECT * FROM test.t6;
+----+----+
| a  | b  |
+----+----+
|  1 |  1 |
|  1 |  2 |
|  1 |  3 |
|  1 |  4 |
|  1 |  5 |
+----+----+
5 rows in set (0.010 sec)

Проверяя сообщения в журнале утилиты mxs_adapter, вы можете наблюдать, как эти INSERT операторы передаются с серверов MariaDB через MaxScale в ColumnStore:

2018-11-23 18:39:09 [main] Started thread 0x176b470
2018-11-23 18:39:09 [main] Started 1 threads
2018-11-23 18:39:09 [test.t6] Requesting data for table: test.t6
2018-11-23 18:39:09 [test.t6] INSERT INTO `test`.`t6` (`a`,`b`) VALUES (1,1)
2018-11-23 18:39:09 [test.t6] DML average: 12ms
2018-11-23 18:39:19 [test.t6] Read timeout
2018-11-23 18:39:22 [test.t6] INSERT INTO `test`.`t6` (`a`,`b`) VALUES (1,2)
2018-11-23 18:39:22 [test.t6] DML average: 4ms
2018-11-23 18:39:24 [test.t6] INSERT INTO `test`.`t6` (`a`,`b`) VALUES (1,3)
2018-11-23 18:39:24 [test.t6] DML average: 4ms
2018-11-23 18:39:26 [test.t6] INSERT INTO `test`.`t6` (`a`,`b`) VALUES (1,4)
2018-11-23 18:39:26 [test.t6] DML average: 4ms
2018-11-23 18:39:28 [test.t6] INSERT INTO `test`.`t6` (`a`,`b`) VALUES (1,5)
2018-11-23 18:39:28 [test.t6] DML average: 9ms

Затем вы можете выполнить аналогичный оператор SELECT для таблицы test.t6 на любом из модулей пользователей для MariaDB ColumnStore, чтобы убедиться, что данные теперь доступны для операций OLAP:

SELECT * FROM test.t6;
+----+----+
|  a | b  |
+----+----+
|  1 |  1 |
|  1 |  2 |
|  1 |  3 |
|  1 |  4 |
|  1 |  5 |
+----+----+
5 rows in set (0.010 sec)

Далее протестируйте другие операции записи с помощью оператора UPDATE или DELETE на сервере Server-1:

UPDATE test.t6 SET a = 2 WHERE b > 3;

SELECT * FROM test.t6;
+----+----+
| a  | b  |
+----+----+
|  1 |  1 |
|  1 |  2 |
|  1 |  3 |
|  2 |  4 |
|  2 |  5 |
+----+----+
5 rows in set (0.000 sec)

Используя сообщения в журнале адаптера CDC Data Adapter, вы можете наблюдать потоковую передачу двоичных событий для этой операции через MaxScale:

2018-11-23 18:44:18 [test.t6] Read timeout
2018-11-23 18:44:22 [test.t6] UPDATE `test`.`t6` SET `a` = 2, `b` = 4 WHERE `a` = 1 AND `b` = 4
2018-11-23 18:44:22 [test.t6] DML average: 12ms
2018-11-23 18:44:22 [test.t6] UPDATE `test`.`t6` SET `a` = 2, `b` = 5 WHERE `a` = 1 AND `b` = 5
2018-11-23 18:44:22 [test.t6] DML average: 13ms
2018-11-23 18:44:27 [test.t6] Read timeout

Как видно из сообщений в журнале, MaxScale обнаружил оператор UPDATE и передал его через адаптер CDC Data Adapter в ColumnStore. Затем адаптер CDC Data Adapter начинает выводить сообщения Read timeout , чтобы указать, что он завершил передачу и ожидает дополнительных двоичных событий с серверов MariaDB.

Вы можете подтвердить, что данные были успешно переданы, выполнив операцию SELECT в одном из модулей пользователя MariaDB ColumnStore:

Server-1

Обратите внимание, что строки 4 и 5 теперь содержат новые значения.

Настройка для трафика приложения

Когда ваше приложение отправляет запросы в Platform X3 для операций HTAP, оно не подключается напрямую ни к серверам MariaDB, ни к модулям пользователя MariaDB ColumnStore. Вместо этого оно подключается к серверу MaxScale, настроенному на селективную маршрутизацию запросов, гарантируя, что операции OLTP выполняются на серверах MariaDB, а операции OLAP — на ColumnStore.

Для лучшего понимания, как MaxScale распределяет запросы между серверами, мы установим демонстрационную базу данных банка и покажем, как обрабатывать платежи и анализировать данные о кредитах.

Наша демонстрационная база данных содержит следующие таблицы:

account — каждый запис описывает статические характеристики счета
client — каждый запис описывает характеристики клиента
client_accts — каждый запис связывает клиента со счетом
loan — каждый запис описывает кредит, предоставленный для данного счета

platform-x3-bank-db

С текущей конфигурацией наше демонстрационное развертывание будет транслировать эти новые таблицы с серверов MariaDB в ColumnStore через адаптер данных CDC, работающий на MaxScale-1. Затем мы настроим второй сервер MaxScale для селективной маршрутизации трафика вашего приложения для операций HTAP.

Подготовка сервера MariaDB и MariaDB ColumnStore для приема трафика от MaxScale

Создайте пользователя чтения для MaxScale на главном сервере MariaDB Server-1 и модулях пользователей ColumnStore. Предоставьте ему необходимые привилегии для работы.

CREATE USER 'maxscale' IDENTIFIED BY 'pass';
GRANT SELECT ON mysql.user TO 'maxscale';
GRANT SELECT ON mysql.db TO 'maxscale';
GRANT SELECT ON mysql.tables_priv TO 'maxscale';
GRANT SHOW DATABASES ON *.* TO 'maxscale';

Затем создайте пользователя записи для MaxScale на тех же серверах.

CREATE USER 'maxuser'@'%' IDENTIFIED BY 'maxpwd';
GRANT ALL ON *.* TO 'maxuser'@'%';

Создание схемы

Скачайте и распакуйте примерный набор данных на Server-1 и модуль пользователя ColumnStore из test-db. Этот файл test-db.zip, который распаковывается в директорию test-db/. Он содержит следующие SQL и CSV файлы:

$ unzip test-db.zip
$ ls test-db/
create-db-cs.sql
create-db-innodb.sql 
account.csv  
client_accts.csv  
client.csv  
loan.csv

На главном сервере MariaDB Server-1, перейдите в распакованную директорию и запустите клиент как пользователя записи maxuser, созданного выше для MaxScale:

$ cd test-db
$ mysql -u 'maxuser' -p

Используйте команду SOURCE для загрузки файла create-db-innodb.sql, чтобы инициализировать базу данных:

SOURCE create-db-innodb.sql;

Затем измените схему, добавив столбец баланса в таблицу bank.loan. Этот столбец будет использоваться в примерах ColumnStore ниже.

SET sql_log_bin = 0;
ALTER TABLE bank.loan ADD COLUMN balance decimal(10,2);
SET sql_log_bin = 1;

На модуле пользователя ColumnStore подключитесь из той же директории и с тем же пользователем:

$ cd test-db
$ mysql -u 'maxuser' -p

Затем используйте команду SOURCE для загрузки файла create-db-cs.sql.

SOURCE create-db-cs.sql;

На данном этапе мы создали базу данных банка и таблицы, загрузив данные на серверы MariaDB (хотя мы записывали только в Server-1, а главный сервер реплицировал данные на подчиненные серверы). Мы также создали базу данных банка и таблицы в MariaDB ColumnStore. В данный момент таблицы в MariaDB ColumnStore пустые.

Трансляция данных с серверов MariaDB на MariaDB ColumnStore

Далее мы начнем трансляцию данных с помощью утилиты mxs_adapter, чтобы данные, загруженные на серверы MariaDB, могли транслироваться в MariaDB ColumnStore. На MaxScale-1, создайте TSV-файл (разделенный табуляцией) с именем bank.lst с таблицами базы данных банка, которые мы хотим транслировать:

$ cat bank.lst
bank	account
bank	client
bank	client_accts
bank	loan

Теперь запустите утилиту mxs_adapter, указав этот файл с опцией -f для этого файла:

$ mxs_adapter -c /etc/Columnstore.xml -u cdcuser -p cdc \
      -h <maxscale-1-host> -P 4001 -r 50 -d -n -f bank.lst

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

2018-11-28 03:56:49 [bank.client_accts] client_id: 13971
2018-11-28 03:56:49 [bank.client_accts] account_id: 11362
2018-11-28 03:56:49 [bank.client_accts] ca_type: OWNER
2018-11-28 03:56:49 [bank.client_accts] ca_id: 13690
2018-11-28 03:56:49 [bank.client_accts] client_id: 13998
2018-11-28 03:56:49 [bank.client_accts] account_id: 11382
2018-11-28 03:56:49 [bank.client_accts] ca_type: OWNER
2018-11-28 03:56:49 [bank.client_accts] ca_id: 0
2018-11-28 03:56:49 [bank.client_accts] client_id:
2018-11-28 03:56:49 [bank.client_accts] account_id:
2018-11-28 03:56:49 [bank.client_accts] ca_type:
2018-11-28 03:56:52 [bank.account] Read timeout
2018-11-28 03:56:57 [bank.loan] Read timeout
2018-11-28 03:56:58 [bank.client] Flushing batch
2018-11-28 03:56:58 [bank.client] 21 rows, 0 transactions inserted over 10.1008 seconds. GTID = 0-1-23:5371
2018-11-28 03:56:59 [bank.client_accts] Flushing batch
2018-11-28 03:56:59 [bank.client_accts] 21 rows, 0 transactions inserted over 10.1153 seconds. GTID = 0-1-27:5371
2018-11-28 03:57:02 [bank.account] Read timeout

Когда все загруженные данные будут транслированы с серверов MariaDB в ColumnStore, вы увидите сообщения Read timeout в выводе. Это означает, что утилита mxs_adapter ожидает появления дополнительных двоичных событий на серверах MariaDB.

В этот момент, если вы выполните операцию SELECT COUNT(*) в MariaDB ColumnStore, вы должны получить следующие наборы результатов:

SELECT COUNT(*) FROM bank.account;
+----------+
| COUNT(*) |
+----------+
|     4502 |
+----------+
1 row in set (0.057 sec)

SELECT COUNT(*) FROM bank.client;
+----------+
| COUNT(*) |
+----------+
|     5371 |
+----------+
1 row in set (0.051 sec)

SELECT COUNT(*) FROM bank.loan;
+----------+
| COUNT(*) |
+----------+
|      684 |
+----------+
1 row in set (0.056 sec)

SELECT COUNT(*) FROM bank.client_accts;
+----------+
| COUNT(*) |
+----------+
|     5371 |
+----------+
1 row in set (0.027 sec)

Серверы MariaDB и ColumnStore теперь содержат одинаковые данные.

Настройка маршрутизации HTAP

В нашем демонстрационном развертывании трафик приложения проксируется через второй сервер MariaDB MaxScale для селективной маршрутизации запросов HTAP. В частности, это предполагает настройку сервера MaxScale-2 таким образом, что:

Все INSERT, UPDATE, DELETE запросы всегда маршрутизируются на Server-1 для (OLTP)
Все запросы SELECT к таблице кредитов всегда маршрутизируются в MariaDB ColumnStore (OLAP)
Все оставшиеся запросы чтения будут маршрутизироваться на любой сервер MariaDB.

Ниже приведена диаграмма конфигурации сервера MaxScale-2:

platform-x3-htap-routing

Вот файл конфигурации, который должен быть в /etc/maxscale.cnf на MaxScale-2, чтобы достичь вышеперечисленного.

[maxscale]
threads  = auto
sql_mode = default

## Identify the Master MariaDB Server: Server-1
[sw-db1]
type     = server
address  = <MariaDB-Server-1-IP>
port     = 3306
protocol = MariaDBBackend

## Identify the Slave MariaDB Server: Server-2
[sw-db2]
type     = server
address  = <MariaDB-Server-2-IP>
port     = 3306
protocol = MariaDBBackend

## Identify the Slave MariaDB Server: Server-3
[sw-db3]
type     = server
address  = <MariaDB-Server-3-IP>
port     = 3306
protocol = MariaDBBackend

## Identify the Columnstore Server: UM-1
[sw-mcs-um1]
type     = server
address  = <MariaDB-UM-1-IP>
port     = 3306
protocol = MariaDBBackend

## Monitor all servers
[MariaDB-Monitor]
type             = monitor
module           = mariadbmon
servers          = sw-db1,sw-db2,sw-db3,sw-mcs-um1
user             = maxuser
password         = maxpwd
monitor_interval = 10000

## Service to talk to the servers.
[MDB-Service]
type      = service
router    = readwritesplit
servers   = sw-db1,sw-db2
user      = maxuser
password  = maxpwd

## Listener that clients use to access the MariaDB Servers.
[MDB-Listener]
type     = listener
service  = MDB-Service
protocol = MariaDBClient
port     = 4009

## The MDB-Service abstracted as a server
[MDB-Service-as-server]
type     = server
address  = 127.0.0.1
port     = 4009
protocol = MariaDBBackend

## Service to talk to the ColumnStore UM
[CS-Service]
type           = service
router         = readconnroute
router_options = running
servers        = sw-mcs-um1
user           = maxuser
password       = maxpwd

## Listener that clients use to access the CS-Service.
[CS-Listener]
type     = listener
service  = CS-Service
protocol = MariaDBClient
port     = 4010

## CS-Service abstracted as a server
[CS-Service-as-server]
type     = server
address  = 127.0.0.1
port     = 4010
protocol = MariaDBBackend

## Filter the _datamart_ queries to the ColumnStore server and rest of the queries to the MariaDB Servers
[target-selector]
type     = filter
module   = namedserverfilter
match01  = (?i)SELECT.*loan
target01 = CS-Service-as-server
match02  = .*
target02 = MDB-Service-as-server

## Filter to replace loan table name without database qualifier, with bank.loan, so that the connection to ColumnStore knows which database to use
[loan-table-filter]
type      = filter
module    = regexfilter
options   = ignorecase
match     = \sloan\s
replace   = /* */  bank.loan /* */
log_trace = true
log_file  = /tmp/regexfilter.log

## Combines the two services as one
[HTAP-Service]
type                   = service
Router                 = schemarouter
ignore_databases_regex = .*
servers                = MDB-Service-as-server,CS-Service-as-server
Preferred_server       = MDB-Service-as-server
user                   = maxuser
password               = maxpwd
filters                = target-selector

## Listener clients use to access the combined service
[HTAP-Listener]
type     = listener
service  = HTAP-Service
protocol = MariaDBClient
port     = 4011

Затем запустите MaxScale:

# systemctl start maxscale

Тестирование трафика приложения HTAP

После настройки и развертывания серверов MariaDB, ColumnStore и MaxScale вы можете начать тестирование демонстрационного развертывания HTAP. Приложение подключается ко второму серверу MaxScale, MaxScale-2, на порту 4011, где выполняется селективная маршрутизация запросов:

Все INSERT, UPDATE, DELETE запросы всегда маршрутизируются на Server-1 (OLTP)
Все запросы SELECT к таблице кредитов всегда маршрутизируются в MariaDB ColumnStore (OLAP)
Все оставшиеся запросы чтения маршрутизируются на любой сервер MariaDB (OLTP)

Подключение приложения к сервису MaxScale HTAP

Из вашего приложения используйте MariaDB Client для подключения к сервису MaxScale HTAP.

$ mysql -h <maxscale2-host> -P 4011 -u maxuser -p

Это те же параметры командной строки, что и при подключении к серверу MariaDB, но вместо отдельного сервера вы подключаетесь к MaxScale, который отправляет запросы на серверы или в один из модулей ColumnStore.

Используйте значение пароля 'maxpwd', которое вы ранее установили для этого пользователя.

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

Конфигурация сервера MariaDB MaxScale выше определяет запросы к таблицам, отличным от bank.loan, как транзакционные и маршрутизирует их на серверы MariaDB, а не в ColumnStore. Вы можете определить, на каком кластере серверов выполняется запрос, используя системную переменную version_comment.

SELECT *, @@version_comment FROM bank.account LIMIT 5;
+------------+-------------+------------------+------------+-------------------+
| account_id | district_id | frequency        | a_d        | @@version_comment |
+------------+-------------+------------------+------------+-------------------+
|        576 |          55 | POPLATEK MESICNE | 1993-01-01 | MariaDB Server    |
|       3818 |          74 | POPLATEK MESICNE | 1993-01-01 | MariaDB Server    |
|        704 |          55 | POPLATEK MESICNE | 1993-01-01 | MariaDB Server    |
|       2378 |          16 | POPLATEK MESICNE | 1993-01-01 | MariaDB Server    |
|       2632 |          24 | POPLATEK MESICNE | 1993-01-02 | MariaDB Server    |
+------------+-------------+------------------+------------+-------------------+
5 rows in set (0.039 sec)

Поскольку MaxScale маршрутизирует этот запрос как транзакционную операцию, системная переменная version_comment возвращает MariaDB Server.

Аналитические запросы

Конфигурация сервера MariaDB MaxScale выше определяет запросы к таблице bank.loans как аналитические запросы и маршрутизирует их на модули пользователей MariaDB ColumnStore, а не на серверы MariaDB. Вы можете определить, на каком кластере серверов выполняется запрос, используя системную переменную version_comment.

SELECT loan_id, account_id, amount, duration, payments,  @@version_comment 
FROM loan LIMIT 5;
+---------+------------+-----------+----------+----------+---------------------+
| loan_id | account_id | amount    | duration | payments | @@version_comment   |
+---------+------------+-----------+----------+----------+---------------------+
|       0 |          0 |      0.00 |        0 |     0.00 | Columnstore 1.2.1-1 |
|    5314 |       1787 |  96396.00 |       12 |  8033.00 | Columnstore 1.2.1-1 |
|    5316 |       1801 | 165960.00 |       36 |  4610.00 | Columnstore 1.2.1-1 |
|    6863 |       9188 | 127080.00 |       60 |  2118.00 | Columnstore 1.2.1-1 |
|    5325 |       1843 | 105804.00 |       36 |  2939.00 | Columnstore 1.2.1-1 |
+---------+------------+-----------+----------+----------+---------------------+

Поскольку MaxScale маршрутизирует запрос как аналитическую операцию, системная переменная version_comment указывает на сервер ColumnStore.

Операции DML

Конфигурация сервера MariaDB MaxScale выше определяет операции манипулирования данными, такие как INSERT, UPDATE и DELETE, как транзакционные и маршрутизирует эти операции на серверы MariaDB. Другой сервер MaxScale затем транслирует изменения в ColumnStore.

Выполните операцию UPDATE для установки начального баланса для кредита:

UPDATE bank.loan SET balance = amount WHERE loan_id = 5314;

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

SELECT loan_id, account_id, amount, payments, @@version_comment 
FROM bank.loan WHERE loan_id = 5314;
+---------+------------+----------+----------+-----------+---------------------+
| loan_id | account_id | amount   | payments |  balance  | @@version_comment   |
+---------+------------+----------+----------+-----------+---------------------+
|    5314 |       1787 | 96396.00 |  8033.00 |  96369.00 | Columnstore 1.2.1-1 |
+---------+------------+----------+----------+-----------+---------------------+
1 row in set (0.113 sec)

Баланс кредита был установлен в его первоначальное значение полученных средств.

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

UPDATE bank.loan SET balance = balance - payments WHERE loan_id = 5314;

Затем запросите кредит, чтобы просмотреть обновленные строки в ColumnStore:

SELECT loan_id, account_id, amount, payments, @@version_comment 
FROM bank.loan WHERE  loan_id = 5314;
+---------+------------+----------+----------+----------+---------------------+
| loan_id | account_id | amount   | payments | balance  | @@version_comment   |
+---------+------------+----------+----------+----------+---------------------+
|    5314 |       1787 | 96396.00 |  8033.00 | 88336.00 | Columnstore 1.2.1-1 |
+---------+------------+----------+----------+----------+---------------------+
1 row in set (0.094 sec)

Баланс кредита теперь уменьшен, чтобы отразить платежи по счету. MaxScale также транслировал данные о внесенных изменениях в ColumnStore.

Дополнительная информация

Получение продуктов

Когда вы готовы установить MariaDB Platform X3, перейдите на страницу Загрузки и выберите Platform X3. Если вы используете дистрибутив Linux на основе RPM или APT, вы можете настроить репозитории сервера для его установки через менеджер пакетов.

Документация

Документация по продуктам MariaDB доступна в Библиотеке. Для получения документации по конкретным продуктам, см. ссылки ниже:

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

© 2023 MariaDB
Licensed under the Creative Commons Attribution 3.0 Unported License and the GNU Free Documentation License.
https://mariadb.com/kb/en/sample-platform-x3-implementation-for-transactional-and-analytical-workloads/

Реализация платформы X3 для транзакционных и аналитических нагрузок

Маршрутизация запросов и потоковая передача данных платформы X3

Масштабирование платформы X3

Примеры использования

Пример розничного магазина

Пример розничного банка

Пример Интернета Вещей

Пример развертывания

Развертывание MariaDB Servers

Развертывание MariaDB ColumnStore Servers

Развертывание MariaDB MaxScale Servers

Настройка репликации

Настройка Server-1 (мастер)

Настройка Server-2 (ведомый)

Настройка Server-3 (ведомый)

Настройка Server-4 (ведомый)

Перезапуск Server-1 до Server-4

Создание пользователя репликации на Server-1

Настройка и запуск репликации на Server-2 по Server-4

Настройка для потоковой передачи данных

Настройка MaxScale

Настройка MaxScale как сервера-следующего сервера

Настройка пользователя CDC

Установка адаптера потоковой передачи данных CDC

Настройка адаптера CDC Data Adapter

Проверка потоковой передачи данных

Настройка для трафика приложения

Подготовка сервера MariaDB и MariaDB ColumnStore для приема трафика от MaxScale

Создание схемы

Трансляция данных с серверов MariaDB на MariaDB ColumnStore

Настройка маршрутизации HTAP

Тестирование трафика приложения HTAP

Подключение приложения к сервису MaxScale HTAP

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

Аналитические запросы

Операции DML

Дополнительная информация

Получение продуктов

Документация

Настройка `Server-1` (мастер)

Настройка `Server-2` (ведомый)

Настройка `Server-3` (ведомый)

Настройка `Server-4` (ведомый)

Перезапуск `Server-1` до `Server-4`

Создание пользователя репликации на `Server-1`

Настройка и запуск репликации на `Server-2` по `Server-4`