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

Question

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

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

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

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

Answer 1

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

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

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

Answer 2

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

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

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

Answer 3

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

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

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

Answer 4

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

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