Passare a ClickHouse: 3 anni dopo

Tre anni fa Viktor Tarnavsky e Alexey Milovidov di Yandex sul palco Gran Carico ++ detto, quanto è buono ClickHouse e come non rallenta. E nella fase successiva c'era Alexander Zaitsev с rapporto riguardo al trasferirsi a CliccaCasa da un altro DBMS analitico e con la conclusione che CliccaCasa, ovviamente, buono, ma non molto conveniente. Quando nel 2016 l'azienda LifeStreet, dove allora lavorava Alexander, stava convertendo un sistema analitico multi-petabyte in CliccaCasa, era un'affascinante “strada di mattoni gialli” piena di pericoli sconosciuti - CliccaCasa allora sembrava un campo minato.

Tre anni dopo CliccaCasa è diventato molto migliore: durante questo periodo Alexander ha fondato la società Altinity, che non solo aiuta le persone a trasferirsi CliccaCasa decine di progetti, ma migliora anche il prodotto stesso insieme ai colleghi di Yandex. Ora CliccaCasa non ancora una passeggiata spensierata, ma non più un campo minato.

Alexander lavora con sistemi distribuiti dal 2003, sviluppando grandi progetti MySQL, Oracle и Vertica. All'ultimo HighLoad ++ 2019 Alexander, uno dei pionieri dell'utilizzo CliccaCasa, ha detto cos'è ora questo DBMS. Impareremo a conoscere le caratteristiche principali CliccaCasa: in cosa differisce dagli altri sistemi e in quali casi è più efficace utilizzarlo. Utilizzando esempi, esamineremo le pratiche recenti e testate dal progetto per la costruzione di sistemi basati su CliccaCasa.

Retrospettiva: cosa è successo 3 anni fa

Tre anni fa abbiamo trasferito l'azienda LifeStreet su CliccaCasa da un altro database analitico e la migrazione dell'analisi della rete pubblicitaria si presentava così:

• Giugno 2016. Nel OpenSource apparso CliccaCasa e il nostro progetto è iniziato;
• Agosto. Verifica teorica: grande rete pubblicitaria, infrastrutture e 200-300 terabyte di dati;
• Ottobre. Primi dati di produzione;
• Dicembre. Il carico completo del prodotto è di 10-50 miliardi di eventi al giorno.
• Giugno 2017. Migrazione degli utenti a CliccaCasa, 2,5 petabyte di dati su un cluster di 60 server.

Durante il processo di migrazione, c’era una crescente consapevolezza di ciò CliccaCasa è un buon sistema con cui è piacevole lavorare, ma questo è un progetto interno di Yandex. Pertanto, ci sono delle sfumature: Yandex si occuperà prima dei propri clienti interni e solo poi della comunità e delle esigenze degli utenti esterni, e ClickHouse in molte aree funzionali non ha raggiunto il livello aziendale. Ecco perché nel marzo 2017 abbiamo fondato Altinity CliccaCasa ancora più veloce e conveniente non solo per Yandex, ma anche per altri utenti. E ora noi:

• Formiamo e aiutiamo a costruire soluzioni basate su CliccaCasa in modo che i clienti non si mettano nei guai e che la soluzione alla fine funzioni;
• Forniamo supporto 24 ore su 7, XNUMX giorni su XNUMX CliccaCasa- impianti;
• Sviluppiamo i nostri progetti ecosistemici;
• Ci impegniamo attivamente con noi stessi CliccaCasa, rispondendo alle richieste degli utenti che desiderano vedere determinate funzionalità.

E, naturalmente, aiutiamo con il trasferimento CliccaCasa с MySQL, Vertica, Oracle, prugna verde, redshift e altri sistemi. Siamo stati coinvolti in una serie di iniziative e tutte hanno avuto successo.

Perché trasferirsi a CliccaCasa

Non rallenta! Questa è la ragione principale. CliccaCasa - database molto veloce per diversi scenari:

Citazioni casuali di persone che lavorano con le persone da molto tempo CliccaCasa.

Scalabilità. Su qualche altro database puoi ottenere buone prestazioni su un componente hardware, ma CliccaCasa puoi scalare non solo verticalmente, ma anche orizzontalmente, semplicemente aggiungendo server. Non tutto funziona così bene come vorremmo, ma funziona. Puoi espandere il sistema man mano che la tua attività cresce. È importante non essere limitati dalla soluzione adesso e c’è sempre un potenziale di sviluppo.

Portabilità. Non c'è attaccamento a una cosa. Ad esempio, con Amazon RedShift È difficile spostarsi da qualche parte. UN CliccaCasa puoi installarlo sul tuo laptop, server, distribuirlo sul cloud, andare su kubernetes — non esistono restrizioni al funzionamento dell'infrastruttura. Questo è conveniente per tutti e questo è un grande vantaggio di cui molti altri database simili non possono vantarsi.

