Управление огромными записями транзакций?

Question

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

Какое решение я могу предоставить, чтобы уменьшить размер базы данных в будущем?

Как бы вы поступили в этой ситуации?

Из моего наблюдения за несколькими корпоративными приложениями можно предоставить возможность, что пользователь может архивировать записи «старше 60 дней» и т. Д.в текстовый файл. Ну, я мог бы предоставить возможность архивировать обработанные записи в текстовый файл и удалять записи из базы данных, текстовый файл можно было бы позже импортировать, если необходимо?Это решение?

Answer 1

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

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

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

Answer 2

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

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

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

Answer 3

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

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

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

Answer 4

ИМХО, это зависит от того, насколько вероятно, что пользователю понадобится анализировать прошлые данные.Если это возможно, просто создайте хорошие индексы и храните все данные в своей основной базе данных.

Если это не так, перенесите его в TXT.Конечно, время, когда это происходит, должно быть настраиваемым.