1 Sharding

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

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

2 вертикального/горизонтального разделения

2.1 Схема расширения MySQL

• Горизонтальное масштабирование

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

• Масштабирование Вертикальное расширение

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

2.2 Стратегия разделения MySQL

1. Вертикальная сегментация: разделение по функциональным модулям для решения表与表之间Конфликт ввода/вывода

Например, разделите исходную старую библиотеку заказов на базовую библиотеку заказов и библиотеку обработки заказов. между базами данных表结构不同

2. Горизонтальная сегментация:同个表Данные разбиваются на куски и сохраняются в разных базах данных.

Чтобы решить проблему роста данных в одной таблице. в этих базах данных表结构完全相同

2.3 Случай проектирования структуры таблицы

вертикальный срез

1. большое поле

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

Горизонтальная сегментация

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

3 разделенных таблицы и разделы

Подтаблицы: разделите таблицу на несколько небольших таблиц; Раздел: разделите данные таблицы на блоки N. Эти блоки могут находиться на одном диске или на разных дисках.

3.1 Разница между таблицей и разделом

• Метод реализации

После того, как таблица MySQL разделена на несколько таблиц, каждая небольшая таблица представляет собой полную таблицу, соответствующую трем файлам (механизм MyISAM: файл данных .MYD, файл индекса .MYI, файл структуры таблицы .frm)

• обработка данных
  • После того, как таблица разделена, данные сохраняются в подтаблице, общая таблица представляет собой просто оболочку, а данные доступа появляются в подтаблицах одна за другой.
  • Разделение не имеет концепции подтаблиц.Разбиение просто делит файл, хранящий данные, на множество небольших блоков.Таблица после разделения остается таблицей, и обработка данных по-прежнему выполняется сама по себе.
• представление
  • После разделения таблицы возможности параллелизма отдельной таблицы улучшаются, а также повышается производительность дискового ввода-вывода. Ключом к секционированию таблиц является то, как улучшить параллелизм MySQL при доступе к данным.
  • Раздел преодолевает узкое место дискового ввода-вывода и хочет улучшить возможности чтения и записи диска, чтобы повысить производительность MySQL.
• стоимость реализации
  • Есть много способов разделить таблицу, используя слияние для разделения таблицы, это самый простой из них. Этот метод аналогичен по сложности партиционированию и прозрачен для программного кода, а если используются другие методы партиционирования таблицы, то он более хлопотный, чем партиционирование.
  • Реализация секционирования относительно проста, создание таблицы разделов ничем не отличается от построения обычной таблицы, и это прозрачно для стороны кода.

3.2 Применимые сценарии для разделения

1. Скорость запроса таблицы настолько низкая, что это влияет на использование
2. Данные в таблице сегментированы
3. Операции с данными часто включают только часть данных, а не все.

3.3 Применимые сценарии подтаблиц

1. Скорость запроса таблицы настолько низкая, что это влияет на использование
2. Замедление при частой вставке или объединении запросов
3. Внедрение подтаблиц требует реализации объединения бизнеса и миграции, что является более сложным

4 подбиблиотеки

подтаблица может решить单表数据量过大带来的查询效率下降Однако это не может качественно улучшить возможности параллельной обработки базы данных. В условиях большого количества одновременных операций чтения и записи, когда главный сервер базы данных не может выдержать нагрузки на запись, независимо от того, как расширять подчиненный сервер, это бессмысленно. Другой способ мышления, разделение базы данных,提高数据库写性能, то есть подбиблиотека.

4.1 Решения для подбиблиотек

Несколько баз данных в экземпляре MySQL разделены на разные экземпляры MySQL:

• дефект

Некоторые узлы по-прежнему не выдерживают давления записи.

4.1.1 Сегментация запросов

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

• преимущество

Алгоритм сопоставления ключа и библиотеки можно настроить по желанию

• недостаток

Вводит дополнительную единую точку

4.1.2 Сегментация диапазона

• Разделите по временному интервалу или интервалу ID.

• преимущество

Емкость одного стола контролируется, а горизонтальное расширение очень удобно.

• недостаток

Проблема узкого места централизованного письма не может быть решена.

4.1.3 Сегментация хешей (ключевые моменты)

• Как правило, используется хэш-сегментация.

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

