предисловие
Бенпийский на«Обсуждение практики таблетированной ямы», поэтому друзья, которые его не видели, советуют сначала прочитать вышеизложенное.
Кратко повторим, что было упомянуто в прошлый раз:
- Стратегия разбиения таблиц: хеширование, архивирование по времени и т. д.
- Выбор полей подтаблицы.
- Сценарий переноса данных.
В основе этой статьи лежат некоторые вопросы, возникающие в наше время, и попытки их решения.
возникает проблема
Как упоминалось ранее, нам необходимо перенести данные исходной таблицы в новую таблицу до того, как приложение для разделения таблиц перейдет в режим онлайн, чтобы гарантировать, что это не повлияет на бизнес.
Поэтому мы написали отдельное приложение для миграции, которое отвечает за миграцию данных в большой таблице в 64 подтаблицы, а данные, сгенерированные в процессе повторной миграции, в конце концов, малы, и, наконец, их можно снова мигрировать на ночь запуска.
Все было очень хорошо, но когда приложение запустили, все оказалось не так просто.
Повышенная нагрузка на базу данных
Прежде всего, первая проблема заключается в том, что сама база данных этого не выдерживает.Перед тем, как мы используем эту программу миграции, нагрузка на саму базу данных относительно велика, и это приложение становится последней каплей.
Конечный результат таков: большая часть работы всех подключенных к базе данных программ не происходит, доступ к диапазону меньше, чем ненормальное подключение к базе данных.
Наконец, мы не можем поставить это приложение только рано утром, но на самом деле это все еще невозможно.
Несмотря на то, что объем бизнеса рано утром снизился, по-прежнему поступает небольшое количество запросов, а также будут возникать различные исключения базы данных.
Во-вторых, эффективность программы миграции также очень низкая.По этой скорости мы оценили время миграции.Миграция трех самых больших таблиц (от 300 до 400 миллионов данных) в подтаблицы займет около 10 дней. .
Итак, мы изменили план, запустили программу миграции в ведомой библиотеке и, наконец, импортировали подтаблицу непосредственно в основную библиотеку посредством эксплуатации и обслуживания.
Поскольку нагрузка подчиненной библиотеки намного меньше, чем нагрузка основной библиотеки, влияние на бизнес невелико, а эффективность миграции намного выше.
Несмотря на это, миграция 100 млн данных заняла одну ночь + один день, но нагрузка на бизнес становится все больше и больше, и объем данных продолжает расти, и этой эффективности все еще недостаточно. .
Совместимое решение
В конце концов, нет другого выхода, кроме как придумать решение, которое не переносит данные, но вновь сгенерированные данные все равно записываются в подтаблицу, по крайней мере, чтобы гарантировать, что данные большой таблицы не будут добавлены.
А как же предыдущие данные? Не могу перестать смотреть.
По сути, операция с данными есть не что иное, как разделение на增删改查, давайте посмотрим, как эти четыре операции совместимы.
новый
Добавлять проще всего, все данные напрямую записываются в новую таблицу согласно правилам шардинга таблиц, что гарантирует, что данные старой таблицы не будут добавлены.
Удалить
Удалить немного сложнее, чем добавить, например, если пользователь хочет удалить сгенерированный им фрагмент информации (например, данные заказа), возможно, что эти данные находятся в новой таблице или в старой таблице.
Поэтому при удалении сначала удалите новую таблицу (ведь частота обращений к вновь генерируемым данным выше), а если удаление не удалось, удалите ее из старой таблицы еще раз.
Исправлять
Модификация такая же, то же самое не будет уверено, где существуют данные, поэтому сначала необходимо изменить новую таблицу, а старая таблица будет изменена снова после сбоя.
Запрос
Запрос относительно более сложнее, поскольку большинство данных в этих больших таблицах хранят несколько записей, сгенерированные пользователем (например, информацию о заказе пользователя).
В это время обычно происходит листание по странице, и сортировка по времени.
Проблема здесь: поскольку она должна быть разбита на страницы, можно запросить часть данных в подтаблице и объединить ее с данными в исходной большой таблице.
Таким образом, запрос здесь фактически разделен на три случая.
- Во-первых, при запросе данные в подтаблице, где находится пользователь, можно разделить на несколько страниц.
- Первый шаг — сначала определить, можно ли получить текущую страницу во всех подтаблицах, и если да, напрямую извлечь данные из подтаблицы и вернуть их (при условии, что всего можно запросить 2 страницы данных). при пейджинге текущая страница является первой страницей, затем извлекаются данные из всех подтаблиц).
- Если это невозможно, оцените, не может ли текущее количество страниц получить какие-либо данные в подтаблице, и если да, то непосредственно взять данные старой таблицы (например, данные страницы 5 должны быть взяты сейчас, а в подтаблице всего 2 страницы данных.Поэтому данные на странице 5 можно получить только из старой таблицы).
- Однако, если есть часть данных как в подтаблице, так и в старой таблице, вам необходимо получить обе таблицы одновременно, сделать сводку и затем вернуться.
Эта логика применима только к предпосылке разбиения запросов на страницы на основе полей таблицы.
Я думаю, должны быть друзья, которые спросят, не будет ли проблем с производительностью таким образом?
В то же время, что делать, если при подсчете количества подтаблиц и подкачки происходит параллельная запись, что приводит к неточному количеству подкачки и последующих запросов?
Сначала первая проблема с производительностью:
На самом деле, это зависит от того, как выбрать.Для таких целей совместимости на самом деле шагов на несколько больше, чем обычные запросы:
- Определяет, можно ли запрашивать текущую страницу в подтаблице.
- При наличии данных в старой и новой таблицах необходимо запрашивать дополнительную большую таблицу.
Первая логика суда фактически рассчитывается в памяти, и я думаю, что эта потеря полностью незначительна.
Что касается второго шага, то это действительно было бы потерей, в конце концов, более проверенная таблица.
Однако до подтаблицы все данные были получены из старой таблицы, и в то время не было проблем с бизнесом; теперь это только запрос подтаблицы, но объем данных подтаблицы определенно намного меньше, чем у большой таблицы, и есть индексы, поэтому эта эффективность не будет намного медленнее.
Более того, по принципу локальности и привычкам пользователей данные в старой таблице редко запрашиваются, со временем все данные обязательно будут получены из подтаблицы, и постепенно старая таблица станет историческая таблица.
Что касается второй проблемы параллелизма, я не думаю, что это имеет большое влияние.Предпосылка этого пейджинга должна быть заблокирована, но для такой маленькой проблемы, которая не вызывает зуда, производительность снижается.Рентабельно.
А в будущем мы также можем потихоньку мигрировать данные старой таблицы в новую таблицу, чтобы эту логику совместимости можно было полностью убрать, а все данные получать из подтаблицы.
Суммировать
Как я уже говорил, различные операции и методы здесь подходят далеко не всем, ведь уйти со сцены — это туфта.
Например, если подтаблица запущена раньше, и бизнес предоставляет определенный период времени для переноса данных в подтаблицу, на этот раз не будет совместимой обработки.
Даже если бизнес-планирование в начале является разумным, а архитекторы команды ориентируются на долгосрочную перспективу, если ключевые данные хранятся в отдельных таблицах, то вообще не будет процесса миграции данных (опытные команды на крупных фабриках могут, маленькие компаниям и небольшим мастерским приходится полагаться на себя.
В этот период меня тоже подкинула БД.Не ерунда БД это последняя капля.
Ваши лайки и репост - лучшая поддержка для меня