Comments 9
А вам не кажется что п.9 и п.10 противоречат друг другу? Материализованное представление мало отличается от витрины данных. Особенно с точки зрения "потребителя" данных
В первом абзаце речь идет только о соединении сущности с ее атрибутами (а не любых таблиц), которое затем используется для построения аналитических запросов, и никогда (в отличие от витрин данных) не используется для рабочей системы («на проде»). Это удобный аналитический инструмент, а не источник данных.
Во втором абзаце говорится об источнике значений (словаре) для заполнения одного поля (в отличие от витрин данных, насчитывающих обычно сотни полей).
В третьем абзаце говорится об автоматических запросах для проверки целостности и качества данных. Это тоже сильно отличается от витрин данных.
Дополнение к разделу "Суррогатные ключи в адаптированном формате ULID" в моем комментарии к другой статье (https://habr.com/ru/post/572700/#comment_23418560):
Вот хороший новый вариант UUID длиной 160 бит: Long ULID for high-load critical systems and IoT, в котором уникальность, монотонность и пригодность для первичного ключа не принесены в жертву 128-битной краткости. Длина всех составных частей UUID и точность времени (timestamp) обоснованы и позволяют достичь максимально возможной производительности. Используется надежный генератор случайных чисел и тактовая последовательность (clock sequence).
Принципиально новым является двухсимвольный локальный для базы данных тип сущности, указывающий на таблицу базы данных, в которой данный UUID является первичным ключом. Это удобно для установления полиморфных отношений между таблицами базы данных. В одном поле типа array или типа jsonb может быть несколько UUID c различными типами сущности. Тип сущности также помогает быстро найти все таблицы, где могут содержаться UUID с указанным типом сущности. Тип сущности опциональный, и может заполняться случайным числом.
Также используется кодировка Crockford's base32 и возможна обратная совместимость по длине и структуре с 128-битными UUID в строковом формате 8-4-4-4-12 с дефисами.
Хранение UUID возможно в любом формате: text, binary, UUID, integer, byte array, jsonb.
Мне задали вопрос, какую СУБД лучше выбрать для хранилища данных с Anchor modeling. Для быстрого чтения данных из таблиц связей лучше всего подходит колоночная СУБД (column-oriented DBMS) - см. https://en.wikipedia.org/wiki/List_of_column-oriented_DBMSes - или Microsoft SQL Server с колоночными индексами (columnstore indexes).
В то же время, для обработки большого количества соединений таблиц необходима СУБД, применимая для многочисленных join'ов и поддерживающая в достаточной степени стандартный SQL. Поэтому ClickHouse не подойдет, несмотря на его рекордную производительность в обычных для него задачах.
Я отдаю предпочтение MariaDB ColumnStore, Vertica, Greenplum и Microsoft SQL Server с колоночными индексами. Их производительность и возможности примерно одинаковые, и выбор должен делаться исходя из стоимости владения и требований совместимости. Хотя нагрузочные тесты, конечно, не помешают.
https://db-engines.com/en/system/Greenplum%3BMariaDB%3BMicrosoft+SQL+Server%3BVertica
В статье Николая Голова Дилемма моделирования в рамках Data Vault/Anchor Modeling: объект или событие описывается используемая в компании ManyChat модель, в которой связи, у которых есть один или несколько атрибутов, выделяются в отдельную категорию "стримов" (stream, поток). Каждая запись в стриме обозначает какое-то событие. В указанной статье примером стрима является таблица покупок. Но стримом может быть и таблица бухгалтерских проводок, лог (журнал), очередь сообщений и т.п.
Стримы позволяют произвести некоторую денормализацию в том месте модели, где это необходимо - в отличие от классической Anchor Modeling и подобно Data Vault. По сравнению с моим прежним предложением разрешить атрибуты для связей, выделение стримов в отдельную категорию более удобно, так как в модели сразу видны такие денормализованные места.
Стримы сочетают в себе черты сущностей, обозначаемых квадратом, и связей, обозначаемых ромбом. Поэтому можно было бы обозначать стримы наложением квадрата на ромб - восьмиконечной звездой 🟐 (U+1F7D0).
В указанной статье утверждается, что событие, в отличие от объекта (сущности), неисторично, то есть не обладает цепочкой состояний. Из этого можно сделать вывод, что для стримов невозможно или не имеет смысла рассчитывать (в момент добавления более актуальной записи) и сохранять дату и время окончания срока действия записи. Впрочем, это верно и для некоторых связей, у которых нет атрибутов, и для некоторых сущностей.
Но я бы не был так категоричен: возможно, что для некотрых стримов было бы удобно сохранять дату и время окончания срока действия записи, как и для связей. Например, для бухгалтерских проводок по закрытым периодам в качестве даты окончания срока действия записи можно было бы указать дату окончания периода, которую можно использовать для секционирования (partitioning) или сегментирования (sharding) БД или архивирования старых записей.
Ситуации, когда в таблицу связей нужно добавить атрибут(ы), не ограничиваются учетом событий. Например, можно создать таблицу для хранения тегов (меток) каких-то сущностей на разных языках. В таблице будет два внешних ключа (указатель на сущность, указатель на язык) и атрибут (сам тег). Вместе эти три поля таблицы образуют составной первичный ключ.
Интересная актуальная инициатива по стандартизации новых версий UUID, очень похожих на ULID: https://github.com/uuid6/uuid6-ietf-draft
Меня спросили, как лучше организовать загрузку данных в хранилище данных.
Я сторонник инкрементальной загрузки и передачи данных между слоями хранилища данных в режиме мягкого реального времени, с отбором подлежащих загрузке новых записей по таймстемпу и сиквенсу в UUID записи с источника данных. Простейший случай - когда источник данных и хранилище данных работают под одной и той же СУБД.
Режим реального времени редко встречается в корпоративных информационных системах, но его польза может быть неоценима - для финансового менеджмента в кризисных ситуациях, для оперативного управления ресурсами и для других критических задач бизнес-пользователей.
Как упростить доработки и поддержку хранилища данных?