Например, в ордерной библиотеке схема подбиблиотеки и подтаблицы 32*32, то есть последние четыре цифры Mod 32 UserId делятся на 32 библиотеки, и при этом каждая библиотека делится на 32 таблицы по четырем цифрам Div 32 Mod 32 после UserId. , что в общей сложности разделено на 1024 таблицы.

Онлайн-развертывание — это 8 кластеров (главный-подчиненный), в каждом кластере по 4 библиотеки.

Почему это легко масштабировать по горизонтали? Проанализируйте следующие сценарии:

Производительность базы данных достигает узкого места

1. Существующие правила остаются неизменными и могут быть напрямую масштабированы до 32 кластеров баз данных.

2. Если 32 кластера не могут удовлетворить спрос, измените правило подтаблицы подбазы данных на (322^n)(32⁄2^n), что может достигать 1024 кластеров.

Емкость одного стола достигает узкого места

или 1024 не может быть удовлетворено.Если размер одной таблицы превышает 200G, 200*1024=200T Неважно, 32 * (32 * 2^n), в это время правила подбиблиотеки остаются неизменными, а таблицы в одной библиотеке снова делятся. последние четыре мода userId), тут еще есть ограничение, т.к. там всего четыре бита, поэтому разбивается максимум 8192 таблицы.

Выберите ключ сегмента

• Старайтесь избегать возникновения запросов между разделами (нельзя полностью избежать)
• Старайтесь, чтобы данные в каждом шарде были как можно более ровными.

Как хранить таблицы без шардинга

• В каждом сегменте хранится одна копия одних и тех же данных.

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

• Унифицированное хранилище с дополнительными узлами

Проблем с избыточностью нет, но эффективность запросов низкая и требует агрегирования.

Развертывание шардов на узлах

• Каждый сегмент использует одну базу данных с одним и тем же именем базы данных.

Структура также остается прежней, такой же, как и у одного узла.

• Храните несколько разделенных таблиц в одной базе данных и добавляйте суффикс номера сегмента к имени таблицы.
• Разверните несколько баз данных в узле, каждая база данных содержит срез

5 Проблемы после подбиблиотеки и подтаблицы

Глобальная схема генерации уникальных идентификаторов

Схем много, основные из них следующие:

Идентификатор автоинкремента базы данных

использовать

• auto_increment_increment
• auto_increment_offset

Системная переменная для MySQL для увеличения на желаемое значение и смещениеauto_incrementзначение столбца.

• преимущество

Самый простой, не зависит от ноды, чаще используется, но требует очень тщательной настройки сервера!

• недостаток

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

Кластер базы данных и установите соответствующий размер шага (схема Flickr)

Создайте глобальный узел базы данных, содержащийauto_incrementТаблица столбцов, из которых приложение генерирует уникальные числа.

• преимущество

Высокая доступность и простой идентификатор.

• недостаток

Требуется отдельный кластер базы данных.

Кэширование сервисов NoSQL, таких как Redis

Избегайте проблемы низкой производительности MySQL.

Снежинка (алгоритм снежинки)

• преимущество

Высокая производительность, высокая доступность и простота расширения.

• недостаток

Требуются отдельные кластеры, а также ЗК.

Различные GUID, случайные алгоритмы

• преимущество

Простой.

• недостаток

Сгенерированный идентификатор длинный, и есть вероятность его повторения.

Сфера бизнеса (план практики Meituan)

Чтобы снизить операционные расходы и снизить дополнительные риски, Meituan исключила все решения, требующие независимых кластеров, и приняла решения с бизнес-атрибутами:时间戳+用户标识码+随机数

преимущество:

• Удобство и низкая стоимость
• Почти нет шансов на повторение
• Поставляется с правилами подбиблиотеки, идентификационный код пользователя здесьuserID的后四位, в сценарии запроса только номер заказа может быть сопоставлен с соответствующей таблицей библиотеки без необходимости идентификатора пользователя.Только четыре цифры берутся, чтобы надеяться, что номер заказа будет как можно короче, и четырех цифр достаточно после оценки .
• Сортировка, потому что метка времени идет первой

недостаток

• Длина немного больше, а производительность немного хуже, чем у int/bigint.

дела

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

• решение

Например, Meituan разделяет весь агрегат поля заказа с одинаковыми размерами, поэтому поддерживается транзакция агрегата.

Проблема соединения между базами данных и таблицами

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

• решение

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

Дополнительное управление данными и вычислительная нагрузка

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

Суммировать

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

Ссылаться на

• Специальности.Meituan.com/2016/11/18/…