diff --git a/dev/database/Online Analytical Processing.md b/dev/database/Online Analytical Processing.md index 07ec54a1..d484d320 100644 --- a/dev/database/Online Analytical Processing.md +++ b/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 Реляционная база данных]] diff --git a/dev/database/Online Transaction Processing.md b/dev/database/Online Transaction Processing.md index e8367677..05651d4f 100644 --- a/dev/database/Online Transaction Processing.md +++ b/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 Реляционная база данных]] diff --git a/dev/database/Таблицы сателиты.md b/dev/database/Таблицы сателиты.md new file mode 100644 index 00000000..db64ac6a --- /dev/null +++ b/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]] +**Автор**:: +### Дополнительные материалы +- + +### Дочерние заметки + + diff --git a/meta/files/images/comp/Снимок экрана 2024-11-25 в 13.57.23.png b/meta/files/images/comp/Снимок экрана 2024-11-25 в 13.57.23.png new file mode 100644 index 00000000..abca9fcc Binary files /dev/null and b/meta/files/images/comp/Снимок экрана 2024-11-25 в 13.57.23.png differ diff --git a/meta/files/images/comp/Снимок экрана 2024-11-25 в 13.57.23.png.md5 b/meta/files/images/comp/Снимок экрана 2024-11-25 в 13.57.23.png.md5 new file mode 100644 index 00000000..05036623 --- /dev/null +++ b/meta/files/images/comp/Снимок экрана 2024-11-25 в 13.57.23.png.md5 @@ -0,0 +1 @@ +dd031945915a3aa2b75f28e449954020 diff --git a/meta/files/images/webp/Снимок экрана 2024-11-25 в 13.57.23.webp b/meta/files/images/webp/Снимок экрана 2024-11-25 в 13.57.23.webp new file mode 100644 index 00000000..a7dce00d Binary files /dev/null and b/meta/files/images/webp/Снимок экрана 2024-11-25 в 13.57.23.webp differ diff --git a/meta/files/images/webp/Снимок экрана 2024-11-25 в 13.57.23.webp.md5 b/meta/files/images/webp/Снимок экрана 2024-11-25 в 13.57.23.webp.md5 new file mode 100644 index 00000000..05036623 --- /dev/null +++ b/meta/files/images/webp/Снимок экрана 2024-11-25 в 13.57.23.webp.md5 @@ -0,0 +1 @@ +dd031945915a3aa2b75f28e449954020 diff --git a/meta/files/images/Снимок экрана 2024-11-25 в 13.57.23.png b/meta/files/images/Снимок экрана 2024-11-25 в 13.57.23.png new file mode 100644 index 00000000..4ad02041 Binary files /dev/null and b/meta/files/images/Снимок экрана 2024-11-25 в 13.57.23.png differ