Kas yra lentelės particionavimas?

Question

Accepted Answer

**Particionavimas** didelę lentelę skaido į mažesnius fizinius gabalus (**particijas**) pagal stulpelio reikšmę — tuo tarpu ji vis dar pasirodo kaip viena loginė lentelė užklausoms. Tai pagerina našumą ir valdymą labai didelėms lentelėms, leidžiant duomenų bazei skenuoti arba prižiūrėti tik atitinkamas particijas.

## Kaip particionavimas veikia

```sql
-- a huge `orders` table partitioned BY RANGE on the order date
CREATE TABLE orders (id INT, order_date DATE, amount DECIMAL)
PARTITION BY RANGE (order_date);

CREATE TABLE orders_2023 PARTITION OF orders
  FOR VALUES FROM ('2023-01-01') TO ('2024-01-01');
CREATE TABLE orders_2024 PARTITION OF orders
  FOR VALUES FROM ('2024-01-01') TO ('2025-01-01');
-- orders is ONE logical table, but stored as separate per-year partitions
```

Lentelė yra vienas loginis subjektas, bet fiziškai saugoma particijose. Užklausos ir įterpimai automatiškai nueina į tinkamą particją.

## Pagrindinė nauda: particijų nukirtimas

```sql
-- a query filtered by the partition key only scans RELEVANT partitions
SELECT * FROM orders WHERE order_date >= '2024-06-01';
-- → the database skips orders_2023 entirely, scanning only orders_2024 ("partition pruning")
```

**Particijų nukirtimas** yra pagrindinė našumo nauda: užklausa, sufiltrota pagal particijų raktą, liečia tik atitinkamas particijas, praleisdama likusias — paverčiant milijardų eilučių skenavimą į tik atitinkamų eilučių poaibio skenavimą.

## Particionavimo strategijos

```text
RANGE → by a value range (dates, numeric ranges) — common for time-series data
LIST  → by a list of discrete values (region, category)
HASH  → by a hash of the key (even distribution across partitions)
```

## Kitos naudos

```text
✓ Maintenance — drop/archive old data by dropping a whole partition (instant vs DELETE)
  e.g. DROP TABLE orders_2020 — far faster than DELETE WHERE year = 2020
✓ Smaller indexes per partition; parallel operations across partitions
✓ Manage huge tables in manageable pieces
```

## Kada naudoti particionavimą

```text
✓ VERY LARGE tables (hundreds of millions / billions of rows) where queries filter
  on a natural partition key (often time/date for logs, events, orders)
✓ Time-series data where you regularly archive/drop old data
✗ Small/medium tables — partitioning adds complexity with little benefit
  (proper indexing usually suffices)
→ Partitioning complements indexing for VERY large tables; it's not a substitute.
```

## Kodėl tai svarbu

Lentelės particionavimas yra svarbi technika **labai didelėms lentelėms** valdyti ir jomis domėtis, ir jos supratimas yra vertingas aukštesnio lygio žinios dirbant su duomenų bazėmis dideliame mastelyje.

Augant lentelėms iki šimtų milijonų arba milijardų eilučių, net indeksuotos užklausos ir priežiūros operacijos gali tapti lėtos, o particionavimas tai sprendžia lentelę suskaidydamas į mažesnius fizinius gabalus.

Pagrindinė našumo nauda yra **particijų nukirtimas** — užklausos, sufiltrutos pagal particijų raktą, skenuoja tik atitinkamas particijas (praleisdamos likusias), o tai drastiškai sumažina duomenų, nuskenutų didelėms lentelėms (ypač paplitusios laiko eilučių duomenims, filtratiems pagal datą) kiekį.

Be užklausų našumo, particionavimas suteikia dideles **priežiūros naudas**: senos duomenys archyvuojami arba ištrinami akimirksniu (visos particijos išmetimas, palyginti su lėtu, brangiu `DELETE` milijonų eilučių — reikšminga operacinė nauda žurnalo/įvykių duomenims, kurie turi saugojimo politiką), be to mažesni per-particijų indeksai ir lygiagretūs procesai.

Supratimas apie **strategijas** (RANGE – datų/skaitinių intervalų – paplitusios laiko eilučių duomenims; LIST – atskiroms reikšmėms; HASH – tolygiam pasiskirstymui) ir svarbiausia **kada naudoti particionavimą** (labai didelės lentelės su natūraliu particijų raktu, ypač laiko eilučių su reguliariniu archyvavimo procesu — *ne* mažos/vidutinės lentelės, kur indeksavimo pakanka ir particionavimas tik prideda sudėtingumo) atspindi brandų sprendimų priėmimą.

Kadangi didelių lentelių valdymas yra tikra iššūkis masteliuojamose sistemose, ir kadangi particionavimas (su particijų nukirtimu ir efektyviu valdymu) yra standartinis įrankis tam — papildantis, o ne keičiantis indeksavimą — lentelės particionavimo supratimas yra vertingos aukštesnio lygio žinios duomenų bazės masteliavimui, ypač aktualios didelės apimties, laiko eilučių arba didelio duomenų srautų sistemoms ir tema, kuri parodo supratingumą duomenų bazių valdymui dideliame mastelyje.