Перевод текста на русский язык:

Разделение чтения и записи, разделение на библиотеки, таблицы, библиотеки и таблицы.

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

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

Зачем разделять таблицы и библиотеки?

Когда объём данных в бизнес-таблицах становится большим, любые операции CRUD (создание, чтение, обновление и удаление) становятся ресурсоёмкими для базы данных независимо от того, используются ли индексы. Из-за большого объёма данных база данных может работать медленнее, поэтому необходимо разделить данные по горизонтали (sharding), разделив одну таблицу на несколько и распределив их по нескольким таблицам.

Отложить разделение таблиц и библиотек?

Можно перенести старые исторические данные из бизнес-таблиц и таблиц заказов в исторические таблицы. Это можно считать начальной стадией разделения таблиц.

Типы:

1. Только разделение таблиц (можно использовать только один источник данных):

• Разделение одной и той же таблицы на две таблицы в одной библиотеке. Например, можно разделить таблицу user на user_0 и user_1 в одной библиотеке;
• Только разделение библиотек (реализовано в V1.8):
  • Можно разделить библиотеку db на db_0 и db_1. В каждой новой библиотеке можно создать новую таблицу user, при этом каждая библиотека будет содержать только часть данных исходной таблицы user.
  • Поскольку каждая библиотека содержит только часть исходных данных, это может включать разделение полей.
  • Однако этот тип разделения библиотек всё ещё может использовать только один источник данных.
  • Только разделение библиотек без разделения таблиц, но исходная одноточечная библиотека имеет таблицы, которые разделены на разные библиотеки.
  • Этот тип разделения библиотек может использовать один источник данных.

3. Копирующий тип разделения библиотек (V1.8 реализовано):

• Копирующее разделение библиотек подразумевает разделение чтения и записи. Каждая библиотека имеет одинаковые таблицы. Данные синхронизируются между библиотеками.

4. Планируется реализовать разделение библиотек и таблиц в версии 2.0:

• Будет разделена библиотека db на db_0 и db_1, и каждая из них будет иметь таблицы user_0, user_1 и user_2, user_3 соответственно.

Цель: Обеспечить работу промежуточного программного обеспечения для разделения баз данных и таблиц ORM, чтобы разработчики могли работать с базами данных так же, как с одной библиотекой и таблицей.

1. Разделение чтения и записи (реализовано в V1.8): Чтение и запись разделены, но все библиотеки одинаковы (таблицы одинаковы, но развёрнуты на разных узлах, например, IP-адреса различаются). С точки зрения приложения необходимо различать операции чтения (select, show, explain и т. д.) и записи (insert, update, delete и т. д.). Для операций записи используется основная библиотека, которая синхронизирует данные со вторичными библиотеками. Затем для операций чтения используется вторичная библиотека.

1. Операции записи выполняются в основной библиотеке, операции чтения — во вторичной библиотеке;
2. Если транзакция содержит операцию чтения (например, select) и операцию записи (например, insert), то она выполняется в основной библиотеке (чтобы избежать проблем с распределёнными транзакциями);
   • В сценариях с высокой согласованностью можно активно запрашивать синхронизацию вторичной библиотеки?
3. Синхронизация основной и вторичной библиотек осуществляется самой базой данных, такой как MySQL proxy. Приложение должно учитывать задержку синхронизации основной и вторичной библиотек.

Решение: Определить тип операции и переключиться на источник данных для выполнения. Не требуется переписывать или изменять SQL. Источник данных можно настроить, изменив его при необходимости, чтобы он мог обнаруживать изменения (переключение на основную библиотеку при изменении основной библиотеки и т.д.). Если одна и та же транзакция включает операцию чтения (например, select) и операцию записи (например, insert), она выполняется в основной библиотеке. Это легко реализовать, просто направив соединение на основную библиотеку при открытии транзакции. В одном потоке и в одном соединении с базой данных, если есть операция записи, все последующие операции чтения будут считываться из основной библиотеки для обеспечения согласованности данных. Как узнать, когда поток завершён? Когда соединение можно вернуть в пул соединений?

Преимущества разделения чтения и записи: Избежание единичных точек отказа. Балансировка нагрузки и расширение возможностей чтения. Можно эффективно предотвратить перегрузку одного узла путём настройки нескольких узлов вторичной библиотеки.

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

2. Разделение таблиц в одной библиотеке (реализовано в V1.8): Таблицы разделяются по дате или номеру. Выбирается ключ разделения (используется для определения соответствующей таблицы), например, временной идентификатор.

