задний план

Не так давно я разместил две статьи о подтаблицах:

• Обсуждение практики наступания на яму с подстолом
• Две-три вещи, на которые стоит обратить внимание после разделения стола

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

Давайте сначала рассмотрим процесс всей подтаблицы подбазы данных следующим образом:

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

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

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

Таким образом, эта статья будет кратким, и содержание, упомянутое ранее, может быть повторено снова.

подтаблица

Прежде всего, какая ситуация подходит для подтаблиц?

По моему опыту, когда объем данных таблицы достиг десятков миллионов или даже сотен миллионов, а ежедневный прирост объема данных составляет более 2%.

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

Когда дело доходит до подтаблиц, мы фокусируемся на горизонтальной подтаблице;

То есть данные большой таблицы распределяются максимально равномерно по N маленьким таблицам посредством алгоритма маршрутизации.

Range

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

Во-первых, первый - разделить по диапазону, например, мы можем разделить время создания таблицы на дату и сохранить ее как ежемесячную таблицу, мы также можем разделить первичный ключ таблицы на диапазон, например [1~10000] в таблице, [10001~20000] в таблице и так далее.

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

В этом подходе есть плюсы и минусы:

• Преимущество в том, что он имеет собственное горизонтальное расширение и не требует слишком большого вмешательства.
• Недостаток в том, что могут быть неравномерные данные (например, всплеск запросов в определенном месяце).

Hash

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

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

Следовательно, размеры нашей таблицы должны быть изменены, и алгоритм таблицы таблицы может принять основнойhash+modКомбинация.

Это классический алгоритм, известныйHashMapТо же самое справедливо и для хранения данных.

Предположим, мы разделили исходную информацию о заказе большой таблицы на 64 подтаблицы:

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

Конечно, если само поле является целым числом и не повторяется, вы можете пропустить этот шаг и продолжить сразу.ModВы можете получить индекс подтаблицы.

Выбор количества подтаблиц

Что касается количества подтаблиц (64), то здесь нет нормативного значения, его нужно оценивать по собственному развитию бизнеса и приращению данных.

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

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

В настоящее время автор не прошел этот этап, поэтому данная статья не представляет его.

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

Range + Hash

Конечно, есть и другой способ,RangeиHashМожно смешать.

Например, вначале мы использовали подтаблицы Hash, но рост данных был огромным, из-за чего данные каждой подтаблицы быстро достигали узкого места, поэтому нам пришлось увеличить емкость, например, с 64 таблиц до 256. .

Однако при расширении мощностей очень сложно мигрировать данные без простоев, даже если это простои, как долго они будут длиться? Сложно сказать.

Так можем ли мыModНа основе подтаблицы она делится на месячную таблицу, с помощьюRangeЕго собственная масштабируемость не требует учета последующей миграции данных.

Этот метод теоретически осуществим, но я не использовал его на практике.Позвольте мне дать вам ссылку для ваших идей.

надоедливая миграция данных

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

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

Ниже приводится краткое изложение наших текущих практик для справки:

1. После того, как подтаблица подключена к сети, все записи данных и запросы относятся к подтаблице, поэтому данные из исходной большой таблицы необходимо перенести в подтаблицу, иначе это окажет большое влияние на бизнес.
2. Мы подсчитали, что для переноса примерно 200 миллионов таблиц программа миграции, написанная нами, займет от 4 до 5 дней.
3. Это означает, что в этот период предыдущие данные невидимы для пользователей, что явно неприемлемо для бизнеса.
4. Таким образом, мы сделали совместимый процесс: после запуска преобразования подтаблицы все вновь сгенерированные данные записываются в подтаблицу, но операция с историческими данными по-прежнему использует старую таблицу, так что шаг переноса данных опущен.
5. Перед операцией с данными необходимо только продумать маршрутизацию.Когда будет сгенерировано достаточно новых данных (у нас есть два месяца), почти все операции будут направлены на подтаблицы, а затем начнется миграция данных из базы данных. миграция завершена, исходное решение о маршрутизации удалено.
6. Наконец, все данные генерируются и записываются из таблицы сегментов.

На этом вся операция с подтаблицей завершена.

бизнес совместимый

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

отчет

Первый отчет.До разделения таблицы это было сделано путем запроса одной таблицы.Теперь это отличается от одной таблицы до N таблиц.

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

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

Запрос

Другое дело – запрос. Исходного запроса на подкачку точно нет, ведь бессмысленно разбивать на страницы сотни миллионов данных.

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

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

Филиальная библиотека

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

В течение месяца после завершения раздельной таблицы увеличился IO всей БД из-за записи в БД "других таблиц", и эти "другие таблицы" не имели отношения к бизнесу.

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

Поэтому мы перенесли эти таблицы в новую базу данных, полностью изолированную от существующего бизнеса.

Для этого потребуется несколько модификаций:

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

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

Суммировать

Наконец, нам также необходимо выполнить этап архивирования исторических данных и перенести данные за N месяцев вHBASEхранение, гарантияMySQLДанные остались в допустимых пределах.

Запрос архивных данных зависит от больших данных для предоставления услуг.

Эта подбиблиотека и подтаблица - очень редкая практическая операция.Большая часть информации в Интернете - это то, что шины были заменены до того, как автомобиль покинет завод.

И большинство сцен, с которыми мы столкнулись, заключались в смене шин автомобиля, едущего по шоссе, и случайно «машина разбилась и умерла»!

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

Ваши лайки и репост - лучшая поддержка для меня