| 178 | | |
| | 178 | - **STEP 1: Преименување на старата табела** |
| | 179 | |
| | 180 | [[Image(Old_ticket.png, 800px)]] |
| | 181 | |
| | 182 | -Се зачувуваат постоечките податоци во стара табела old_ticket |
| | 183 | |
| | 184 | -Ова овозможува безбедна миграција кон нова партиционирана структура |
| | 185 | |
| | 186 | -Не се губат претходно генерираните податоци |
| | 187 | |
| | 188 | - **STEP 2: Креирање на нова партиционирана табела** |
| | 189 | |
| | 190 | [[Image(new_ticket.png, 500px)]] |
| | 191 | |
| | 192 | -Се креира нова главна табела Ticket која служи како parent табела |
| | 193 | |
| | 194 | -Податоците се дефинирани да се делат со користење на PARTITION BY HASH (ticket_id) |
| | 195 | |
| | 196 | -Типот на податок за цената е оптимизиран во NUMERIC(5,2) за соодветна поддршка на вредностите |
| | 197 | |
| | 198 | - **STEP 3: Автоматско креирање партиции (динамички преку DO блок)** |
| | 199 | |
| | 200 | [[Image(Particija.png, 500px)]] |
| | 201 | |
| | 202 | -Се користи динамички DO блок со FOR јамка за автоматизација |
| | 203 | |
| | 204 | -Автоматски се креираат 16 партиции (од ticket_p0 до ticket_p15) |
| | 205 | |
| | 206 | -Секоја партиција се заснова на MODULUS 16 и соодветниот REMAINDER |
| | 207 | |
| | 208 | -Спречува мануелно пишување на 16 посебни SQL команди за креирање табели |
| | 209 | |
| | 210 | - **STEP 4: Внесување податоци од стара табела (Миграција)** |
| | 211 | |
| | 212 | [[Image("Insert vo particiite.png", 500px)]] |
| | 213 | |
| | 214 | -Ги префрла сите зачувани записи од old_ticket во новата структура |
| | 215 | |
| | 216 | -PostgreSQL автоматски во позадина ги распределува редовите низ 16-те партиции врз основа на хаш функцијата |
| | 217 | |
| | 218 | - **STEP 5: Проверка на сите партиции** |
| | 219 | |
| | 220 | [[Image("Proverka dali site particii postojat.png", 500px)]] |
| | 221 | |
| | 222 | -Врши селекција од системската табела pg_inherits |
| | 223 | |
| | 224 | -Ги прикажува сите реално креирани партиции под главната табела ticket |
| | 225 | |
| | 226 | -Служи како потврда за успешна структура на базата |
| | 227 | |
| | 228 | === Заклучок |
| | 229 | |
| | 230 | Со имплементација на HASH партиционирање на табелата Ticket, успеавме масовниот волумен од милиони податоци да го поделиме на 16 рамномерни физички табели. Пребарувањето на билетите сега се извршува моментално бидејќи PostgreSQL точно знае во која под-табела се наоѓа бараниот ticket_id. Ова резултира со драстично намалување на оптоварувањето, побрз одзив на системот и долгорочна скалабилност на железничката платформа. |
