В предыдущей статье уже говорилось о master-slave кластере кластера базы данных, то есть о разделении чтения-записи, а также упоминалосьНа самом деле, разделение чтения и записи разделяет только давление доступа, но не решает проблему хранения.
Проще говоря, нагрузка на хранилище означает, что с развитием системы и увеличением спроса количество таблиц может постепенно увеличиваться, например, необходимо добавить новую таблицу на определенный период времени. И по мере увеличения количества пользователей, количество строк в подобных пользовательских таблицах обязательно будет увеличиваться, и данные в таблице заказов со временем обязательно будут увеличиваться.Когда количество данных достигает десятков миллионов или даже сотен миллионов -разделение записи не может быть удовлетворено, производительность чтения и записи серьезно снижается.
То есть ресурсы сервера, такие как ЦП, память, ввод-вывод, диск и т. д., ограничены, поэтому в это время подбаза данных и подтаблица включены!
Филиальная библиотека
Грубо говоря подбаза это например, теперь у вас есть сервер базы данных, и в базе есть две таблицы, пользовательская таблица и таблица заказов. Если вы хотите разделить базу данных, теперь вам нужно купить две машины, поставить две базы данных на две машины и одну базу данных для пользовательской таблицы, одну базу данных для таблицы заказов.
Таким образом, нагрузка на хранилище распределяется между двумя серверами, но это приведет к новым проблемам, поэтому, когда все усложнится, возникнут новые проблемы.
1, запросы таблицы непредвиденных обстоятельств То есть присоединиться, и раньше в базу данных, которая может быть использована для присоединения с оператором sql может быть связан запрос таблицы, чтобы получить результаты, которые вы хотите, но теперь разделены на несколько баз данных, так что присоединиться не имеет значения. Например, пришло время проверить регистрационную информацию пользователя, чтобы после 2019 года вам нужно было перейти к запросам таблицы базы данных с информацией о пользователе, зарегистрированным в 2019 году, после чего получить идентификатор пользователя, id давайте использовать эти базы данных для Таблица заказов B Найдите информацию о заказе, а затем сшивайте полученную информацию. Так много равно, чтобы написать код.
2. Деловые вопросы Транзакции базы данных в основном неотделимы от транзакций, но теперь различные транзакции базы данных являются не простыми локальными транзакциями раньше, а распределенными транзакциями, а введение распределенных транзакций также увеличивает сложность системы, а некоторая эффективность Высокая также влияет на производительность, например Mysql XA . Существуют также распределенные транзакции, основанные на промежуточном программном обеспечении сообщений и т. д., которые здесь не описаны.
подтаблица
Мы уже сделали филиальную базу данных, но сейчас ситуация такая, что в нашей таблице слишком много данных, а продукты вашей компании случайно популярны, например Douyin, если все пользователи существуют в одной таблице, они этого не выносят, так что на этот раз таблица очков. Он разделен на вертикальную подтаблицу и горизонтальную подтаблицу соответственно.
вертикальный стол
Смысл вертикальной таблицы как ось у оси координат, а ось х разрезана пополам, что соответствует нашей таблице.Например, наша таблица имеет 10 столбцов.Теперь мы ее обрезаем и разделяем на две таблицы, одна из которых - столбец таблицы 3, другая - столбец таблицы 7.
Благодаря этому универсальному сокращению две таблицы имеют несколько столбцов, которые не являются фиксированными, а таблица с вертикальным разделением подходит для таблиц, которые обычно не используются и занимают много места.
Возьмите информацию о пользователе Toutiao, Например, таблица пользователей имеет только четыре поля: идентификатор пользователя, псевдоним, номер мобильного телефона и личный профиль. Однако такая информация, как номера мобильных телефонов и личные профили, обычно не используется и занимает много места.Некоторые люди написали много личных профилей. Поэтому два столбца с номером мобильного телефона и личным профилем разделены.
Влияние вертикального разделения таблиц заключается в том, что раньше требовался только один запрос, но теперь требуется два запроса, чтобы получить полную информацию о пользовательской таблице перед разделением таблицы.
горизонтальная подтаблица
Смысл горизонтальной подтаблицы такой же, как ось x оси координат, а ось y разрезана пополам (разумеется, она не ограничена одним разрезом, но может быть разрезана несколько раз). Возьмем в качестве примера таблицу пользователей.Например, таблица пользователей теперь имеет 50 миллионов строк данных.Мы разрезаем 5 ножей и делим его на 5 таблиц, каждая с 10 миллионами строк данных.
Горизонтальная подтаблица подходит для случаев, когда количество строк в пользовательской таблице велико.Как правило, количество строк в одной таблице превышает 50 миллионов, и таблица оценивается.Если данные в одной таблице более сложный, он может быть оценен в 20 миллионов или даже в 10 миллионов.Это зависит от реальной ситуации.Таблица очень проста и не может быть разбита на 100 миллионов строк. Поэтому обратите внимание, когда количество строк в таблице превышает десятки миллионов.Если нет проблем с производительностью, вы можете подождать и посмотреть.Не спешите разбивать таблицу, потому что разбиение таблицы принесет много проблем.
Проблема горизонтального разделения раздражает больше, чем вертикальное.
Чтобы рассмотреть, как резать, продвинутая точка называется маршрутизацией.
1, в соответствии с идентификатором, это диапазон маршрутов, например, от 1 до 9999 миллионов, 1,03 миллиона ~ 1999, положить таблицу, один класс. Это зависит от области действия, и все еще есть проблема с возможной производительностью, и область действия мала. . Этот стол не должен умереть.
Преимущество этого метода деления в том, что его легко вырезать, он простой и грубый, а новые подтаблицы данных не повлияют на предыдущие данные, а предыдущие данные не нужно перемещать.
2. Маршрутизация хэшей Просто возьмите несколько столбцов для хеширования и посмотрите, в какой базе данных находятся данные. Например, возьмите идентификатор в качестве хэша. Остаток от 1500 равен 4, поэтому эта запись помещается в таблицу user_4. В 2011 году остаток от 8 равен 3, поэтому эта запись помещается в user_3. Преимущество этого метода классификации в том, что он очень равномерно разделен.В основном данные в каждой таблице похожи, но что делать, если я добавляю новые данные и забиваю таблицу в будущем, предыдущие данные должны быть перемещены , что больше раздражает!
3. Создайте таблицу для хранения отношений маршрутизации Или возьмем в качестве примера таблицу пользователей, то есть получим таблицу маршрутизации, в которой хранится userId и номер таблицы, указывающие на то, что userId принадлежит этой пользовательской таблице. Этот метод также прост, и после разделения таблицы изменяется таблица маршрутизации и переносятся некоторые данные. Но этот метод приводит к двум запросам на каждый запрос, и если таблица маршрутизации слишком велика, таблица маршрутизации снова становится узким местом!
Давайте поговорим о времени запроса.
Например, если вы хотите проверить 100 лучших пользователей с самым ранним временем регистрации, это означает, что вы должны отсортировать по времени регистрации для каждой таблицы в горизонтальной оценке и взять 100, а затем сравнить 100 результатов каждой таблицы с получить окончательный результат. Во-первых, операция становится хлопотной.То, что было сделано с одним заказом в прошлом, теперь сложнее, и еще один фактор, который следует учитывать, - это вопрос времени.Если вы разбиваете его на 20 таблиц, то вам нужно выполнить 20 заказов по , Если это выполняется последовательно, это накладные расходы времени также являются проблемой!
Реализация подставной базы данных и подсула
Конкретная реализация также делится на инкапсуляцию программного кода и инкапсуляцию промежуточного программного обеспечения базы данных. Сложность реализации будет больше, чем у разделения чтения-записи.Что касается сравнения двух пакетов, то мы уже упоминали о разделении чтения-записи и чтения-записи и не будем повторять их здесь.
Суммировать
Сказав так много, кажется, что подтаблица подбазы данных совсем не хороша. Да, она создаст много проблем. Поэтому проектирование архитектуры должно следовать эволюционному принципу. Ничего нельзя достичь за одну ночь. В разных сценариях ,подстраиваются разные архитектуры,и архитектура только подходящая.Да нет единой архитектуры под любой сценарий.
В программном обеспечении достаточно просто - хорошо.Технологии не дороги и не дешевы.Плохо, если они распределены.Чем сложнее система, тем выше стоимость и сложность сопровождения, и тем больше вероятность возникновения проблем. Эволюция этой архитектуры часто определяется пользователями, что можно назвать «последним средством».
По сути, база данных на одном компьютере может поддерживать 100 000 пользователей. В общем, если база данных не выдерживает, обновите оборудование, оптимизируйте конфигурацию базы данных, оптимизируйте код, внедрите Redis и т. д. Используйте эти более сложные вещи только тогда, когда они действительно не работают.
Если есть ошибки, поправьте меня! Личный публичный аккаунт: стратегия прокачки да