Waarom column-oriented databases gebruiken voor analytics?

Column-oriented databases versus row-oriented databases en waarom deze beter zijn voor het doen van analytics.

Door de steeds toenemende hoeveelheid aan informatie (data) verandert traditionele landschap van database software leverancies die we al minstens 30 jaar kennen. Door nieuwe innovaties en technieken zijn de oplossingen voor het opslaan en verwerken van grote hoeveelheden data zeer snel geevolueerd, met name door toedoen van de open source gemeenschap.

Zo onstond ook een nieuw type database bekend als column-oriented database.

Verschil in data opslag

Maar wat is nu het verschil tussen een traditionele row-oriented database en een column-oriented database en waarvoor gebruiken we column-oriented databases?

Een row-oriented database slaat de data rij voor rij op, terwijl een column-oriented database de gegevens van een tabel kolom voor kolom op schijf opslaat.

Om de uitleg hiervan eenvoudig te maken gaan we uit van de volgende eenvoudige dataset:

In een row-oriented database wordt deze data als volgt op disk opgeslagen:

In een column-oriented database wordt deze data als volgt op disk opgeslagen:

 

Verschil in verwerken van een Query

Als we de data bevragen met de volgende query:

SELECT correlation(Feature 2, Feature 5) FROM dataset

In het geval van een traditionele row-oriented database zal de database de gehele tabel lezen of met andere woorden alle Feature kolommen.

In het geval van een column-oriented database worden door de database alleen de kolommen gelezen waarin we geinteresseerd zijn (Feature 2 en Feature 5 volgens onze Query)

 

Voordelen column-oriented over row-oriented

  • Iedereen kan begrijpen dat bovenstaande een groot verschil maakt in de hoeveelheid data die moet worden gelezen, dus uiteindelijk de prestatie positief beinvloed. In principe kunnen we naar de juiste kolom springen en de gegevens ervan verwerken en de overige kolommen waarin we niet geinterresseerd zijn negeren.
  • Het opslaan van data van hetzelfde datatype in de zelfde kolom heeft als bijkomend voordeel dat data beter gecomprimeerd kan worden aangezien de data homogeen is, wat ook weer de prestatie positief beinvloed.

Nadelen

Naast voordelen in het gebruik van column-gerorienteerd dabases zijn er ook nadelen, bijvoorbeeld het manipuleren (opzoeken, bijwerken of verwijderen) van een volledige rij is inefficient in vergelijk met een row-oriented database. In een row-oriented database wordt een rij in één stap geschreven of bijgewerkt terwijl dit in een column-gerorienteerde database dit in meerdere stappen plaatsvindt (voor elke kolom). Deze situate komt echter zelden voor in een analytics database waar de meeste operaties bestaan uit het lezen van informatie. Slechts zelden dienen er veel attributen uit dezelfde tabel te worden gelezen en schrijf operaties bestaan voornamelijk uit toevoegingen (appends).

 

In samenvatting

Column-oriented databases zijn goed voor:

  • Queries betrekking hebbende op enkele kolommen
  • Aggregaties voor grote hoeveelheden data
  • Compressie van kolommen (leveren een betere performance op voor queries)

Column-oriented databases zijn niet zo goed voor:

  • Incrementeel laden van data
  • Online transaction processing
  • Queries op een zeer beperkte dataset

 

Les

De les die we uit bovenstaande moeten trekken is dat niet elke database een transactionele of row-oriented database is, maar dat er databases bestaan voor een specifiek doel. Aangezien we datasets met meerdere billioenen rijen zo snel mogelijk willlen verwerken cq. bevragen, of met andere woorden dashboards met data interactief willen laten verversen zonder hierbij 20-30 seconden te moeten wachten op resultaten die we terugkrijgen op basis van filtering en bevraging en daarnaast tientallen tot honderden gebruikers op ons systeem willen toestaan in plaats van een handvol bestaan column-oriented databases, in memory data processing en massieve parallelle processing technieken.

Middels deze technieken kunnen we snel aggregeren, onnodige disk i/o voorkomen en meerdere taken tegelijkertijd uitvoeren op data, om de performance van bevragingen (queries) significant op te voeren. Om enkele namen te noemen van databases die gebruik maken van deze technieken: Redshift, Vertical, Exasol, Impala, Apache Drill en SAP Hana.

 

GPU

In de zoektocht naar nog snellere resultaten is de laatste trend de inzet van GPU's (Graphical Processing Units) omdat deze sneller zijn bij het uitvoeren van berekeningen dan de traditionele CPU's (Central Processing Units) en zich daarmee dus goed lenen voor het doen van analytics, speciaal in het geval van column-oriented databases. Wanneer kolommen van hetzelfde data type zijn en de data localiteit hoog is presteren GPU's zeer goed. Ook kunnen we gebruik maken van technieken zoals cascading compression wat normaal gesproken een zeer rekenintensieve taak is.

Grote hoeveelheden transformaties of ingewikkelde verbind (join) instructies of zeer grote datasets kunnen enorm profiteren van de rekenkracht van een GPU. Als je ooit geprobeerd hebt om meerdere tabellen over meedere kolommen met elkaar te verbinden (joinen) dan weet je wellicht dat je hash verbindingen (joins) wilt gebruiken en dingen wilt gaan doen zoals sorteren en hash generatie, e.e.a. zijn zeer rekenintensieve operaties en bij uitstek geschikt om op een GPU uit te voeren.

Voorbeelden van op GPU gebaseerde databases zijn: MapD, Kinetica, BlazingDB, SQream, Alenka (Open Source)

Vanwege de noodzaak om zo snel mogelijk grote hoeveelheden data te kunnen verwerken en bevragen mag het u niet verbazen dat er inmiddels vele cloud providers zijn die servers met GPU's aanbieden. Enkele voorbeelden hiervan zijn: Amazon, Microsoft Azure, IBM Cloud, Cloudalize, Frame, Outscale, Secure-24, NaviSite etc.

Conclusie

Bovenstaande zullen zeker niet de laatste ontwikkelingen zijn om onze honger in het verwerken en bevragen van grote hoeveelheden data te kunnen stillen. Sterker nog Google kwam recentlijk met voor ons allen redelijk verassend nieuws naar buiten dat ze een eigen AI (Artificial Intelligence) processor hadden ontwikkelt, genaamd TPU (Tensor Processing Unit), om specifieke snelheidsverbeteringen te realiseren over GPU's in het uitvoeren van instructies op data in deep neural networks.

 

Ronald Span

Founder of Scalar Data, over 20 years of experience in a variety of national and international IT projects in different roles, development, consultancy, pre-sales, management and business development. Scalar Data is helping organizations to implement their big data strategy.