Changes between Version 39 and Version 40 of Partitioning
- Timestamp:
- 11/06/25 00:37:44 (3 weeks ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Partitioning
v39 v40 98 98 PARTITION p_2026_01 VALUES LESS THAN (TO_DAYS('2026-02-01')), 99 99 PARTITION p_2026_02 VALUES LESS THAN (TO_DAYS('2026-02-02')), 100 PARTITION p_2026_0 2VALUES LESS THAN (TO_DAYS('2026-02-03')),100 PARTITION p_2026_03 VALUES LESS THAN (TO_DAYS('2026-02-03')), 101 101 PARTITION p_future VALUES LESS THAN MAXVALUE 102 102 ); … … 120 120 }}} 121 121 122 ==== pass anger122 ==== passenger 123 123 124 124 * Партиционирана по колона passenger_id користејќи HASH. … … 149 149 * За табелата passenger каде што нема временска компонента, HASH е подобар избор бидејќи ги дистрибуира патниците рамномерно низ партициите. Уникатниот индекс треба да се брише само ако MySQL го спречува партиционирањето (како во случајот со HASH или RANGE по колона која не е дел од уникатниот индекс). Ако уникатноста е критична, подобро е да се најде начин да се вклучи во партиционирањето или да се задржи контролата на апликациски слој. 150 150 151 * Dropping Unique Index (pass_unq) 152 * MySQL бара сите колони од UNIQUE индекс да бидат вклучени во партициониот клуч 153 * Ризици: 154 * Можност за внесување на дупликат записи ако апликацијата не прави проверка 155 * Влијание врз постоечки кодот кој се потпира на оваа constraint 156 157 158 151 159 == Тестирање и Перформанси 152 160 … … 203 211 ==== Заклучок 204 212 205 * Партиционирањето на табели е моќна техника за оптимизација на перформанси кај големи time-series бази, но доаѓа со значајни ограничувања особено во MySQL забраната за foreign keys на партиционирани табели. За airportdb базата, единствено weatherdata табелата е идеален кандидат за месечно RANGE партиционирање бидејќи содржи time-series податоци, нема foreign key зависности, и PRIMARY KEY веќе вклучува log_date, и pass anger табелата за HASH партиционирање. Останатите табели како flight, flight_log и booking не се погодни поради критичните referential integrity constraints кои се неопходни за одржување на интегритетот на податоците во авионската резервациска система.213 * Партиционирањето на табели е моќна техника за оптимизација на перформанси кај големи time-series бази, но доаѓа со значајни ограничувања особено во MySQL забраната за foreign keys на партиционирани табели. За airportdb базата, единствено weatherdata табелата е идеален кандидат за месечно RANGE партиционирање бидејќи содржи time-series податоци, нема foreign key зависности, и PRIMARY KEY веќе вклучува log_date, и passenger табелата за HASH партиционирање. Останатите табели како flight, flight_log и booking не се погодни поради критичните referential integrity constraints кои се неопходни за одржување на интегритетот на податоците во авионската резервациска система.
