Таблицы сателиты.md

dev/database/Online Analytical Processing.md

@@ -8,9 +8,12 @@ date: 2024-03-31
 OLAP (Online Analytical Processing) — это тип нагрузки, который ориентирован на выполнение сложных аналитических запросов, охватывающих большие объемы данных. OLAP используется для построения отчетов, аналитики и поддержки принятия решений, где важно работать с историческими данными и выполнять сложные агрегации.
 
 **Особенности:**
-- Операции SELECT выполняются значительно чаще, чем операции изменения данных.
+- Источником для OLAP являются различные [[Online Transaction Processing|OLTP]] базы
+- Операции `SELECT` выполняются значительно чаще, чем операции изменения данных.
 	- Запросы часто содержат операции агрегации (например, SUM, AVG) и группировки (GROUP BY).
-- Запросы SELECT охватывают большие выборки данных и могут включать сложные агрегации и группировки.
+- Запросы `SELECT` охватывают большие выборки данных и могут включать сложные агрегации и группировки.
+- Часто используется денормализация
+- Скорость обработки зависит от количества данных, но обычно медленнее чем в [[Online Transaction Processing|OLTP]]
 
 Примеры задач:
 - Поиск зависимостей по товарам, которые пользователи покупают вместе.
@@ -24,6 +27,10 @@ OLAP (Online Analytical Processing) — это тип нагрузки, кото
 - Поддержка исторических данных для анализа трендов и построения отчетов.
 
 Это не то же самое, что создание отдельной реплики для отчетности, так как это не решает проблему разных индексов. Однако на логической репликации это возможно.
+
+Рекомендации:
+- Использовать колоночную базу данных
+	- Не вставлять в нее записи по одной, а вставлять пачками.
 ***
 ## Мета информация
 **Область**:: [[../../meta/zero/00 Реляционная база данных|00 Реляционная база данных]]

dev/database/Online Transaction Processing.md

@@ -12,16 +12,18 @@ OLTP (Online Transaction Processing) — это тип нагрузки, кот
 - Частое выполнение операций `INSERT`, `UPDATE`, `DELETE`.
 - Подавляющее большинство операций затрагивает только одну строку.
 - Запросы должны выполняться максимально быстро.
+- Высокая степень нормализации таблиц
 
 Примеры задач:
 - Продажа товаров пользователям.
 - Прием платежей за сотовую связь.
-
 ## Лучшие практики для оптимизации производительности
 - **Использование индексов**: правильно настроенные [[Индекс базы данных|индексы]] позволяют быстрее выполнять операции и уменьшить количество операций чтения.
 - [[../../../../_inbox/Шардирование БД|Шардинг]] (разделение таблиц): разделение таблиц на части снижает нагрузку и улучшает производительность.
 - **Избегание блокировок**: минимизация блокировок таблиц и строк особенно важна при большом количестве параллельных транзакций.
 - Для OLTP-нагрузки не следует использовать параллельное выполнение запросов, так как это забирает ядро процессора у другого запроса, что может привести к задержкам в обработке транзакций и снижению общей производительности системы. В контексте OLTP важнее минимизировать время выполнения каждого отдельного запроса, а не распределять его между несколькими ядрами. ==Каждый запрос должен выполняться на одном ядре как можно быстрее.==
+- #idea Не хранить данные, которые уже не нужны для бизнес-логики, а нужны для OLAP. Попробовать переносить архивные данные в отдельную базу данных. Но возникает вопрос, а как объединять актуальные данные с архивными, чтобы отдавать их на фронт?
+
 ***
 ## Мета информация
 **Область**:: [[../../meta/zero/00 Реляционная база данных|00 Реляционная база данных]]

dev/database/Таблицы сателиты.md

