задний план

Поскольку исторические бизнес-данные хранятся в mysql, существует таблица записи операций video_log. Всякий раз, когда пользователь создает, обновляет или проверяет аудитором, журнал будет добавляться в соответствующий video_log. Эта таблица журнала имеет только вставку, как вы можете представьте, 1 видео соответствует нескольким логам, 10w видео в день и в среднем 5 логов на одно видео, тогда 50w логов в день, 50*30=1500w записей в месяц, а год 1500*12=180 миллионов. На данный момент в сети находится более 200 млн данных.Так как сам лог не ориентирован на сторону C, он используется для запросов проблем, поэтому можно допустить небольшую задержку. Однако с накоплением времени он неизбежно будет становиться все медленнее и медленнее, что влияет на эффективность, поэтому предлагается преобразование.

Вариант 1. Резервное копирование старых данных

Поскольку журнал сам по себе не является наиболее важными данными, но также требует высокой производительности в реальном времени (для проблем с запросами в реальном времени), первоначальная идея состоит в том, что основное базовое хранилище должно оставаться неизменным, а более старые данные будут перенесены. Вероятность оперативных записей многолетней давности очень мала, если вдруг захочется проверить, можно выйти в офлайн. Что касается дизайна, нам нужен только синхронизированный скрипт для извлечения данных каждый день около 4:00 утра (период низкой деловой активности). Извлеченные данные могут быть переданы в какое-либо автономное хранилище (обычно компании имеют хранилища данных на основе ульев и т.п.), чтобы данные онлайн-видеожурнала не росли все время.

Вариант 2: Подтаблица

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

1. Сначала подтвердите ключ сегментирования, потому что video_log привязан к видео, поэтому, естественно, выберите video_id в качестве нашего ключа сегментирования.
2. Таблица определяется в зависимости от того, какая таблица, а затем подтвердите, сколько таблиц нужно разделить. Сначала поставьте небольшую цель и поддерживайте ее в течение 3 лет. Максимальное количество данных на таблицу — 100 миллионов (потому что наш запрос простой).Согласно приведенной выше статистике, нас будет около 3*1,8=540 миллионов за 3 года, поэтому необходимо примерно 5,4/1≈6 таблиц.

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

1. Вставка новых данных непосредственно в новую таблицу
2. Поскольку таблица журнала имеет только вставку, в ней нет таких операций, как обновление и удаление, и эти сценарии не нужно рассматривать.
3. После разделения таблицы в журнале видео есть две таблицы (старая таблица и новая таблица), поэтому две таблицы временно проверяются, а затем объединяются.
4. Синхронизировать старые данные с новой таблицей
5. Код для чтения старой таблицы в автономном режиме

Вариант 3. Переход на tidb

Недостатки второго плана более очевидны.Что делать через 3 года и продолжать демонтаж счетчика? Такое ощущение, что там всегда есть исторический долг. Итак, мы нацелились на tidb.Tidb — это распределенная база данных.При подключении к tidb нам не нужно заботиться о подтаблицах.Эти tidb делают это за нас, и он сам по себе расширит возможности узлов. Поскольку он распределен, очень важно, чтобы первичный ключ tidb был неупорядоченным.
Весь процесс условно делится на следующие 4 шага:

1. Сначала двойная запись (запишите идентификатор mysql при первом запуске двойной записи, данные перед этим идентификатором должны быть старыми данными)
2. Синхронизировать старые данные (отличающиеся идентификатором, записанным на первом этапе)
3. Вырезать чтение (синхронизация старых данных завершена)
4. удвоить

Сосредоточьтесь на ямах, возникающих при синхронизации старых данных

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

1. Если задание прерывается в середине, что делать, если оно перезапущено, помимо временных затрат на повторный запуск данных, данные, которые были синхронизированы, будут повторяться при повторном запуске, и проблема дублирования данных также должна быть решена. обдуманный. Чтобы решить проблему дублирования данных, вы можете добавить новое поле в старую таблицу, чтобы определить, была ли она синхронизирована.После каждой синхронизации обновляйте следующее поле. Недостатки: онлайн-данных много, и добавлять поле небезопасно, что может вызвать перегрузку онлайн.
2. Поскольку добавлять поле нехорошо, используйте существующий идентификатор первичного ключа в качестве ограничения и синхронизируйте идентификатор первичного ключа, чтобы даже если сценарий перезапустился и запустился с самого начала, поскольку был вставлен тот же первичный ключ, будет сообщено об ошибке. Вроде все идеально, но tidb распределенный и id первичного ключа не является непрерывным, поэтому может возникнуть такая ситуация. Обычные бизнес-данные вставляются в tidb, и идентификатор первичного ключа, назначенный tidb, дублируется с идентификатором первичного ключа, синхронизированным с mysql, поэтому независимо от того, кто это, последний вставленный должен дать сбой.

Окончательный сценарий сценария синхронизации

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

1. 任务分批提升效率: Во-первых, в соответствии с производительностью обработки и ожидаемым временем завершения, старые данные делятся на пакеты, около 10 пакетов и 10 заданий используются для запуска разных пакетов данных, не мешая друг другу, и каждый раз обновляются 100 пакетов. .
2. 记录状态，重启自动恢复到断点: Записывать текущую позицию синхронизации после каждой синхронизации данных (redis записывает текущий id), даже если вы перезапустите, вы можете получить предыдущую позицию обновления от redis, а затем обновить ее.
3. 避免主键冲突: синхронизировать все поля, кроме первичного ключа (не синхронизировать первичный ключ).

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