Flessibilità. CliccaCasa non si ferma a una cosa, ad esempio Yandex.Metrica, ma si sviluppa e viene utilizzato in progetti e settori sempre più diversi. Può essere ampliato aggiungendo nuove funzionalità per risolvere nuovi problemi. Ad esempio, si ritiene che archiviare i registri in un database sia una cattiva educazione, quindi è stato inventato elasticsearch. Ma grazie alla flessibilità CliccaCasa, puoi anche memorizzarvi i log, e spesso questo è anche meglio che in elasticsearch - in CliccaCasa questo richiede 10 volte meno ferro.

Gratuito Open Source. Non devi pagare nulla. Non è necessario negoziare l'autorizzazione per installare il sistema sul tuo laptop o server. Nessun costo nascosto. Allo stesso tempo, nessun'altra tecnologia di database Open Source può competere in velocità CliccaCasa. MySQL, MariaDB, Greenplum - sono tutti molto più lenti.

Comunità, guida e ti divertirai. In CliccaCasa community eccellente: incontri, chat e Alexey Milovidov, che ci carica tutti con la sua energia e ottimismo.

Passare a ClickHouse

Andare a CliccaCasa per qualche motivo, hai solo bisogno di tre cose:

• Comprendi i limiti CliccaCasa e per cosa non è adatto.
• Approfitta tecnologia e i suoi maggiori punti di forza.
• Sperimentare. Anche capendo come funziona CliccaCasa, non è sempre possibile prevedere quando sarà più veloce, quando sarà più lento, quando andrà meglio e quando sarà peggio. Quindi provalo.

Problema di spostamento

C’è solo un “ma”: se ti trasferisci CliccaCasa da qualcos'altro, di solito qualcosa va storto. Siamo abituati ad alcune pratiche e cose che funzionano nel nostro database preferito. Ad esempio, chiunque lavori con SQI database L considerano obbligatorio il seguente insieme di funzioni:

• transazioni;
• vincoli;
• consistenza;
• indici;
• AGGIORNA/ELIMINA;
• NULL;
• millisecondi;
• getti di tipo automatico;
• unioni multiple;
• partizioni arbitrarie;
• strumenti di gestione dei cluster.

Il reclutamento è obbligatorio, ma tre anni fa CliccaCasa Nessuna di queste funzioni era disponibile! Ora rimane meno della metà di ciò che non è stato implementato: transazioni, vincoli, Consistency, millisecondi e type casting.

E la cosa principale è che dentro CliccaCasa alcune pratiche e approcci standard non funzionano o funzionano in modo diverso da come siamo abituati. Tutto ciò che appare in CliccaCasa, corrisponde a "Modo ClickHouse", cioè. le funzioni differiscono da altri database. Per esempio:

• Gli indici non vengono selezionati, ma saltati.
• AGGIORNA/ELIMINA non sincrono, ma asincrono.
• Sono disponibili più join, ma non è disponibile un pianificatore di query. Il modo in cui vengono poi eseguiti generalmente non è molto chiaro a chi lavora nel mondo dei database.

Script ClickHouse

Nel 1960, un matematico americano di origine ungherese Wigner EP ha scritto un articolo "L’irragionevole efficacia della matematica nelle scienze naturali" ("L'incomprensibile efficacia della matematica nelle scienze naturali") che il mondo che ci circonda è per qualche motivo ben descritto dalle leggi matematiche. La matematica è una scienza astratta e le leggi fisiche espresse in forma matematica non sono banali Wigner EP ha sottolineato che questo è molto strano.

Dal mio punto di vista, CliccaCasa - la stessa stranezza. Per riformulare Wigner, possiamo dire questo: l’efficienza inconcepibile è sorprendente CliccaCasa in un'ampia varietà di applicazioni analitiche!

Prendiamo ad esempio Magazzino dati in tempo reale, in cui i dati vengono caricati quasi continuamente. Vogliamo ricevere le richieste da esso con un secondo ritardo. Per favore, usalo CliccaCasa, perché questo è lo scenario per cui è stato progettato. CliccaCasa questo è esattamente il modo in cui viene utilizzato non solo sul web, ma anche nel marketing e nell'analisi finanziaria, AdTech, così come in Intercettazione di una frodeN. IN Magazzino dati in tempo reale viene utilizzato uno schema strutturato complesso come "stella" o "fiocco di neve", molte tabelle con ISCRIVITI (a volte multipli) e i dati vengono generalmente archiviati e modificati in alcuni sistemi.

