Kaip veikia lentelės skaidymas PostgreSQL?

Question

Accepted Answer

**Skaidymas** didelę lentelę padalija į mažesnes fizines dalis (**particijas**) pagal stulpelio reikšmę, tačiau ji lieka viena logine lentele. PostgreSQL **deklaratyvus skaidymas** (Postgres 10+) tai daro aiškiai. Tai pagerina našumą ir valdymą labai didelėms lentelėms.

## Deklaratyvus skaidymas (šiuolaikinis būdas)

```sql
-- create a partitioned table, partitioned by RANGE on a date
CREATE TABLE orders (id INT, order_date DATE, amount NUMERIC)
PARTITION BY RANGE (order_date);

-- create partitions for each range
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` yra viena loginė lentelė, fiziškai saugoma per metų particijose. Įterpimas ir užklausos automatiškai maršrutizuojamos į tinkamą particijas.

## Particijų nukirtimas — pagrindinis našumo privalumas

```sql
-- a query filtered on the partition key scans ONLY relevant partitions
SELECT * FROM orders WHERE order_date >= '2024-06-01';
-- → Postgres skips orders_2023 entirely ("partition pruning") — scans only orders_2024
```

**Particijų nukirtimas** yra pagrindinis privalumas: užklausos, filtruojančios pagal particijos raktą, liečia tik atitinkamas particijas, dramatiškai sumažindamos nuskaitytų duomenų dydį didelėse lentelėse.

## Skaidymo strategijos

```text
PARTITION BY RANGE → value ranges (dates, numbers) — common for time-series
PARTITION BY LIST  → discrete values (region, status)
PARTITION BY HASH  → hash of the key (even distribution across N partitions)
```

## Priežiūros privalumai

```sql
-- drop old data instantly by dropping a whole partition (vs slow DELETE)
DROP TABLE orders_2020;              -- removes all 2020 data instantly
-- vs DELETE FROM orders WHERE year = 2020 → slow, creates bloat

-- detach/attach partitions; automate with pg_partman extension
```

Viso paticijos nušalinimas seno duomenų archyvavimui arba šalinimui yra momentinis — didžiulis operacinis privalumas lyginant su `DELETE` operacija dideliems duomenų rinkiniais.

## Kodėl tai svarbu

Lentelės skaidymas yra svarbi PostgreSQL technika valdyti ir užklausti **labai dideles lenteles**, ir jos supratimas yra vertingas dirbant su Postgres dideliu mastu.

Kai lentelės auga iki šimtų milijonų ar milijardų eilučių, skaidymas sprendžia našumo ir valdymo problemas, padalydamas lentelę į mažesnes fizines dalis.

Postgres **deklaratyvus skaidymas** (Postgres 10+) tai daro aiškiai ir yra šiuolaikinis standartas, kurį reikia žinoti.

Pagrindinis našumo privalumas yra **particijų nukirtimas** — užklausos, filtruojančios pagal particijos raktą, skaito tik atitinkamas particijas (praleidžiant likutį), dramatiškai sumažindamos nuskaitytus duomenis labai didelėse lentelėse (ypač vertinga laiko eilučių duomenims, filtruotiems pagal datą, labai bendram atvejui).

Be našumo, skaidymas suteikia didelius **priežiūros privalumus**: senus duomenis archyvuoti ar panaikinti tampa momentinis, nušalinant visą particią (lyginant su lėta, blokų sukaupimą kuriančia `DELETE` operacija milijonų eilučių — reikšmingas operacinis privalumas duomenims su išlaikymo politika, tokiems kaip žurnalai ir įvykiai).

Supratimas **strategijų** (RANGE – datų/skaičinių diapazonams – bendras laiko eilutėms; LIST – atskiroms reikšmėms; HASH – tolygiam pasiskirstymui) ir **kada naudoti skaidymą** (labai didelės lentelės su natūraliu skaidymo raktu, ypač laiko eilutės su reguliariu archyvavimu – ne mažos lentelės, kurioms pakanka indeksavimo) atspindi gerą sprendimą.

Kadangi labai didelių lentelių valdymas yra tikra iššūkis didelių PostgreSQL sistemų atveju, o kadangi deklaratyvus skaidymas (su particijų nukirtimu ir efektyviu particijų šalinimu) yra standartinis įrankis – papildantis indeksavimą – PostgreSQL lentelės skaidymo supratimas yra vertinga, praktiškai svarbi žinios duomenų bazės keičiamumui, ypač svarbi didelėms, didelės apimties arba laiko eilučių aplikacijoms ir bendras klausimas, rodantis galimybę valdyti Postgres dideliu mastu.