Kolomgeoriënteerde opslag

Wat is kolomgeoriënteerde opslag?

Kolomgeoriënteerde opslag bewaart data per kolom in plaats van per rij. Alle waarden van order_date staan bij elkaar, alle waarden van amount staan bij elkaar, en zo verder.

Dat past goed bij analytische queries. Een dashboard dat omzet per maand berekent, heeft misschien alleen datum en bedrag nodig. Met kolomopslag hoeft de engine niet alle klantnamen, adressen en opmerkingen mee te lezen.

Rijopslag is beter wanneer je vaak volledige records schrijft of ophaalt, zoals in een kassasysteem. Kolomopslag is beter wanneer je veel rijen scant maar weinig kolommen nodig hebt.

Hoe werkt het in de praktijk?

Bij rijopslag liggen alle velden van één record naast elkaar. Dat is handig voor transacties: haal klant 42 op en je krijgt meteen alle kolommen van die klant.

Bij kolomopslag liggen waarden van dezelfde kolom naast elkaar. Dat geeft twee voordelen. De engine leest alleen de gevraagde kolommen, en waarden binnen één kolom lijken vaak op elkaar. Daardoor comprimeren ze goed.

Bestandsformaten zoals Parquet gebruiken dit principe. Ook data warehouses zoals Snowflake bewaren data intern kolomgeoriënteerd, zodat analytische workloads minder data hoeven te scannen.

Wanneer gebruik je kolomgeoriënteerde opslag?

• Voor data warehouses. Rapporten lezen vaak miljoenen rijen maar slechts enkele kolommen.

• Voor lakehouses. Parquet, Delta Lake en Iceberg bouwen verder op kolomopslag voor snelle scans.

• Voor aggregaties. Sommen, gemiddelden en tellingen over grote datasets profiteren van kolommen die apart gelezen worden.

• Voor compressie. Herhalende waarden binnen een kolom nemen minder plaats in dan losse gemengde rijen.

Kolomopslag versus rijopslag

Rijopslag is de natuurlijke vorm voor operationele systemen. Een webshop die één bestelling aanmaakt, schrijft meteen alle velden van die bestelling. Dat moet snel en betrouwbaar.

Kolomopslag is de natuurlijke vorm voor analyse. Een BI-query vraagt zelden alle kolommen van elke rij. Ze vraagt een paar kolommen over heel veel rijen. Dan is kolomopslag zuiniger.

Veel moderne architecturen gebruiken daarom beide. Het bronsysteem draait op rijopslag. De analytische kopie in het data warehouse of lakehouse draait op kolomopslag.

Waar moet je op letten bij kolomgeoriënteerde opslag

• Kleine schrijfacties passen minder goed. Kolomopslag blinkt uit in lezen en bulk loads, niet in losse rij-updates.

• Bestandsindeling blijft belangrijk. Slecht gepartitioneerde of versnipperde Parquet-bestanden kunnen nog altijd traag zijn.

• Niet elke query profiteert evenveel. Vraag je bijna alle kolommen op, dan verdwijnt een groot deel van het voordeel.

• Compressie is geen magie. Rommelige types, hoge cardinaliteit en brede tekstvelden blijven aandacht vragen.

FAQ over kolomgeoriënteerde opslag

1. Is Parquet altijd kolomgeoriënteerd?
Ja. Parquet is ontworpen als kolomgeoriënteerd bestandsformaat voor analytische workloads.

2. Is kolomopslag hetzelfde als een column in SQL?
Nee. Elke tabel heeft kolommen. Kolomopslag gaat over hoe de data fysiek of intern bewaard wordt.

3. Waarom is kolomopslag goed voor Power BI?
Omdat rapporten meestal filters en aggregaties uitvoeren op een beperkt aantal kolommen. Dat sluit aan bij hoe columnar engines data lezen.