Как разбить базу на таблицы

MySQL
Как разбить базу на таблицы

узкое место базы данных

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

узкое место ввода-вывода

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

Узкое место ЦП

  • Первый тип: проблема SQL: например, SQL включает соединение, группировку, упорядочивание, условный запрос неиндексированного поля и т. д., увеличивает работу ЦП -> оптимизация SQL, устанавливает соответствующие индексы и выполняет бизнес-вычисления в уровень бизнес-услуг.
  • Второй: объем данных в одной таблице слишком велик, слишком много строк сканируется при запросе, эффективность SQl низкая, а работа процессора повышена. -> Горизонтальная подтаблица.

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

Горизонтальная подбиблиотека

1. Концепция: В зависимости от поля, согласно определенной стратегии (хэш, диапазон и т.д.), данные в одной библиотеке разбиваются на несколько библиотек.
2. Результаты:

  • Структура каждой библиотеки одинакова
  • Данные в каждой библиотеке разные, пересечения нет
  • Объединение данных всех библиотек — это полные данные
    3. Сценарий: абсолютный параллелизм системы увеличился, и трудно фундаментально решить проблему подтаблиц, и нет очевидной бизнес-атрибуции в случае вертикальной подбазы данных.
    4. Анализ: с большим количеством библиотек нагрузка на ввод-вывод и процессор естественным образом может быть удвоена.

горизонтальная подтаблица

1. Концепция: На основе полей, согласно определенным стратегиям (хэш, диапазон и т.д.), данные в одной таблице разбиваются на несколько таблиц.
2. Результаты:

  • Структура каждой таблицы одинакова
  • Данные каждой таблицы разные, пересечения нет, и объединение всех таблиц представляет собой полный объем данных.
    3. Сценарий: Абсолютный параллелизм системы не достигнут, но объем данных в одной таблице слишком велик, что влияет на эффективность SQL и увеличивает нагрузку на ЦП, так что он становится узким местом.Можно рассмотреть горизонтальный деление стола.
    4. Анализ: объем данных в одной таблице меньше, а эффективность выполнения одного SQL-запроса высока, что естественным образом снижает нагрузку на ЦП.

вертикальная библиотека

1. Концепция: на основе таблицы, в зависимости от принадлежности к бизнесу, разные таблицы делятся на разные библиотеки.
2. Результаты:

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

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

1. Концепция: в зависимости от поля, в зависимости от активности поля, поля в таблице разбиты на разные таблицы (основная таблица и таблица расширения).
2. Результаты:

  • Структура каждой таблицы разная.
  • Данные каждой таблицы разные.Вообще говоря, поля каждой таблицы имеют по крайней мере одно пересечение, которое обычно является первичным ключом, который используется для связывания данных.
  • Объединение всех таблиц представляет собой полный объем данных. 3. Сценарий: Абсолютный параллелизм системы не подошёл, записей в таблице не много, а полей много, и горячие данные и не горячие данные вместе, место для хранения требуется для одной строки объем данных велик, поэтому строка данных, кэшированная базой данных, сокращается, возвращается к чтению данных с диска при запросе, что приводит к большому количеству операций ввода-вывода случайного чтения, что приводит к узким местам ввода-вывода.
    4. Анализ: страницы списков и страницы с подробными сведениями можно использовать для облегчения понимания. Принцип разделения вертикальных таблиц заключается в объединении «горячих» данных (данных, которые могут часто запрашиваться) в качестве основной таблицы и «негорячих» данных в виде таблицы расширения, чтобы можно было кэшировать больше «горячих» данных, тем самым уменьшая операции ввода-вывода со случайным чтением. . После демонтажа, если вы хотите получить все данные, вам нужно связать две таблицы, чтобы получить данные.
    Но помните, никогда не используйте объединение, потому что объединение не только увеличивает нагрузку на ЦП, но и связывает вместе две таблицы (должно быть в одном экземпляре базы данных). Связанные данные должны выполняться на уровне службы, получая данные основной таблицы и таблицы расширения соответственно, а затем используя связанные поля для связывания всех данных.

Инструмент подтаблицы подбиблиотеки

  • осколки-jdbc (dangdang)
  • Шардинг (Грибная улица)
  • Атлас (Qihoo 360)
  • Кобар (Алибаба)
  • MyCAT (на базе Cobar)
  • Океан (58 в том же городе)
  • Витесс (Google) Самоанализ плюсов и минусов различных инструментов

Проблемы, вызванные подбиблиотекой и подтаблицей

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

Проблемы согласованности транзакций

Распределенная транзакция

Когда обновленный контент существует в разных базах данных одновременно, это неизбежно приведет к проблемам с транзакциями между базами данных. Межсегментные транзакции также являются распределенными транзакциями. Простого решения не существует. Как правило, можно использовать «протокол XA» и «двухфазную фиксацию».
Распределенные транзакции могут максимизировать атомарность операций базы данных. Однако при фиксации транзакции необходимо координировать работу нескольких узлов, что задерживает время фиксации транзакции, продлевает время выполнения транзакции и увеличивает вероятность конфликта или взаимоблокировки при доступе транзакции к общим ресурсам. С увеличением количества узлов базы данных эта тенденция будет становиться все более и более серьезной, становясь, таким образом, оковами горизонтального расширения системы на уровне базы данных.

