Главная » SQL

Приложения DistSQL: Построение динамической распределенной базы данных

На чтение 12 мин. Просмотров 53 Опубликовано

Содержание
  1. Справочная информация
  2. Обзор
  3. Практический пример
  4. Вспомогательный запрос DistSQL
  5. Заключение
  6. Ссылки на проект:
  7. Ссылки
  8. Автор

Справочная информация

С момента выпуска ShardingSphere 5.0.0 DistSQL предоставляет экосистеме ShardingSphere мощные возможности динамического управления.

Благодаря DistSQL пользователи получили возможность делать следующее:

  • Создавать логические базы данных в режиме онлайн.
  • Динамически настраивать правила (например, шардинг, шифрование данных, разделение чтения/записи, обнаружение баз данных, теневые БД и глобальные правила).
  • Регулировать ресурсы хранения в режиме реального времени.
  • Мгновенное переключение типов транзакций.
  • Включение и отключение журналов SQL в любое время.
  • Предварительный просмотр результатов маршрутизации SQL.В то же время, в контексте все более разнообразных сценариев, создаются все новые и новые возможности DistSQL, а разнообразные ценные синтаксисы завоевывают популярность среди пользователей.

Обзор

В этой заметке в качестве примера, иллюстрирующего сценарии применения DistSQL и связанные с ним методы шардинга, рассматривается шардинг данных.

Ряд утверждений DistSQL объединяется с помощью практических примеров, чтобы дать вам полный набор практических схем управления шардингом DistSQL, которые создают и поддерживают распределенные базы данных посредством динамического управления. В данном примере будет использован следующий DistSQL:

Практический пример

Необходимые сценарии

  • Создайте две таблицы шардинга: t_order и t_order_item.
  • Для обеих таблиц шардинг базы данных осуществляется по полю user_id, а шардинг таблицы — по полю order_id.
  • Количество шардов составляет 2 базы данных * 3 таблицы, как показано на рисунке ниже:

Настройка среды

1.Подготовьте экземпляр базы данных MySQL для доступа. Создайте две новые базы данных: demo_ds_0 и demo_ds_1.

Здесь мы берем MySQL в качестве примера, но вы также можете использовать базы данных PostgreSQL или openGauss.

2.Разверните Apache ShardingSphere-Proxy 5.1.2 и Apache ZooKeeper. ZooKeeper действует как центр управления и хранит информацию метаданных ShardingSphere.

3.Настройте server.yaml в каталоге Proxy conf следующим образом:

mode:
  type: Cluster
  repository:
    type: ZooKeeper
    props:
      namespace: governance_ds
      server-lists: localhost:2181  # ZooKeeper address
      retryIntervalMilliseconds: 500
      timeToLiveSeconds: 60
      maxRetries: 3
      operationTimeoutMilliseconds: 500
  overwrite: false
rules:
  - !AUTHORITY
    users:
      - root@%:root
Войти в полноэкранный режим Выйти из полноэкранного режима

4.Запустите ShardingSphere-Proxy и подключите его к Proxy с помощью клиента, например:

mysql -h 127.0.0.1 -P 3307 -u root -p
Войти в полноэкранный режим Выйти из полноэкранного режима

Создание распределенной базы данных

CREATE DATABASE sharding_db;
USE sharding_db;
Войти в полноэкранный режим Выход из полноэкранного режима

Добавление ресурсов хранения
1.Добавьте ресурсы хранения, соответствующие подготовленной базе данных MySQL.

ADD RESOURCE ds_0 (
    HOST=127.0.0.1,
    PORT=3306,
    DB=demo_ds_0,
    USER=root,
    PASSWORD=123456
), ds_1(
    HOST=127.0.0.1,
    PORT=3306,
    DB=demo_ds_1,
    USER=root,
    PASSWORD=123456
);
Войти в полноэкранный режим Выход из полноэкранного режима

2.Просмотр ресурсов хранения

mysql> SHOW DATABASE RESOURCESG;
*************************** 1. row ***************************
                           name: ds_1
                           type: MySQL
                           host: 127.0.0.1
                           port: 3306
                             db: demo_ds_1
                            -- Omit partial attributes
*************************** 2. row ***************************
                           name: ds_0
                           type: MySQL
                           host: 127.0.0.1
                           port: 3306
                             db: demo_ds_0
                            -- Omit partial attributes
Войти в полноэкранный режим Выйти из полноэкранного режима

Добавление G в оператор запроса направлено на то, чтобы сделать формат вывода более читабельным, и не является обязательным.

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

Более подробную информацию об автоматическом шардинге можно найти по следующим ссылкам:

Знакомство с DistSQL — открытым исходным кодом и более мощным SQL

AutoTable: Ваш инструмент настройки шардинга, похожий на дворецкого

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

Генератор первичных ключей

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