Prendiamo un altro scenario: Serie storiche: monitoraggio dei dispositivi, reti, statistiche di utilizzo, Internet of Things. Qui incontriamo eventi abbastanza semplici ordinati nel tempo. CliccaCasa non è stato originariamente sviluppato per questo, ma ha dimostrato di funzionare bene, motivo per cui lo utilizzano le grandi aziende CliccaCasa come archivio per il monitoraggio delle informazioni. Per verificare se è adatto CliccaCasa per le serie temporali, abbiamo creato un benchmark basato sull'approccio e sui risultati InflussoDB и Scala cronologica DB - specializzato serie temporali banche dati. Si è scopertoChe CliccaCasa, anche senza ottimizzazione per tali compiti, vince su un campo straniero:

В serie temporali Di solito viene utilizzata una tabella stretta: diverse piccole colonne. Dal monitoraggio possono provenire molti dati, milioni di record al secondo, e di solito arrivano in piccole quantità (tempo reale streaming). Pertanto, è necessario uno script di inserimento diverso e le query stesse hanno le proprie specifiche.

Log Management. La raccolta dei log in un database è solitamente negativa, ma CliccaCasa questo può essere fatto con alcuni commenti come descritto sopra. Molte aziende utilizzano CliccaCasa proprio per questo scopo. In questo caso, utilizziamo una tabella larga e piatta in cui memorizziamo tutti i log (ad esempio, nel form JSON) o tagliarli a pezzetti. I dati vengono solitamente caricati in grandi batch (file) e cerchiamo in base ad alcuni campi.

Per ciascuna di queste funzioni vengono solitamente utilizzati database specializzati. CliccaCasa si può fare tutto e così bene da superarli. Diamo ora uno sguardo più da vicino serie temporali scenario e come “cucinare” correttamente CliccaCasa per questo scenario.

Serie temporali

Attualmente questo è lo scenario principale per il quale CliccaCasa considerata la soluzione standard. serie temporali è un insieme di eventi ordinati nel tempo, che rappresentano i cambiamenti in alcuni processi nel tempo. Potrebbe trattarsi, ad esempio, della frequenza cardiaca giornaliera o del numero di processi nel sistema. Tutto ciò che dà al tempo uno tic con determinate dimensioni lo è serie temporali:

La maggior parte di questi tipi di eventi derivano dal monitoraggio. Può trattarsi non solo del monitoraggio del web, ma anche di dispositivi reali: automobili, sistemi industriali, IoT, fabbriche o taxi senza pilota, nel bagagliaio dei quali Yandex sta già mettendo CliccaCasa-server.

Ad esempio, ci sono aziende che raccolgono dati dalle navi. Ogni pochi secondi, i sensori sulla nave portacontainer inviano centinaia di misurazioni diverse. Gli ingegneri li studiano, costruiscono modelli e cercano di capire quanto sia efficiente l'utilizzo della nave, perché una nave portacontainer non dovrebbe restare ferma nemmeno per un secondo. Eventuali tempi di inattività rappresentano una perdita di denaro, quindi è importante prevedere il percorso in modo che le interruzioni siano minime.

Al giorno d'oggi c'è una crescita di database specializzati che misurano serie temporali. Sul posto Motori DB I diversi database sono in qualche modo classificati e puoi visualizzarli per tipo:

Il tipo in più rapida crescita è serie temporaliS. Anche i database grafici stanno crescendo, ma serie temporalisono cresciuti più velocemente negli ultimi anni. I rappresentanti tipici di questa famiglia di database sono InflussoDB, Prometeo, KDB, Scala cronologica DB (costruita su PostgreSQL), soluzioni da Amazon. CliccaCasa può essere utilizzato anche qui, e viene utilizzato. Lasciate che vi faccia alcuni esempi pubblici.

Uno dei pionieri è l'azienda CloudFlare (CDN-fornitore). Monitorano il loro CDN attraverso CliccaCasa (DNS-richieste, HTTP-queries) con un carico enorme: 6 milioni di eventi al secondo. Tutto passa Kafka, va a CliccaCasa, che offre l'opportunità di vedere dashboard degli eventi nel sistema in tempo reale.

Comcast - uno dei leader nelle telecomunicazioni negli USA: Internet, televisione digitale, telefonia. Hanno creato un sistema di controllo simile CDN all'interno della Open Source progetto Controllo del traffico Apache per lavorare con i tuoi enormi dati. CliccaCasa utilizzato come backend per l'analisi.

percona integrato CliccaCasa dentro il tuo PMMper memorizzare il monitoraggio di vari MySQL.

Requisiti specifici

I database di serie temporali hanno requisiti specifici.

