Cursus
Of je nu klantgerichte apps bouwt of complexe analyses-pijplijnen draait, één ding wordt duidelijk: hoe je data opslaat en benadert kan de prestatie maken of breken.
Ik heb van dichtbij gezien hoe veel soepeler systemen draaien wanneer data doordacht is gestructureerd, en daar komt datapartitionering om de hoek kijken. Het is zo’n techniek die de snelheid van queries, opslag efficiëntie en schaalbaarheid drastisch kan verbeteren.
In dit artikel leg ik uit wat datapartitionering is, welke typen er zijn en de best practices die ik onderweg heb geleerd.
Wat is datapartitionering?
Datapartitionering is een techniek om grote datasets op te delen in kleinere, beheersbare stukken, zogenaamde partities. Elke partitie bevat een subset van de data en wordt verdeeld over meerdere nodes of servers. Deze partities kunnen worden opgeslagen, bevraagd en beheerd als afzonderlijke tabellen, hoewel ze logisch bij dezelfde dataset horen.
Datapartitionering verbetert de databaseprestaties en schaalbaarheid. Zo kost het zoeken naar een datapunt in de hele tabel meer tijd en resources dan zoeken in een specifieke partitie. Daarom wordt data als partities opgeslagen.
Typen datapartitionering
Datapartitionering omvat verschillende typen, elk met een eigen strategie en voordelen. In deze sectie bespreek ik de meest voorkomende typen.
Horizontale partitionering
In plaats van alle data in één tabel op te slaan, splitst horizontale partitionering de data in rijen, wat betekent dat verschillende sets rijen als partities worden opgeslagen.
Alle partities bij horizontale partitionering bevatten dezelfde set kolommen, maar verschillende groepen rijen.
- Voorbeeld: Stel dat je een weersdataset hebt voor meerdere deelstaten in drie verschillende landen. Je kunt dit in drie tabellen partitioneren door de rijen per land te splitsen.
|
Temperatuur |
Deelstaat |
Land |
Seizoen |
|
-30° F |
Alaska |
VS |
Winter |
|
48.2° F |
Queensland |
Australië |
Zomer |
|
100° F |
Andhra Pradesh |
India |
Zomer |
|
35° F |
Californië |
VS |
Winter |
|
96° F |
Texas |
VS |
Zomer |
|
62° F |
Tasmanië |
Australië |
Winter |
Horizontale partitionering per land:
|
Temperatuur |
Deelstaat |
Land |
Seizoen |
|
-30° F |
Alaska |
VS |
Winter |
|
35° F |
Californië |
VS |
Winter |
|
35° F |
Californië |
VS |
Winter |
|
Temperatuur |
Deelstaat |
Land |
Seizoen |
|
48.2° F |
Queensland |
Australië |
Zomer |
|
62° F |
Tasmanië |
Australië |
Winter |
|
Temperatuur |
Deelstaat |
Land |
Seizoen |
|
100° F |
Andhra Pradesh |
India |
Zomer |
Verticale partitionering
Verticale partitionering verdeelt data per kolommen, waardoor elke partitie hetzelfde aantal rijen bevat maar minder kolommen.
De partitiesleutel of de primaire kolom is in elke partitie aanwezig om de logische relatie te behouden.
Verticale partitionering is populair wanneer gevoelige informatie apart van reguliere data moet worden opgeslagen. Het maakt het mogelijk om gevoelige kolommen in één partitie en standaarddata in een andere op te slaan.
Een andere veelvoorkomende use-case is het groeperen van kolommen die vaak geüpdatet worden in één partitie en de rest in een aparte partitie.
- Voorbeeld: Als de kolommen met telefoonnummer en salaris van medewerkers in onderstaande tabel vertrouwelijk zijn, laten we de tabel dienovereenkomstig partitioneren.
|
Emp_id |
Emp_name |
Functie |
Emp_email |
Emp_phone |
Emp_salary |
|
z0yu9h |
Alex |
Data scientist |
alex@yoho.com |
+101 890 456 |
250K |
|
f8o5pj |
Adam |
Data engineer |
adam@prodgy.com |
+630 789 365 |
230K |
|
z006yu |
Matt |
Data-analist |
matt@oltk.com |
+857 342 937 |
166K |
|
a6u895 |
Elina |
Ops engineer |
elina@wal.com |
+892 494 782 |
190K |
|
g68w90 |
Joseph |
Software engineer |
joseph@yoho.com |
+852 603 389 |
210K |
Emp_id is de unieke identifier in de bovenstaande tabel, dus alle partities bevatten deze.
Partitie 1:
|
Emp_id |
Emp_name |
Functie |
Emp_email |
|
z0yu9h |
Alex |
Data scientist |
alex@yoho.com |
|
f8o5pj |
Adam |
Data engineer |
adam@prodgy.com |
|
z006yu |
Matt |
Data-analist |
matt@oltk.com |
|
a6u895 |
Elina |
Ops engineer |
elina@wal.com |
|
g68w90 |
Joseph |
Software engineer |
joseph@yoho.com |
Partitie 2:
|
Emp_id |
Emp_phone |
Emp_salary |
|
z0yu9h |
+101 890 456 |
250K |
|
f8o5pj |
+630 789 365 |
230K |
|
z006yu |
+857 342 937 |
166K |
|
a6u895 |
+892 494 782 |
190K |
|
g68w90 |
+852 603 389 |
210K |
Range-partitionering
Range-partitionering splitst data op basis van een bereik aan waarden voor een bepaalde kolom.
Doorgaans heeft elke partitie een onder- en bovengrens voor de sleutelkolom, en een record dat binnen dit bereik valt, wordt aan die partitie toegewezen.
- Voorbeeld: Stel dat verkoopdata beschikbaar is van 2021 tot 2023. We kunnen dit per jaar partitioneren, zodat verkopen van 2021 tot 2022 in één partitie vallen en van 2022 tot 2023 in een andere.
|
Product_id |
Datum |
Winst |
|
z0yu9h |
2021-03-17 |
$100K |
|
f8o5pj |
2022-04-04 |
$234K |
|
z006yu |
2022-09-13 |
$789K |
|
a6u895 |
2021-07-23 |
$237K |
|
g68w90 |
2022-02-26 |
$2345K |
Partitie 1:
|
product_id |
Datum |
Winst |
|
z0yu9h |
2021-03-17 |
$100K |
|
a6u895 |
2021-07-23 |
$237K |
Partitie 2:
|
product_id |
Datum |
Winst |
|
f8o5pj |
2022-04-04 |
$234K |
|
z006yu |
2022-09-13 |
$789K |
Hash-partitionering
Er wordt een hashfunctie toegepast op de partitiesleutel, en de output bepaalt in welke partitie een record moet worden opgeslagen. Bij deze techniek wordt het aantal partities vooraf bepaald.
De restwaarde die ontstaat door de hashwaarde te delen door het aantal partities bepaalt in welke partitie dat specifieke record moet worden opgeslagen. Laten we dit met een voorbeeld bekijken:
- Voorbeeld: Stel, voor het product met ID
z0yu9hgeldthash(‘z0yu9h’) = 101en het aantal partities = 4, dan is 101%4 = 1. Dit record wordt dus in de eerste partitie opgeslagen.
Op deze manier worden hashwaarden berekend voor de partitiesleutelkolom, gedeeld door het aantal partities, en het resultaat bepaalt de uiteindelijke partitie.
Lijst-partitionering
De procedure lijkt op range-partitionering, maar in plaats van data te verdelen op een bereik aan waarden, verdeelt lijst-partitionering de data op basis van een vooraf gedefinieerde set waarden.
Neem opnieuw de temperatuurtabel als voorbeeld.
|
Temperatuur |
Deelstaat |
Land |
Seizoen |
|
30° F |
Alaska |
VS |
Winter |
|
48.2° F |
Queensland |
Australië |
Zomer |
|
100° F |
Andhra Pradesh |
India |
Zomer |
|
35° F |
Californië |
VS |
Winter |
|
96° F |
Texas |
VS |
Zomer |
|
62° F |
Tasmanië |
Australië |
Winter |
In de bovenstaande data bevat de kolom ‘Seizoen’ een lijst met waarden [‘winter’, ‘summer’]. De lijst-partitionering op seizoen ziet er dan als volgt uit:
Partitie 1:
|
Temperatuur |
Deelstaat |
Land |
Seizoen |
|
30° F |
Alaska |
VS |
Winter |
|
35° F |
Californië |
VS |
Winter |
|
62° F |
Tasmanië |
Australië |
Winter |
Partitie 2:
|
Temperatuur |
Deelstaat |
Land |
Seizoen |
|
48.2° F |
Queensland |
Australië |
Zomer |
|
100° F |
Andhra Pradesh |
India |
Zomer |
|
96° F |
Texas |
VS |
Zomer |
Samengestelde partitionering
Een samengestelde partitie is een combinatie van twee partitioneringstechnieken. Een tabel wordt eerst verdeeld met één strategie en elke partitie wordt vervolgens verder onderverdeeld met een andere techniek.
Partitioneringsstrategieën komen vaak ter sprake in technische sollicitaties—bekijk de top DBA-sollicitatievragen voor 2025.
Use-cases voor datapartitionering
Nu we de verschillende typen partitioneringsstrategieën hebben bekeken, gaan we na wanneer datapartitionering nuttig is.
Gedistribueerde databases
Gedistribueerde systemen zijn verzamelingen van nodes die fysiek op aparte servers staan maar via een netwerk met elkaar zijn verbonden. Voorbeelden zijn Apache Cassandra, Amazon DynamoDB en Google Bigtable.
Deze systemen gebruiken intern datapartitionering om data over nodes te organiseren en te verdelen.
OLAP-operaties
OLAP representeert multidimensionale data als kubussen, zodat je data vanuit verschillende hoeken kunt verkennen. Hoewel deze kubussen vooraf geaggregeerde data voorstellen, is de onderliggende data nog steeds enorm, dus moeten de queries verder geoptimaliseerd worden met datapartitionering.
Door bijvoorbeeld kubuspartitionering (een techniek voor datapartitionering) toe te passen, wordt de data opgedeeld in kleinere kubussen op basis van specifieke criteria. Wanneer je de data bevraagt, wordt er in een specifieke kubus gezocht en worden irrelevante kubussen overgeslagen, wat I/O-bewerkingen vermindert.
Op vergelijkbare wijze kan dimensiepartitionering worden toegepast om data te splitsen per niveau, hiërarchie of kolom.
Logbeheer
Logs bevatten informatie over de events, transacties en bewerkingen die in een systeem plaatsvinden. Ze worden gebruikt om storingen, bugs, randgevallen en zelfs succesberichten te traceren.
Logpartitionering versnelt het debuggen en geeft je sneller de benodigde informatie. Als je logs bijvoorbeeld per periode hebt gepartitioneerd, kun je ze eenvoudig ophalen op datum, week, maand of jaar.
Machine learning-pijplijnen
Bij machine learning worden data gepartitioneerd in trainings-, validatie- en testsets. Deze aanpak zorgt ervoor dat inzichten uit de testset niet tijdens het trainen aan het model worden blootgesteld om overfitting te voorkomen.
Bovendien kan één machine bij zeer grote trainingsdata niet alle data in één keer verwerken en aan een model voeren. Daarom wordt de data in stukken verdeeld en via datapartitionering in het model ingevoerd.
Tools voor datapartitionering
Datapartitionering kan worden geïmplementeerd in zowel SQL- als NoSQL-databases. Laten we ze in deze sectie bespreken.
SQL-databases
PostgreSQL
PostgreSQL biedt ingebouwde ondersteuning voor range-, lijst- en hash-partitionering. De volgende query maakt bijvoorbeeld een partitie voor elk jaar om verkoopwinsten en totale verkopen per boekjaar efficiënt te benaderen.
CREATE TABLE sales(
city_id int not null,
sales_year date not null,
total_sales int,
sales_profits int
) PARTITION BY RANGE (sales_year);
MySQL
MySQL ondersteunt verschillende vormen van horizontale partitionering, zoals range-, lijst-, hash- en key-partitionering. Op dit moment (versie 8.4) ondersteunt het geen verticale partitionering.
De onderstaande MySQL-query partitioneert medewerkersdata in drie groepen, p1, p2 en p3, op basis van hun indiensttredingsdata. Alle medewerkers die vóór 2000 in dienst kwamen, vallen in de partitie p1. Medewerkers die tussen 2000 en 2010 in dienst kwamen, vallen in p2, en medewerkers die tussen 2010 en 2020 in dienst kwamen, vallen onder p3.
CREATE TABLE employee(
firstname VARCHAR(25) NOT NULL,
username VARCHAR(16) NOT NULL,
email VARCHAR(35),
salary INT,
joined DATE NOT NULL
)
PARTITION BY RANGE( YEAR(joined) ) (
PARTITION p1 VALUES LESS THAN (2000),
PARTITION p2 VALUES LESS THAN (2010),
PARTITION p3 VALUES LESS THAN (2020)
);
Microsoft SQL Server
SQL Server biedt partitioneringsfuncties via partitie-functies en partitie-schema’s. Een partitie-functie specificeert hoe de data wordt gesplitst, terwijl het partitie-schema bepaalt in welke filegroup de partitie wordt opgeslagen.
In de volgende queries:
- Functienaam:
sales_by_year - Schemenaam:
sales_filegroup - Filegroup-namen:
fg01,fg02,fg03,fg04
Partitie-functie:
create partition function sales_by_year (date)
as range right for values
('2024-01-01', '2024-02-01', '2024-03-01', ‘2024-04-01’);
Partitie-schema:
CREATE PARTITION SCHEME sales_filegroup
AS PARTITION sales_by_year
TO (fg01, fg02, fg03, fg04);
Hier slaan de files data als volgt op:
fg01- data vóór ‘2024-01-01’,fg02- ‘2024-01-01’ tot ‘2024-01-31’fg03- ‘2024-02-01’ tot ‘2024-02-29’fg04- ‘2024-03-01’ tot ‘2024-03-31’
Omdat we range right in de query hebben aangegeven, wordt elke grensdatum in de volgende partitie opgenomen.
Als je SQL Server gebruikt, loopt deze SQL Server-tutorial door de belangrijkste concepten en tools voor het beheren van gepartitioneerde data. Voor een gestructureerd leerpad introduceert de SQL Server Fundamentals-track de kernfuncties die je nodig hebt om performante SQL-databases te bouwen.
NoSQL-databases
Amazon DynamoDB
DynamoDB handelt partitionering automatisch intern af. Wanneer je een item naar een DynamoDB-tabel schrijft, gaat het via een requestrouter. De router parseert de partitiesleutel en past een hashfunctie toe. De output van de hashfunctie bepaalt in welke specifieke partitie het record wordt opgeslagen.
Dit hele proces is geautomatiseerd binnen DynamoDB, dus de gebruiker hoeft zich geen zorgen te maken over de hashfunctie of hoe de partities worden beheerd.
Mongodb
MongoDB verdeelt data over servers via het concept sharding. De data wordt gepartitioneerd op basis van een shard key, die zorgvuldig gekozen moet worden om oneven verdelingen te voorkomen.
Doorgaans moet de shard key een hoge cardinaliteit hebben en vaak worden gebruikt in queries. Deze MongoDB-sollicitatievragen behandelen vrijwel alle belangrijke onderwerpen, inclusief sharding.
Apache Cassandra
Cassandra-partitioner is een hashing-algoritme dat bepaalt welke node in een cluster een bepaalde partitie moet opslaan. De partitiesleutel wordt door het algoritme gehaald om een token te genereren. Dit token wordt vervolgens vergeleken met de tokenwaarden die aan de nodes zijn toegewezen. Uiteindelijk worden de data opgeslagen in de node die overeenkomt met het token.
Veelgebruikte partitioneringsalgoritmen zijn Murmur3Partitioner, RandomPartitioner en ByteOrderedPartitioner.
Hoe implementeer je datapartitionering?
Laten we nu de noodzakelijke stappen bespreken om datapartitionering correct te implementeren.
Stap 1: Begrijp data en toegangspatronen
Beoordeel grondig hoe je applicatie de database bevraagt, welke data vaak wordt benaderd, de omvang van de data en waar de performance knelpunten zitten. Deze inzichten helpen je heldere doelen voor partitionering te definiëren en sleutelkolommen te identificeren die vaak bij databewerkingen betrokken zijn.
Stap 2: Kies een partitioneringstechniek
We hebben eerder de gangbare technieken behandeld, en zo kies je daartussen:
- Horizontale partitionering: Wanneer je miljoenen tot miljarden rijen in één tabel zou opslaan wat tot geheugenproblemen leidt, kies je horizontale partitionering. Het slaat verschillende sets rijen in verschillende tabellen op.
- Verticale partitionering: Als een groep kolommen vaak wordt benaderd en andere slechts af en toe worden bevraagd, kun je verticale partitionering toepassen om kolommen apart op te slaan op basis van hun toegangspatronen.
- Hybride aanpak: Wanneer je grotere datasets hebt waarbij je het aantal rijen wilt verminderen en tegelijk queries voor een subset van kolommen wilt optimaliseren, kies je een hybride aanpak. Die combineert de voordelen van zowel horizontale als verticale partitionering.
Stap 3: Maak partities
Het volgende is een voorbeeld van een SQL-query om partities te maken met behulp van hash-partitionering.
CREATE TABLE employees (
emp_id INT NOT NULL,
name VARCHAR(30),
hired DATE NOT NULL DEFAULT '2024-01-01',
job_id INT,
location_id INT
)
PARTITION BY HASH(location_id)
PARTITIONS 4;
In de bovenstaande code wordt de kolom ‘location_id’ door de hashfunctie gehaald, en de output bepaalt aan welke partitie het record wordt toegewezen. De coderegel partitions 4 specificeert het totale aantal partities dat moet worden aangemaakt.
Sla dit handige SQL Basics Cheat Sheet op als naslag voor kern-SQL-syntaxis terwijl je partities implementeert.
Stap 4: Monitor en optimaliseer partities
- Monitor je databewerkingen continu en zorg dat de partities up-to-date en geldig zijn.
- Naarmate de applicatie schaalt, moet je mogelijk meer partities toevoegen of een andere aanpak kiezen, zoals een hybride partitie, om aan de veranderende vraag te voldoen.
- Zorg dat de partitieomvang en -strategie de veelvoorkomende bewerkingen op de database ten goede komen.
- Zorg voor een gelijkmatige verdeling van data over partities; zo niet, dan moet je mogelijk herverdelen.
Uitdagingen en overwegingen bij datapartitionering
Optimalisaties gaan, zoals in de softwarewereld wel vaker, gepaard met trade-offs en uitdagingen. Dit zijn de punten om rekening mee te houden:
- Partitie-scheefgroei (skew): Partitie-scheefgroei betekent dat enkele partities meer data en verwerkingswerk krijgen terwijl andere vaak idle blijven. Kies hiervoor de juiste partitiesleutel en strategie die data gelijkmatig over alle partities verdeelt.
- Onderhoudsoverhead: Naarmate de data groeit, moet je bestaande partitioneringsstrategieën opnieuw evalueren en controleren of ze nog relevant zijn voor de huidige data. Zo niet, dan moet je mogelijk herpartitioneren of partities samenvoegen.
- Datamigraties: Bij migratie van je data naar een nieuwe architectuur is extra zorg nodig om te garanderen dat de partities compatibel zijn met de nieuwe omgeving. Bovendien brengt het verplaatsen van data tussen partities complexiteit met zich mee, zoals het beheren van dataconsistentie over shards.
- Steile leercurve: Datapartitionering voegt complexiteit toe aan een systeem- of cloudarchitectuur. Ze zijn niet eenvoudig te bevragen, migreren of analyseren, wat voor beginners resulteert in een steile leercurve.
Best practices voor datapartitionering
Zoals je ziet, wordt datapartitionering complexer naarmate het datavolume groeit. Door deze praktijken te hanteren, zorg je er echter voor dat partitionering de efficiëntie verbetert zonder de prestaties te schaden.
- Stem partities af op querypatronen: Het kiezen van de juiste partitioneringsstrategie en partitiesleutel kan de databaseprestaties aanzienlijk verbeteren. Begrijp de meest voorkomende databewerkingen en querypatronen in je database, en kies een partitiesleutel die vaak in queries voorkomt en tegelijkertijd een gelijkmatige dataverdeling waarborgt.
- Monitor regelmatig: Tegenwoordig zijn applicaties dynamisch en continu in ontwikkeling door veranderende trends en behoeften. Het is daarom belangrijk om je partities regelmatig te monitoren om ze in lijn te houden met de huidige toegangspatronen en waar nodig te herpartitioneren.
- Minimaliseer overhead: Handmatig beheren van partities op grote schaal is complex. NoSQL-databases zoals Apache Cassandra en Amazon DynamoDB automatiseren dit proces echter zonder veel extra werk. Bovendien passen sommige automatiseringstools de partities aan naarmate de data schaalt, waardoor herpartitioneren of samenvoegen van partities volgens je behoeften mogelijk wordt.
Conclusie
Effectieve datapartitionering is cruciaal om prestaties en schaalbaarheid te behouden naarmate je data groeit. Met de juiste strategie kun je de query-latentie verlagen, opslag optimaliseren en onderhoud vereenvoudigen. Het is een praktische stap met meetbare impact.
Voor een diepere duik in hoe partitionering gedistribueerde systemen helpt schalen, bekijk deze gids over Kafka-partities. Om te begrijpen hoe relationele structuren partitioneringsbeslissingen beïnvloeden, begin met deze cursus relationele databases.
Srujana is een freelance techschrijver met een vierjarige opleiding in Computer Science. Schrijven over uiteenlopende onderwerpen, waaronder data science, cloud computing, development, programmeren, security en veel meer, gaat haar vanzelf af. Ze houdt van klassieke literatuur en het ontdekken van nieuwe bestemmingen.

