Рефакторинг синтаксиса DistSQL | ShardingSphere 5.3.0 Глубокое погружение

Экземпляр объекта

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

Общие правила

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

Примечание. все глобальные правила в ShardingSphere имеют значения по умолчанию. Если у пользователей нет особых потребностей, просто оставьте значения по умолчанию.

Распределенные переменные

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

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

Переменные Dist включают SQL_SHOW, MAX_CONNECTIONS_SIZE_PER_QUERY, SQL_FEDERATION_TYPE и другие часто используемые атрибуты вычислительного узла, полностью охватывающие конфигурацию props в YAML.

Работа

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

Объект базы данных

Объекты базы данных используются для управления метаданными в логических базах данных и обеспечения операций над метаданными, такими как REFRESH DATABASE METADATA и EXPORT DATABASE CONFIGURATION.

Объект таблицы

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

Табличные объекты содержат общие правила, такие как Broadcast (широковещательная таблица), Encrypt (шифрование данных), Sharding (сегментирование данных) и Single (отдельная таблица), которые часто называются так же, как имя логической таблицы.

Объект отношения

Объекты отношения не используются для управления конкретной базой данных или таблицей. Они используются для описания отношений между набором объектов.

В настоящее время объекты отношения включают два типа: DB_Discovery Rule, который описывает отношения между узлами хранения, и Sharding Table Reference Rule, который описывает отношения между таблицами сегментирования.

Объект движения

Объекты трафика используются для управления трафиком данных в ShardingSphere, включая правила трафика, такие как Readwrite-splitting Rule и Shadow Rule.

Краткое содержание

Соедините вышеуказанные концепции вместе, и мы получим архитектурную диаграмму объектов, управляемых DistSQL, как показано ниже:

Эта диаграмма помогает нам лучше классифицировать DistSQL и систематически разрабатывать его синтаксис.

Синтаксический рефакторинг

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

Узел

Вычислительный узел

Описание: ключевое слово INSATNCE изменено на COMPUTE NODE。

Узел хранения

Описание:

Ключевое слово RESOURCE изменено на STORAGE NODE / STORAGE UNIT, что соответствует хранилищу на уровне экземпляра и хранилище на уровне базы данных соответственно.

Пункт STORAGE NODE зарезервирован и в настоящее время не используется.

Экземпляр объекта

Общие правила

Синтаксис глобального правила на этот раз не изменен.

Переменные Dist

Описание: DIST добавляется перед VARIABLE для представления распределенной переменной.

Задание МИГРАЦИЯ

Описание:

Ключевое слово PROCESS CONFIGURATION изменено на RULE.

Удалите операции CREATE и DROP, так как MIGRATION RULE имеет значения по умолчанию.

Другой синтаксис не настраивается.

Объект базы данных

Описание:

CONFIG заменено на CONFIGURATION, что более точно.

Оператор REFRESH DATABASE METADATA добавлен для извлечения конфигурации из центра управления для принудительного обновления локальных метаданных.

Объект таблицы

Таблица трансляции

Описание: ключевое слово SHARDING удалено из таблицы широковещательной рассылки.

Шифрование данных

Синтаксис, связанный с шифрованием данных, на этот раз не изменен. Пожалуйста, обратитесь к официальному документу [1].

Таблица разделения

Описание:

Удалите синтаксис для независимого создания алгоритмов сегментирования и распределенных генераторов идентификаторов и интегрируйте их в определение правила CREATE SHARDING TABLE RULE..

Другой синтаксис не настраивается.

Одна таблица

Описание: по умолчанию можно создать только один маршрутизатор с одной таблицей. И CREATE заменяется на SET.

Объект отношения

Обнаружение базы данных

Описание:

Удалите синтаксис для создания DB_DISCOVERY TYPE и HEARTBEAT независимо и интегрируйте их в определение правила CREATE DB_DISCOVERY RULE.

Другой синтаксис не настраивается.

Привязка таблицы

Описание: измените ключевое слово и добавьте ruleName для упрощения управления.

Объект движения

Разделение чтения/записи

