Предыстория создания подбиблиотеки и подтаблицы
С быстрым развитием Интернета будет генерироваться огромное количество данных. Когда количество данных все еще относительно невелико, традиционный метод обработки заключается в хранении данных в реляционных или нереляционных базах данных. данные увеличиваются постепенно, в одной базе данных трудно разместить все данные в таблице базы данных, поэтому в отрасли появилась концепция подбазы данных и подтаблицы. Используя идею разделения на знания, данные отлично разделяются, но это также приносит много сложных проблем, таких как введение распределенных транзакций, расширение и так далее.
История использования базы данных
Мы используем базу данных в приложении в основном через следующие три этапа.
- Одна база данных и одна таблица на начальном этапе приложения, поскольку объем данных меньше порога допустимости базы данных на этом этапе, практически не влияет на производительность приложения.
- Одна подтаблица базы данных, поскольку определенная таблица в базе данных базы данных слишком велика, это оказывает определенное влияние на производительность приложения, такого как запрос и т. д., таблица будет разделена на таблицу_1, таблицу_2, таблицу_N и таблица будет разделена на N маленьких таблиц. Обратите внимание, что на данном этапе емкость диска достаточна. Но это больше касается секционирования используемой базы данных.Принцип секционирования очень похож на принцип секционирования таблицы, такой как секционирование хэша mysql.
CREATE TABLE `test_user_hash` (
`user_id` bigint(19) NOT NULL,
`user_name` varchar(50) NOT NULL,
`ext_int` int(2) NOT NULL,
`ts` bigint(19) NOT NULL,
PRIMARY KEY (`user_id`,`ext_int`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
//Mysql 分区
ALTER TABLE `test_user_hash` PARTITION BY HASH(ext_int) PARTITIONS 3 ;
Форма хранения в базе данных mysql, так как указанное выше вычисляется по 3хэшу, она будет разделена на три файла хранения
- Когда вышеуказанные два метода не могут быть решены, появляется схема подбазы данных и подтаблицы, то есть данные одной базы данных рассредоточены по нескольким базам данных.
При каких обстоятельствах вам нужна подбиблиотека и подтаблица
В принципе, можно стараться максимально не делить БД, когда это неизбежно или есть тренд, который нужно разделить на БД и таблицу, будет использоваться подбиблиотека и таблица.
- Пропускная способность базы данных становится узким местом, и для ее повышения необходимо расширить несколько экземпляров базы данных;
- Данные в таблице данных достигают определенной величины, что оказывает значительное влияние на производительность запросов приложений и других приложений.Производительность может быть улучшена за счет подбазы данных и подтаблицы.Некоторые данные показывают, что объем данных одного таблица в базе данных Mysql превышает 5000 Вт, что повлияет на производительность запросов.
- Чтобы избежать сложного расширения емкости на более позднем этапе, оцените объем данных за N лет вперед, исходя из тенденции роста данных.Количество / емкость одной базы данных = требуемый экземпляр базы данных, который относится к предварительному планированию и предотвращает это. в первую очередь.
Общие схемы разделения
Существуют две распространенные схемы разделения: вертикальное разделение и горизонтальное разделение, а также разделение базы данных и разделение таблиц — обычное решение для разделения базы данных.
- вертикальное разделение
Вертикальное разбиение заключается в централизованном хранении некоторых реляционных таблиц в определенной БД в соответствии с бизнес-характеристиками, и объем данных этих таблиц, как правило, не слишком велик. Например, в системе электронной коммерции есть пользовательские модули и модули заказов.
- разделить по горизонтали
В каждой БД существует одинаковая структура таблиц, а данные разбросаны по нескольким БД по определенным правилам.
Схема реализации подтаблицы подбазы данных
Существуют в основном три схемы реализации:
- сегментация клиента
- Брокер реализует шардинг
- Распределенная база данных
сегментация клиента
Как правило, существует два способа реализации клиентского сегментирования: один реализуется непосредственно на прикладном уровне.Прикладной уровень содержит логику сегментирования и алгоритмы сегментирования, которые тесно связаны с бизнес-кодом.
Прикладной уровень реализует всю логику, и бизнес-персонал должен участвовать.
Другой - реализовать стандартный протокол JDBC, предоставить упакованный JDBC для приложений и не иметь никакого представления об использовании приложения.Логика реализации встроена в приложение в виде jar-файла, и приложение можно гибко переключать.
Этот метод реализует стандартный интерфейс JDBC, который не влияет на приложение, использующее собственный JDBC. Оба следуют единой спецификации. Преимущество по сравнению с первым методом состоит в том, что он отделен от бизнес-кода. Повышение гибкости.
прокси осколок
Метод прокси реализуется путем добавления уровня прокси между приложением и базой данных и развертывания его независимо. Прокси выступает в роли данных. Для приложения использование прокси эквивалентно базе данных. В принципе, использование прокси ничем не отличается от прямого использования базы данных, но прокси ведь это не настоящая база данных уровень прокси только решает как в полной мере использовать ресурсы базы данных уровень прокси реализует все под- логика базы данных и подтаблиц, включая правила сегментирования и т. д. Деловому персоналу не нужно обращать внимание, и они могут посвятить больше времени логике реализации бизнеса.
Обычно слой нагрузки добавляется за пределы уровня прокси.
Этот метод позволяет бизнес-персоналу больше сосредоточиться на бизнесе, но сложность намного выше, чем у первого метода, который увеличивает канал связи и включает преобразование протокола, поэтому будут очевидные потери производительности по сравнению с первым методом. В то же время требования к персоналу относительно высоки, и для их поддержки нужны технические специалисты, иначе будет сложно справиться с возникающими проблемами. Mycat мне знаком, поскольку я занимался глубокой вторичной разработкой на основе Mycat и имею определенное представление об исходном коде, дефекты действительно велики. . . . , надеюсь пользователи внимательно рассмотрят, лирическое отступление о(￣︶￣)o
Распределенная база данных
TiDB знакома публике, которая предоставляет масштабируемую архитектуру системы и определенную распределенную транзакцию. Масштабируемые и распределенные транзакции упакованы во внутреннюю реализацию, и пользователям не нужно напрямую управлять этими функциями. Например, TiDB предоставляет интерфейс JDBC и прикладной уровень.Нет никакой разницы между использованием TiDB и прямым подключением к базе данных MySQL
Проблемы, вызванные подбиблиотеками и подтаблицами
- После разделения данные разбрасываются по разным БД.При использовании родной операции соединения базы данных происходит соединение между базами данных, которое имеет низкую производительность.
- С введением распределенных транзакций трудно решить вопрос согласованности распределенных транзакций.
- Пейджинг, чем дальше вы переворачиваете страницу, тем медленнее запрос, например, запрос 10 фрагментов данных после 100w, предел 1000000, 10.
- Сложность расширения мощностей без простоев
В последующих статьях будут проанализированы более зрелые решения в отрасли, чтобы решить проблемы, вызванные подбазой данных и подтаблицей, так что следите за обновлениями...