Partitionering opdeler en stor tabel i mindre fysiske dele (partitioner) baseret på en kolonnes værdi — samtidig med at den stadig fremstår som en enkelt logisk tabel for forespørgsler. Det forbedrer ydeevne og håndterbarhed for meget store tabeller ved at lade databasen scanne eller vedligeholde kun relevante partitioner.
orders (id , order_date , amount )
(order_date);
orders_2023 orders
() ();
orders_2024 orders
() ();
Tabellen er en logisk enhed, men fysisk lagret i partitioner. Forespørgsler og indsættelser går automatisk til den rigtige partition.
-- 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")
Partition pruning er den vigtigste ydelsesforbedring: en forespørgsel filtreret på partitionsnøglen berører kun relevante partitioner, springes resten over — og forvandler en scanning af milliarder af rækker til en scanning af kun det relevante delmængde.
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)
✓ 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
✓ 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.
Table partitionering er en vigtig teknik til at styre og forespørge meget store tabeller, og at forstå det er værdifuld viden på seniorniveau for arbejde med databaser i stor skala.
Når tabeller vokser til hundreder af millioner eller milliarder af rækker, kan selv indekserede forespørgsler og vedligeholdelseoperationer blive langsomme, og partitionering løser dette ved at opdele tabellen i mindre fysiske dele.
Den vigtigste ydelsesforbedring er partition pruning — forespørgsler filtreret på partitionsnøglen scannner kun de relevante partitioner (springes resten over), hvilket dramatisk reducerer de data, der scannes for enorme tabeller (især almindeligt for tidsseriedata filtreret efter dato).
Ud over forespørgselsydeevne giver partitionering store vedligeholdelses fordele: arkivering eller sletning af gamle data bliver øjeblikkelig (dropping af en hel partition i stedet for langsom, dyr DELETE af millioner af rækker — en betydelig operationel fordel for log-/begivenhedsdata med opbevaringspolitikker), plus mindre per-partition indekser og parallelle operationer.
At forstå strategierne (RANGE for dato-/numeriske intervaller — almindeligt for tidsseriedata; LIST for diskrete værdier; HASH for ligelig fordeling) og især hvornår man skal bruge partitionering (meget store tabeller med en naturlig partitionsnøgle, især tidsseriedata med regelmæssig arkivering — ikke små/mellemstore tabeller, hvor indeksering er tilstrækkeligt, og partitionering blot tilføjer kompleksitet) afspejler moden dømmekraft.
Da styring af meget store tabeller er en reel udfordring i skalerede systemer, og da partitionering (med partition pruning og effektiv vedligeholdelse) er standardværktøjet til det — som supplerer snarere end erstatter indeksering — er forståelse af table partitionering værdifuld viden på seniorniveau for databaseskalerbarhed, især relevant for stor-skala, tidsserier eller høj-volumen datasystemer og et emne, der demonstrerer forståelse af styring af databaser i stor skala.