Zodra we in gesprek komen met onze klanten over de noodzaak van een column-store database ten behoeve van hun BI behoeften gaat het veelal zo:

 

Met zulke hoeveelheden rijen waarover jullie willen rapporteren, is het raadzaam om een column store database aan te schaffen voor jullie BI omgeving

Wat? Hoezo? We hebben net veel geld uitgegeven aan nieuwe hardware voor onze Oracle omgeving en we hebben op die omgeving nog genoeg ruimte

Laat me raden, jullie ERP omgeving draait daar op?

Jazeker, en we hebben ook nog een hot-standby scenario ingericht

Dat is allemaal prachtig voor jullie operationele behoeften, maar als wij de BI omgeving gaan inrichting op die omgeving gaan we niet de performance halen die jullie verwachten

Die performance is nu meer dan goed, via de webportal worden soms wel 100 orders per minuut ingeschoten, zonder problemen!

Klinkt inderdaad alsof jullie het goed voor mekaar hebben, maar geloof ons nu maar, voor jullie BI gaat het niet werken

Hoe moet ik mijn manager nu overtuigen om budget ter beschikking te stellen voor een nieuwe database terwijl we net afgelopen jaar al geinvesteerd hebben in de database?

Horses for courses

Huh? Leg uit!

 

Ok, dat probeer ik dan maar te doen

Bij het starten van BI trajecten vergeet men  vaak te kijken of hun huidige database wel aansluit bij de eisen van een BI omgeving. Veel bedrijfen beschikken namelijk vaak al over een van de traditionele OLTP database smaken zoals Oracle, DB2, Sybase ASE, Microsoft SQL Server, Informix etc. Het is dan begrijpelijk dat men vergeet om te toetsen of de BI omgeving uit de voeten kan met die bestaande database:

Een database is immers toch maar gewoon een database?

Nee, het tegendeel is waar. Databases zijn er in allerlei smaken.
Het eenvoudigste tweedeling die je kan maken is wel of geen On-line Transaction Processing database (OLTP).

Sterk versimpelt kun je zeggen dat OLTP databases als primair doel hebben het snel en betrouwbaar vastleggen van transacties. Daarom is het zo dat bijna elk bedrijf wel een database in-huis heeft dat goed is voor OLTP, omdat transactionele vastlegging belangrijk is voor elk bedrijf.

OLTP databases kenmerken zich door een rij/record als een geheel op te slaan, dus rij blok na rij blok achter mekaar. Rijen als geheel kunnen hierdoor snel gevonden en bijgewerkt worden. Onderstaande plaatje illustreert het verschil in fysieke opslag methodiek tussen rij en kolom opslag. 

 

row storage column storage comparison

 

De niet-OLTP database smaken zijn er legio, maar in ons geval ligt de focus op databases die data-analyse vergemakkelijken. Dus met het oog op functionaliteit die nodig is voor efficiente BI omgevingen.

Waar moet dan een database voor data analyse aan voldoen?

  • Snel grote hoeveelheden data kunnen laden
  • Snel kunnen aggregeren over veel data om samenvattingen te maken
  • Ad-hoq vragen moeten niet veel langzamer beantwoord worden dan veel voorkomende vragen
  • Data opslag moet niet te kostbaar zijn (compressie is belangrijk)
  • Schaalbaar voor toenemende hoeveelheden data qua query snelheid en data laad tijd

Wat is niet zo belangrijk voor een data analyse database?

  • ACID compliance
  • Veel concurrerende sessies ondersteunen
  • Snel kunnen updaten van een enkel record
  • Fail over (vaak niet bedrijfskritisch)

Geconcludeerd kan worden dat een row-store OLTP database zeer verschilt van een column-store data-anaylyse database, en in een volgende blog zal ik ingaan waarom een column-store database veel beter voldoet aan de eisen die een BI omgeving stelt dan een row-store OLTP database. Dit zal ik illustreren met enkele praktijk voorbeelden. Stay-tuned