Realtime petabyte-analytics zonder impact op de database
Hoe analyseert u petabytes aan data in real time zonder uw productiedatabase te vertragen?
Groeiende apps bereiken allemaal hetzelfde kantelpunt, waarop een bedrijf een PostgreSQL- of MySQL-database met petabytes aan data wil bevragen op een manier waarvoor deze nooit is ontworpen.
Het resultaat: een dashboard-query die 200ms zou moeten duren, duurt 40 seconden omdat de analytics 500M rijen scant, wat de CPU en I/O zwaar belast. Gebruikers wachten te lang op queryresultaten en uiteindelijk staat de gehele SLA-overeenkomst op het spel.
Het is geen probleem dat u kunt oplossen met tuning; in plaats daarvan vereist het een verandering in architectuur: u moet stoppen met het uitvoeren van zware query's op uw productiedatabase.
In dit artikel leert u het architectuurpatroon voor het scheiden van OLTP van OLAP, hoe u data veilig naar ClickHouse streamt en waarom de managed service van OVHcloud de juiste keuze is voor SaaS-, FinTech-, AdTech- en e-commerce-teams die opschalen naar miljarden rijen.
Waarom uw productiedatabase de verkeerde plek is om analytics uit te voeren
Een productie Public Cloud-database-instantie is gebouwd voor transacties, niet voor analytics. Wanneer business-teams beginnen te vragen om real-time dashboards, fraudedetectie of klantsegmentatie-query's op terabytes aan historische data... nou, dan stort de performance in.
Dat gebeurt niet zozeer omdat de infrastructuur zwak is, maar omdat de app de verkeerde tool voor de taak gebruikt.
OLTP versus OLAP
OLTP (online transaction processing) en OLAP (online analytical processing) bevinden zich aan tegenovergestelde uiteinden van het data-architectuurspectrum.
OLTP -systemen geven prioriteit aan correctheid en precisie op transactieniveau, waarbij ze duizenden kleine, snelle schrijfbewerkingen en leesbewerkingen per seconde verwerken. Ze slaan data rij voor rij op, geoptimaliseerd voor het opzoeken van een enkel klantrecord of het bijwerken van een orderstatus in milliseconden.
OLAP -systemen zijn daarentegen ontworpen om biljoenen rijen te scannen voor complexe aggregaties. Ze gebruiken kolomgeoriënteerde opslag, waarbij elke kolom onafhankelijk wordt opgeslagen. Dit betekent dat wanneer u SUM(revenue) WHERE date > '2025-01-01' opvraagt, de database alleen de kolommen revenue en date leest en al het andere overslaat. Dus, bijvoorbeeld in ClickHouse, worden bewerkingen uitgevoerd in vectoriële executie. ClickHouse verwerkt hele arrays met waarden tegelijk in plaats van individuele rijen, wat de CPU-overhead drastisch vermindert en het cachegebruik maximaliseert.
Geen enkele hoeveelheid data-indexering, query-optimalisatie of hardware-upgrades zal een rij-georiënteerde database efficiënt maken bij kolomgeoriënteerde scans. De architecturen zijn fundamenteel verschillend.
Waarom read-replica's het probleem niet zullen oplossen
Read-replica's in Public Cloud Databases zijn de meest gebruikelijke eerste reactie op analytische druk op productiedatabases. Ze ontlasten het leesverkeer van de primaire node, maar ze lossen de architecturale mismatch niet op.
Een read-replica kan de strijd om resources op uw primaire database verminderen, maar wanneer u SELECT SUM(revenue), COUNT(*) FROM events WHERE date >= '2024-01-01' uitvoert over 500M rijen, leest en verwijdert de replica nog steeds bijna elke rij.
Deze analytische queries concurreren met productietransacties om CPU, geheugen en I/O. Applicatielatentie stijgt, SLA's komen in gevaar en real-time use cases zoals fraudedetectie of anomaliebewaking worden onmogelijk.
De query van 40 seconden die 200 ms zou moeten duren
Dit is het typische scenario voor een SaaS-scale-up of FinTech-platformbedrijf dat het data-kantelpunt bereikt. Een query wordt uitgevoerd, bedoeld om de dagelijkse omzet per klantsegment over 18 maanden (500M rijen) te aggregeren,
De verwachte uitvoeringstijd onder het OLAP-domeinmodel is 200 ms, maar de werkelijke tijd onder het OLTP-platform bedraagt uiteindelijk 40 seconden. Waarom? Dit is wat er op de achtergrond gebeurt:
Volledige tabelscan: Het PostgreSQL/MySQL-platform moet alle 500M rijen lezen omdat de index niet helpt bij brede aggregaties.
Rij-voor-rij verwerking: Elke rij wordt afzonderlijk gedecomprimeerd, geparseerd en geëvalueerd.
I/O-knelpunt: Schijflezingen domineren—het grootste deel van de gelezen data wordt weggegooid.
CPU-verspilling: CPU-cycli besteed aan rij-parsing in plaats van aggregatiekwaliteit.
Geheugendruk: Grote sorteringen en hash-joins worden naar de schijf weggeschreven.
De zakelijke impact is direct en cumulatief, omdat wat een uurlijks dashboard zou moeten zijn, in de praktijk slechts één keer per dag kan worden gegenereerd, wat zakelijke beslissingen vertraagt.
Zakelijke beslissingen worden vertraagd omdat minuut-tot-minuut analyses te duur worden en real-time functies onmogelijk worden op schaal. En dat is belangrijk – real-time responsiviteit is essentieel voor use cases zoals fraudedetectie, personalisatie en anomaliebewaking. Deze use cases zijn niet haalbaar met een query-latentie van 40 seconden.
Het architectuurpatroon: het scheiden van OLTP van OLAP
De oplossing is architecturale scheiding: voer transacties uit op een OLTP-database-instantie en stream gegevens naar een afzonderlijke OLAP-instantie die is gebouwd voor het scannen van miljarden rijen in minder dan een seconde. Elk systeem doet waarvoor het is ontworpen, zonder het andere te compromitteren.
Kolomgeoriënteerde opslag en vectorized execution uitgelegd
PostgreSQL en MySQL slaan gegevens rij voor rij op, wat logisch is voor technische transacties die afzonderlijke records ophalen, maar verschrikkelijk voor analyses die één kolom over miljarden rijen aggregeren. ClickHouse slaat gegevens daarentegen per kolom op.
Wanneer u SUM(revenue) over 5 miljard rijen opvraagt, leest het alleen de kolom revenue en slaat het al het andere over. Dit vermindert I/O met 90% of meer en maakt agressieve compressie mogelijk, aangezien waarden in een kolom op elkaar lijken.
Vectorized execution is de tweede vermenigvuldiger. Traditionele databases verwerken één rij per keer. ClickHouse verwerkt hele arrays met waarden tegelijk, laadt een blok van de kolom revenue in de CPU-cache en voert bewerkingen uit op het gehele vectorvolume in één instructie. Dit vermindert de CPU-overhead aanzienlijk.
De combinatie maakt query's in minder dan een seconde op miljarden rijen mogelijk. Kolomgeoriënteerde opslag minimaliseert schijfleesacties; vectorized execution minimaliseert CPU-werk. ClickHouse kan 10 miljard rijen aggregeren in minder dan een seconde, terwijl een PostgreSQL-instantie er minuten over doet.
Gerealiseerde views: pre-aggregatie tijdens het opnameproces
Zelfs met kolomgeoriënteerde gegevensopslag is het scannen van onbewerkte gegevens elke keer kostbaar. Gerealiseerde views berekenen aggregaten vooraf tijdens het opnameproces.
In ClickHouse is een gerealiseerde view een actieve pijplijn, geen passieve snapshot. Wanneer je gegevens invoegt, evalueert ClickHouse automatisch de query van de view en schrijft de resultaten naar een aparte tabel.
Als je 100.000 gebeurtenissen per seconde opneemt met een view die per minuut en segment aggregeert, berekent ClickHouse die aggregaten in realtime.
Je dashboard bevraagt de vooraf geaggregeerde tabel in plaats van onbewerkte gebeurtenissen te scannen. Dit verschuift de kosten van querytijd naar opnametijd, waarbij een kleine schrijfoverhead wordt geaccepteerd voor een onmiddellijke queryrespons. Voor dashboards per minuut en fraudedetectie elimineren gerealiseerde views de latentie tussen het aankomen van gegevens en het bevragen ervan.
Ze maken ook multi-resolutie-analyse mogelijk: bewaar onbewerkte gegevens voor forensisch onderzoek terwijl je uurlijkse/dagelijkse aggregaten voor dashboards behoudt. Naarmate gegevens verouderen, bevraag je grovere aggregaten, waardoor de prestaties consistent blijven terwijl je schaalt van terabytes naar petabytes.
Gelaagde opslag om kosten lineair te houden op petabyteschaal
Het opslaan van petabytes op SSD's is onbetaalbaar. Gelaagde opslag verplaatst oudere gegevens naar goedkopere objectopslag, terwijl recente gegevens op snelle lokale schijven blijven staan.
OVHcloud Managed ClickHouse implementeert dit bijvoorbeeld standaard in tools met OVHcloud Object Storage (S3-compatibele)* streamverwerking. Recente gegevens (30–90 dagen) blijven op NVMe SSD's staan.
Oudere gegevens migreren automatisch naar een OVHcloud Object Storage-bucket tegen een fractie van de kosten, waarbij snelle query's nog steeds mogelijk zijn omdat ClickHouse alleen de benodigde kolommen leest. De kosten voor engineers blijven lineair naarmate je schaalt: elke extra terabyte kost hetzelfde bij 10 TB of 100 TB.
ClickHouse bevraagt OVHcloud Object Storage-gegevens zonder Athena, Presto of Spark. Hot data op SSD, cold data op S3, alles via dezelfde SQL-interface. Dit elimineert het onderhoud van afzonderlijke systemen voor hot- en cold-data.
Gelaagde opslag vereenvoudigt ook langetermijngegevensretentie: bewaar onbewerkte gegevens voor onbepaalde tijd voor compliance zonder dat het de hoofdprijs kost. Query's uitvoeren op 18 maanden oude gegevens voor onderzoeken? ClickHouse leest het van OVHcloud Object Storage S3*, wat langzamer is maar nog steeds snel genoeg voor ad-hoc analyse.
Hoe je gegevens in je analytische laag voert
Zodra je de OLTP-instantie hebt gescheiden van OLAP-tools, moet je gegevens verplaatsen van je productiedatabase naar ClickHouse. Er zijn drie hoofdpatronen, elk met verschillende afwegingen in latentie, complexiteit en operationele overhead.
Batch ETL met Airflow, dbt of cron-jobs
Batch ETL is het eenvoudigste startpunt. Extraheer gegevens uit je productiedatabase volgens een schema (per uur of dagelijks), transformeer ze met dbt en laad ze in ClickHouse. Airflow orkestreert de pijplijn, of cron-jobs handelen eenvoudige scripts af.
Dit werkt wanneer je geen minuut-tot-minuut actualiteit nodig hebt. Dashboards per uur zijn prima voor veel zakelijke gevallen, en batchverwerking is eenvoudiger te debuggen en te monitoren. Mislukte taken worden opnieuw geprobeerd volgens het volgende schema, en het opvullen van historische gegevens is eenvoudig.
De afweging is de latentie die je creëert. Gegevens zijn verouderd tussen batches, dus real-time fraudedetectie of live personalisatie zijn niet mogelijk. Je voert ook zware extractiequery's uit op productie tijdens het batchvenster, wat kan leiden tot strijd om resources als het niet wordt gepland tijdens perioden met weinig verkeer. Batch ETL is de juiste keuze wanneer je begint met ClickHouse, geen streaming-expertise hebt, of gegevens van een uur oud tolereert.
Real-time CDC met Apache Kafka en Debezium
Change Data Capture (CDC) streamt elke insert, update en delete van productie naar ClickHouse in bijna real-time. Debezium leest het transactielogboek van je database (WAL voor PostgreSQL, binlog voor MySQL) en publiceert wijzigingen naar Apache Kafka. ClickHouse verbruikt gegevens uit Kafka en voegt deze onmiddellijk in.
CDC-tools bereiken een latentie van minder dan een seconde tot enkele seconden, wat echte real-time data-analytics mogelijk maakt: fraudedetectie die transacties detecteert en blokkeert zodra ze plaatsvinden, anomaliebewaking die binnen enkele seconden waarschuwt, personalisatie die direct reageert om gebruikersgedrag te ondersteunen.
Hoewel de complexiteit van de installatie hoger is, is CDC de standaard voor real-time analytics op schaal. De overhead is gerechtvaardigd wanneer zakelijke beslissingen afhangen van de versheid van gegevens. Veel teams gebruiken managed Kafka om de werklast te verminderen, of beginnen met batchverwerking en migreren naar CDC zodra de real-time waarde is gevalideerd.
Directe applicatieschrijfacties efficiënt voor puur event-driven workloads
Uw applicatie schrijft naast uw kritieke OLTP-database rechtstreeks naar ClickHouse-tools. Dit werkt het beste voor event-driven workloads waarbij elke gebruikersactie een gebeurtenis is die het analyseren waard is: paginaweergaven, klikken, API-aanroepen, sensorgegevens. De applicatie stuurt de gebeurtenis parallel naar beide systemen, of gebruikt ClickHouse als primair systeem en synchroniseert met PostgreSQL voor transacties.
Dit elimineert de ETL-laag volledig. Geen Kafka, geen Debezium, geen batchtaken. De applicatie schrijft één keer, gegevens zijn onmiddellijk opvraagbaar en de latentie is minimaal.
Waarom ClickHouse de juiste OLAP-engine is voor real-time analytics
ClickHouse is vanaf de basis opgebouwd voor real-time analytics op enorme datasets. In tegenstelling tot datawarehouses voor algemeen gebruik die optimaliseren voor batch-workloads of voor interactieve BI, geeft ClickHouse prioriteit aan query-latentie van minder dan een seconde, zelfs bij het scannen van miljarden rijen.
Dit maakt het de juiste keuze voor SaaS-, FinTech-, AdTech- en e-commercebedrijven die analytics nodig hebben die gelijke tred houden met hun productiesystemen.
Queryprestaties van minder dan een seconde :
ClickHouse bereikt een latentie van minder dan een seconde bij query's die miljarden rijen scannen dankzij kolomgeoriënteerde opslag, vectoriële uitvoering en agressieve compressie. Het kan 10 miljard rijen aggregeren in minder dan een seconde, terwijl PostgreSQL er minuten over doet en andere warehouses seconden tot tientallen seconden nodig hebben.
ClickHouse vs Redshift vs BigQuery :
ClickHouse levert stabiele, op resources gebaseerde prijzen met hoge gelijktijdigheid en efficiënte schaalbaarheid, ideaal voor interactieve real-time analytics. Redshift is het meest geschikt voor batch-georiënteerde datawarehousing met voorspelbare workloads en bestaande AWS-infrastructuur. BigQuery blinkt uit in serverless analytics met sporadische queries en teams die geen operationele overhead willen.
ClickHouse SQL :
ClickHouse gebruikt een SQL-dialect dat voor 90% compatibel is met de standaard SQL-ontwikkelervaring, maar er zijn belangrijke verschillen. Aggregatiefuncties gebruiken MergeTree-tabellen met specifieke engine-syntaxis. De meeste SELECT-queries vertalen direct, maar complexe JOINs en subqueries moeten mogelijk worden geoptimaliseerd.
Migratietips om te beheren zijn onder meer het eerst testen van queries op een representatieve host-dataset, het gebruik van ClickHouse's EXPLAIN om sessie-uitvoeringsplannen te optimaliseren en het benutten van materialized views om complexe aggregaties van de toolstack vooraf te berekenen.
Waarom kiezen voor OVHcloud Managed ClickHouse
OVHcloud Managed ClickHouse is de enige native managed ClickHouse die wordt aangeboden door een Europese cloudprovider, naast onze gevestigde Managed Databases for PostgreSQL . Dit betekent geen datarouting door derden, geen afhankelijkheid van ClickHouse Cloud en geen datastromen tussen providers.
Managed ClickHouse van een EU-provider: OVHcloud is de enige cloudprovider in de Europese regio die een native managed ClickHouse-engine aanbiedt. In tegenstelling tot concurrenten waarbij u via diensten van derden zou routeren, draait OVHcloud ClickHouse rechtstreeks op zijn eigen infrastructuur.
Automatisch naar OVHcloud Object Storage: Oude data wordt automatisch gemigreerd naar S3-compatibele* OVHcloud Object Storage, waardoor de kosten lineair blijven op petabyteschaal. Recente data (30–90 dagen) blijft op NVMe SSD's staan voor maximale snelheid, terwijl oudere data naar OVHcloud Object Storage verplaatst wordt tegen een fractie van de kosten. Cruciaal is dat er geen egress-kosten zijn.
3-AZ-implementaties in Parijs en Milaan : Productieclusters draaien over drie beschikbaarheidszones in Parijs of Milaan met 99,99% SLA in 3 A-Z, 24/7 technische ondersteuning inbegrepen en multi-node replicatie voor hoge beschikbaarheid. De Gen3-service (sinds augustus 2025) levert 5× opslag, 4× bandbreedte, 2× TPS en 1,5× snellere opstarttijd in vergelijking met de vorige generatie; dit alles is beter voor schalen.
GDPR by design, geen Cloud Act-blootstelling : OVHcloud is een Frans bedrijf dat uitsluitend onder de Franse/EU-wetgeving valt. Alle analytische gegevens blijven in Europese datacenters, zonder Cloud Act-blootstelling die van invloed is op Amerikaanse providers. Dit is vooral relevant voor gedragsgegevens, financiële transacties en gegevens die onder de GDPR vallen.
Bovendien zijn de diensten van OVHcloud ISO/IEC 27001/27017/27018/27701 gecertificeerd en HDS-compliant, met SecNumCloud in uitvoering. Dat omvat onze Managed Apache Kafka voor CDC-pipelines en onze OVHcloud Object Storage (S3-compatible)*.
Voor Europese SaaS-, FinTech-, AdTech- en e-commercebedrijven die EU-klantgegevens verwerken, elimineert deze soevereiniteitsgarantie het juridische risico dat Amerikaanse autoriteiten toegang krijgen tot gegevens die zijn opgeslagen bij Amerikaanse cloudproviders.
Ga aan de slag: implementeer ClickHouse en verbind het met uw productiedatabase
Klaar om uw productiedatabase te ontlasten van zware analysequery's? Het implementeren van OVHcloud Managed ClickHouse duurt slechts enkele minuten via het configuratiescherm of de API.
Wij zorgen ervoor dat uw gegevens in Europese datacenters blijven om privacy en volledige observeerbaarheid te garanderen, zonder uitgaande kosten, en gelaagde opslag naar OVHcloud Object Storage S3-compatibel* zorgt ervoor dat de kosten voorspelbaar blijven naarmate u schaalt van terabytes naar petabytes.
Start vandaag nog uw ClickHouse-cluster en ontdek waarom meer dan 2.000 bedrijven, waaronder Tesla, Bloomberg en Anthropic, vertrouwen op ClickHouse voor real-time analyses.
* S3 is een geregistreerd handelsmerk van Amazon Technologies, Inc. OVHcloud-services worden op geen enkele manier gesponsord of goedgekeurd door Amazon Technologies, Inc. en zijn er ook niet aan gelieerd.