• Inserimento rapido da parte di molti agenti. Dobbiamo inserire i dati da molti flussi molto rapidamente. CliccaCasa Lo fa bene perché tutti i suoi inserti non sono bloccanti. Qualunque insert è un nuovo file su disco e piccoli inserti possono essere memorizzati nel buffer in un modo o nell'altro. IN CliccaCasa È preferibile inserire i dati in grandi batch piuttosto che una riga alla volta.
• Schema flessibile. In serie temporali di solito non conosciamo completamente la struttura dei dati. È possibile realizzare un sistema di monitoraggio per un'applicazione specifica, ma poi è difficile utilizzarlo per un'altra applicazione. Ciò richiede uno schema più flessibile. CliccaCasa, ti consente di farlo, anche se è una base fortemente tipizzata.
• Archiviazione efficiente e dimenticanza dei dati. Di solito dentro serie temporali un'enorme quantità di dati, quindi deve essere archiviata nel modo più efficiente possibile. Ad esempio, a InflussoDB una buona compressione è la sua caratteristica principale. Ma oltre all'archiviazione, devi anche essere in grado di "dimenticare" i vecchi dati e fare qualcosa sottocampionamento — conteggio automatico degli aggregati.
• Query veloci su dati aggregati. A volte è interessante osservare gli ultimi 5 minuti con una precisione di millisecondi, ma per i dati mensili la granularità al minuto o al secondo potrebbe non essere necessaria: sono sufficienti le statistiche generali. Un supporto di questo tipo è necessario, altrimenti una richiesta di 3 mesi richiederà molto tempo per essere completata anche in CliccaCasa.
• Richieste come "ultimo punto, a partire da». Questi sono tipici per serie temporali query: guarda l'ultima misurazione o lo stato del sistema in un momento nel tempo t. Queste non sono query molto piacevoli per un database, ma devi anche essere in grado di eseguirle.
• Serie storiche “incollate”.. serie temporali è una serie temporale. Se sono presenti due serie temporali, spesso necessitano di essere collegate e correlate. Non è conveniente farlo su tutti i database, soprattutto con serie temporali non allineate: qui ci sono alcuni punti temporali, ce ne sono altri. Puoi considerarlo nella media, ma all'improvviso ci sarà ancora un buco lì, quindi non è chiaro.

Vediamo come vengono soddisfatti questi requisiti CliccaCasa.

Guida

В CliccaCasa schema per serie temporali può essere effettuata in diversi modi, a seconda del grado di regolarità dei dati. È possibile costruire un sistema su dati regolari quando conosciamo tutte le metriche in anticipo. Ad esempio, ho fatto questo CloudFlare con monitoraggio CDN è un sistema ben ottimizzato. È possibile costruire un sistema più generale che monitori l'intera infrastruttura e i vari servizi. In caso di dati irregolari non sappiamo in anticipo cosa stiamo monitorando e questo è probabilmente il caso più comune.

Dati regolari. Colonne. Lo schema è semplice: colonne con i tipi richiesti:

CREATE TABLE cpu (
  created_date Date DEFAULT today(),  
  created_at DateTime DEFAULT now(),  
  time String,  
  tags_id UInt32,  /* join to dim_tag */
  usage_user Float64,  
  usage_system Float64,  
  usage_idle Float64,  
  usage_nice Float64,  
  usage_iowait Float64,  
  usage_irq Float64,  
  usage_softirq Float64,  
  usage_steal Float64,  
  usage_guest Float64,  
  usage_guest_nice Float64
) ENGINE = MergeTree(created_date, (tags_id, created_at), 8192);

Questa è una tabella normale che monitora qualche tipo di attività di caricamento del sistema (Utente, sistema, inattivo, bello). Semplice e conveniente, ma non flessibile. Se vogliamo uno schema più flessibile, possiamo usare gli array.

Dati irregolari. Array:

CREATE TABLE cpu_alc (
  created_date Date,  
  created_at DateTime,  
  time String,  
  tags_id UInt32,  
  metrics Nested(
    name LowCardinality(String),  
    value Float64
  )
) ENGINE = MergeTree(created_date, (tags_id, created_at), 8192);

SELECT max(metrics.value[indexOf(metrics.name,'usage_user')]) FROM ...

Struttura Annidati sono due array: metrics.name и metrica.valore. Qui è possibile memorizzare dati di monitoraggio arbitrari come un array di nomi e un array di misurazioni per ciascun evento. Per un'ulteriore ottimizzazione, invece di una di queste strutture, puoi crearne diverse. Ad esempio, uno per galleggiante-valore, un altro - per int-significato perché int Voglio archiviare in modo più efficiente.

Ma una struttura del genere è più difficile da raggiungere. Dovrai utilizzare una costruzione apposita, utilizzando apposite funzioni per estrarre i valori prima dell'indice e poi dell'array:

SELECT max(metrics.value[indexOf(metrics.name,'usage_user')]) FROM ...

Ma funziona ancora abbastanza velocemente. Un altro modo per memorizzare dati irregolari è per riga.

Dati irregolari. stringhe. In questo metodo tradizionale, senza array, nomi e valori vengono memorizzati contemporaneamente. Se 5 misurazioni provengono da un dispositivo contemporaneamente, nel database vengono generate 000 righe:

