Analisi in tempo reale di petabyte senza rallentare il DB di produzione
Separa le transazioni dall'analisi
Risultato: una query di dashboard che dovrebbe richiedere 200 ms 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 si può risolvere con la messa a punto, ma che richiede, invece, un cambiamento nell'architettura: è necessario smettere di eseguire query pesanti sul database di produzione.
Mantieni PostgreSQL focalizzato su letture e scritture transazionali, mentre OVHcloud Managed ClickHouse gestisce le query analitiche. Per l'analisi di petabyte di dati in tempo reale, lo storage a oggetti compatibile con S3 offre un livello di capacità scalabile oltre lo storage primario ad alta velocità, consentendo al tuo ambiente analitico di crescere senza espandere il database di produzione.
Prestazioni e controllo su larga scala
![[object Object]](https://assets.ovhcloud.com/1fipjkCd6Fynpkj2pu4pL37bz_sYmY1YjFkODJlY2IyOGI5/1c4b1724-8eb2-433e-817d-75cffa9e8203_ite_79aa0c4f.svg){kind=small}
![[object Object]](https://assets.ovhcloud.com/1fiX5E4qzpXh67Ljo5AmdpyC4_sOTg4ZGYwMzQ5ZmJhOTY0/1c4b1724-8eb2-433e-817d-75cffa9e8203_ite_2d4e9ac8.svg){kind=small}
![[object Object]](https://assets.ovhcloud.com/1fipChngFS3mvuo2AkLC4LAjh_sZGYyMTFhOGIzZGFjOWVm/1c4b1724-8eb2-433e-817d-75cffa9e8203_ite_1f60228d.svg){kind=small}
![[object Object]](https://assets.ovhcloud.com/1fid6rzboLjodqmFX8pbmmpr8_sZDc4MTgzZjQ2OTg2NTIw/1c4b1724-8eb2-433e-817d-75cffa9e8203_ite_0703c5fb.svg){kind=small}
Perché la scalabilità dei database di produzione non è sufficiente a soddisfare la domanda analitica
Pressione sui database transazionali
I database transazionali sono particolarmente efficaci nelle operazioni di ricerca rapida, inserimento e aggiornamento. L'analisi di petabyte di dati in tempo reale genera esigenze diverse: scansioni estese, join complesse e aggregazioni ripetute che competono con il traffico di produzione per CPU, memoria e la velocità di trasmissione dei dati di archiviazione. 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.
Limitazioni delle repliche di lettura
Le repliche di lettura nei 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 si esegue 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.
Separazione durevole del carico di lavoro
Un approccio durevole separa i carichi di lavoro. Apache Kafka trasmette gli eventi confermati in una piattaforma dedicata realizzata per l'analisi su scala petabyte. I database di produzione continuano a gestire le transazioni, mentre l'ambiente analitico si scala in modo indipendente per dati su larga scala, analisi in streaming, intelligenza artificiale e business intelligence.
Assegna ogni carico di lavoro al motore giusto
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.
Al contrario, i sistemi OLAP 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 sono 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 hardware renderà un database orientato alle righe efficiente nelle scansioni colonnari. Le architetture sono fondamentalmente diverse.
Scegli un modello di caricamento per ogni origine dati
Streaming
Distribuisci eventi continuamente quando le dashboard operative e gli avvisi dipendono da insight a bassa latenza.
Elaborazione batch
Usa ETL batch con Airflow per pianificare backfilling dei dati storici, esportazioni periodiche e caricamenti di origine in blocco.
Change Data Capture
Propaga le modifiche al database confermate limitando il lavoro aggiuntivo sull'origine transazionale.
Ingestione diretta
Consenti alle applicazioni di scrivere eventi analitici direttamente quando i tuoi team possiedono e governano il contratto dell'evento.
Separazione di OLTP da OLAP
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. Questo 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.
![[object Object]](https://assets.ovhcloud.com/1fiz3Ewd3ACopFnjLbkLvoSdp_sYjBlNTU5YjQyYWVjNjdl/76542f62-8c49-48e5-92ec-910825c8d69c_ima_e302634e.png)
Progettazione per aggiornamenti, velocità, resilienza e governance
ETL batch
L'ETL batch è il punto di partenza più semplice.
Estrai i dati dal 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.
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. L'ETL batch è adatto quando si inizia con ClickHouse, non si ha esperienza di streaming o si tollerano dati vecchi di un'ora.
CDC in tempo reale
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 nello stesso istante in cui avvengono, monitoraggio delle anomalie che avvisa in pochi secondi, personalizzazione che reagisce istantaneamente per supportare il comportamento dell'utente.
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 uno storage a 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.
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 (snapshot). Quando si inseriscono i dati, ClickHouse valuta automaticamente la query della vista e scrive i risultati in una tabella separata.
Se si stanno ingerendo 100.000 eventi al secondo con una vista che aggrega per minuto e segmento, ClickHouse calcola quegli aggregati in tempo reale.
Perché ClickHouse è il motore giusto per l'analisi in tempo reale
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 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 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.
Esplora OVHcloud Managed ClickHouse o collabora con i nostri specialisti per dimensionare un'architettura in base al volume, agli aggiornamenti, alla conservazione e alla concorrenza delle query dei tuoi dati.