Автор: Architecture Xiaohe | Публичный аккаунт WeChat: Architect's Top

1. Предпосылки

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

2. Как разделить данные заказа

Мы можем разделить данные заказа на два типа: горячие данные и холодные данные.

• Горячие данные: данные заказа в течение 3 месяцев, высокий запрос в реальном времени;

• Холодные данные A: данные заказа от 3 до 12 месяцев назад, частота запросов невелика;

• Холодные данные B: данные о заказе за 1 год почти никогда не запрашиваются, и запросы запрашиваются лишь время от времени;

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

Текущее планирование хранения этих трех типов данных выглядит следующим образом:

• Горячие данные: используйте mysql для хранения, конечно, вам нужна подбаза данных и подтаблица;

• Холодные данные A: Для этого типа данных они могут храниться в ES, и в основном более быстрые запросы могут выполняться с использованием характеристик поисковых систем;

• Холодные данные B: для такого рода данных, которые не часто запрашиваются, они могут храниться в Hive;

3. Как MySql разделяет базу данных и таблицу

3.1 Разделение по бизнесу

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

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

Однако с улучшением бизнеса поддерживать все сервисы в одной библиотеке становится все сложнее, поэтому мы рекомендуем размещать разные сервисы в разных библиотеках, как показано на следующем рисунке:

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

3.2 Подбиблиотека и подтаблица

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

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

(1) Стратегия подстола

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

1create table order(2 order_id bigint(11) ,3

Мы предполагаем, что, по оценкам, одной библиотеке необходимо выделить таблицы 100 для удовлетворения наших бизнес-потребностей.Мы можем просто взять модуль, чтобы вычислить, в какой подтаблице находится заказ, например: order_id % 100,

В это время кто-то может спросить, если я разделю таблицу в соответствии с order_id, но я хочу запросить соответствующий порядок в соответствии с user_id, не могу ли я найти, какая подтаблица? Это правда, как только ключ сегмента определено, его можно определить только в соответствии с ключом сегмента, расположенным в подтаблице для запроса данных в подтаблице; если вы действительно хотите запрашивать связанные заказы на основе user_id, вы должны установить ключ сегмента на user_id , и соответственно изменить правило подтаблицы: user_id % 100;

(1) Стратегия реализации подбиблиотеки

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

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

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

Возьмем в качестве примера таблицу заказов.

Например: order_id % емкости библиотеки,

Если order_id не является целочисленным типом, вы можете сначала хэшировать его и взять по модулю,

Например: hash(order_id) % емкости библиотеки

(3) Комбинированная стратегия использования подбиблиотеки и подтаблицы

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

Если подбаза данных и подтаблица используются в комбинации, операция по модулю order_id не может быть просто выполнена, и необходимо добавить промежуточную переменную для распределения по разным подтаблицам Формула выглядит следующим образом:

Промежуточная переменная = ключ сегмента % (количество библиотек * количество таблиц в одной библиотеке); 2 серийный номер библиотеки = округлено (промежуточная переменная / одиночная

Например: есть 10 баз данных, каждая база данных имеет 100 таблиц данных, пользовательский order_id = 1001, в соответствии с приведенной выше стратегией маршрутизации мы можем получить:

В этом случае для order_id=1001 он будет перенаправлен на вторую таблицу первой базы данных (индекс 0 соответствует 1 и т. д.).

3. Общий архитектурный дизайн

Из рисунка разделим запрос на чтение и запись Запрос на запись относительно прост, то есть его можно записать в БД по правилам подбазы и подтаблицы.

Для запросов на чтение нам нужно рассчитать, является ли запрос горячими данными или холодными данными.Общие правила генерации order_id следующие: «код города продавца + метка времени + случайное число», мы можем вычислить, является ли запрос горячими данными. или холодные данные в соответствии с меткой времени (конечно, конкретный бизнес требует подробного рассмотрения и здесь не рассматривается)

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

На рисунке показано задание синхронизации, которое в основном используется для регулярного переноса данных заказа.Холодные данные необходимо перенести в ES и hive соответственно.