CREATE TABLE cpu_rlc (
  created_date Date,  
  created_at DateTime,  
  time String,  
  tags_id UInt32,  
  metric_name LowCardinality(String),  
  metric_value Float64
) ENGINE = MergeTree(created_date, (metric_name, tags_id, created_at), 8192);


SELECT 
    maxIf(metric_value, metric_name = 'usage_user'),
    ... 
FROM cpu_r
WHERE metric_name IN ('usage_user', ...)

CliccaCasa affronta questo problema: ha estensioni speciali CliccaCasa SQL. Ad esempio, maxSe — una funzione speciale che calcola il massimo tramite una metrica quando viene soddisfatta una determinata condizione. È possibile scrivere diverse espressioni di questo tipo in un'unica richiesta e calcolare immediatamente il valore per diverse metriche.

Confrontiamo tre approcci:

Dettagli

Qui ho aggiunto "Dimensione dati disco" per alcuni set di dati di test. Nel caso delle colonne abbiamo la dimensione dei dati più piccola: massima compressione, massima velocità di interrogazione, ma paghiamo dovendo registrare tutto in una volta.

Nel caso degli array, tutto è un po' peggio. I dati sono ancora ben compressi ed è possibile memorizzare uno schema irregolare. Ma CliccaCasa - un database a colonne e quando iniziamo a memorizzare tutto in un array, si trasforma in una riga uno e paghiamo la flessibilità con l'efficienza. Per qualsiasi operazione, dovrai leggere l'intero array in memoria, quindi trovare l'elemento desiderato al suo interno e se l'array cresce, la velocità diminuisce.

In una delle aziende che utilizza questo approccio (ad esempio, Uber), gli array vengono tagliati in pezzi di 128 elementi. I dati di diverse migliaia di parametri con un volume di 200 TB di dati al giorno non vengono archiviati in un array, ma in 10 o 30 array con una logica di archiviazione speciale.

L'approccio più semplice è con le stringhe. Ma i dati sono scarsamente compressi, la dimensione della tabella è grande e anche quando le query si basano su più parametri, ClickHouse non funziona in modo ottimale.

Schema ibrido

Supponiamo di aver scelto un circuito array. Ma se sappiamo che la maggior parte dei nostri dashboard mostra solo parametri utente e di sistema, possiamo inoltre materializzare questi parametri in colonne da un array a livello di tabella in questo modo:

CREATE TABLE cpu_alc (
  created_date Date,  
  created_at DateTime,  
  time String,  
  tags_id UInt32,  
  metrics Nested(
    name LowCardinality(String),  
    value Float64
  ),
  usage_user Float64 
             MATERIALIZED metrics.value[indexOf(metrics.name,'usage_user')],
  usage_system Float64 
             MATERIALIZED metrics.value[indexOf(metrics.name,'usage_system')]
) ENGINE = MergeTree(created_date, (tags_id, created_at), 8192);

Durante l'inserimento CliccaCasa li conterà automaticamente. In questo modo puoi unire l'utile al dilettevole: lo schema è flessibile e generale, ma abbiamo estratto le colonne utilizzate più frequentemente. Si noti che ciò non ha richiesto la modifica dell'inserto e ETLche continua a inserire array nella tabella. L'abbiamo appena fatto ALTER TABLE, abbiamo aggiunto un paio di altoparlanti e abbiamo ottenuto uno schema ibrido e più veloce che puoi iniziare a utilizzare subito.

Codec e compressione

per serie temporali È importante quanto bene impacchetti i dati perché la quantità di informazioni può essere molto grande. IN CliccaCasa Esiste una serie di strumenti per ottenere un effetto di compressione di 1:10, 1:20 e talvolta di più. Ciò significa che 1 TB di dati non compressi sul disco occupa 50-100 GB. Le dimensioni più piccole sono buone, i dati possono essere letti ed elaborati più velocemente.

Per ottenere un livello elevato di compressione, CliccaCasa supporta i seguenti codec:

Tabella di esempio:

CREATE TABLE benchmark.cpu_codecs_lz4 (
    created_date Date DEFAULT today(), 
    created_at DateTime DEFAULT now() Codec(DoubleDelta, LZ4), 
    tags_id UInt32, 
    usage_user Float64 Codec(Gorilla, LZ4), 
    usage_system Float64 Codec(Gorilla, LZ4), 
    usage_idle Float64 Codec(Gorilla, LZ4), 
    usage_nice Float64 Codec(Gorilla, LZ4), 
    usage_iowait Float64 Codec(Gorilla, LZ4), 
    usage_irq Float64 Codec(Gorilla, LZ4), 
    usage_softirq Float64 Codec(Gorilla, LZ4), 
    usage_steal Float64 Codec(Gorilla, LZ4), 
    usage_guest Float64 Codec(Gorilla, LZ4), 
    usage_guest_nice Float64 Codec(Gorilla, LZ4), 
    additional_tags String DEFAULT ''
)
ENGINE = MergeTree(created_date, (tags_id, created_at), 8192);