1.Создайте генератор первичного ключа.

CREATE SHARDING KEY GENERATOR snowflake_key_generator (
TYPE(NAME=SNOWFLAKE)
);
Войти в полноэкранный режим Выйти из полноэкранного режима

2.Запросить генератор первичного ключа

mysql> SHOW SHARDING KEY GENERATORS;
+-------------------------+-----------+-------+
| name                    | type      | props |
+-------------------------+-----------+-------+
| snowflake_key_generator | snowflake | {}    |
+-------------------------+-----------+-------+
1 row in set (0.01 sec)
Войти в полноэкранный режим Выйти из полноэкранного режима

Алгоритм шардинга

1.Создайте алгоритм шардинга базы данных, используемый t_order и t_order_item совместно.

-- Modulo 2 based on user_id in database sharding
CREATE SHARDING ALGORITHM database_inline (
TYPE(NAME=INLINE,PROPERTIES("algorithm-expression"="ds_${user_id % 2}"))
);
Вход в полноэкранный режим Выйти из полноэкранного режима

2.Создайте различные алгоритмы чередования таблиц для t_order и t_order_item.

-- Modulo 3 based on order_id in table sharding
CREATE SHARDING ALGORITHM t_order_inline (
TYPE(NAME=INLINE,PROPERTIES("algorithm-expression"="t_order_${order_id % 3}"))
);
CREATE SHARDING ALGORITHM t_order_item_inline (
TYPE(NAME=INLINE,PROPERTIES("algorithm-expression"="t_order_item_${order_id % 3}"))
);
Вход в полноэкранный режим Выход из полноэкранного режима

3.Запросить алгоритм чередования

mysql> SHOW SHARDING ALGORITHMS;
+---------------------+--------+---------------------------------------------------+
| name                | type   | props                                             |
+---------------------+--------+---------------------------------------------------+
| database_inline     | inline | algorithm-expression=ds_${user_id % 2}            |
| t_order_inline      | inline | algorithm-expression=t_order_${order_id % 3}      |
| t_order_item_inline | inline | algorithm-expression=t_order_item_${order_id % 3} |
+---------------------+--------+---------------------------------------------------+
3 rows in set (0.00 sec)
Вход в полноэкранный режим Выйти из полноэкранного режима

Стратегия шардинга по умолчанию

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

Стратегия шардинга состоит из databaseStrategy и tableStrategy.

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

1.Создание стратегии шардинга базы данных по умолчанию

CREATE DEFAULT SHARDING DATABASE STRATEGY (
TYPE=STANDARD,SHARDING_COLUMN=user_id,SHARDING_ALGORITHM=database_inline
);
Войдите в полноэкранный режим Выйти из полноэкранного режима

2.Запросить стратегию по умолчанию

mysql> SHOW DEFAULT SHARDING STRATEGYG;
*************************** 1. row ***************************
                    name: TABLE
                    type: NONE
         sharding_column:
 sharding_algorithm_name:
 sharding_algorithm_type:
sharding_algorithm_props:
*************************** 2. row ***************************
                    name: DATABASE
                    type: STANDARD
         sharding_column: user_id
 sharding_algorithm_name: database_inline
 sharding_algorithm_type: inline
sharding_algorithm_props: {algorithm-expression=ds_${user_id % 2}}
2 rows in set (0.00 sec)
Войти в полноэкранный режим Выйти из полноэкранного режима

Стратегия разделения таблиц по умолчанию не настроена, поэтому стратегия по умолчанию для TABLE — NONE.

Правила шардинга

Генератор первичного ключа и алгоритм шардинга готовы. Теперь создайте правила шардинга.

1.t_order

CREATE SHARDING TABLE RULE t_order (
DATANODES("ds_${0..1}.t_order_${0..2}"),
TABLE_STRATEGY(TYPE=STANDARD,SHARDING_COLUMN=order_id,SHARDING_ALGORITHM=t_order_inline),
KEY_GENERATE_STRATEGY(COLUMN=order_id,KEY_GENERATOR=snowflake_key_generator)
);
Вход в полноэкранный режим Выйти из полноэкранного режима

DATANODES указывает узлы данных таблиц шардинга.

2.t_order_item

CREATE SHARDING TABLE RULE t_order_item (
DATANODES("ds_${0..1}.t_order_item_${0..2}"),
TABLE_STRATEGY(TYPE=STANDARD,SHARDING_COLUMN=order_id,SHARDING_ALGORITHM=t_order_item_inline),
KEY_GENERATE_STRATEGY(COLUMN=order_item_id,KEY_GENERATOR=snowflake_key_generator)
);
Вход в полноэкранный режим Выйти из полноэкранного режима

3.Запрос правил шардинга

