è un sistema di gestione di database colonnare open source per l'elaborazione di query analitiche online (OLAP), creato da Yandex. Viene utilizzato da Yandex, CloudFlare, VK.com, Badoo e altri servizi in tutto il mondo per archiviare quantità di dati davvero grandi (inserendo migliaia di righe al secondo o petabyte di dati archiviati su disco).
In un normale DBMS "stringa", di cui esempi sono MySQL, Postgres, MS SQL Server, i dati vengono archiviati nel seguente ordine:
In questo caso, i valori relativi a una riga vengono archiviati fisicamente nelle vicinanze. Nei DBMS a colonne, i valori di diverse colonne vengono archiviati separatamente e i dati di una colonna vengono archiviati insieme:
Esempi di DBMS a colonne sono Vertica, Paraccel (Actian Matrix, Amazon Redshift), Sybase IQ, Exasol, Infobright, InfiniDB, MonetDB (VectorWise, Actian Vector), LucidDB, SAP HANA, Google Dremel, Google PowerDrill, Druid, kdb+.
Azienda di spedizioni postali ha iniziato a utilizzare Clickhouse nel 2018 per il reporting e è rimasto molto colpito dalla sua semplicità, scalabilità, supporto SQL e velocità. La velocità di questo DBMS rasentava la magia.
Alleviare
Clickhouse si installa su Ubuntu con un solo comando. Se conosci SQL, puoi iniziare subito a utilizzare Clickhouse per le tue esigenze. Tuttavia, questo non significa che puoi fare “mostra crea tabella” in MySQL e copia e incolla l’SQL in Clickhouse.
Rispetto a MySQL, ci sono importanti differenze del tipo di dati nelle definizioni dello schema delle tabelle, quindi avrai ancora bisogno di un po' di tempo per modificare le definizioni dello schema delle tabelle e apprendere i motori delle tabelle per familiarizzare.
Clickhouse funziona perfettamente senza software aggiuntivo, ma se desideri utilizzare la replica, dovrai installare ZooKeeper. L'analisi delle prestazioni delle query mostra risultati eccellenti: le tabelle di sistema contengono tutte le informazioni e tutti i dati possono essere recuperati utilizzando il vecchio e noioso SQL.
Производительность
- confronti di Clickhouse con Vertica e MySQL sulla configurazione del server: due socket Intel® Xeon® CPU E5-2650 v2 @ 2.60GHz; RAM da 128 GiB; md RAID-5 su HDD SATA da 8 6TB, ext4.
- confronto tra Clickhouse e lo storage cloud di Amazon RedShift.
- Estratti dal blog :
Il database ClickHouse ha un design molto semplice: tutti i nodi del cluster hanno le stesse funzionalità e utilizzano ZooKeeper solo per il coordinamento. Abbiamo creato un piccolo cluster di diversi nodi ed eseguito test, durante i quali abbiamo scoperto che il sistema ha prestazioni piuttosto impressionanti, che corrispondono ai vantaggi dichiarati nei benchmark analitici DBMS. Abbiamo deciso di dare un'occhiata più da vicino al concetto alla base di ClickHouse. Il primo ostacolo alla ricerca è stata la mancanza di strumenti e la piccola comunità di ClickHouse, quindi abbiamo approfondito la progettazione di questo DBMS per capire come funziona.
ClickHouse non supporta la ricezione di dati direttamente da Kafka poiché è solo un database, quindi abbiamo scritto il nostro servizio adattatore in Go. Leggeva i messaggi codificati di Cap'n Proto da Kafka, li convertiva in TSV e li inserirà in ClickHouse in batch tramite l'interfaccia HTTP. Successivamente abbiamo riscritto questo servizio per utilizzare la libreria Go insieme all'interfaccia di ClickHouse per migliorare le prestazioni. Valutando le prestazioni di ricezione dei pacchetti, abbiamo scoperto una cosa importante: si è scoperto che per ClickHouse questa prestazione dipende fortemente dalla dimensione del pacchetto, ovvero dal numero di righe inserite contemporaneamente. Per capire perché ciò accade, abbiamo esaminato il modo in cui ClickHouse archivia i dati.
Il motore principale, o meglio la famiglia di motori di tabelle, utilizzato da ClickHouse per archiviare i dati è MergeTree. Questo motore è concettualmente simile all'algoritmo LSM utilizzato in Google BigTable o Apache Cassandra, ma evita di costruire una tabella di memoria intermedia e scrive i dati direttamente su disco. Ciò garantisce un eccellente throughput di scrittura, poiché ogni pacchetto inserito viene ordinato solo in base alla chiave primaria, compresso e scritto su disco per formare un segmento.
L'assenza di una tabella di memoria o di qualsiasi concetto di “freschezza” dei dati significa anche che possono solo essere aggiunti; il sistema non supporta la modifica o la cancellazione. Attualmente, l'unico modo per eliminare i dati è eliminarli per mese di calendario, poiché i segmenti non oltrepassano mai il limite del mese. Il team di ClickHouse sta lavorando attivamente per rendere questa funzionalità personalizzabile. D'altro canto, rende la scrittura e l'unione dei segmenti esenti da conflitti, quindi il throughput di ricezione scala linearmente con il numero di inserimenti simultanei finché non si verifica la saturazione dell'I/O o del core.
Ciò significa però anche che il sistema non è adatto a pacchetti di piccole dimensioni, quindi per il buffering vengono utilizzati i servizi e gli inseritori Kafka. Successivamente, ClickHouse in background continua ad eseguire costantemente la fusione dei segmenti, in modo che tante piccole informazioni vengano combinate e registrate più volte, aumentando così l'intensità della registrazione. Tuttavia, troppe parti non collegate causeranno una forte limitazione degli inserti finché l'unione continua. Abbiamo scoperto che il miglior compromesso tra l'acquisizione in tempo reale e le prestazioni di acquisizione è quello di inserire nella tabella un numero limitato di inserimenti al secondo.
La chiave per le prestazioni di lettura della tabella è l'indicizzazione e la posizione dei dati sul disco. Non importa quanto sia veloce l'elaborazione, quando il motore deve scansionare terabyte di dati dal disco e utilizzarne solo una parte, ci vorrà del tempo. ClickHouse è un negozio a colonne, quindi ogni segmento contiene un file per ogni colonna (colonna) con valori ordinati per ogni riga. In questo modo, è possibile prima ignorare intere colonne mancanti nella query e quindi elaborare più celle in parallelo con l'esecuzione vettorizzata. Per evitare una scansione completa, ogni segmento ha un piccolo file indice.
Dato che tutte le colonne sono ordinate in base alla “chiave primaria”, il file indice contiene solo le etichette (righe catturate) di ogni N-esima riga per poterle mantenere in memoria anche per tabelle molto grandi. Ad esempio, è possibile impostare le impostazioni predefinite su "contrassegnare ogni 8192a riga", quindi sull'indicizzazione "scarsa" di una tabella con 1 trilione. le righe che si adattano facilmente alla memoria occuperanno solo 122 caratteri.
Sistema di sviluppo
Lo sviluppo e il miglioramento di Clickhouse possono essere rintracciati su e assicurarsi che il processo di “crescita” avvenga a un ritmo impressionante.
Popolarità
La popolarità di Clickhouse sembra crescere in modo esponenziale, soprattutto nella comunità di lingua russa. La conferenza High load 2018 dell'anno scorso (Mosca, 8-9 novembre 2018) ha mostrato che mostri come vk.com e Badoo utilizzano Clickhouse, con cui inseriscono dati (ad esempio log) da decine di migliaia di server contemporaneamente. In un video di 40 minuti . Presto pubblicheremo la trascrizione su Habr per facilitare il lavoro con il materiale.
applicazioni
Dopo aver dedicato un po' di tempo alla ricerca, penso che ci siano aree in cui ClickHouse potrebbe essere utile o sostituire completamente altre soluzioni più tradizionali e popolari come MySQL, PostgreSQL, ELK, Google Big Query, Amazon RedShift, TimescaleDB, Hadoop, MapReduce, Pinot e Druido. Di seguito vengono descritti i dettagli sull'utilizzo di ClickHouse per modernizzare o sostituire completamente il DBMS di cui sopra.
Estensione delle funzionalità di MySQL e PostgreSQL
Proprio di recente abbiamo parzialmente sostituito MySQL con ClickHouse per la nostra piattaforma di newsletter . Il problema era che MySQL, a causa di una progettazione scadente, registrava ogni email inviata e ogni collegamento in quell'email con un hash base64, creando un'enorme tabella MySQL (email_stats). Dopo aver inviato solo 10 milioni di e-mail agli abbonati al servizio, questa tabella occupava 150 GB di spazio file e MySQL ha iniziato a essere "stupido" con query semplici. Per risolvere il problema dello spazio file, abbiamo utilizzato con successo la compressione della tabella InnoDB che lo ha ridotto di un fattore 4. Tuttavia, non ha ancora senso archiviare più di 20-30 milioni di email in MySQL solo per il gusto di leggere la cronologia, dal momento che qualsiasi semplice query che per qualche motivo necessita di una scansione completa risulta in swap e molti errori /O load, in base al quale abbiamo ricevuto regolarmente avvisi da Zabbix.
Clickhouse utilizza due algoritmi di compressione che riducono approssimativamente il volume dei dati , ma in questo caso particolare i dati erano particolarmente “comprimibili”.
Sostituzione dell'ELK
In base alla mia esperienza, lo stack ELK (ElasticSearch, Logstash e Kibana, in questo caso particolare ElasticSearch) richiede molte più risorse per l'esecuzione di quelle necessarie per archiviare i log. ElasticSearch è un ottimo motore se hai bisogno di una buona ricerca di log full-text (di cui non credo che tu abbia realmente bisogno), ma mi chiedo perché sia diventato di fatto il motore di registrazione standard. Le sue prestazioni di acquisizione combinate con Logstash ci hanno dato problemi anche con carichi abbastanza leggeri e ci hanno richiesto di aggiungere sempre più RAM e spazio su disco. Come database, Clickhouse è migliore di ElasticSearch per i seguenti motivi:
- Supporto dialetto SQL;
- Il miglior grado di compressione dei dati archiviati;
- Supporto per ricerche di espressioni regolari Regex invece di ricerche di testo completo;
- Pianificazione delle query migliorata e prestazioni complessive più elevate.
Attualmente, il problema più grande che si presenta quando si confronta ClickHouse con ELK è la mancanza di soluzioni per caricare i log, nonché la mancanza di documentazione e tutorial sull’argomento. Inoltre, ogni utente può configurare ELK utilizzando il manuale Digital Ocean, che è molto importante per la rapida implementazione di tali tecnologie. Esiste un motore di database, ma non esiste ancora Filebeat per ClickHouse. Sì, è lì e un sistema per lavorare con i log , c'è uno strumento per inserire i dati del file di registro in ClickHouse, ma tutto ciò richiede più tempo. Tuttavia, ClickHouse è ancora il leader grazie alla sua semplicità, quindi anche i principianti possono installarlo facilmente e iniziare a utilizzarlo in modo completamente funzionale in soli 10 minuti.
Preferendo soluzioni minimaliste, ho provato a utilizzare FluentBit, uno strumento per la spedizione di log con pochissima memoria, insieme a ClickHouse, cercando di evitare l'uso di Kafka. Tuttavia, è necessario risolvere piccole incompatibilità, come ad esempio prima che ciò possa essere fatto senza il livello proxy che converte i dati da FluentBit a ClickHouse.
In alternativa, Kibana può essere utilizzato come backend ClickHouse . Da quanto ho capito, ciò può causare problemi di prestazioni durante il rendering di un numero enorme di punti dati, soprattutto con le versioni precedenti di Grafana. Non l'abbiamo ancora provato su Qwintry, ma di tanto in tanto compaiono reclami al riguardo sul canale di supporto ClickHouse in Telegram.
Sostituzione di Google Big Query e Amazon RedShift (soluzione per grandi aziende)
Il caso d'uso ideale per BigQuery è caricare 1 TB di dati JSON ed eseguire query analitiche su di essi. Big Query è un prodotto eccellente la cui scalabilità non può essere sopravvalutata. Si tratta di un software molto più complesso di ClickHouse, che gira su un cluster interno, ma dal punto di vista del cliente ha molto in comune con ClickHouse. BigQuery può diventare rapidamente costoso una volta che inizi a pagare per SELECT, quindi è una vera soluzione SaaS con tutti i suoi pro e contro.
ClickHouse è la scelta migliore quando si eseguono molte query computazionalmente costose. Più query SELECT esegui ogni giorno, più ha senso sostituire Big Query con ClickHouse, perché tale sostituzione può farti risparmiare migliaia di dollari quando si tratta di molti terabyte di dati da elaborare. Ciò non si applica ai dati archiviati, che sono piuttosto economici da elaborare in Big Query.
In un articolo del co-fondatore di Altinity, Alexander Zaitsev parla dei vantaggi di una tale migrazione DBMS.
Sostituzione TimescaleDB
TimescaleDB è un'estensione PostgreSQL che ottimizza il lavoro con le serie temporali in un database normale (, ).
Sebbene ClickHouse non sia un serio concorrente nella nicchia delle serie temporali, ma nella struttura colonnare e nell'esecuzione di query vettoriali, è molto più veloce di TimescaleDB nella maggior parte dei casi di elaborazione di query analitiche. Allo stesso tempo, le prestazioni di ricezione di dati batch da ClickHouse sono circa 3 volte superiori e utilizzano anche 20 volte meno spazio su disco, il che è davvero importante per l'elaborazione di grandi volumi di dati storici: .
A differenza di ClickHouse, l'unico modo per risparmiare spazio su disco in TimescaleDB è utilizzare ZFS o file system simili.
I prossimi aggiornamenti di ClickHouse introdurranno probabilmente la compressione delta, che lo renderà ancora più adatto all'elaborazione e all'archiviazione di dati di serie temporali. TimescaleDB può essere una scelta migliore rispetto a ClickHouse semplice nei seguenti casi:
- piccole installazioni con pochissima RAM (<3 GB);
- un gran numero di piccoli INSERT che non si desidera bufferizzare in frammenti di grandi dimensioni;
- migliore consistenza, uniformità e requisiti di ACIDO;
- supporto PostGIS;
- unendosi alle tabelle PostgreSQL esistenti, poiché Timescale DB è essenzialmente PostgreSQL.
Concorrenza con i sistemi Hadoop e MapReduce
Hadoop e altri prodotti MapReduce possono eseguire molti calcoli complessi, ma tendono a funzionare con enormi latenze. ClickHouse risolve questo problema elaborando terabyte di dati e producendo risultati quasi istantaneamente. Pertanto, ClickHouse è molto più efficace nell'eseguire ricerche analitiche veloci e interattive, che dovrebbero interessare i data scientist.
Gara con Pinot e Druido
I concorrenti più vicini di ClickHouse sono i prodotti open source colonnari e linearmente scalabili Pinot e Druid. Un ottimo lavoro che confronta questi sistemi è pubblicato nell'articolo 1 Febbraio 2018
Questo articolo necessita di un aggiornamento: dice che ClickHouse non supporta le operazioni UPDATE e DELETE, il che non è del tutto vero per le ultime versioni.
Non abbiamo molta esperienza con questi database, ma non mi piace molto la complessità dell'infrastruttura richiesta per eseguire Druid e Pinot: è un insieme di parti mobili circondate da Java su tutti i lati.
Druid e Pinot sono progetti incubatori di Apache, il cui progresso è trattato in dettaglio da Apache nelle pagine del progetto GitHub. Pinot è apparso nell'incubatrice nell'ottobre 2018 e Druid è nato 8 mesi prima, a febbraio.
La mancanza di informazioni su come funziona AFS mi solleva alcune domande, forse stupide. Mi chiedo se gli autori di Pinot abbiano notato che la Fondazione Apache è più favorevole nei confronti di Druid e se questo atteggiamento nei confronti del concorrente abbia causato un sentimento di invidia? Lo sviluppo di Druid rallenterà e quello di Pinot accelererà se i sostenitori del primo si interessassero improvvisamente al secondo?
Svantaggi di ClickHouse
Immaturità: ovviamente non si tratta ancora di una tecnologia noiosa, ma in ogni caso non si osserva nulla di simile in altri DBMS a colonne.
Gli inserti piccoli non funzionano bene ad alta velocità: gli inserti devono essere divisi in blocchi più grandi perché le prestazioni degli inserti piccoli peggiorano in proporzione al numero di colonne in ciascuna riga. Ecco come ClickHouse memorizza i dati sul disco: ogni colonna rappresenta 1 file o più, quindi per inserire 1 riga contenente 100 colonne, è necessario aprire e scrivere almeno 100 file. Questo è il motivo per cui gli inserti di buffering richiedono un intermediario (a meno che il client stesso non fornisca il buffering), solitamente Kafka o qualche tipo di sistema di gestione delle code. Puoi anche utilizzare il motore delle tabelle Buffer per copiare successivamente grandi blocchi di dati nelle tabelle MergeTree.
Le unioni di tabelle sono limitate dalla RAM del server, ma almeno ci sono! Ad esempio, Druid e Pinot non dispongono affatto di tali connessioni, poiché sono difficili da implementare direttamente in sistemi distribuiti che non supportano lo spostamento di grandi quantità di dati tra i nodi.
risultati
Prevediamo di utilizzare ampiamente ClickHouse in Qwintry nei prossimi anni, poiché questo DBMS offre un eccellente equilibrio tra prestazioni, costi generali ridotti, scalabilità e semplicità. Sono abbastanza sicuro che inizierà a diffondersi rapidamente una volta che la community di ClickHouse troverà più modi per utilizzarlo in installazioni di piccole e medie dimensioni.
Alcuni annunci 🙂
Grazie per stare con noi. Ti piacciono i nostri articoli? Vuoi vedere contenuti più interessanti? Sostienici effettuando un ordine o raccomandando agli amici, , un analogo unico dei server entry-level, che è stato inventato da noi per te: (disponibile con RAID1 e RAID10, fino a 24 core e fino a 40 GB DDR4).
Dell R730xd 2 volte più economico nel data center Equinix Tier IV ad Amsterdam? Solo qui In Olanda! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - da $99! Leggi
Fonte: habr.com