Analisi in tempo reale di petabyte senza impatto sul database
Come analizzare petabyte di dati in tempo reale senza rallentare il database di produzione?
Le applicazioni in crescita raggiungono tutte lo stesso punto di svolta, in cui un'azienda desidera interrogare un database PostgreSQL o MySQL con petabyte di dati, in un modo per cui non è mai stato progettato.
Il risultato: una query di dashboard che dovrebbe richiedere 200ms ne richiede 40 secondi poiché l'analisi scansiona 500M di righe, distruggendo CPU e I/O. Gli utenti attendono troppo a lungo i risultati delle query e, alla fine, l'intero accordo SLA è a rischio.
Non è un problema che puoi risolvere con la messa a punto, richiede invece un cambiamento nell'architettura: devi smettere di eseguire query pesanti sul tuo database di produzione.
In questo articolo imparerai il pattern architetturale per separare OLTP da OLAP, come trasmettere i dati in modo sicuro in ClickHouse e perché il servizio gestito di OVHcloud è la scelta giusta per i team SaaS, FinTech, AdTech ed e-commerce che scalano fino a miliardi di righe.
Perché il tuo database di produzione è il posto sbagliato per eseguire analisi
Un'istanza di database Public Cloud di produzione è creata per le transazioni, non per l'analisi. Quando i team aziendali iniziano a richiedere dashboard in tempo reale, rilevamento delle frodi o query di segmentazione dei clienti su terabyte di dati storici... beh, le prestazioni crollano.
Ciò accade non tanto perché l'infrastruttura è debole, ma perché l'applicazione sta utilizzando lo strumento sbagliato per il lavoro.
OLTP vs OLAP
OLTP (elaborazione delle transazioni online) e OLAP (elaborazione analitica online) si trovano agli estremi opposti dello spettro dell'architettura dei dati.
I sistemi OLTP danno priorità alla correttezza e alla precisione a livello di transazione, gestendo migliaia di piccole e veloci operazioni di scrittura e lettura al secondo. Memorizzano i dati riga per riga, ottimizzati per la ricerca di un singolo record cliente o l'aggiornamento dello stato di un ordine in pochi millisecondi.
I sistemi OLAP , al contrario, sono progettati per scansionare trilioni di righe per aggregazioni complesse. Utilizzano l'archiviazione colonnare, in cui ogni colonna viene archiviata in modo indipendente. Ciò significa che quando esegui una query SUM(revenue) WHERE date > '2025-01-01', il database legge solo le colonne revenue e date, saltando tutto il resto. Quindi, ad esempio in ClickHouse, le operazioni vengono eseguite in esecuzione vettorializzata. ClickHouse elabora intere matrici di valori contemporaneamente anziché singole righe, il che riduce drasticamente il sovraccarico della CPU e massimizza l'utilizzo della cache.
Nessuna quantità di indicizzazione dei dati, ottimizzazione delle query o aggiornamento dell'hardware renderà un database orientato alle righe efficiente nelle scansioni colonnari. Le architetture sono fondamentalmente diverse.
Perché le repliche di lettura non risolveranno il problema
Le repliche di lettura in Public Cloud Databases sono la prima risposta più comune alla pressione analitica sui database di produzione. Scaricano il traffico di lettura dal nodo primario, ma non risolvono la discrepanza architettonica.
Una replica di lettura potrebbe ridurre la contesa sul database primario, ma quando esegui SELECT SUM(revenue), COUNT(*) FROM events WHERE date >= '2024-01-01' su 500M di righe, la replica legge comunque e scarta quasi ogni riga.
Queste query analitiche competono con le transazioni di produzione per CPU, memoria e I/O. La latenza dell'app aumenta, gli SLA sono a rischio e casi d'uso in tempo reale come il rilevamento delle frodi o il monitoraggio delle anomalie diventano impossibili.
La query da 40 secondi che dovrebbe richiedere 200 ms
Ecco lo scenario tipico per una società SaaS in fase di scale-up o una piattaforma FinTech che raggiunge il punto di svolta dei dati. Viene eseguita una query, intesa ad aggregare le entrate giornaliere per segmento di clientela su 18 mesi (500M di righe),
Il tempo previsto per l'esecuzione nel modello di dominio OLAP è di 200 ms, ma il tempo effettivo sulla piattaforma OLTP finisce per essere di 40 secondi. Perché? Ecco cosa succede in background:
Scansione completa della tabella: La piattaforma PostgreSQL/MySQL deve leggere tutte le 500M di righe perché l'indice non aiuta con aggregazioni estese.
Elaborazione riga per riga: Ogni riga viene decompressa, analizzata e valutata individualmente.
Collo di bottiglia I/O: Le letture su disco predominano: la maggior parte dei dati letti viene scartata.
Spreco di CPU: Cicli di CPU spesi per l'analisi delle righe invece che per la qualità dell'aggregazione.
Pressione sulla memoria: I grandi ordinamenti e gli hash join vengono riversati su disco.
L'impatto sul business è immediato e crescente, perché quella che dovrebbe essere una dashboard dati oraria può, in pratica, essere generata solo una volta al giorno, ritardando le decisioni aziendali.
Le decisioni aziendali vengono ritardate perché l'analisi minuto per minuto diventa troppo costosa e le funzionalità in tempo reale diventano impossibili su larga scala. E questo è importante: la reattività in tempo reale è essenziale per casi d'uso come il rilevamento delle frodi, la personalizzazione e il monitoraggio delle anomalie. Questi casi d'uso non sono sostenibili con una latenza di query di 40 secondi.
Il modello di architettura: separare OLTP da OLAP
La soluzione è la separazione architettonica: eseguire le transazioni su un'istanza di database OLTP e trasmettere i dati in un'istanza OLAP separata, creata per scansionare miliardi di righe in frazioni di secondo. Ogni sistema fa ciò per cui è stato progettato, senza compromettere l'altro.
Spiegazione dell'archiviazione colonnare e dell'esecuzione vettorializzata
PostgreSQL e MySQL archiviano i dati riga per riga, il che ha senso per le transazioni ingegneristiche che recuperano singoli record, ma è terribile per le analisi che aggregano una colonna su miliardi di righe. ClickHouse archivia invece i dati per colonna.
Quando si interroga SUM(revenue) su 5 miliardi di righe, viene letta solo la colonna revenue, ignorando tutto il resto. Ciò riduce l'I/O del 90% o più e consente una compressione aggressiva, poiché i valori in una colonna sono simili.
L'esecuzione vettorializzata è il secondo moltiplicatore. I database tradizionali elaborano una riga alla volta. ClickHouse elabora intere matrici di valori contemporaneamente, caricando un blocco della colonna revenue nella cache della CPU e applicando le operazioni all'intero volume vettoriale in una singola istruzione. Ciò riduce drasticamente il sovraccarico della CPU.
La combinazione consente query in frazioni di secondo su miliardi di righe. L'archiviazione colonnare riduce al minimo le letture su disco; l'esecuzione vettorializzata riduce al minimo il lavoro della CPU. ClickHouse può aggregare 10 miliardi di righe in meno di un secondo, mentre un'istanza PostgreSQL impiega minuti.
Viste materializzate: pre-aggregazione al momento dell'ingestione
Anche con l'archiviazione dei dati colonnare, la scansione dei dati grezzi ogni volta è costosa. Le viste materializzate pre-calcolano gli aggregati al momento dell'ingestione.
In ClickHouse, una vista materializzata è una pipeline attiva, non un'istantanea passiva. Quando inserisci i dati, ClickHouse valuta automaticamente la query della vista e scrive i risultati in una tabella separata.
Se stai ingerendo 100.000 eventi al secondo con una vista che aggrega per minuto e segmento, ClickHouse calcola quegli aggregati in tempo reale.
La tua dashboard interroga la tabella pre-aggregata invece di scansionare gli eventi grezzi. Questo sposta il costo dal momento della query al momento dell'ingestione, accettando un piccolo sovraccarico di scrittura per una risposta immediata alla query. Per dashboard minuto per minuto e rilevamento delle frodi, le viste materializzate eliminano la latenza tra l'arrivo dei dati e la possibilità di interrogarli.
Consentono anche analisi a più risoluzioni: conserva i dati grezzi per l'analisi forense mantenendo aggregati orari/giornalieri per le dashboard. Man mano che i dati invecchiano, interroga aggregati più grossolani, mantenendo le prestazioni costanti mentre passi da terabyte a petabyte.
Archiviazione a livelli per mantenere i costi lineari su scala petabyte
Archiviare petabyte su SSD è proibitivamente costoso. L'archiviazione a livelli sposta i dati più vecchi su un archivio oggetti più economico, mantenendo i dati recenti su dischi locali veloci.
Ad esempio, OVHcloud Managed ClickHouse implementa questo nativamente negli strumenti con l'elaborazione dei flussi OVHcloud Object Storage (compatibile con S3)*. I dati recenti (30–90 giorni) rimangono nel flusso su SSD NVMe.
I dati più vecchi migrano automaticamente in un bucket OVHcloud Object Storage a una frazione del costo, consentendo comunque query veloci poiché ClickHouse legge solo le colonne necessarie. I costi per gli ingegneri rimangono lineari man mano che si scala: ogni terabyte aggiuntivo costa lo stesso a 10 TB o 100 TB.
ClickHouse interroga i dati di OVHcloud Object Storage senza Athena, Presto o Spark. Dati caldi su SSD, dati freddi su S3, tutto attraverso la stessa interfaccia SQL. Ciò elimina la necessità di mantenere sistemi separati per i dati basati su caldo e freddo.
L'archiviazione a livelli semplifica anche la conservazione dei dati a lungo termine: conserva i dati grezzi a tempo indeterminato per la conformità senza spendere una fortuna. Interrogare dati vecchi di 18 mesi per le indagini? ClickHouse li legge da OVHcloud Object Storage S3*, che è più lento ma comunque abbastanza veloce per l'analisi ad-hoc.
Come alimentare i dati nel tuo livello analitico
Una volta separata l'istanza OLTP dagli strumenti OLAP, devi spostare i dati dal tuo database di produzione a ClickHouse. Esistono tre modelli principali, ognuno con diversi compromessi in termini di latenza, complessità e sovraccarico operativo.
ETL batch con Airflow, dbt o cron job
L'ETL batch è il punto di partenza più semplice. Estrai i dati dal tuo database di produzione secondo una pianificazione (oraria o giornaliera), trasformali con dbt e caricali in ClickHouse. Airflow orchestra la pipeline, oppure i cron job gestiscono script semplici.
Questo funziona quando non hai bisogno di aggiornamenti minuto per minuto. Le dashboard orarie vanno bene per molti casi aziendali e l'elaborazione batch è più facile da sottoporre a debug e monitoraggio. I job falliti vengono riprovati alla pianificazione successiva e il backfilling dei dati storici è semplice.
Il compromesso è la latenza che crei. I dati sono obsoleti tra un batch e l'altro, quindi il rilevamento delle frodi in tempo reale o la personalizzazione dal vivo non sono possibili. Esegui anche pesanti query di estrazione sulla produzione durante la finestra batch, il che può causare contese se non pianificato durante periodi di basso traffico. L'ETL batch è adatto quando inizi con ClickHouse, non hai esperienza di streaming o tolleri dati vecchi di un'ora.
CDC in tempo reale con Apache Kafka e Debezium
Il Change Data Capture (CDC) trasmette ogni inserimento, aggiornamento ed eliminazione dalla produzione a ClickHouse quasi in tempo reale. Debezium legge il log delle transazioni del tuo database (WAL per PostgreSQL, binlog per MySQL) e pubblica le modifiche su Apache Kafka. ClickHouse consuma da Kafka e inserisce immediatamente.
Gli strumenti CDC raggiungono una latenza da frazioni di secondo a pochi secondi, consentendo un'analisi dei dati in tempo reale: rilevamento delle frodi che individua e blocca le transazioni mentre avvengono, monitoraggio delle anomalie che avvisa in pochi secondi, personalizzazione che reagisce istantaneamente per supportare il comportamento dell'utente.
Sebbene la complessità di configurazione sia maggiore, il CDC è lo standard per l'analisi in tempo reale su larga scala. Il sovraccarico è giustificato quando le decisioni aziendali dipendono dalla freschezza dei dati. Molti team utilizzano Kafka gestito per ridurre il carico, oppure iniziano con il batch e migrano al CDC una volta convalidato il valore in tempo reale.
Scritture dirette dell'applicazione in modo efficiente per carichi di lavoro puramente basati su eventi
La tua applicazione scrive direttamente sugli strumenti ClickHouse insieme al tuo database OLTP critico. Questo funziona meglio per carichi di lavoro basati su eventi in cui ogni azione dell'utente è un evento che vale la pena analizzare: visualizzazioni di pagina, clic, chiamate API, dati dei sensori. L'applicazione invia l'evento a entrambi i sistemi in parallelo, oppure utilizza ClickHouse come primario e si sincronizza con PostgreSQL per le transazioni.
Questo elimina completamente il livello ETL. Niente Kafka, niente Debezium, niente processi batch. L'applicazione scrive una volta, i dati sono immediatamente interrogabili e la latenza è minima.
Perché ClickHouse è il motore OLAP giusto per l'analisi in tempo reale
ClickHouse è stato costruito da zero per l'analisi in tempo reale su enormi set di dati. A differenza dei data warehouse generici che ottimizzano per carichi di lavoro batch o per quelli che ottimizzano per la BI interattiva, ClickHouse dà priorità alla latenza di query inferiore al secondo anche quando scansiona miliardi di righe.
Questo lo rende la scelta giusta per le aziende SaaS, FinTech, AdTech ed e-commerce che necessitano di analisi che stiano al passo con i loro sistemi di produzione.
Prestazioni di query inferiori al secondo :
ClickHouse raggiunge una latenza inferiore al secondo su query che scansionano miliardi di righe grazie all'archiviazione colonnare, all'esecuzione vettorializzata e alla compressione aggressiva. Può aggregare 10 miliardi di righe in meno di un secondo, mentre PostgreSQL impiega minuti e altri warehouse impiegano da secondi a decine di secondi.
ClickHouse vs Redshift vs BigQuery :
ClickHouse offre prezzi stabili basati sulle risorse con elevata concorrenza e scalabilità efficiente, ideale per analisi interattive in tempo reale. Redshift è ideale per il data warehousing orientato al batch con carichi di lavoro prevedibili e infrastruttura AWS esistente. BigQuery eccelle nell'analisi serverless con query sporadiche e per i team che desiderano zero overhead operativo.
ClickHouse SQL :
ClickHouse utilizza un dialetto SQL compatibile al 90% con l'esperienza di sviluppo SQL standard, ma esistono differenze chiave. Le funzioni di aggregazione utilizzano tabelle MergeTree con una sintassi specifica del motore. La maggior parte delle query SELECT si traduce direttamente, ma JOIN e subquery complesse potrebbero necessitare di ottimizzazione.
I suggerimenti per la migrazione da gestire includono il test preliminare delle query su un set di dati host rappresentativo, l'utilizzo di EXPLAIN di ClickHouse per ottimizzare i piani di esecuzione delle sessioni e lo sfruttamento delle viste materializzate per pre-calcolare aggregazioni complesse dello stack di strumenti.
Perché scegliere OVHcloud Managed ClickHouse
OVHcloud Managed ClickHouse è l'unico ClickHouse gestito nativo offerto da un provider cloud europeo, insieme ai nostri consolidati Managed Databases for PostgreSQL . Ciò significa nessun instradamento dei dati tramite terze parti, nessuna dipendenza da ClickHouse Cloud e nessun flusso di dati tra provider.
ClickHouse gestito da un provider UE: OVHcloud è l'unico provider cloud della regione europea a offrire un motore ClickHouse gestito nativo. A differenza dei concorrenti, dove dovresti passare attraverso servizi di terze parti, OVHcloud esegue ClickHouse direttamente sulla propria infrastruttura.
Automatico verso OVHcloud Object Storage: I dati freddi migrano automaticamente verso OVHcloud Object Storage compatibile con S3*, mantenendo i costi lineari su scala petabyte. I dati recenti (30–90 giorni) rimangono su SSD NVMe per la massima velocità, mentre i dati più vecchi si spostano su OVHcloud Object Storage a una frazione del costo. Fondamentalmente, non ci sono costi di egress.
Distribuzioni su 3-AZ a Parigi e Milano : I cluster di produzione sono eseguiti su tre zone di disponibilità a Parigi o Milano con un SLA del 99,99% su 3 A-Z, supporto tecnico 24/7 incluso e replica multi-nodo per un'elevata disponibilità. Il servizio Gen3 (da agosto 2025) offre 5× storage, 4× larghezza di banda, 2× TPS e un avvio 1,5× più veloce rispetto alla generazione precedente; tutto ciò è migliore per la scalabilità.
GDPR by design, nessuna esposizione al Cloud Act: OVHcloud è un'azienda francese soggetta esclusivamente alla legge francese/UE. Tutti i dati analitici rimangono nei data center europei, senza alcuna esposizione al Cloud Act che colpisca i provider statunitensi. Questo è particolarmente rilevante per i dati comportamentali, le transazioni finanziarie e i dati soggetti al GDPR.
Inoltre, i servizi di OVHcloud sono certificati ISO/IEC 27001/27017/27018/27701 e conformi HDS, con SecNumCloud in fase di ottenimento. Ciò include il nostro Managed Apache Kafka per pipeline CDC e il nostro OVHcloud Object Storage (compatibile con S3)*.
Per le aziende europee SaaS, FinTech, AdTech ed e-commerce che gestiscono dati di clienti UE, questa garanzia di sovranità elimina il rischio legale che le autorità statunitensi accedano ai dati archiviati presso provider cloud americani.
Inizia subito: distribuisci ClickHouse e connettilo al tuo database di produzione
Sei pronto a liberare il tuo database di produzione da pesanti query analitiche? La distribuzione di OVHcloud Managed ClickHouse richiede solo pochi minuti tramite il pannello di controllo o l'API.
Garantiamo che i tuoi dati rimangano nei data center europei per assicurare privacy e piena osservabilità, senza costi di traffico in uscita, e lo storage a livelli verso OVHcloud Object Storage compatibile con S3* garantisce costi prevedibili man mano che passi da terabyte a petabyte.
Avvia oggi stesso il tuo cluster software ClickHouse e scopri perché oltre 2.000 aziende, tra cui Tesla, Bloomberg e Anthropic, si affidano a ClickHouse per l'analisi in tempo reale.
*S3 è un marchio registrato di Amazon Technologies, Inc. I servizi di OVHcloud non sono in alcun modo sponsorizzati, approvati o affiliati da Amazon Technologies, Inc.