Как использовать ShardingSphere-Proxy в реальных производственных сценариях — краткое руководство пользователя

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

Если не указано иное, в следующих примерах, когда мы говорим «база данных», мы имеем в виду MySQL.

Что делает ShardingSphere-Proxy?

ShardingSphere-Proxy позволяет пользователям использовать Apache ShardingSphere так же, как если бы это была собственная база данных.

Чтобы лучше понять, что такое ShardingSphere-proxy, давайте посмотрим на его определение, данное на официальном сайте Apache ShardingSphere:

ShardingSphere-Proxy — это прозрачный прокси базы данных, который предоставляет сервер базы данных, содержащий бинарные протоколы базы данных, разработанные для поддержки гетерогенных языков.
В настоящее время он поддерживает MySQL и PostgreSQL (и базы данных на основе PostgreSQL, такие как openGauss) и любые связанные с ними терминалы (такие как MySQL Command Client, https://blog.devart.com/mysql-command-line-client.html Workbench и т.д.), которые совместимы с протоколами MySQL или PostgreSQL для работы с данными. Это удобный для DBA инструмент.

Стоит отметить, что ShardingSphere-Proxy является сервисным процессом. С точки зрения программных соединений на стороне клиента он аналогичен базе данных MySQL.

Зачем вам нужен ShardingSphere-Proxy

ShardingSphere-Proxy является хорошим выбором, когда:

• используются правила шардинга или другие правила; поскольку данные будут распределены по нескольким экземплярам базы данных, что неизбежно сделает управление неудобным.
• разработчикам, не использующим Java, необходимо использовать возможности ShardingSphere.

1. Сценарии применения

Существует множество сценариев, в которых ShardingSphere-JDBC используется для шардинга данных. Если у вас есть таблица пользователей и необходимо выполнить горизонтальное масштабирование с помощью Hash для свойства User ID, то способ подключения клиента к базе данных будет выглядеть следующим образом:

Ниже приведены три реальных производственных сценария:

1. Инженер по тестированию хочет посмотреть информацию о пользователе с идентификатором 123456 в базах данных & таблиц, и вам нужно сказать ему, в какой подтаблице находится пользователь.
2. Вам нужно узнать общий прирост пользователей в 2022 году и общую информацию о пользователях для составления годового отчета.
3. Ваша компания собирается провести мероприятие в честь своего 8-летия, и вам необходимо предоставить список активных пользователей, зарегистрированных более 8 лет. Поскольку данные распределены по шардам базы данных и шардам таблиц, выполнить вышеупомянутые задачи непросто. Если каждый раз разрабатывать код для удовлетворения этих временных требований, это будет, мягко говоря, неэффективно. ShardingSphere-Proxy идеально подходит для таких сценариев.

ShardingSphere-Proxy скрывает реальные базы данных бэкенда, поэтому пользователь работает с клиентской частью так же, как и с базой данных.

Например, t_user разделен на несколько реальных таблиц на уровне базы данных, то есть от t_user_0 до t_user_9. При работе с ShardingSphere-Proxy на стороне клиента пользователю необходимо знать только одну логическую таблицу t_user, а маршрутизация к реальным таблицам выполняется внутри ShardingSphere-Proxy.

1. Логическая таблица: Логическое имя горизонтально масштабируемых баз данных/таблиц с одинаковой структурой. Логическая таблица — это логический идентификатор таблиц в SQL. Например, данные пользователя разбиты на 10 таблиц в соответствии со значащими цифрами первичного ключа, то есть от t_user_0 до t_user_9, а их общая логическая таблица называется t_user.

2. Фактическая таблица: Физическая таблица, фактически существующая в базах данных после масштабирования, то есть вышеупомянутые t_user_0 — t_user_9 .

2. Различия между ShardingSphere-JDBC и ShardingSphere-Proxy

Прочитав приведенное выше описание, вы, вероятно, почувствовали, что ShardingSphere-Proxy и ShardingSphere-JDBC очень похожи. Так в чем же различия между ними?

Узнайте больше о различиях между ними ниже:

1. ShardingSphere-JDBC — это пакет .jar. Его нижний слой завершает разбор, маршрутизацию, переписывание, выполнение и другие процессы SQL путем переписывания компонентов JDBC. Для реализации соответствующих функций в проекте необходимо добавить конфигурационные файлы, что делает его навязчивым для приложений.

2. ShardingSphere-Proxy — это служба процесса. В большинстве случаев он позиционируется как инструмент производительности для помощи операциям. Он маскируется под базу данных, что делает его неинтрузивным для приложений. Логика выполнения SQL в ShardingSphere-Proxy такая же, как и в ShardingSphere-JDBC, поскольку они используют одно и то же ядро.

Поскольку ShardingSphere-Proxy не мешает приложениям и имеет общее ядро с ShardingSphere-JDBC — так почему же нам все еще нужен ShardingSphere-JDBC?

1. Когда приложение напрямую работает с базами данных через ShardingSphere-JDBC, происходит только один сетевой ввод/вывод. Однако когда приложение подключается к ShardingSphere-Proxy, происходит один сетевой ввод-вывод, а затем ShardingSphere-Proxy работает с базами данных, и происходит еще один сетевой ввод-вывод, в общей сложности два сетевых запроса ввода-вывода.

2. Существует еще один уровень приложения под названием link, который с большей вероятностью вызовет узкое место в трафике данных и потенциальные риски для приложения. В целом, рекомендуется использовать приложение вместе с ShardingSphere-JDBC.

Конечно, ShardingSphere-JDBC и ShardingSphere-Proxy могут быть развернуты одновременно в гибридной архитектуре. ShardingSphere-JDBC подходит для высокопроизводительных легких приложений обработки транзакций в режиме онлайн (OLTP), разработанных на Java, а ShardingSphere-Proxy идеально подходит для приложений аналитической обработки в режиме онлайн (OLAP) и сценариев управления и эксплуатации баз данных sharding.

Руководство по быстрому запуску

Существует три метода установки ShardingSphere-Proxy: бинарный пакет, Docker и Helm. Также предусмотрены автономное развертывание и кластерное развертывание. Здесь в качестве примера мы рассмотрим автономный бинарный пакет:

1. Получите двоичный установочный пакет ShardingSphere-Proxy по этой ссылке;

2. Распакуйте его, а затем измените conf/server.yaml и файлы, начинающиеся с префикса config- для настройки шардинга, разделения чтения/записи и других функций;

3. Если вы используете Linux в качестве операционной системы, пожалуйста, запустите bin/start.sh. Для операционных систем Windows, пожалуйста, запустите bin/start.bat для загрузки ShardingSphere-Proxy.

Каталог файлов выглядит следующим образом:

├── LICENSE
├── NOTICE
├── README.txt
0009 ─ ─ bin #Start/stop script
0009 ─ ─ conf #service configuration, data sharding, read/write splitting, data encryption, and other function configuration files
├── lib # Jar package
└── licenses

1. Скопируйте Java-коннектор MySQL в пакет ext-lib
Загрузите драйвер mysql-connector-java-5.1.47.jar (Нажмите на ссылку для загрузки) или mysql-connector-java-8.0.11.jar (https://repo1.maven.org/maven2/mysql/mysql-connector-java/8.0.11/mysql-connector-java-8.0.11.jar) в пакет ext-lib. Примечание: в начальном каталоге нет пакета ext-lib, поэтому вам нужно создать его самостоятельно.

2. Измените конфигурационный файл conf/server.yaml.
Для server.yaml по умолчанию установлен режим работы Cluster Mode. Ниже описано, как настроить автономный режим работы.

mode:
Type: Standalone #Standalone mode
repository:
type: File
props:
Path: /Users/xxx/software/apache-shardingsphere-5.1.0-shardingsphere-proxy/file #persistent file paths such as metadata configuration
Overwrite: false #Overwrite the existing metadata？
Rules: #Verification Info
- !AUTHORITY
Users: #Init user
- root@%:root
- sharding@:sharding
provider:
type: ALL_PRIVILEGES_PERMITTED
- !TRANSACTION
defaultType: XA
provider Type: Atomikos
- !SQL_PARSER
sqlCommentParseEnabled: true
sqlStatementCache:
initialCapacity: 2000
maximum Size: 65535
concurrencyLevel: 4
parseTreeCache:
initialCapacity: 128
maximum Size: 1024
concurrencyLevel: 4
Props: #public configuration
max-connections-size-per-query: 1
kernel-executor-size: 16  # Infinite by default.
proxy-frontend-flush-threshold: 128  # The default value is 128.
proxy-opentracing-enabled: false
proxy-hint-enabled: false
sql-show: false
check-table-metadata-enabled: false
show-process-list-enabled: false
# Proxy backend query fetch size. A larger value may increase the memory usage of ShardingSphere Proxy.
# The default value is -1, which means set the minimum value for different JDBC drivers.
proxy-backend-query-fetch-size: -1
check-duplicate-table-enabled: false
proxy-frontend-executor-size: 0 # Proxy frontend executor size. The default value is 0, which means let Netty decide.
# Available options of proxy backend executor suitable: OLAP(default), OLTP. The OLTP option may reduce time cost of writing packets to client, but it may increase the latency of SQL execution
# and block other clients if client connections are more than `proxy-frontend-executor-size`, especially executing slow SQL.
proxy-backend-executor-suitable: OLAP
proxy-frontend-max-connections: 0 # Less than or equal to 0 means no limitation.
sql-federation-enabled: false
# Available proxy backend driver type: JDBC (default), ExperimentalVertx
proxy-backend-driver-type: JDBC

Примечание: если вы запускаете автономный ShardingSphere-Proxy и позже вам понадобится изменить конфигурацию прокси, вам необходимо установить mode.overwrite в true. Таким образом, ShardingSphere-Proxy будет перезагружать метаданные после запуска.

3. Запустите ShardingSphere-Proxy
Выполните команду bootup: sh bin/start.sh. Порт по умолчанию - 3307, порт можно заменить, добавив параметры в команду сценария запуска: sh bin/start.sh 3308 .

Чтобы проверить, успешно ли стартовал ShardingSphere-Proxy, выполните команду check log: tail -100f logs/stdout.log .

Следующая информация, размещенная в последней строке, означает, что запуск прошел успешно:

[INFO ] xxx-xx-xx xx:xx:xx.xxx [main] o.a.s.p.frontend.ShardingSphereProxy - ShardingSphere-Proxy Standalone mode started successfully

Сценарии и приложения

На основе реальных сценариев работы мы хотели бы показать вам, как вы можете использовать ShardingSphere-Proxy, чтобы оправдать ваши ожидания.

1. Инициализируйте базу данных & table

# CREATE DATABASE
CREATE DATABASE user_sharding_0;
CREATE DATABASE user_sharding_1;
# CREATE TABLE
use user_sharding_0;
CREATE TABLE `t_user_0` (
`id` bigint (20) NOT NULL,
`user_id` bigint (20) NOT NULL,
`create_date` datetime DEFAULT NULL,
PRIMARY KEY (`id`)) ENGINE = InnoDB DEFAULT CHARSET = latin1;
CREATE TABLE `t_user_1` (
`id` bigint (20) NOT NULL,
`user_id` bigint (20) NOT NULL,
`create_date` datetime DEFAULT NULL,
PRIMARY KEY (`id`)) ENGINE = InnoDB DEFAULT CHARSET = latin1;
use user_sharding_1;
CREATE TABLE `t_user_0` (
`id` bigint (20) NOT NULL,
`user_id` bigint (20) NOT NULL,
`create_date` datetime DEFAULT NULL,
PRIMARY KEY (`id`)) ENGINE = InnoDB DEFAULT CHARSET = latin1;
CREATE TABLE `t_user_1` (
`id` bigint (20) NOT NULL,
`user_id` bigint (20) NOT NULL,
`create_date` datetime DEFAULT NULL,
PRIMARY KEY (`id`)) ENGINE = InnoDB DEFAULT CHARSET = latin1;

2. Инициализация конфигурации шардинга в Proxy

schemaName: sharding_db
dataSources:
ds_0:
url: jdbc:mysql://127.0.0.1:3306/user_sharding_0?serverTimezone=UTC&useSSL=false
username: root
password: root
connectionTimeoutMilliseconds: 30000
idleTimeoutMilliseconds: 60000
maxLifetimeMilliseconds: 1800000
maxPoolSize: 50
minPoolSize: 1
ds_1:
url: jdbc:mysql://127.0.0.1:3306/user_sharding_1?serverTimezone=UTC&useSSL=false
username: root
password: root
connectionTimeoutMilliseconds: 30000
idleTimeoutMilliseconds: 60000
maxLifetimeMilliseconds: 1800000
maxPoolSize: 50
minPoolSize: 1
rules:
- !SHARDING
tables:
t_user:
actualDataNodes: ds_${0..1}.t_user_${0..1}
tableStrategy:
standard:
shardingColumn: user_id
shardingAlgorithmName: t_user_inline
keyGenerateStrategy:
column: user_id
keyGeneratorName: snowflake
bindingTables:
- t_user
defaultDatabaseStrategy:
standard:
shardingColumn: user_id
shardingAlgorithmName: database_inline
defaultTableStrategy:
none:
shardingAlgorithms:
database_inline:
type: INLINE
props:
algorithm-expression: ds_${user_id % 2}
t_user_inline:
type: INLINE
props:
algorithm-expression: t_user_${user_id % 2}
KeyGenerators:
snowflake:
type: SNOWFLAKE

3. Протестируйте конфигурацию шардинга

Используйте команду терминала MySQL для подключения к серверу ShardingSphere-Proxy.

Если вы развертываете базы данных в контейнерах Docker, вам необходимо добавить -h родной ip. Потому что доступ к 127.0.0.1 в контейнере блокируется.

#replace {xx} with actual parameter
mysql -h {ip} -u {username} -p{password} -P 3307
#example command
mysql -h 127.0.0.1 -u root -proot -P 3307

ShardingSphere-Proxy поддерживает Navicat MySQL, DataGrip, WorkBench, TablePlus и другие коннекторы управления базами данных.

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

mysql> show databases;
+-------------+
| schema_name |
+-------------+
| sharding_db |
+-------------+

1 строка в наборе (0,02 секунды)
Выполните новый оператор t_user, вставьте 6 частей данных пользователя (3 части для 2021 года и 3 части для 2022 года).

mysql> use sharding_db;
mysql> INSERT INTO t_user (id, user_id, create_date) values(1, 1, '2021-01-01 00:00:00'), (2, 2, '2021-01-01 00:00:00'), (3, 3, '2021-01-01 00:00:00'), (4, 4, '2022-01-01 00:00:00'), (5, 5, '2022-02-01 00:00:00'), (6, 6, '2022-03-01 00:00:00');
Query OK, 6 rows affected (0.16 sec)
mysql> select * from t_user;
+----+---------+---------------------+
| id | user_id | create_date         |
+----+---------+---------------------+
|  2 |       2 | 2021-01-01 00:00:00 |
|  4 |       4 | 2022-01-01 00:00:00 |
|  6 |       6 | 2022-03-01 00:00:00 |
|  1 |       1 | 2021-01-01 00:00:00 |
|  3 |       3 | 2021-01-01 00:00:00 |
|  5 |       5 | 2022-02-01 00:00:00 |
+----+---------+---------------------+

В это время данные находятся в user_sharding_0 и

Сценарий 1: Как найти информацию о данных?

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

mysql> select * from t_user where user_id = 1;
+----+---------+---------------------+
| id | user_id | create_date         |
+----+---------+---------------------+
|  1 |       1 | 2021-01-01 00:00:00 |
+----+---------+---------------------+
1 row in set (0.01 sec)

Сценарий 2: Как проверить рост пользователей в 2022 году и информацию о пользователях?

mysql> select count(*) from t_user where create_date > '2022-00-00 00:00:00';
+----------+
| count(*) |
+----------+
|        3 |
+----------+
1 row in set (0.10 sec)
mysql> select * from t_user where create_date > '2022-00-00 00:00:00';
+----+---------+---------------------+
| id | user_id | create_date         |
+----+---------+---------------------+
|  4 |       4 | 2022-01-01 00:00:00 |
|  6 |       6 | 2022-01-01 00:00:00 |
|  5 |       5 | 2022-01-01 00:00:00 |
+----+---------+---------------------+
3 rows in set (0.02 sec)

Сценарий 3: Как получить список активных пользователей, зарегистрированных более 8 лет?

Обратитесь к приведенному выше коду, и вы узнаете, как с этим справиться.

Заключение

В этой статье кратко изложены основные концепции ShardingSphere-Proxy на основе реальных производственных сценариев шардинга данных, и показано, как ShardingSphere-Proxy справляется с этими сценариями.

После прочтения этой статьи вы должны быть в состоянии:

Понимать, почему ShardingSphere-Proxy является отличным продуктом для помощи разработчикам в DevOps.
Знать различия между ShardingSphere-JDBC и ShardingSphere-Proxy, их преимущества и недостатки, а также то, как они реализованы.
Поскольку теперь вы лучше понимаете ShardingSphere-Proxy, мы уверены, что вам будет проще изучить его исходный код. Чтобы узнать больше о ShardingSphere, посетите официальный сайт Apache ShardingSphere или предыдущие блоги нашего сообщества, например, «Создание решения распределенной базы данных на основе PostgreSQL/openGauss».

Ссылки на проект Apache ShardingSphere:
ShardingSphere Github

ShardingSphere Twitter

ShardingSphere Slack

Руководство для вкладчиков

Ссылки

[1]Страница загрузки Apache ShardingSphere:
https://shardingsphere.apache.org/document/current/en/downloads/

[2] mysql-connector-java-5.1.47.jar: https://repo1.maven.org/maven2/mysql/mysql-connector-java/5.1.47/mysql-connector-java-5.1.47.jar

[3] mysql-connector-java-8.0.11.jar: https://repo1.maven.org/maven2/mysql/mysql-connector-java/8.0.11/mysql-connector-java-8.0.11.jar

[4] Официальный сайт Apache ShardingSphere: https://shardingsphere.apache.org/

[5] Создание решения распределенной базы данных на основе PostgreSQL/openGauss: https://shardingsphere.apache.org/blog/en/material/jan_28_blog_pg_create_a_distributed_database_solution_based_on_postgresql__opengauss/