| | 112 | Табелата Ticket претставува една од трансакциски најоптоварените табели во системот, бидејќи во неа се зачувува секој купен билет за секое поединечно патување, вклучувајќи детали за седиштето, вагонот, цената и релевантните дестинации. |
| | 113 | |
| | 114 | === Причини за партиционирање |
| | 115 | |
| | 116 | - **Екстремно висок волумен на податоци** Со симулација на над 10 милиони записи, оваа табела е критична за перформансите. Класично пребарување низ единечна табела од ваков размер предизвикува креирање на огромни индекси кои не можат да се соберат во RAM меморијата. |
| | 117 | |
| | 118 | - **Природа на пребарувањата (Клуч за партиционирање)** За разлика од патувањата кои логички се пребаруваат по датум, билетите во реалниот систем најчесто се пребаруваат поединечно преку нивниот уникатен ID (`ticket_id`) при валидација на станица или при проверка од кондуктер. Поради ова, HASH партиционирањето е најефикасниот избор. |
| | 119 | |
| | 120 | - **Паметна и рамномерна распределба** Преку HASH партиционирање со користење на клучот `ticket_id`, податоците математички се делат на еднакви делови. Наместо една масивна табела, системот користи 16 помали партиции каде што податоците се идеално распределени. |
| | 121 | |
| | 122 | - **Како помага партиционирањето** Кога системот извршува прашање за конкретен `ticket_id`, PostgreSQL врши брзо хаширање на бараниот ID и веднаш детерминира во која точно партиција се наоѓа билетот. Базата целосно ги игнорира останатите 15 партиции, со што драстично се крати времето на пребарување и се одржуваат мали и брзи индекси. |
| | 123 | |
| | 124 | === Kод со објаснување |
| | 125 | |