mysql> SHOW SHARDING TABLE RULESG;
*************************** 1. row ***************************
                            table: t_order
                actual_data_nodes: ds_${0..1}.t_order_${0..2}
              actual_data_sources:
           database_strategy_type: STANDARD
         database_sharding_column: user_id
 database_sharding_algorithm_type: inline
database_sharding_algorithm_props: algorithm-expression=ds_${user_id % 2}
              table_strategy_type: STANDARD
            table_sharding_column: order_id
    table_sharding_algorithm_type: inline
   table_sharding_algorithm_props: algorithm-expression=t_order_${order_id % 3}
              key_generate_column: order_id
               key_generator_type: snowflake
              key_generator_props:
*************************** 2. row ***************************
                            table: t_order_item
                actual_data_nodes: ds_${0..1}.t_order_item_${0..2}
              actual_data_sources:
           database_strategy_type: STANDARD
         database_sharding_column: user_id
 database_sharding_algorithm_type: inline
database_sharding_algorithm_props: algorithm-expression=ds_${user_id % 2}
              table_strategy_type: STANDARD
            table_sharding_column: order_id
    table_sharding_algorithm_type: inline
   table_sharding_algorithm_props: algorithm-expression=t_order_item_${order_id % 3}
              key_generate_column: order_item_id
               key_generator_type: snowflake
              key_generator_props:
2 rows in set (0.00 sec)
Войти в полноэкранный режим Выход из полноэкранного режима

💡До сих пор были настроены правила шардинга для t_order и t_order_item.

Немного сложно? Что ж, вы можете пропустить шаги создания генератора первичного ключа, алгоритма шардинга и стратегии по умолчанию и завершить настройку правил шардинга за один шаг. Давайте посмотрим, как сделать это проще.

Синтаксис
Теперь, если нам нужно добавить таблицу шардинга t_order_detail, мы можем создать правила шардинга следующим образом:

CREATE SHARDING TABLE RULE t_order_detail (
DATANODES("ds_${0..1}.t_order_detail_${0..1}"),
DATABASE_STRATEGY(TYPE=STANDARD,SHARDING_COLUMN=user_id,SHARDING_ALGORITHM(TYPE(NAME=INLINE,PROPERTIES("algorithm-expression"="ds_${user_id % 2}")))),
TABLE_STRATEGY(TYPE=STANDARD,SHARDING_COLUMN=order_id,SHARDING_ALGORITHM(TYPE(NAME=INLINE,PROPERTIES("algorithm-expression"="t_order_detail_${order_id % 3}")))),
KEY_GENERATE_STRATEGY(COLUMN=detail_id,TYPE(NAME=snowflake))
);
Войти в полноэкранный режим Выйти из полноэкранного режима

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

Поэтому движок DistSQL автоматически использует входное выражение для создания алгоритма для правил шардинга t_order_detail. Теперь генератор первичного ключа, алгоритм шардинга и правила шардинга выглядят следующим образом:

1.Генератор первичного ключа

mysql> SHOW SHARDING KEY GENERATORS;
+--------------------------+-----------+-------+
| name                     | type      | props |
+--------------------------+-----------+-------+
| snowflake_key_generator  | snowflake | {}    |
| t_order_detail_snowflake | snowflake | {}    |
+--------------------------+-----------+-------+
2 rows in set (0.00 sec)
Вход в полноэкранный режим Выход из полноэкранного режима

2.Алгоритм шардинга

mysql> SHOW SHARDING ALGORITHMS;
+--------------------------------+--------+-----------------------------------------------------+
| name                           | type   | props                                               |
+--------------------------------+--------+-----------------------------------------------------+
| database_inline                | inline | algorithm-expression=ds_${user_id % 2}              |
| t_order_inline                 | inline | algorithm-expression=t_order_${order_id % 3}        |
| t_order_item_inline            | inline | algorithm-expression=t_order_item_${order_id % 3}   |
| t_order_detail_database_inline | inline | algorithm-expression=ds_${user_id % 2}              |
| t_order_detail_table_inline    | inline | algorithm-expression=t_order_detail_${order_id % 3} |
+--------------------------------+--------+-----------------------------------------------------+
5 rows in set (0.00 sec)
Войти в полноэкранный режим Выход из полноэкранного режима

3.Правила чередования

mysql> SHOW SHARDING TABLE RULESG;
*************************** 1. row ***************************
                            table: t_order
                actual_data_nodes: ds_${0..1}.t_order_${0..2}
              actual_data_sources:
           database_strategy_type: STANDARD
         database_sharding_column: user_id
 database_sharding_algorithm_type: inline
database_sharding_algorithm_props: algorithm-expression=ds_${user_id % 2}
              table_strategy_type: STANDARD
            table_sharding_column: order_id
    table_sharding_algorithm_type: inline
   table_sharding_algorithm_props: algorithm-expression=t_order_${order_id % 3}
              key_generate_column: order_id
               key_generator_type: snowflake
              key_generator_props:
