Changes between Version 8 and Version 9 of AdvancedConcepts
- Timestamp:
- 06/11/26 09:58:37 (5 days ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
AdvancedConcepts
v8 v9 1 = = Advanced Concepts ==2 3 = Документација за имплементација на Time-Series и OLAP=1 = Advanced Concepts = 2 3 == Документација за имплементација на Time-Series и OLAP == 4 4 5 5 {{{ Цел на скриптата}}} … … 17 17 * Намалување на оптоварувањето врз оперативната база. 18 18 19 --- 20 21 {{{ 1. Иницијализација на TimescaleDB }}} 22 23 ```sql 24 CREATE EXTENSION IF NOT EXISTS timescaledb; 25 ``` 19 20 == 1. Иницијализација на TimescaleDB == 21 22 {{{CREATE EXTENSION IF NOT EXISTS timescaledb;}}} 26 23 27 24 Во првиот чекор се активира TimescaleDB екстензијата. … … 29 26 TimescaleDB претставува надградба на PostgreSQL специјализирана за работа со временски серии (time-series data). Бидејќи сите движења и трансакции во системот содржат временска ознака (`created_at`), овие податоци природно се вклопуваат во time-series модел. 30 27 31 --- 32 33 {{{ 2. Подготовка на табелите }}} 34 35 Отстранување на постоечки ограничувања 28 29 30 == 2. Подготовка на табелите == 31 32 {{{Отстранување на постоечки ограничувања}}} 36 33 37 34 Пред конверзијата се отстрануваат: … … 42 39 Причината е што TimescaleDB бара временската колона да биде дел од примарниот клуч на hypertable. 43 40 44 --- 45 46 {{{ 3. Редефинирање на примарните клучеви}}} 47 48 Се воведуваат композитни примарни клучеви: 49 50 ```sql 41 42 43 == 3. Редефинирање на примарните клучеви == 44 45 === Се воведуваат композитни примарни клучеви: === 46 47 {{{ 51 48 ALTER TABLE inventory_movements 52 49 ADD PRIMARY KEY (created_at, id); 53 ``` 50 }}} 54 51 55 52 и 56 53 57 ```sql 54 {{{ 58 55 ALTER TABLE inventory_transactions 59 56 ADD PRIMARY KEY (created_at, id); 60 ``` 61 62 Зошто е имплементирано?57 }}} 58 59 === Зошто е имплементирано? === 63 60 64 61 TimescaleDB бара partition колоната (`created_at`) да биде дел од примарниот клуч. … … 70 67 * одржување на уникатност на записите. 71 68 72 --- 73 74 {{{ 4. Миграција кон Hypertables }}} 75 76 Креирање Hypertables77 78 ```sql 69 70 71 == 4. Миграција кон Hypertables == 72 73 === Креирање Hypertables === 74 75 {{{ 79 76 SELECT create_hypertable( 80 77 'inventory_transactions', 81 78 'created_at', 82 79 chunk_time_interval => INTERVAL '1 month', 83 migrate_data => FALSE80 migrate_data => TRUE 84 81 ); 85 ``` 86 87 Зошто е имплементирано?82 }}} 83 84 === Зошто е имплементирано? === 88 85 89 86 Hypertable претставува логичка табела која физички е поделена на повеќе помали партиции (chunks). … … 95 92 * значително се намалува количината на податоци која PostgreSQL треба да ја скенира. 96 93 97 --- 98 99 {{{ 5. OLAP Слој }}} 94 95 96 == 5. OLAP Слој == 100 97 101 98 По оптимизацијата на складирањето се имплементира аналитички слој. … … 105 102 Наместо тоа се користат **Continuous Aggregates**. 106 103 107 --- 108 109 {{{ 6. Daily Cube – cube_movements_daily }}} 110 111 Се креира материјализиран поглед: 112 113 ```sql 104 105 == 6. Daily Cube – cube_movements_daily == 106 107 === Се креира материјализиран поглед: === 108 109 {{{ 114 110 CREATE MATERIALIZED VIEW cube_movements_daily 115 111 WITH (timescaledb.continuous) 116 ``` 112 }}} 117 113 118 114 Овој агрегат ги групира податоците по: … … 123 119 * ден. 124 120 125 --- 126 127 Метрики128 129 ## total_moved 121 122 123 === Метрики === 124 125 ==== total_moved ==== 130 126 131 127 Пресметува нето движење на залихите. 132 128 133 Излезни движења: 134 135 ```sql 129 **Излезни движења:** 130 131 {{{ 136 132 WHEN mv.from_bin_id IS NOT NULL 137 133 THEN -mv.quantity 138 ``` 139 140 Влезни движења: 141 142 ```sql 134 }}} 135 136 **Влезни движења:** 137 138 {{{ 143 139 WHEN mv.to_bin_id IS NOT NULL 144 140 THEN mv.quantity 145 ``` 141 }}} 146 142 147 143 Ова овозможува следење на реалниот проток на роба низ магацините. 148 144 149 --- 150 151 ## movement_count 152 153 ```sql 145 146 147 ==== movement_count ==== 148 149 {{{ 154 150 COUNT(*) 155 ``` 151 }}} 156 152 157 153 Го претставува бројот на движења. 158 154 159 --- 160 161 ## transaction_count 162 163 ```sql 155 156 ==== transaction_count ==== 157 158 {{{ 164 159 COUNT(DISTINCT mv.inventory_transactions_id) 165 ``` 160 }}} 166 161 167 162 Го претставува бројот на уникатни трансакции. 168 163 169 --- 170 171 {{{ 7. Monthly Cube – cube_movements_monthly }}} 164 165 166 == 7. Monthly Cube – cube_movements_monthly == 172 167 173 168 Над дневниот агрегат се гради месечен агрегат: 174 169 175 ```sql 170 {{{ 176 171 CREATE MATERIALIZED VIEW cube_movements_monthly 177 ``` 172 }}} 178 173 179 174 Овој пристап е познат како: … … 189 184 * подобра скалабилност. 190 185 191 --- 192 193 {{{ 8. Автоматско освежување}}} 186 187 == 8. Автоматско освежување == 194 188 195 189 Се конфигурира политика: 196 190 197 ```sql 191 {{{ 198 192 SELECT add_continuous_aggregate_policy(...) 199 ``` 193 }}} 200 194 201 195 Политиката автоматски ги освежува агрегатите секој час. … … 211 205 Дополнително се извршува: 212 206 213 ```sql 207 {{{ 214 208 CALL refresh_continuous_aggregate(...) 215 ``` 209 }}} 216 210 217 211 за иницијално пополнување на агрегатите. 218 212 219 --- 220 221 {{{ 9. Аналитички извештаи }}} 222 223 # Извештај 1: Топ 25% производи 213 214 == 9. Аналитички извештаи == 215 216 === Извештај 1: Топ 25% производи === 224 217 225 218 Целта е да се идентификуваат најактивните производи според количината на движење. … … 238 231 * планирање на набавки. 239 232 240 --- 241 242 # Извештај 2: Bottom 25% Warehouses by Inventory Turnover 233 234 === Извештај 2: Bottom 25% Warehouses by Inventory Turnover === 243 235 244 236 Целта е да се идентификуваат магацини со најнизок коефициент на обртот на залихите. … … 246 238 Коефициентот се пресметува како: 247 239 248 ```text 240 {{{ 249 241 Turnover Ratio = 250 242 Вкупно движење / Вкупна количина на залиха 251 ``` 243 }}} 252 244 253 245 Потоа магацините се распределуваат во квартили. … … 261 253 * подобрување на логистичките процеси. 262 254 263 --- 264 265 {{{ Заклучок }}} 255 256 == Заклучок == 266 257 267 258 Со оваа имплементација оперативните табели за движење и трансакции се трансформираат во TimescaleDB hypertables, што овозможува значително подобри перформанси при работа со големи количини временски податоци.
