Стратегия хранения данных

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

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

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

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

Данные рассуждения не являются чем-то новым, так как уже реализованы в хранилищах больших данных типа Hadoop.

Формат хранения данных

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

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

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

С учетом этих соображений, и предлагается нижеследующий формат хранения данных.

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

Итак, предлагается формат записей данных о сущностях и их атрибутах, основанный на понятии потока операций, базирующихся на следующих определениях:

• Операция — это атомарное изменение одной сущности данных.
• Сущность состоит из атрибутов.
• Сущность имеет тип, который определяет состав ее атрибутов.
• Сущности одного типа хранятся в одном потоке.
• Поток операций — объект хранения типа таблица, где располагаются операции, относящиеся к сущностям одного типа и изменяющие их состояние.

Соответственно, каждая операция состоит из заголовка операции и набора атрибутов, которые зависят от типа сущности:

1. OpID — уникальный идентификатор операции
2. OpTS — временная метка операции
3. OpType — тип операции
4. OpClass — название потока
5. OpUser — пользователь системы, выдавший команду
6. OpDoc — документ операции, то есть документ, который ее создал, может не устанавливаться
7. OpComment — комментарий операции
8. ID — идентификатор сущности, к которой относится операция
9. Параметры — атрибуты операции, зависящие от потока

OpID и ID могут быть любыми, но сейчас, возможно имеет смысл использовать UID.
OpTS скорее всего должно быть типа timestamp, но дополненная порядковым индексом, если несколько операций попадут в один временной промежуток, чтобы обеспечить однозначный порядок операций.

OpType может быть любого типа, к примеру, один/несколько символов или число.
OpClass, OpUser и OpComment могут быть как строкой, так и некими ссылками на справочник.
OpDoc обеспечивает связку с документом, но может и отсутствовать. Это связь с верхним уровнем.

Операции делятся на базовые и сервисные.

Базовые операции

Базовых операций 3 — добавление, обновление, удаление,:

1. Операция «A» добавление — констатирует инстанционирование новой сущности определенного типа и устанавливает набор атрибутов.
2. Операция «U» обновление — констатирует изменение сущности определенного типа и устанавливает новые значения определенного набора атрибутов.
3. Операция «D» удаление — констатирует окончание действительности сущности определенного типа.

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

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

При выдаче операции U, система должна проверять наличие операции A для этой сущности и, если она отсутствует, менять тип операции на A.

Операция D закрывает существование определенной сущности и при запросе значений атрибутов этой сущности с точкой актуальности после этой операции, для всех атрибутов этой сущности должны возвращаться значения «не установлено». При выдаче операции D, система должна проверять наличие операции A для этой сущности и, если она отсутствует, отказывать в сохранении команды D.

Как дополнительную особенность, такая структура операций позволяет организовать хранение сущности с одним и тем же ID с разными атрибутами в разные моменты времени не только на основе атрибутов, но и всей сущности. То есть у нас может быть несколько блоков A-N*U-D, в которых сущность существует, а между D и A она не существует.

Сервисные операции

Сервисных операций может быть много и их состав может пополняться. Как пример, можно привести несколько соображений:

1. Операция «N» недействительная операция — данная операция должна игнорироваться системой. Можно менять другие виды операций на N, чтобы исключить их из работы.
2. Операция «C» кэш — данная операция может создаваться с определенной частотой и хранить значения атрибутов на определенный момент времени с целью уменьшить затраты на поиск значений атрибутов вглубь. Подробности параметров операции можно хранить, к примеру, в комментарии или в самом коде операции. Разумеется, при применении базовых операций, операции типа C должны пересчитываться или заменяться на N.
3. Операция «S» групповые операции — данная операция может создаваться с определенной частотой и хранить групповые значения (к примеру, суммы, средние и так далее) атрибутов числовых типов за определенный период. Подробности параметров операции можно хранить, к примеру, в комментарии или в самом коде операции. Разумеется, при применении базовых операций, операции типа S должны пересчитываться или заменяться на N.
4. Операция «G» групповые атрибуты — данная операция может быть аналогична U, но при этом, определенные команды системы будут выдавать не одно значение атрибута(ов), а несколько. Одно значение атрибута на операцию A/U, остальные значения — на операции G, которые расположены между соседними A/U.

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