| 205 | | |
| 206 | | Финална проверка на капацитетот:$$650 \text{ возови} \times 30 \text{ билети} = \mathbf{19,500 \text{ билети}} \approx 20,000 \quad \checkmark$$ |
| | 205 | Зошто по точно 650? |
| | 206 | |
| | 207 | Бидејќи train_trip_id се доделуваат последователно (1, 2, 3...), во еден месец ID-ата се движат во строго дефиниран континуиран опсег. Ова овозможува директно следење на партициите на Train Trip, но со прецизно сечење на 5 помали пакувања по месец. |
| | 208 | Со овој пристап секоја партиција на Ticket директно кореспондира со точно дефиниран подопсег од месечна партиција на Train Trip, со што се гарантира: |
| | 209 | |
| | 210 | - Еден тикет се наоѓа во точно една партиција. |
| | 211 | |
| | 212 | - Секоја партиција содржи стабилни ~19,500 записи. |
| | 213 | |
| | 214 | - PostgreSQL може максимално да примени Partition Pruning при JOIN операции меѓу билетите и возовите. |
| | 215 | |
| | 216 | - Партициите на Ticket и Train Trip се логички и структурно усогласени. |
| | 217 | |
| | 218 | Финална проверка на капацитетот: |
| | 219 | [[Image("finalna presmetka.png",500px)]] |
| 225 | | -Податоците се дефинирани да се делат со користење на PARTITION BY HASH (ticket_id) |
| 226 | | |
| 227 | | -Типот на податок за цената е оптимизиран во NUMERIC(5,2) за соодветна поддршка на вредностите |
| | 238 | -Податоците се дефинирани да се делат со PARTITION BY RANGE ("Train Triptrip_id"). |
| | 239 | |
| | 240 | -Примарниот клуч е составен (composite): (ticket_id, "Train Triptrip_id") – задолжително бидејќи партицискиот клуч мора да биде дел од PRIMARY KEY во PostgreSQL. |
| | 241 | |
| | 242 | -Додадена е колоната payment_transaction_date за да се овозможи composite Foreign Key кон Payment, со цел усогласување на партициите. |
| | 243 | |
| | 244 | [[Image(constraint.png,500px)]] |
| | 245 | -Дополнителни constraints кои треба да се запазат при внес на податоците во новата табела. |
| 231 | | [[Image(Particija.png, 500px)]] |
| 232 | | |
| 233 | | -Се користи динамички DO блок со FOR јамка за автоматизација |
| 234 | | |
| 235 | | -Автоматски се креираат 16 партиции (од ticket_p0 до ticket_p15) |
| 236 | | |
| 237 | | -Секоја партиција се заснова на MODULUS 16 и соодветниот REMAINDER |
| 238 | | |
| 239 | | -Спречува мануелно пишување на 16 посебни SQL команди за креирање табели |
| | 249 | [[Image(particii.png, 500px)]] |
| | 250 | |
| | 251 | -Се користи динамички DO блок со WHILE јамка за автоматизација.Автоматски се креираат ~616 партиции (**400,000 / 650 ~ 616**) именувани ticket_p_range_0 до ticket_p_range_615. |
| | 252 | |
| | 253 | -Секоја партиција покрива опсег од 650 trip_id вредности, односно приближно ~19,500 тикети по партиција. |
| | 254 | |
| | 255 | -LEAST(current_id + step_size, max_id + 1) спречува излегување надвор од дефинираниот опсег при последната партиција. |
| | 256 | |
| | 257 | -Спречува мануелно пишување на стотици посебни SQL команди за креирање табели. |
| 261 | | Со имплементација на HASH партиционирање на табелата Ticket, успеавме масовниот волумен од милиони податоци да го поделиме на 16 рамномерни физички табели. Пребарувањето на билетите сега се извршува моментално бидејќи PostgreSQL точно знае во која под-табела се наоѓа бараниот ticket_id. Ова резултира со драстично намалување на оптоварувањето, побрз одзив на системот и долгорочна скалабилност на железничката платформа. |
| | 283 | Со имплементација на RANGE партиционирање на табелата Ticket по Train Triptrip_id, успеавме масовниот волумен од 12 милиони записи да го поделиме на ~616 рамномерни физички табели од приближно ~19,500 записи секоја. Пребарувањето на билетите сега се извршува моментално бидејќи PostgreSQL точно знае во која под-табела се наоѓа бараниот тикет врз основа на патувањето. |
| | 284 | |
| | 285 | Дополнително, усогласувањето со партициите на Payment преку composite Foreign Key гарантира дека еден тикет никогаш не се појавува во две различни партиции. Ова резултира со драстично намалување на оптоварувањето, побрз одзив на системот и долгорочна скалабилност на железничката платформа. |
