Всем привет, я младший черный брат внизу~
С быстрым ростом бизнеса бизнес становится все более и более массовым, процесс, в котором мы столкнемся с множеством проблем, вынуждающих нас к техническому обновлению.
Давайте поговорим об этом сегодня, этот процесс столкнется с проблемами, связанными с данными.
Проблема роста данных
При быстром росте бизнеса и постоянном увеличении количества записей данных в бизнес-таблице возникнут две проблемы.
Во-первых, данные базы данных в конечном итоге будут храниться на локальном диске, чем больше записей данных, тем больше места на диске будет занято, а соответствующее оставшееся свободное место будет меньше.
После того, как оставшееся пространство достигнет определенного порога, будет срабатывать непрерывный сигнал тревоги о дисковом пространстве, потребляя ресурсы драгоценного производственного сервера базы данных.
Во-вторых, чем больше записей в бизнес-таблице, тем менее эффективным будет запрос к таблице и тем труднее будет изменить таблицу.
То, что решает эту проблему, существует множество решений, одно из которых внедряет на сегодняшний день и архивы данных.
архивирование данных
Решение архивации данных очень простое, то есть перенести данные производственной базы данных в базу данных с той же структурой таблиц, и повысить эффективность запроса данных и других операций за счет уменьшения количества записей в производственной базе данных.
Процесс архивации данных показан на рисунке:
Архивирование данных разделено на три процесса
- Создайте новую библиотеку архива базы данных, затем создайте те же таблицы в библиотеке архива, что и в производственной библиотеке.
- Производство продолжает запрашивать запись данных репозитория, синхронную репликацию в архивную библиотеку.
- Производственная библиотека удаляет записи данных, которые были скопированы.
Хотя процесс архивирования данных очень прост, мы должны четко продумать следующие вопросы при разработке схемы архивирования данных:
- Перед архивированием: какие данные можно архивировать? Как выбрать архивную библиотеку?
- В архивировании: план внедрения архивации данных
- После архивирования: Архивирование данных приводит к планированию проблем
перед подачей
Во-первых, нам нужно подумать о первом вопросе, эти данные могут быть заархивированы?
В таблице большой объем данных, и явно есть горячие и холодные данные, реже холодный доступ к данным.
Очень типичный пример, данные заказа. Обычно мы получаем доступ к самым последним историческим ордерам, в то время как исторические ордера годовой давности просматриваются редко.
Другим примером являются данные о купонах. Для использования купонов, срок действия которых еще не истек, может потребоваться запрос. А купоны, срок действия которых истек год назад или которые были использованы, используются редко.
Поэтому, прежде чем проектировать архивирование данных, нам нужно подумать о том, подходят ли данные, которые мы архивируем, для архивирования.
Во-вторых, нужно подумать о выборе архивных баз.
Основная цель архивирования данных — сохранить ценное хранилище рабочего сервера, а данные необходимо сжать перед сохранением в базе данных.
Поэтому архивным библиотекам необходимо выбирать механизмы хранения, поддерживающие высокие коэффициенты сжатия.
В настоящее время мы используем выделение библиотеки архива Tokudb MySQL базы данных Tokudb, соотношение сжатия около 6: 1.
в архиве
Как видно из приведенного выше процесса, архивирование данных — это не что иное, как запрос данных, вставка данных и последующее удаление данных.
Затем мы можем разработать общий сценарий архива на основе этого процесса.
Google провел поиск и нашел на Github гаджет для архивирования, который в основном реализует автоматическую операцию архивирования данных, унифицированное управление планированием задач архивирования, автоматический мониторинг и раннее предупреждение, а также автоматическое создание отчетов. В определенной степени сохраняется производительность и повышается эффективность эксплуатации и технического обслуживания.
адрес гитхаба:GitHub.com/но барун/ничего...
особые требования к файлам
Как правило, в большинстве ситуаций достаточно стандартного сценария архивирования данных. Но если есть какие-то особые требования к архивированию данных, его нужно разработать самостоятельно.
Например, у нас есть проект, и требование для архивации данных состоит в том, чтобы запрашивать данные 90-дневной давности пакетами, а затем вставлять данные в архивную таблицу текущего года.
Например, если текущая запись данных была создана 31.12.2020, эта запись будет заархивирована в таблице archive_2020.
Затем, если запись данных была создана 01.01.2021, запись будет заархивирована в таблице archive_2021.
Как и этот метод архивации данных с очевидными бизнес-требованиями, нам нужно самим разработать его в проекте.
Рекомендации по архивированию
Во-первых, процесс архивации данных требует непрерывного чтения и записи производственной библиотеки, которая будет использовать много сети и операций ввода-вывода. Чтобы предотвратить давление на онлайн-бизнес, архивирование данных обычно выполняется только в периоды низкой пиковой нагрузки.
Кроме того, нам необходимо максимально оптимизировать данные, чтобы свести к минимуму влияние на онлайн-бизнес.
Во-вторых, после того, как данные будут заархивированы, данные в производственной базе данных будут удалены.После удаления данных это вызоветдыры в данных. То есть после удаления данных табличное пространство не освобождается вовремя, а когда нет заполнения новыми данными в течение длительного времени, это приведет к пустой трате места.
Поэтому после удаления данных нам нужно вовремя оптимизировать дыры в данных, чтобы освободить эти пустые места.
В-третьих, если архивирование данных влияет на онлайн-бизнес, вы должны вовремя остановить потери, прекратить архивирование данных, а затем проанализировать проблему, чтобы вовремя обнаружить проблему.
после архивации
После того, как данные будут заархивированы, это принесет некоторые проблемы, и нам нужно вовремя подумать об этих планах.
Идемпотентность данных нарушена
Для производственных баз данных мы можем использовать уникальные индексы, чтобы предотвратить вставку повторяющихся данных.
Однако после того, как данные заархивированы, часть данных заархивирована в архивную библиотеку, чтобы производственную библиотеку можно было снова вставить в эти базы данных, что приведет к вставке дубликатов данных в бизнес.
Тогда эту проблему мы можем решить с помощью генератора идентификационных номеров. Уникальный индекс производственной базы данных хранит идентификатор, сгенерированный номером идентификатора, который монотонно увеличивается каждый день, поэтому теоретически повторяющихся идентификаторов не будет.
RT более высокий запрос архив библиотеки
Так как архивная база данных использует механизм хранения с высокой степенью сжатия, это приведет к более высокому RT запроса к архивной базе данных.Например, запрос рабочей базы данных составляет 1 мс RT, а при использовании tokudb станет 2 мс.
Тогда этот вопрос нам нужно подумать с точки зрения бизнеса, приемлемо ли это.
Если вы занимаетесь фоновыми запросами и можете принимать запросы с высоким RT, мы можем использовать архивную библиотеку.
Затем, если вы выполняете запрос со стороны внешнего пользователя, а RT запроса низкое, вы не можете принять запрос к архивной библиотеке.
Но с другой стороны, если бизнес требует, чтобы RT запроса был ниже, действительно ли эти данные подходят для архивирования?
Отсутствующие архивные данные влияют на бизнес
После того, как данные будут заархивированы, эта часть данных будет отсутствовать в производственной библиотеке. Если бизнесу потребуется использовать эти данные, это вызовет бизнес-исключения.
Например, в платежном бизнесе возврат средств обычно должен поддерживать заказы в течение одного года. Затем, если данные текущего платежа по транзакции просто заархивированы во время возврата, это приведет к тому, что соответствующие данные платежа не будут найдены во время возврата, что приведет к сбою возврата.
У этой проблемы есть два решения: первое решение — двойной запрос. Если производственная база данных не может найти бизнес-данные, перейдите в архивную библиотеку, чтобы найти их.
Это решение подходит для офлайн-бизнеса.
Второе решение заключается в разработке совместимого решения, предоставляющего обратный интерфейс данных для обратного восстановления записей архивной базы данных в рабочую базу данных.
Это решение подходит только для небольшого числа бизнес-сценариев, в которых бизнес-исключения вызваны архивными данными.
Суммировать
Архивирование данных может решить такие проблемы, как предупреждения о нехватке места на диске, запросы к таблицам и снижение эффективности изменений из-за чрезмерного объема данных в производственной базе данных.
Однако у плана задач есть две стороны: архивирование данных может вызвать такие проблемы, как идемпотентное повреждение данных, высокая RT базы данных запроса архива, отсутствие архивных данных и влияние на бизнес.
Поэтому, когда мы разрабатываем план архивации данных, нам необходимо всесторонне рассмотреть его, заранее подготовить план и решить возможные бизнес-задачи.