Решение с высокой степенью параллелизма для базы данных MySQL

MySQL
Решение с высокой степенью параллелизма для базы данных MySQL

предисловие

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

Итак, чтобы решить проблему, мы должны поговорить о плане. Но есть много вариантов, как мы выбираем?

Оптимизация и решения

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

короткая дистанция

Так называемое короткое расстояние относится к короткому пути от внешнего интерфейса к базе данных.

  1. Страница статична. Данные некоторых страниц не меняются в определенные промежутки времени, поэтому страница может быть статической, что может повысить скорость доступа.
  2. Используйте кеш. Мы все знаем, что кэширование выполняется быстро, потому что оно основано на памяти. Следовательно, использование кэша в памяти может сократить доступ к базе данных и ускорить доступ.
  3. Массовое чтение. В случае высокого параллелизма запросы нескольких запросов могут быть объединены одновременно, чтобы снизить скорость доступа к базе данных.
  4. Модификация задержки. Отложенная модификация означает, что в случае высокого параллелизма может быть помещение в кеш нескольких измененных данных, а затем периодическое обновление данных из кеша в базу данных; это также может быть синхронизировано с базой данных асинхронно посредством синтаксического анализа через синхронизацию. стратегия тайника.
  5. Используйте индекс. Излишне говорить, что существует много типов индексов, таких как обычные индексы/индексы первичного ключа/комбинированные индексы/полнотекстовые индексы.

мало данных

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

  1. подтаблица. Так называемая разделенная таблица на самом деле имеет горизонтальное разделение и вертикальное разделение. Друзья, которые играли в одиночную игру, знают, что часто некоторые исторические формы содержат десятки миллионов уровней данных. Таким образом, для MySQL, даже если добавить индекс и продолжить оптимизацию SQL, трудно добиться более высокой скорости выполнения запросов. Затем мы можем добиться этого с помощью работы с подтаблицами. Например, чаще всего мы можем разделить таблицу по горизонтали в соответствии с измерением времени, данные за этот год сохраняются, а данные за прошлый год могут храниться в другой таблице.
  2. Отдельные активные данные. По сути, это немного похоже на кеширование, но разница в том, что данные по-прежнему находятся в MySQL. Например, в бизнесе, который ищет товары, может быть активная таблица для некоторых популярных/часто искомых товаров. При запросе сначала запрашивайте активную таблицу, если нет, то запрашивайте общую таблицу товаров.
  3. Блокировать. Этот блок чем-то похож на «поиск по порядку индекса» в алгоритме. Благодаря оптимизации уровня данных данные размещаются в разных блоках, и нам нужно только рассчитать и найти соответствующий блок.

дисперсионное давление

Так называемое дисперсионное давление на самом деле представляет собой дисперсионное давление на разные серверы баз данных.

  1. кластер. Я полагаю, что всем известна концепция кластеризации.Для бизнес-серверов это фактически развертывание нескольких серверов с одним и тем же бизнес-процессом и распределение запросов на разные серверы с помощью балансировки нагрузки или других методов. То же самое верно и для баз данных, которые направляют данные на определенные серверы баз данных с помощью определенных правил и политик.
  2. распределенный. Так называемое распределенное, по сути, заключается в распределении бизнес-логики изначально в одном процессе на разные серверы для выполнения, чем достигается эффект «параллельного» выполнения и ускоряется скорость выполнения.
  3. Подтаблица подбиблиотеки. Подбиблиотека и подтаблица в основном разделены по горизонтали и по вертикали. Для одной таблицы с высокой частотой обращения и огромным объемом данных данные одной таблицы могут быть уменьшены, а горизонтальное разбиение может быть выполнено по определенным размерам для увеличения пропускной способности базы данных.Разделить таблицу по горизонтали; Для нескольких таблиц с низкой деловой связью разные таблицы могут храниться в разных базах данных, а база данных может быть разделена по вертикали, чтобы улучшить способность базы данных к записи, то естьВертикальное разделение подбиблиотек.
  4. Создайте мастер-раб. Цель создания master-slave на самом деле состоит в том, чтобы разделить чтение и запись. Все мы знаем, что до тех пор, пока уровень транзакций в базе данных достаточно высок, параллельное чтение не повлияет на путаницу данных, в то время как параллельная запись повлияет. Итак, чтобы установить master-slave В общем, записи останутся на главном сервере для записи, а чтение будет с подчиненного сервера.Таким образом, пусть мастер выполняет транзакционные операции, а подчиненный — запросы на выборку. Таким образом, изменения, вызванные транзакционными операциями (добавление/удаление/изменение), синхронизируются с подчиненными базами данных в кластере..

Эпилог

над!