Структура таблицы для контроля версий данных

Question

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

Answer 1

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

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

Answer 2

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