1. Транзакции временно поддерживают только одну библиотеку (не поддерживают разделение таблиц между несколькими библиотеками, чтобы избежать распределённых транзакций);
2. Сопоставление javabean и таблицы;
3. Переписывание SQL и изменение:
   • При обновлении значений в разделяемой таблице обновляется только значение, а не переносится на основе обновлённого значения. Это может вызвать проблемы. Необходимо объединить результаты, если SQL не переписывается и все библиотеки выполняют один и тот же SQL.
   • Таблицы имеют разные имена при разделении.
   • Что делать при одновременном обновлении нескольких таблиц? Как откатить?
   • Выводимый SQL является фактически выполняемым SQL, включая имя источника данных. Отличается от Sharding. DBA и разработчики могут видеть user001 и знать, что это таблица user, нет необходимости скрывать эти детали.
   • Маршрутизация к одному узлу SQL не требует оптимизации или переписывания. Поэтому сначала выбирается DS, а затем определяется следующий шаг.

3. Основные концепции:

• Разделение на уровне фрагментов делится на разделение полей и разделение таблиц.
• Алгоритм разделения обеспечивает поддержку операций разделения =, >, <, >=, <= и BETWEEN AND в SQL-инструкциях, а также IN.
• Широковещательные таблицы: конфигурации таблиц, параметров и других, которые могут быть размещены в каждой библиотеке.

Можно выбрать разделение или не использовать его. Некоторые таблицы имеют номера, рассчитанные на основе ключа разделения. Например, 0 в user0 можно получить с помощью определённого поля. Устанавливается значение по умолчанию для DS, и если DS не найден, используется значение по умолчанию. DS определяет, как маршрутизировать, а таблицы — как анализировать и преобразовывать в правильные таблицы для создания правильного SQL. Определяет, следует ли создавать несколько SQL на основе ключа разделения.

Возможно, SQL генерируется на основе библиотеки или таблицы и разделяется.

Промежуточное ПО обнаруживает, что SQL-скрипт представляет собой инструкцию INSERT, UPDATE или DELETE, автоматически выбирает основную библиотеку данных; если это запрос, он случайным образом выбирает вторичную библиотеку данных; и выбирает основную библиотеку, если транзакция открыта. Таким образом, источник данных также имеет атрибут типа, и вторичные библиотеки одного типа одинаковы и совместно используют кэш.

Обязательное разделение маршрутизации (применимо только к текущему потоку):

Пользователи могут указать конкретную DS и таблицу для использования, вместо того чтобы полагаться на вычисление ключа разделения для маршрутизации. В Bee это можно сделать с помощью HintManager.

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

5. Разделение библиотек без разделения таблиц (реализовано в V1.8): Разделение чтения и записи считается типичным примером разделения библиотек без разделения таблиц. Все таблицы одинаковы. Обычно таблицы, связанные с различными бизнес-процессами, разделяются между разными библиотеками в соответствии с таблицами для маршрутизации.

6. Разделение библиотек и таблиц: Не поддерживается (планируется в версии 2.0). Почему? Причины следующие: Хотя разделение таблиц может снизить нагрузку на отдельные таблицы, оно не всегда может использоваться для локальных транзакций. Вместо этого следует использовать таблицы в разных библиотеках, чтобы эффективно избегать распределённых транзакционных проблем. В сценариях, где невозможно избежать распределённых транзакций, некоторые бизнес-операции всё равно требуют сохранения согласованности транзакций. На основе XA распределённые транзакции неэффективны в высококонкурентных сценариях и широко не используются крупными интернет-компаниями. Они предпочитают гибкие транзакции с конечной согласованностью вместо строгих транзакций с сильной согласованностью.

С точки зрения приложений необходимо различать операции чтения (такие как select, show и explain) и операции записи (такие как insert, update и delete). Операции записи направляются в основную библиотеку, а основная библиотека синхронизируется со вторичной. Последующие операции чтения направляются во вторичную библиотеку для запроса данных. Проблемы с транзакциями. Если транзакция включает операции чтения (например, select) и записи (например, insert), и операция чтения направляется во вторичную библиотеку, а операция записи — в основную, поскольку они охватывают несколько библиотек, локальные транзакции JDBC больше не могут контролироваться и становятся распределёнными.

Поэтому для операций чтения и записи в настоящее время основным подходом является выполнение всех SQL-операций в основной библиотеке для управления ими. Поскольку задействована только одна библиотека, локальная транзакция JDBC может справиться с этим.