@@ -0,0 +1,79 @@
+---
+aliases: 
+tags:
+  - maturity/🌱
+date: 2024-11-25
+---
+**Сателлитные таблицы (Satellite Tables)** — это концепция, часто используемая в методологии **Data Vault**, которая предназначена для моделирования данных в хранилищах. Их основная цель — хранение атрибутов, которые связаны с основными объектами (например, сущностями или событиями), но имеют динамическую природу или часто изменяются.
+
+![[../../meta/files/images/Снимок экрана 2024-11-25 в 13.57.23.png]]
+
+**Основные понятия:**
+- **Хаб (Hub):**  
+    Таблица, представляющая основную сущность или бизнес-объект, например, клиент, продукт или заказ. В хабе обычно содержатся стабильные и уникальные бизнес-идентификаторы.
+- **Линк (Link):**  
+    Таблица, представляющая связь между хабами. Она моделирует отношения, например, какой клиент сделал какой заказ.
+- **Сателлит (Satellite):**  
+    Таблица, привязанная к хабу или линку, которая хранит дополнительные атрибуты и временные данные.
+
+**Зачем нужны сателлиты?**
+- **Отделение изменяемых данных от неизменяемых:** Хаб содержит уникальные данные, которые редко изменяются. Все остальные данные, которые могут меняться (например, имя клиента, его адрес или статус заказа), переносятся в сателлиты.
+- **Историзация данных:** Сателлиты поддерживают версионность, т.е. они хранят не только актуальное состояние данных, но и их историю. Это достигается за счет добавления колонок:
+    - Дата начала действия версии (`start_date`).
+    - Дата окончания действия версии (`end_date`).
+    - Индикатор актуальной версии (например, `is_current`).
+- **Разделение областей данных:** Сателлиты позволяют разделить разные типы данных для более удобного хранения и обработки. Например:
+    - Один сателлит может хранить адресную информацию.
+    - Другой — контактные данные.
+    - Третий — финансовую информацию
+- **Облегчение загрузки данных:** При использовании ETL (Extract, Transform, Load) сателлиты упрощают инкрементальную загрузку, так как можно обрабатывать только те записи, которые изменились.
+- **Масштабируемость:**  За счет хранения данных в разных таблицах (сателлитах), можно легче управлять растущим объемом данных и делать хранилище более модульным.
+
+**Преимущества сателлитных таблиц:**
+- **Поддержка аудита:** История изменений атрибутов сохраняется, что критично для аналитики и соблюдения нормативных требований.
+- **Управление большими данными:** Разделение на хабы, линки и сателлиты делает модель гибкой и позволяет обрабатывать большие объемы данных с меньшими затратами.
+- **Удобство для интеграции:**  Модель легко расширяется за счет добавления новых сателлитов без изменения существующей структуры.
+
+**Недостатки:**
+- Увеличение количества таблиц и сложности структуры.
+- Медленные запросы из-за множества JOIN-операций.
+- Увеличение объема данных из-за историзации.
+- Сложные и трудоемкие ETL/ELT процессы.
+- Требуется опыт и квалификация для работы с моделью.
+- Ограниченная поддержка в BI-инструментах.
+- Модель может быть избыточной для небольших проектов.
+## Пример
+Предположим, у нас есть сущность "Клиент". В Data Vault модель она будет представлена следующим образом:
+
+Хаб (Hub_Client):
+```plaintext
+client_id | business_key | load_date | record_source
+```
+
+Сателлит (Satellite_Client_Demographics):
+```plaintext
+client_id | name | birth_date | start_date | end_date | is_current | record_source
+```
+
+Сателлит (Satellite_Client_Address):
+```plaintext
+client_id | address | city | country | start_date | end_date | is_current | record_source
+```
+
+Здесь:
+- **Hub_Client** хранит уникальный идентификатор клиента (например, ID из CRM).
+- **Satellite_Client_Demographics** хранит демографические данные клиента, которые могут изменяться (например, имя при смене паспорта).
+- **Satellite_Client_Address** хранит адресные данные клиента, включая исторические изменения адресов.
+***
+## Мета информация
+**Область**:: 
+**Родитель**:: 
+**Источник**:: 
+**Создана**:: [[2024-11-25]]
+**Автор**:: 
+### Дополнительные материалы
+- 
+
+### Дочерние заметки
+<!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
+

meta/files/images/comp/Снимок экрана 2024-11-25 в 13.57.23.png.md5

@@ -0,0 +1 @@
+dd031945915a3aa2b75f28e449954020

meta/files/images/webp/Снимок экрана 2024-11-25 в 13.57.23.webp.md5

@@ -0,0 +1 @@
+dd031945915a3aa2b75f28e449954020