*************************** 2. row ***************************
                            table: t_order_item
                actual_data_nodes: ds_${0..1}.t_order_item_${0..2}
              actual_data_sources:
           database_strategy_type: STANDARD
         database_sharding_column: user_id
 database_sharding_algorithm_type: inline
database_sharding_algorithm_props: algorithm-expression=ds_${user_id % 2}
              table_strategy_type: STANDARD
            table_sharding_column: order_id
    table_sharding_algorithm_type: inline
   table_sharding_algorithm_props: algorithm-expression=t_order_item_${order_id % 3}
              key_generate_column: order_item_id
               key_generator_type: snowflake
              key_generator_props:
*************************** 3. row ***************************
                            table: t_order_detail
                actual_data_nodes: ds_${0..1}.t_order_detail_${0..1}
              actual_data_sources:
           database_strategy_type: STANDARD
         database_sharding_column: user_id
 database_sharding_algorithm_type: inline
database_sharding_algorithm_props: algorithm-expression=ds_${user_id % 2}
              table_strategy_type: STANDARD
            table_sharding_column: order_id
    table_sharding_algorithm_type: inline
   table_sharding_algorithm_props: algorithm-expression=t_order_detail_${order_id % 3}
              key_generate_column: detail_id
               key_generator_type: snowflake
              key_generator_props:
3 rows in set (0.01 sec)
Вход в полноэкранный режим Выход из полноэкранного режима

Примечание: В операторе CREATE SHARDING TABLE RULE, DATABASE_STRATEGY, TABLE_STRATEGY и KEY_GENERATE_STRATEGY могут повторно использовать существующие алгоритмы.

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

После создания правил проверки конфигурации их можно проверить следующими способами:

Проверка распределения узлов

DistSQL предоставляет SHOW SHARDING TABLE NODES для проверки распределения узлов, и пользователи могут быстро узнать распределение таблиц шардов.

Мы видим, что распределение узлов таблицы шардов соответствует тому, что описано в требовании.

Предварительный просмотр SQL

Предварительный просмотр SQL также является простым способом проверки конфигураций. Его синтаксис — PREVIEW SQL:

1.Запрос без ключа шарда со всеми маршрутами

2.Укажите user_id для запроса с одним маршрутом базы данных

3.Укажите user_id и order_id с помощью маршрута по одной таблице.

Маршруты с одной таблицей сканируют наименьшее количество таблиц шарда и обеспечивают наивысшую эффективность.

Вспомогательный запрос DistSQL

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

Запрос неиспользуемых ресурсов

1.Синтаксис: SHOW UNUSED RESOURCES.

2.Пример:

Запрос неиспользуемого генератора первичного ключа

1.Синтаксис: SHOW UNUSED SHARDING KEY GENERATORS

2.Образец:

Запрос неиспользуемого алгоритма шардинга

1.Синтаксис: SHOW UNUSED SHARDING ALGORITHMS

2.Образец:

Запрос правил, использующих ресурсы целевого хранилища

1.Синтаксис: SHOW RULES USED RESOURCE.

2.Образец:

Можно запросить все правила, использующие ресурс, не ограничиваясь правилом Sharding Rule.

Запрос правил шардинга, использующих целевой генератор первичного ключа

1.Синтаксис: SHOW SHARDING TABLE RULES USED KEY GENERATOR.

2.Образец:

Правила разделения запросов, использующие целевой алгоритм

1.Синтаксис: SHOW SHARDING TABLE RULES USED ALGORITHM

2.Образец:

Заключение

В этой заметке в качестве примера для ознакомления с приложениями и методами DistSQL рассматривается сценарий шардинга данных.

DistSQL предоставляет гибкий синтаксис для упрощения операций. В дополнение к алгоритму INLINE, DistSQL поддерживает стандартный шардинг, составной шардинг, шардинг Hint и пользовательские алгоритмы шардинга. Больше примеров будет рассмотрено в ближайшем будущем.

Если у вас есть вопросы или предложения по Apache ShardingSphere, пожалуйста, опубликуйте их в списке проблем на GitHub.

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

ShardingSphere Github

ShardingSphere Twitter

ShardingSphere Slack

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

Вопросы на GitHub

Руководство для контрибьюторов

Ссылки

  1. Concept-DistSQL

  2. Concept-Distributed Primary Key

  3. Концепция-стратегия шардинга

  4. Концепция INLINE-выражения

  5. Встроенный алгоритм шардинга

  6. Руководство пользователя: DistSQL

Автор

Цзян Лонгтао
SphereEx Middleware R&D Engineer & Apache ShardingSphere Committer.

Лонгтао специализируется на R&D DistSQL и связанных с ним функциях.

Оцените статью
devanswers.ru
Добавить комментарий