Qui definiamo il codec Doppio Delta in un caso, nel secondo - Gorilla, e ne aggiungeremo sicuramente altri LZ4 compressione. Di conseguenza, la dimensione dei dati su disco è notevolmente ridotta:

Questo mostra quanto spazio occupano gli stessi dati, ma utilizzando codec e compressioni diversi:

• in un file GZIP su disco;
• in ClickHouse senza codec, ma con compressione ZSTD;
• in ClickHouse con codec e compressione LZ4 e ZSTD.

Si può vedere che le tabelle con codec occupano molto meno spazio.

Le dimensioni contano

Non meno importante scegliere tipo di dati corretto:

In tutti gli esempi sopra ho usato galleggiante64. Ma se scegliessimo galleggiante32, allora sarebbe ancora meglio. Ciò è stato ben dimostrato dai ragazzi di Perkona nell'articolo linkato sopra. È importante utilizzare la tipologia più compatta e adatta al compito: ancor meno per le dimensioni del disco che per la velocità di interrogazione. CliccaCasa molto sensibile a questo.

Se puoi usare int32 invece di int64, quindi aspettatevi un aumento quasi doppio delle prestazioni. I dati occupano meno memoria e tutta l’“aritmetica” funziona molto più velocemente. CliccaCasa internamente è un sistema molto rigorosamente tipizzato; sfrutta al massimo tutte le possibilità offerte dai sistemi moderni.

Aggregazione e Viste materializzate

L'aggregazione e le visualizzazioni materializzate consentono di creare aggregati per diverse occasioni:

Ad esempio, potresti avere dati di origine non aggregati e puoi allegare ad essi varie viste materializzate con somma automatica tramite un motore speciale SummingMergeTree (SMT). SMT è una speciale struttura dati di aggregazione che calcola automaticamente gli aggregati. I dati grezzi vengono inseriti nel database, vengono aggregati automaticamente e su di essi è possibile utilizzare immediatamente le dashboard.

TTL - “dimenticare” i vecchi dati

Come “dimenticare” i dati che non servono più? CliccaCasa sa come farlo. Quando crei le tabelle, puoi specificare TTL espressioni: ad esempio, memorizziamo i dati minuti per un giorno, i dati giornalieri per 30 giorni e non tocchiamo mai i dati settimanali o mensili:

CREATE TABLE aggr_by_minute
…
TTL time + interval 1 day

CREATE TABLE aggr_by_day
…
TTL time + interval 30 day

CREATE TABLE aggr_by_week
…
/* no TTL */

Multi-livello - dividere i dati su dischi

Portando avanti questa idea, i dati possono essere archiviati in CliccaCasa in luoghi diversi. Supponiamo di voler archiviare i dati importanti dell'ultima settimana su un locale molto veloce SSDe inseriamo più dati storici in un altro posto. IN CliccaCasa ora è possibile:

È possibile configurare una policy di archiviazione (politica di archiviazione) COSÌ CliccaCasa trasferirà automaticamente i dati al raggiungimento di determinate condizioni in un altro archivio.

Ma non è tutto. A livello di una tabella specifica, è possibile definire regole precise per quando i dati vanno nella cella frigorifera. Ad esempio, i dati vengono archiviati su un disco molto veloce per 7 giorni e tutto ciò che è più vecchio viene trasferito su un disco lento. Questo è positivo perché permette di mantenere il sistema al massimo delle prestazioni, controllando i costi e non sprecando soldi con dati freddi:

CREATE TABLE 
... 
TTL date + INTERVAL 7 DAY TO VOLUME 'cold_volume', 
    date + INTERVAL 180 DAY DELETE

Caratteristiche uniche CliccaCasa

In quasi tutto CliccaCasa Esistono tali "punti salienti", ma sono compensati dall'esclusività, qualcosa che non si trova in altri database. Ad esempio, ecco alcune delle caratteristiche uniche CliccaCasa:

• array. In CliccaCasa ottimo supporto per gli array, nonché la capacità di eseguire calcoli complessi su di essi.
• Aggregazione di strutture dati. Questa è una delle "caratteristiche killer" CliccaCasa. Nonostante i ragazzi di Yandex affermino che non vogliamo aggregare i dati, tutto viene aggregato CliccaCasa, perché è veloce e conveniente.
• Viste materializzate. Insieme all'aggregazione delle strutture dei dati, le visualizzazioni materializzate ti consentono di rendere conveniente tempo reale aggregazione.
• Fare clic su House SQL. Questa è un'estensione della lingua SQL con alcune funzionalità aggiuntive ed esclusive disponibili solo in CliccaCasa. In precedenza, da un lato era come un’espansione e dall’altro uno svantaggio. Ora quasi tutti gli svantaggi rispetto a SQL92 l'abbiamo rimosso, ora è solo un'estensione.
• Lambda–espressioni. Sono ancora in qualche database?
• ML-supporto. Questo è disponibile in diversi database, alcuni sono migliori, altri sono peggiori.
• fonte aperta. Possiamo espanderci CliccaCasa insieme. Ora in CliccaCasa circa 500 contributori, e questo numero è in costante crescita.

