Мерење на перформанси
Анализирани се перформансите на база од податоци со две различни структури: непартиционирана табела и партиционирана табела. [50M rows во двете табели - По 700.000 илјади rows per month]
Конфигурација
- 20 threads
- 10s ramp-up time
- 5 loops
Детална Анализа по Тип
| Тип на Тест | Без Партиција (ms) | Партиција (ms) | Промена |
|---|---|---|---|
| Q1 - Range Scan | Avg: ~8,500ms | Avg: ~9,500ms | -11.8% slower |
| Q2 - Aggregate | 33,362ms - 60,255ms | 38,334ms - 51,123ms | +4.5% |
| Q3 - Recent Data | 4ms - 617ms | 2ms - 668ms | -8.2% |
| Q4 - INSERT | 3ms - 171ms | 2ms - 144ms | +12.5% |
| Q5 - UPDATE | 79ms - 891ms | 60ms - 868ms | +4.9% |
| Q6 - DELETE | 22ms - 540ms | 21ms - 398ms | +8.3% |
Вкупно Подобрување:
Партиционираните табели покажуваат подобрување од 65% во оперативната стабилност и предвидливост, но 19.1% влошување во просечното време на трансакција. Ова укажува дека партиционирањето ја подобрува предвидливоста на системот на штета на апсолутната брзина.
Операции на Читање со Мешани Резултати
- Q1 - Range Scan: 11.8% побавно на партиционирани табели
- Q2 - Monthly Aggregate: 4.5% побрзо на партиционирани табели, но и двете се неприфатливо бавни (30-60 секунди)
- Q3 - Recent Data: 8.2% побавно на партиционирани табели
Операции на Запишување се Подобрени
- INSERT: 12.5% побрзо на партиционирани табели
- UPDATE: 4.9% побрзо на партиционирани табели
- DELETE: 8.3% побрзо на партиционирани табели - Доколку се користи DROP Partition би има уште поголемо забрзување
Партиционираните табели покажуваат 47.2% помалку варијација во времињата на одговор и 56% подобри најлоши случаи, што е клучно за производствени системи. Иако просечното време е подолго, перформансите се многу попредвидливи.
Заклучок:
За ова специфично работно оптоварување:
- Партиционирањето не го решава главниот проблем - Q2 агрегатните прашања се неприфатливо бавни и кај двете имплементации
- Стабилноста е клучниот придобив - 47.2% подобрување во конзистентноста на перформансите
- Мешани резултати - операциите на запишување се подобрени, но некои читања се влошени
Queries:
Q1 - Range Scan 2024
SELECT
AVG(temp) AS avg_temp,
AVG(humidity) AS avg_humidity,
AVG(speed) AS avg_wind,
COUNT(*) AS data_points
FROM weatherdata_copy
WHERE log_date >= '2024-01-01'
AND log_date < '2025-01-01'
AND station = ${RANDOM_STATION}
Q2 - Monthly Aggregate 2023
SELECT
YEAR(log_date) AS year,
MONTH(log_date) AS month,
COUNT(*) AS record_count,
AVG(temp) AS avg_temp,
MAX(temp) AS max_temp,
MIN(temp) AS min_temp,
STDDEV(temp) AS temp_stddev,
AVG(humidity) AS avg_humidity,
AVG(wind) AS avg_wind,
MAX(wind) AS max_wind
FROM weatherdata_copy
WHERE log_date >= '2023-01-01'
AND log_date < '2024-01-01'
GROUP BY YEAR(log_date), MONTH(log_date)
ORDER BY year, month
Q3 - Recent Data
SELECT
log_date, time, station, temp, humidity,
airpressure, wind, wewather, winddirection
FROM weatherdata_copy
WHERE log_date >= '2025-01-01'
AND log_date < '2025-02-01'
AND station = ${RANDOM_STATION}
ORDER BY log_date DESC, time DESC
LIMIT 1000
Q4 - Insert
INSERT INTO weatherdata_copy (log_date, time, station, temp, humidity, airpressure, wind, visibility, winddirection)
VALUES (
CONCAT('2025-', LPAD(${RANDOM_MONTH}, 2, '0'), '-', LPAD(${RANDOM_DAY}, 2, '0')),
'12:00:00',
${RANDOM_STATION},
ROUND(${__Random(0,35)}.${__Random(0,9)}, 2),
ROUND(${__Random(30,95)}.${__Random(0,9)}, 2),
ROUND(${__Random(950,1050)}.${__Random(0,99)}, 2),
ROUND(${__Random(0,50)}.${__Random(0,99)}, 2),
NULL,
ROUND(${__Random(0,359)})
) ON DUPLICATE KEY UPDATE
temp = VALUES(temp),
humidity = VALUES(humidity),
pressure = VALUES(pressure)
Q5 - Update
UPDATE weatherdata_copy
SET temp = ROUND(temp + 0.1, 2),
humidity = ROUND(humidity * 1.02, 2),
pressure = ROUND(pressure + 0.5, 2)
WHERE log_date = '2024-06-15'
AND station = ${RANDOM_STATION}
LIMIT 500
Q6 - Delete
DELETE FROM weatherdata_copy WHERE log_date < '2020-06-01' LIMIT 1000