Описание: нет серьезных изменений в синтаксисе разделения чтения/записи. Только RESOURCE заменяется на STORAGE_UNIT на основе изменения ключевого слова узла хранения. Например:

CREATE READWRITE_SPLITTING RULE ms_group_0 (
WRITE_STORAGE_UNIT=write_ds,
READ_STORAGE_UNITS(read_ds_0,read_ds_1),
TYPE(NAME="random")
);

Теневая база данных

Описание:

Удалите синтаксис для самостоятельного создания теневых алгоритмов и интегрируйте его в определение правила CREATE SHADOW RULE..

Добавьте операторы в ALTER и SHOW теневой алгоритм по умолчанию, соответствующий CREATE DEFAULT SHADOW ALGORITHM.

Оптимизация спецификации свойства

Помимо рефакторинга синтаксиса, это обновление еще больше упрощает работу с DistSQL для пользователей, в том числе:

• При ссылке на тип встроенной стратегии или тип алгоритма кавычки не заключайте.
• Тип значения в PROPERTIES изменен с string на literal, который поддерживает строки, целые числа и логические значения.

Пример

Например, когда пользователи создают правила сегментирования, алгоритм должен соответствовать следующим правилам:

TYPE(NAME="MOD",PROPERTIES("sharding-count"="4"))

• "MOD" — это имя типа алгоритма, принадлежащее строке, поэтому его необходимо заключить в кавычки;
• Хотя значение PROPERTIES равно "4", оно также является строкой и должно быть заключено в кавычки.

После этой оптимизации вы можете опускать кавычки при ссылке на встроенный тип алгоритма, а значение PROPERTIES также может опускать кавычки, если оно не является строкой.

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

TYPE(NAME=MOD,PROPERTIES("sharding-count"=4)).

Демо

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

При использовании оператора CREATE SHARDING TABLE RULE для создания правила автоматического сегментирования мы должны ссылаться на ресурсы хранилища в режиме RESOURCES(ds_0, ds_1). С этого момента он изменен на STORAGE_UNITS(ds_0, ds_1).

Далее ниже приведена демонстрация того, как использовать новый DistSQL со сценарием сегментирования в качестве примера.

• Создайте логическую базу данных

CREATE DATABASE sharding_db;
USE sharding_db;

• Зарегистрировать ресурсы хранения

REGISTER STORAGE UNIT ds_0 (
    HOST="127.0.0.1",
    PORT=3306,
    DB="ds_0",
    USER="root",
    PASSWORD="root"
),ds_1 (
    HOST="127.0.0.1",
    PORT=3306,
    DB="ds_1",
    USER="root",
    PASSWORD="root"
);

• Создание правил шардинга

CREATE SHARDING TABLE RULE t_order(
STORAGE_UNITS(ds_0,ds_1),
SHARDING_COLUMN=order_id,
TYPE(NAME=MOD,PROPERTIES("sharding-count"=4)),
KEY_GENERATE_STRATEGY(COLUMN=order_id,TYPE(NAME=SNOWFLAKE))
);

• Создайте таблицу шардинга

CREATE TABLE t_order (
  `order_id` int NOT NULL,
  `user_id` int NOT NULL,
  `status` varchar(45) DEFAULT NULL,
  PRIMARY KEY (`order_id`)
);

• Чтение и запись данных

INSERT INTO t_order (order_id, user_id, status) VALUES 
(1,1,'OK'),
(2,2,'OK'),
(3,3,'OK');

SELECT * FROM t_order;

• Удалить таблицу

DROP TABLE IF EXISTS t_order;

• Удалить правила шардинга

DROP SHARDING TABLE RULE t_order;

• Удалить узел хранения

UNREGISTER STORAGE UNIT ds_0, ds_1;

• Удалить логическую базу данных

DROP DATABASE sharding_db;

Заключение

Это все, что касается рефакторинга DistSQL. Пожалуйста, обратитесь к официальному документу [1] для получения дополнительной информации о синтаксисе DistSQL.

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

Ссылка

[1] Синтаксис DistSQL

[2] Проблема с GitHub