Domande complicate

В CliccaCasa ci sono molti modi diversi per fare la stessa cosa. Ad esempio, puoi restituire l'ultimo valore da una tabella in tre modi diversi per CPU (ce n'è anche una quarta, ma è ancora più esotica).

Il primo mostra quanto sia conveniente farlo CliccaCasa query quando vuoi verificarlo tupla contenuto nella sottoquery. Questo è qualcosa che personalmente mi è mancato molto in altri database. Se voglio confrontare qualcosa con una sottoquery, in altri database è possibile confrontare solo uno scalare, ma per diverse colonne devo scrivere ISCRIVITI. In CliccaCasa puoi usare la tupla:

SELECT *
  FROM cpu 
 WHERE (tags_id, created_at) IN 
    (SELECT tags_id, max(created_at)
        FROM cpu 
        GROUP BY tags_id)

Il secondo metodo fa la stessa cosa ma utilizza una funzione aggregata argMax:

SELECT 
    argMax(usage_user), created_at),
    argMax(usage_system), created_at),
...
 FROM cpu 

В CliccaCasa ci sono diverse dozzine di funzioni aggregate e se usi i combinatori, secondo le leggi della combinatoria ne otterrai circa un migliaio. ArgMax - una delle funzioni che calcola il valore massimo: la richiesta restituisce il valore utilizzo_utente, al quale viene raggiunto il valore massimo create_at:

SELECT now() as created_at,
       cpu.*
  FROM (SELECT DISTINCT tags_id from cpu) base 
  ASOF LEFT JOIN cpu USING (tags_id, created_at)

ISCRIVITI SUBITO — “incollare” righe con tempi diversi. Questa è una funzionalità unica per i database disponibile solo in kdb +. Se ci sono due serie temporali con tempi diversi, ISCRIVITI SUBITO ti consente di spostarli e unirli in un'unica richiesta. Per ogni valore in una serie temporale, viene trovato il valore più vicino nell'altra e vengono restituiti sulla stessa riga:

Funzioni analitiche

Nella norma SQL-2003 puoi scrivere così:

SELECT origin,
       timestamp,
       timestamp -LAG(timestamp, 1) OVER (PARTITION BY origin ORDER BY timestamp) AS duration,
       timestamp -MIN(timestamp) OVER (PARTITION BY origin ORDER BY timestamp) AS startseq_duration,
       ROW_NUMBER() OVER (PARTITION BY origin ORDER BY timestamp) AS sequence,
       COUNT() OVER (PARTITION BY origin ORDER BY timestamp) AS nb
  FROM mytable
ORDER BY origin, timestamp;

В CliccaCasa Non puoi farlo: non supporta lo standard SQL-2003 e probabilmente non lo farà mai. Invece, dentro CliccaCasa È consuetudine scrivere così:

Ho promesso dei lambda: eccoli qui!

Questo è un analogo della query analitica nello standard SQL-2003: conta la differenza tra i due timestamp, durata, numero ordinale: tutto ciò che solitamente consideriamo funzioni analitiche. IN CliccaCasa Li contiamo attraverso gli array: prima comprimiamo i dati in un array, dopo facciamo tutto ciò che vogliamo sull'array, quindi lo espandiamo nuovamente. Non è molto conveniente, richiede almeno un amore per la programmazione funzionale, ma è molto flessibile.

Caratteristiche speciali

Inoltre, dentro CliccaCasa molte funzioni specializzate. Ad esempio, come determinare quante sessioni si svolgono contemporaneamente? Una tipica attività di monitoraggio è determinare il carico massimo con una richiesta. IN CliccaCasa A questo scopo esiste una funzione speciale:

In generale, ClickHouse ha funzioni speciali per molti scopi:

• corsaDifferenza, corsaAccumulata, vicino;
• sumMap(chiave, valore);
• timeSeriesGroupSum(uid, timestamp, valore);
• timeSeriesGroupRateSum(uid, timestamp, valore);
• skewPop, skewSamp, kurtPop, kurtSamp;
• CON RIEMPIMENTO / CON LEGAMI;
• regressionlineare semplice, regressione lineare stocastica.

Questo non è un elenco completo delle funzioni, ce ne sono 500-600 in totale. Suggerimento: tutte le funzioni in CliccaCasa è nella tabella di sistema (non tutti sono documentati, ma tutti sono interessanti):

