Changes between Version 5 and Version 6 of AdvancedConcepts

Timestamp:

06/11/26 09:21:40 (5 days ago)

Author:

231014

Comment:

--

AdvancedConcepts

@@ -1 +1 @@
 == Advanced Concepts ==
 
-Напредната тема имплементира напреден аналитички (OLAP) слој врз трансакциски податоци за инвентар, користејќи TimescaleDB и pg_cron. Главната идеја е да се овозможи брза анализа на големи количини на податоци преку податочни cubes, наместо директно читање од сурови трансакции. Со ова се подобрува перформансата на извештаи, се намалува комплексноста на SQL кверињата и се овозможува скалабилна аналитика во реално време.
-
-{{{ Креирање на hypertables }}}
-Во првиот дел се трансформираат класичните табли во TimescaleDB hypertables. Табелите inventory_transactions и inventory_movements се партиционираат по created_at во месечни chunk-ови. Ова овозможува значително побрзо читање и скалирање на временски базирани податоци.
-
-{{{ cube_movements_daily }}}
-Овој дел креира материјализиран view кој агрегира движења по ден, производ, бренд и магацин. Податоците се поделени на outbound и inbound логика за да се следи протокот на роба од и кон магацини. Резултатот е дневен аналитички слој кој значително ја намалува потребата од сложени join операции во реално време.
-
-{{{ cube_movements_monthly }}}
-Овој куб ги агрегира дневните податоци во месечни резимеа. Наместо директно да работи со сурови податоци, системот сега користи веќе пресметани дневни вредности. Ова овозможува побрзи извештаи на месечно ниво и подобра скалабилност.
-
-{{{ cube_movements_monthly }}}
-Овој материјализиран view ги поврзува варијантите на производи со нивните атрибути (како боја, големина итн.). Се чуваат и агрегирани информации за број на атрибути по производ. Ова овозможува брзо филтрирање и сегментација во аналитички извештаи.
-
-{{{ Автоматско освежување }}}
-Во овој дел се дефинираат continuous aggregate политики за автоматско ажурирање на дневниот и месечниот куб. Системот периодично ги пресметува новите податоци без рачна интервенција. Ова обезбедува податоците секогаш да бидат релативно свежи и конзистентни.
-
-{{{ Cron Job }}}
-Со pg_cron се закажува дневно освежување на cube_product_attributes. Ова осигурува дека атрибутите на производите се синхронизирани со најновите промени. Се користи за задачи кои не бараат континуирано ажурирање, туку периодично.
-
-{{{ Извештаи }}}
--Топ 25% производи по продажба
-
-Овој извештај ги рангира производите според вкупно поместена количина во даден магацин и период. Се користи NTILE за да се најдат најдобрите 25% од производите. Ова помага во анализа на најуспешни производи.
-
--Најслаби 25% магацини по turnover
-
-Овој извештај ја пресметува ефикасноста на магацините според односот помеѓу движење и залиха. Магацините се рангираат во квартили за да се идентификуваат најслабите перформанси. Ова помага за оптимизација на логистиката.
-
--Топ црвени производи
-
-Овој дел филтрира производи со атрибут „црвена боја“ и ги рангира според продажба. Се комбинираат атрибути и агрегирани податоци од кубот.
-
-
-Ова решение овозможува брза и ефикасна анализа на големи количини податоци преку OLAP кубови наместо директни квериња од сурови трансакции. Со тоа се добиваат значително побрзи извештаи, помало оптоварување на базата и пониски инфраструктурни трошоци. Бизнисот добива подобар увид во продажба, залихи и перформанси на магацините, што овозможува брзо носење одлуки. Дополнително, автоматското освежување на податоците обезбедува секогаш актуелни и сигурни аналитики без рачна интервенција.
-
-
-
-
-
+# Документација за имплементација на Time-Series и OLAP 
+
+## Цел на скриптата
+
+Целта на оваа скрипта е да ја подобри аналитичката ефикасност и скалабилност на системот за управување со магацин преку имплементација на **TimescaleDB** и **OLAP (Online Analytical Processing)** архитектура.
+
+Системот содржи голем број трансакции и движења на залихи кои континуирано се генерираат со текот на времето. Поради тоа, класичните PostgreSQL табели стануваат неефикасни за аналитички прашања кои опфаќаат големи временски периоди.
+
+Со оваа имплементација се постигнува:
+
+* Подобри перформанси при аналитички пребарувања.
+* Оптимизирано складирање на временски податоци.
+* Автоматско партиционирање на податоците според време.
+* Брзо генерирање на извештаи преку претходно агрегирани податоци.
+* Намалување на оптоварувањето врз оперативната база.
+
+---
+
+# 1. Иницијализација на TimescaleDB
+
+```sql
+CREATE EXTENSION IF NOT EXISTS timescaledb;
+```
+
+Во првиот чекор се активира TimescaleDB екстензијата.
+
+TimescaleDB претставува надградба на PostgreSQL специјализирана за работа со временски серии (time-series data). Бидејќи сите движења и трансакции во системот содржат временска ознака (`created_at`), овие податоци природно се вклопуваат во time-series модел.
+
+---
+
+# 2. Подготовка на табелите
+
+## Отстранување на постоечки ограничувања
+
+Пред конверзијата се отстрануваат:
+
+* примарни клучеви;
+* надворешни клучеви кои зависат од табелите што ќе се мигрираат.
+
+Причината е што TimescaleDB бара временската колона да биде дел од примарниот клуч на hypertable.
+
+---
+
+# 3. Редефинирање на примарните клучеви
+
+Се воведуваат композитни примарни клучеви:
+
+```sql
+ALTER TABLE inventory_movements
+ADD PRIMARY KEY (created_at, id);
+```
+
+и
+
+```sql
+ALTER TABLE inventory_transactions
+ADD PRIMARY KEY (created_at, id);
+```
+
+## Зошто е имплементирано?
+
+TimescaleDB бара partition колоната (`created_at`) да биде дел од примарниот клуч.
+
+Ова овозможува:
+
+* правилна распределба на податоците во chunk-ови;
+* побрзо пребарување по временски интервали;
+* одржување на уникатност на записите.
+
+---
+
+# 4. Миграција кон Hypertables
+
+## Креирање Hypertables
+
+```sql
+SELECT create_hypertable(
+    'inventory_transactions',
+    'created_at',
+    chunk_time_interval => INTERVAL '1 month',
+    migrate_data => FALSE
+);
+```
+
+### Зошто е имплементирано?
+
+Hypertable претставува логичка табела која физички е поделена на повеќе помали партиции (chunks).
+
+Во овој случај:
+
+* секој chunk содржи податоци за еден месец;
+* пребарувањата врз одреден временски период ги читаат само релевантните chunks;
+* значително се намалува количината на податоци која PostgreSQL треба да ја скенира.
+
+---
+
+# 5. OLAP Слој
+
+По оптимизацијата на складирањето се имплементира аналитички слој.
+
+Основната идеја е оперативните податоци да не се пресметуваат повторно при секој извештај.
+
+Наместо тоа се користат **Continuous Aggregates**.
+
+---
+
+# 6. Daily Cube – cube_movements_daily
+
+Се креира материјализиран поглед:
+
+```sql
+CREATE MATERIALIZED VIEW cube_movements_daily
+WITH (timescaledb.continuous)
+```
+
+Овој агрегат ги групира податоците по:
+
+* производ;
+* бренд;
+* магацин;
+* ден.
+
+---
+
+## Метрики
+
+### total_moved
+
+Пресметува нето движење на залихите.
+
+Излезни движења:
+
+```sql
+WHEN mv.from_bin_id IS NOT NULL
+THEN -mv.quantity
+```
+
+Влезни движења:
+
+```sql
+WHEN mv.to_bin_id IS NOT NULL
+THEN mv.quantity
+```
+
+Ова овозможува следење на реалниот проток на роба низ магацините.
+
+---
+
+### movement_count
+
+```sql
+COUNT(*)
+```
+
+Го претставува бројот на движења.
+
+---
+
+### transaction_count
+
+```sql
+COUNT(DISTINCT mv.inventory_transactions_id)
+```
+
+Го претставува бројот на уникатни трансакции.
+
+---
+
+# 7. Monthly Cube – cube_movements_monthly
+
+Над дневниот агрегат се гради месечен агрегат:
+
+```sql
+CREATE MATERIALIZED VIEW cube_movements_monthly
+```
+
+Овој пристап е познат како:
+
+**Aggregation-on-Aggregation**
+
+Наместо секој пат да се читаат милиони записи од `inventory_movements`, системот чита веќе агрегирани дневни резултати.
+
+Со тоа се добива:
+
+* помал број прочитани записи;
+* побрзо извршување на извештаи;
+* подобра скалабилност.
+
+---
+
+# 8. Автоматско освежување
+
+Се конфигурира политика:
+
+```sql
+SELECT add_continuous_aggregate_policy(...)
+```
+
+Политиката автоматски ги освежува агрегатите секој час.
+
+## Причина
+
+На овој начин:
+
+* аналитичките податоци остануваат речиси во реално време;
+* нема потреба од рачно освежување;
+* извештаите секогаш користат ажурирани податоци.
+
+Дополнително се извршува:
+
+```sql
+CALL refresh_continuous_aggregate(...)
+```
+
+за иницијално пополнување на агрегатите.
+
+---
+
+# 9. Аналитички извештаи
+
+## Извештај 1: Топ 25% производи
+
+Целта е да се идентификуваат најактивните производи според количината на движење.
+
+Се користат:
+
+* месечниот cube;
+* агрегирање по производ;
+* квартилна анализа преку `NTILE(4)`.
+
+Производите во првиот квартил претставуваат најдвижени производи во избраниот период.
+
+Овој извештај е корисен за:
+
+* оптимизација на залихи;
+* планирање на набавки.
+
+---
+
+## Извештај 2: Bottom 25% Warehouses by Inventory Turnover
+
+Целта е да се идентификуваат магацини со најнизок коефициент на обртот на залихите.
+
+Коефициентот се пресметува како:
+
+```text
+Turnover Ratio =
+Вкупно движење / Вкупна количина на залиха
+```
+
+Потоа магацините се распределуваат во квартили.
+
+Првиот квартил ги претставува магацините со најслаби перформанси.
+
+Овој извештај може да помогне при:
+
+* откривање неефикасни магацини;
+* оптимизација на складишниот простор;
+* подобрување на логистичките процеси.
+
+---
+
+# Заклучок
+
+Со оваа имплементација оперативните табели за движење и трансакции се трансформираат во TimescaleDB hypertables, што овозможува значително подобри перформанси при работа со големи количини временски податоци.
+
+Дополнително, преку имплементација на Continuous Aggregates се создава OLAP слој кој обезбедува брзо генерирање на аналитички извештаи без потреба од повторно процесирање на суровите податоци.
+
+Резултатот е архитектура која истовремено поддржува оперативни трансакции (OLTP) и аналитичко известување (OLAP), со висока скалабилност, подобри перформанси и поефикасно користење на ресурсите на базата на податоци.