Как мне моделировать данные, которые со временем меняются медленно?

Question

Допустим, я получаю большое (2 миллиона строк?) Количество данных, которое должно быть статичным и неизменным. Должно быть. И эти данные публикуются ежемесячно. Какие методы доступны для 1) знать, какие точки данных менялись от месяца к месяцу и 2) использовать данные, данные на определенный момент времени?

Решение 1) Наивно сохраняйте каждый снимок данных, аннотированный по дате. Осведомленность о разнице обрабатывается некоторой внутренней программой, но потребление данных по дате тривиально. Минусы, требования к пространству аэростата на порядок.

Решение 2A) Используя внутреннюю программу, отследите, когда происходят различия, и сохраните их в таблице EAV с аннотацией по дате. Требования к пространству низки, но потребление, интегрированное с исходными данными, становится громоздким.

Решение 2B) Используя внутреннюю программу, отследите, когда происходят различия, и сохраните их в редко заполненной таблице, которая очень похожа на исходную таблицу, заполненную только измененными данными и датой. когда изменилось. Минусы, модель редкая, а потребление, интегрированное с исходными данными, нетривиально.

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

Относится ли это вообще к хранилищу данных?

Пахнет как ... Медленно меняющееся измерение?

Answer 1

У меня была похожая проблема - большие плоские файлы импортировались в базу данных один раз в день. Большая часть данных не меняется.

Добавьте два дополнительных столбца в таблицу, начальная_дата и конечная_дата. Значение по умолчанию для end_date должно быть когда-нибудь в будущем.

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

• Если ключи равны: сравните остальные столбцы, чтобы увидеть, изменились ли данные. Если данные строки равны, строка уже находится в базе данных и делать нечего; если он другой, обновите существующую строку в базе данных с конечной датой сегодняшнего дня и вставьте новую строку с начальной датой сегодняшнего дня. Прочитать новую строку из обоих файлов.
• Если ключ из старого файла меньше: строка была удалена. Обновление конечной даты до сегодняшнего дня. Прочитать новую строку из старого файла.
• Если ключ из нового файла меньше: была вставлена ​​строка. Вставьте строку в базу данных с начальной датой сегодняшнего дня. Прочитать новую строку из нового файла.

Повторяйте, пока не прочитаете все из обоих файлов.

Теперь, чтобы запросить строки, которые были действительны на любую дату, просто выберите с предложением where test_date между start_date и end_date.

Answer 2

Вы также можете взять лист из книги хранилища данных. Существует три основных способа борьбы с изменяющимися данными. Взгляните на эту статью в Википедии для SCD, но это по сути таблицы: http://en.wikipedia.org/wiki/Slowly_changing_dimension

Answer 3

Не могли бы вы сделать следующее:

1. Each month BCP all data into a temporary table
2. Run a script or stored procedure to update the primary table 
   (which has an additional  DateTime column as  part of a composite key), 
   with any changes made.
3. Repeat each month.

Это должно дать вам таблицу, к которой вы можете запрашивать данные на определенную дату.

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

Однако, в качестве резервной копии, я бы сохранял каждый файл данных, как предлагает Бреннан.

Answer 4

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

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

Answer 5

Если бы это был я, я сохранял бы все это каждый месяц (не обязательно в базе данных, но в виде файла данных или текстового файла в автономном режиме) - вы будете рады, что сделали это. Даже при размере строки 4096 байт (дикая догадка) вы говорите только о 8 ГБ диска в месяц. Вы можете сэкономить много месяцев на диске 300G. Я делал что-то подобное годами, когда я загружал более 1 ГБ в день в хранилище данных.

Answer 6

Многое зависит от того, как вы храните данные. Есть два фактора, которые следует учитывать:

• Как часто меняются данные?
• Насколько изменяются данные?

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

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

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

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