окончательная согласованность

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

Проблема объединения запроса межузловой ассоциации

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

глобальная таблица

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

Полевое резервирование

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

сборка данных

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

сегментация электронной почты

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

Пейджинг между узлами, сортировка, функциональные проблемы

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

Приведенное выше изображение берет данные только первой страницы, и влияние на производительность невелико. Однако, если количество полученных страниц очень велико, ситуация значительно усложняется, так как данные в каждом узле шарда могут быть случайными, для точности сортировки необходимо отсортировать данные первых N страниц всех узлов. И, наконец, выполняется общая сортировка, эта операция потребляет ресурсы ЦП и памяти, поэтому чем больше количество страниц, тем хуже будет производительность системы.
При использовании для расчета таких функций, как Max, Min, Sum и Count, также необходимо сначала выполнить соответствующую функцию для каждого сегмента, а затем агрегировать наборы результатов каждого сегмента и выполнить повторный расчет.

Глобальная проблема избегания первичного ключа

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

UUID

Стандартная форма UUID — 32 шестнадцатеричных цифры, разделенных на 5 сегментов, а форма — 36 символов 8-4-4-4-12. UUID — самое простое решение, генерируется локально, обладает высокой производительностью и не требует сетевого времени, однако имеет очевидные недостатки и занимает много места в хранилище, кроме того, возникают проблемы с производительностью при построении индекса как первичный ключ и запросы на основе индекса, особенно в движке InnoDb, беспорядок UUID может привести к частым изменениям позиции индекса, что приведет к подкачке.

В сочетании с базой данных для поддержки таблицы идентификаторов первичного ключа

Создайте таблицу последовательности в базе данных:

CREATE TABLE `sequence` (  
  `id` bigint(20) unsigned NOT NULL auto_increment,  
  `stub` char(1) NOT NULL default '',  
  PRIMARY KEY  (`id`),  
  UNIQUE KEY `stub` (`stub`)  
) ENGINE=MyISAM;

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

REPLACE INTO sequence (stub) VALUES ('a');  
SELECT 1561439;

Это решение относительно простое, но недостатки очевидны: проблема в одном месте, сильная зависимость от БД, недоступность всей системы при аварийной БД. Настройка master-slave может повысить доступность. Кроме того, узкое место производительности ограничено производительностью чтения и записи одного Mysql.
Существует еще одна стратегия генерации первичного ключа, похожая на схему таблицы последовательности, которая лучше решает проблемы с одной точкой и узкими местами производительности. Общая идея этого решения состоит в том, чтобы установить более двух серверов для генерации глобальных идентификаторов, развернуть только одну базу данных на каждом сервере и иметь таблицу последовательности для каждой базы данных для записи текущего глобального идентификатора.Шаг роста в таблице — это количество библиотек, а начальные значения расположены в шахматном порядке по очереди, чтобы генерацию ID можно было хешировать к каждой базе данных

Это решение равномерно распределяет нагрузку по генерации идентификаторов на две машины и обеспечивает отказоустойчивость системы.Если ошибка возникает на первой машине, она может автоматически переключаться на вторую машину для получения идентификаторов. Однако есть несколько минусов: система добавляет машины, а горизонтальное расширение усложняется, каждый раз при получении ID БД надо считывать один раз, а нагрузка на БД по-прежнему очень высока, а производительность может только быть улучшены кучей машин.

Алгоритм распределенного самоинкрементного идентификатора Snowflake

Алгоритм Snowfalke Twitter устраняет потребность в распределенной системе для генерации глобальных идентификаторов и генерирует 64-битные числа типа Long.Компоненты:

  • первый бит не используется
  • Следующие 41 бит — это время в миллисекундах, а длина 41 бита может представлять 69 лет времени.
  • 5 datacenterId, 5 рабочий идентификатор. 10-битная длина поддерживает развертывание до 1024 узлов.
  • Последние 12 бит — это счет в миллисекундах, а 12-битный порядковый номер счетчика позволяет каждому узлу генерировать 4096 последовательностей идентификаторов в миллисекунду.

Проблемы миграции и расширения данных

Дизайн Sharding считается только тогда, когда бизнес быстро развивается и сталкивается с узкими местами производительности и хранения. В это время неизбежно рассмотреть миграцию исторических данных. Общая практика заключается в том, чтобы сначала прочитать исторические данные, а затем записывать данные каждому узлу Sharding в соответствии с указанными правилами каревки. Кроме того, необходимо проводить планирование емкости в соответствии с текущим объемом данных и QPS, а также скоростью развития бизнеса и рассчитать приблизительное количество оскорблений (вообще, рекомендуется, чтобы объем данных единой таблицы Один осколок не превышает 1000 Вт)

Когда задуматься о шардинге

не могу отличить

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

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

Эксплуатация и техническое обслуживание здесь относится к:

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

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

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

Быстро растущий объем данных

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

Ссылка на ссылку:
Блог woowoo.cn на.com/butterfly10…
woohoo.cn blog.com/little Чара…

Категории