Вовед

Општа Цел

Оваа фаза има цел да имплементира партиционирање на клучни табели во AirportDB базата на податоци за да се подобрат перформансите на системот, олесни одржувањето на податоците и овозможи поефикасно процесирање на големи волумени на податоци кои се типични за авиоиндустрија.

Зошто Партиционирање?

Специфични предизвици на AirportDB:

• Континуиран раст на податоци за летови (секојдневно се додаваат нови летови)
• Историски податоци што се акумулираат со години (weatherdata)
• Честа потреба за пристап до актуелни податоци, додека стари податоци се ретко користат
• Сезонски query-ја (пребарување на летови по датум, сезона, временски услови)

Очекувани придобивки:

• Подобрени Перформанси
• Полесно Одржување
• Скалабилност

Анализа на AirpotdDB табели

• Табелата airline не треба да биде партиционирана затоа што содржи мал број податоци и нема потреба од подобрување на перформанси преку партиционирање.
• Табелата airplane_type не треба да се партиционира затоа што содржи мал број статични записи и нема практична добивка од партиционирање.
• Табелата airplane не треба да биде партиционирана затоа што содржи ограничен број редови, нема колона погодна за партиционирање и не би се добила никаква подобрување во перформансите.
• Табелата airport_geo е lookup табела и треба да остане непартиционирана.
• Табелата airport_reachable има специфична, ограничена намена и мала големина. Партиционирањето би додало административен товар без вистинска корист за перформансите.
• Табелата airport не треба да биде партиционирана затоа што содржи ограничен број статични записи и нема колона погодна за поделба на податоците по партиции.
• Табелата booking е добар кандидат за партиционирање бидејќи може да содржи огромен број на редови со тек на време. Партиционирањето би помогнало за подобри перформанси и полесно управување со историски податоци — особено ако се воведе колона со датум за да се партиционира по време. Но не може да биде партиционирана во MySQL затоа што содржи foreign keys(flight_id, passenger_id). Иако има голем обем на податоци и би имало смисла логички, ограничувањата на MySQL не дозволуваат партиционирање на такви табели.
• Табелата employee не треба да биде партиционирана затоа што содржи релативно мал број записи, нема природен критериум за поделба на партиции и партиционирањето не би донело никакво подобрување на перформансите.
• Табелата flight_log има голем обем на податоци и би била идеална за партиционирање по log_date. Меѓутоа, бидејќи содржи foreign key (flight_id), MySQL не дозволува партиционирање, така што во пракса оваа табела не може да се партиционира додека постои foreign кey.
• Табелата flight не треба да се партиционира бидејќи има foreign keys кон airline или airplane, бидејќи MySQL не дозволува партиционирање со foreign keys. Ако ги нема или се отстранат, партиционирањето по departure би имало смисла за големи обеми на летови.

Имплементација

Тестирање и Перформанси

Предности и Недостатоци

Заклучок и Препораки