Het verdelen van grote hoeveelheden gegevens gebeurt op twee hoofdmanieren:
Partitionering (partitioning): Logische verdeling van één tabel binnen één database in segmenten (partition) op basis van een bepaalde sleutel, meestal datum of een bereik van waarden. Dit maakt het mogelijk om snel bewerkingen op afzonderlijke secties uit te voeren, versnelt het zoeken en vergemakkelijkt het onderhoud.
Sharding (sharding): Fysieke verdeling van gegevens over meerdere databases/servers volgens een bepaald algoritme — de tabel wordt feitelijk gedupliceerd op verschillende clusters, elk met zijn eigen segment gegevens.
De voordelen van partitionering zijn dat er geen aparte businesslogica voor het routeren van verzoeken vereist is, alles gebeurt "transparant" voor de applicatie; nadelen zijn de beperkingen van wat één DBMS kan bieden.
Sharding biedt horizontale schaalbaarheid (de limiet hangt alleen af van het aantal servers), maar vereist complexe synchronisatie, routing en verwerking van "tussen-shard" verzoeken.
-- Basis gepartitioneerde tabel CREATE TABLE orders ( id SERIAL PRIMARY KEY, customer_id INT, order_date DATE ) PARTITION BY RANGE (order_date); CREATE TABLE orders_2023 PARTITION OF orders FOR VALUES FROM ('2023-01-01') TO ('2024-01-01');
Vraag: Is het mogelijk om gegevens "on the fly" tussen partities te verplaatsen zonder de hoofdtafel te vergrendelen?
Antwoord: In de meeste DBMS-systemen is het verplaatsen van een rij tussen partities equivalent aan het verwijderen en opnieuw invoegen — dergelijke operaties kunnen rijen en zelfs de tabel zelf vergrendelen, vooral als triggers of buitenlandse sleutels betrokken zijn. Dit moet in overweging worden genomen bij massale "migraties" van gegevens tussen secties.
-- ALTER TABLE ... MOVE PARTITION vereist doorgaans extra aandacht voor vergrendelingen. Het is beter om dit te doen op momenten van lage belasting.
Verhaal 1: In een project werden analytische rapporten over alle partities tegelijk gebouwd, zonder rekening te houden met het feit dat een gepartitioneerde tabel met duizenden secties enorme uitvoeringsplannen creëerde. Dit resulteerde in een plotselinge toename van de uitvoeringstijd en serverbelasting. Oplossing: verhoog het aantal partities dat overeenkomt met de werkelijke business-aspecten van de aanvraag en optimaliseer de scanplannen.
Verhaal 2: Bij het toevoegen van sharding werd de non-uniciteit van de identificator tussen shards niet in overweging genomen. Vaak traden conflictsleutels op bij inter-shard aggregatie.
Verhaal 3: Automatische archivering van "verouderde" partities verwijderde deze zonder hercontrole van de externe relaties, wat leidde tot verlies van verbinding met andere tabellen en verlies van een deel van de "levende" gegevens. Na dit probleem is de hele logica voor het verwijderen van partities herschreven met multi-tests op samenhang.