select * from system.functions order by name

CliccaCasa memorizza molte informazioni su se stesso, incluso tabelle di registro, query_log, log di traccia, log delle operazioni con blocchi dati (part_log), registro delle metriche e registro di sistema, che in genere scrive su disco. Le metriche di registro sono serie temporali в CliccaCasa infatti CliccaCasa: Il database stesso può svolgere un ruolo serie temporali database, “divorando” se stessa.

Anche questa è una cosa unica, poiché facciamo un buon lavoro per serie temporali, perché non possiamo conservare dentro di noi tutto ciò di cui abbiamo bisogno? Non abbiamo bisogno Prometeo, teniamo tutto per noi. Collegato graminacee e monitoriamo noi stessi. Tuttavia, se CliccaCasa cade, non vedremo perché, quindi di solito non lo fanno.

Cluster grande o molti piccoli CliccaCasa

Cosa è meglio: un grande cluster o tante piccole ClickHouse? Approccio tradizionale a ACS è un grande cluster in cui i circuiti sono allocati per ciascuna applicazione. Siamo andati dall'amministratore del database: forniscici un diagramma e ce ne hanno dato uno:

В CliccaCasa puoi farlo diversamente. Puoi personalizzare ogni applicazione CliccaCasa:

Non abbiamo più bisogno di quello grande e mostruoso ACS e amministratori intrattabili. Possiamo dare ad ogni applicazione il suo CliccaCasa, e lo sviluppatore può farlo da solo, da allora CliccaCasa molto facile da installare e non richiede un'amministrazione complessa:

Ma se ne abbiamo molti CliccaCasae devi installarlo spesso, quindi vuoi automatizzare questo processo. Per questo possiamo, ad esempio, utilizzare kubernetes и clickhouse-operatore. IN Kubernetes ClickHouse puoi metterlo "on-click": posso fare clic su un pulsante, eseguire il manifest e il database è pronto. Posso creare immediatamente un diagramma, iniziare a caricare le metriche lì e in 5 minuti ho una dashboard pronta graminacee. È così semplice!

Il risultato?

Così, CliccaCasa - questo è:

• rapidamente. Tutti lo sanno.
• Solo. Un po' controverso, ma credo che sia difficile nell'allenamento, facile nel combattimento. Se capisci come CliccaCasa funziona, quindi tutto è molto semplice.
• Universalmente. È adatto a diversi scenari: DWH, serie temporali, archiviazione dei log. Ma non è OLTP database, quindi non provare a fare brevi inserimenti e letture lì.
• È interessante notare che. Probabilmente quello con cui lavora CliccaCasa, ho vissuto molti momenti interessanti nel bene e nel male. Ad esempio, è uscita una nuova versione, tutto ha smesso di funzionare. Oppure quando hai avuto difficoltà con un compito per due giorni, ma dopo aver posto una domanda nella chat di Telegram, il compito è stato risolto in due minuti. O come alla conferenza sul rapporto di Lesha Milovidov, uno screenshot di CliccaCasa ha interrotto la trasmissione Gran Carico ++. Questo genere di cose accade continuamente e rende la nostra vita difficile. CliccaCasa luminoso e interessante!

Puoi guardare la presentazione qui.

Il tanto atteso incontro degli sviluppatori di sistemi ad alto carico presso Gran Carico ++ si svolgerà il 9 e 10 novembre a Skolkovo. Infine, questa sarà una conferenza offline (anche se con tutte le precauzioni in atto), poiché l'energia di HighLoad++ non può essere impacchettata online.

Per la conferenza troviamo e vi mostriamo casi sulle massime potenzialità della tecnologia: HighLoad++ era, è e sarà l'unico posto dove potrete imparare in due giorni come funzionano Facebook, Yandex, VKontakte, Google e Amazon.

Dopo aver tenuto i nostri incontri ininterrottamente dal 2007, quest'anno ci incontreremo per la 14esima volta. Durante questo periodo, la conferenza è cresciuta di 10 volte; l'anno scorso, l'evento chiave del settore ha riunito 3339 partecipanti, 165 relatori, relazioni e incontri e 16 percorsi si sono svolti contemporaneamente.
L'anno scorso c'erano 20 autobus, 5280 litri di tè e caffè, 1650 litri di bevande alla frutta e 10200 bottiglie d'acqua. E altri 2640 chilogrammi di cibo, 16 piatti e 000 bicchieri. A proposito, con i soldi raccolti dalla carta riciclata, abbiamo piantato 25 piantine di quercia :)

Puoi acquistare i biglietti qui, ricevi notizie sulla conferenza - qui, e parla su tutti i social network: Telegram, Facebook, Vkontakte и Twitter.

Fonte: habr.com