Changes between Version 46 and Version 47 of AdvancedTopics

Timestamp:

05/22/26 01:52:19 (5 days ago)

Author:

231189

Comment:

--

AdvancedTopics

@@ -114 +114 @@
 === Причини за партиционирање 
 
-- **Екстремно висок волумен на податоци** Со симулација на над 12 милиони записи, оваа табела е критична за перформансите. Класично пребарување низ единечна табела од ваков размер предизвикува креирање на огромни индекси кои не можат да се соберат во RAM меморијата.
+- **Природата на табелата како релациски јазол** Табелата Ticket функционира како централна агрегациска табела која ги поврзува Train_Trip (патувањата) и Payment (плаќањата) – двата ентитети со најголем секојдневен прилив на податоци во целиот систем. Бидејќи секое патување продуцира стотици продадени билети, а секое плаќање резултира со фискален запис за билет, волуменот во оваа табела се мултиплицира експоненцијално во споредба со останатите табели.
 
-- **Природа на пребарувањата (Клуч за партиционирање)** За разлика од патувањата кои логички се пребаруваат по датум, билетите во реалниот систем најчесто се пребаруваат поединечно преку нивниот уникатен ID (`ticket_id`) при валидација на станица или при проверка од кондуктер. Поради ова, HASH партиционирањето е најефикасниот избор.
+- **Екстремно висок волумен на податоци** Бидејќи табелата моментално содржи 12 милиони записи, и при секое ново плаќање се прави нов тикет оваа табела станува критична за перформансите.
 
-- **Паметна и рамномерна распределба** Преку HASH партиционирање со користење на клучот `ticket_id`, податоците математички се делат на еднакви делови. Наместо една масивна табела, системот користи 16 помали партиции каде што податоците се идеално распределени.
+- **Природа на пребарувањата (Клуч за партиционирање)**Билетите во реалниот систем најчесто се пребаруваат поединечно преку нивниот уникатен ID (`ticket_id`) при валидација на станица или при проверка од кондуктер. Поради ова, HASH партиционирањето е најефикасниот избор.
+
+- **Рамномерна распределба** Преку HASH партиционирање со користење на `ticket_id`, податоците математички се делат на еднакви делови. Наместо една масивна табела, системот користи 16 помали партиции каде што податоците се идеално распределени.
 
 - **Како помага партиционирањето** Кога системот извршува прашање за конкретен `ticket_id`, PostgreSQL врши брзо хаширање на бараниот ID и веднаш детерминира во која точно партиција се наоѓа билетот. Базата целосно ги игнорира останатите 15 партиции, со што драстично се крати времето на пребарување и се одржуваат мали и брзи индекси.