és un sistema de gestió de bases de dades de codi obert per al processament de consultes analítiques en línia (OLAP) creat per Yandex. L'utilitzen Yandex, CloudFlare, VK.com, Badoo i altres serveis d'arreu del món per emmagatzemar quantitats de dades realment grans (inserció de milers de files per segon o petabytes de dades emmagatzemades al disc).
En un SGBD de "cadena" normal, exemples dels quals són MySQL, Postgres, MS SQL Server, les dades s'emmagatzemen en aquest ordre:
En aquest cas, els valors relacionats amb una fila s'emmagatzemen físicament un al costat de l'altre. En el SGBD de columna, els valors de diferents columnes s'emmagatzemen per separat i les dades d'una columna s'emmagatzemen junts:
Alguns exemples de SGBD de columna són Vertica, Paraccel (Actian Matrix, Amazon Redshift), Sybase IQ, Exasol, Infobright, InfiniDB, MonetDB (VectorWise, Actian Vector), LucidDB, SAP HANA, Google Dremel, Google PowerDrill, Druid, kdb+.
L'empresa és un reenviador de correu Vaig començar a utilitzar Clickhouse l'any 2018 per generar informes i em va impressionar molt la seva senzillesa, escalabilitat, suport SQL i velocitat. La velocitat d'aquest SGBD va vorejar la màgia.
Facilitat
Clickhouse s'instal·la a Ubuntu amb una única comanda. Si coneixeu SQL, podeu començar immediatament a utilitzar Clickhouse per a les vostres necessitats. Tanmateix, això no vol dir que pugueu "mostrar la taula de creació" a MySQL i copiar i enganxar SQL a Clickhouse.
En comparació amb MySQL, hi ha diferències importants de tipus de dades en les definicions de l'esquema de la taula d'aquest SGBD, de manera que encara necessiteu una mica de temps per canviar les definicions de l'esquema de la taula i aprendre els motors de la taula per estar còmode.
Clickhouse funciona molt bé sense cap programari addicional, però si voleu utilitzar la replicació, haureu d'instal·lar ZooKeeper. L'anàlisi del rendiment de les consultes mostra resultats excel·lents: les taules del sistema contenen tota la informació i totes les dades es poden obtenir mitjançant SQL antic i avorrit.
Productivitat
- Comparacions de Clickhouse versus Vertica i MySQL al servidor de configuració: CPU Intel® Xeon® E5-2650 v2 de dos sockets a 2.60 GHz; 128 GiB de RAM; md RAID-5 en 8 HDD SATA de 6 TB, ext4.
- comparació de Clickhouse amb l'emmagatzematge al núvol d'Amazon RedShift.
- Fragments del blog :
La base de dades ClickHouse té un disseny molt senzill: tots els nodes del clúster tenen la mateixa funcionalitat i només utilitzen ZooKeeper per a la coordinació. Vam construir un petit clúster de diversos nodes i vam realitzar proves, durant les quals vam trobar que el sistema té un rendiment força impressionant, que correspon als avantatges reclamats en els punts de referència analítics de DBMS. Vam decidir fer una ullada més de prop al concepte darrere de ClickHouse. El primer obstacle per a la investigació va ser la manca d'eines i la petita comunitat de ClickHouse, així que vam aprofundir en el disseny d'aquest SGBD per entendre com funciona.
ClickHouse no admet rebre dades directament de Kafka, ja que només és una base de dades, així que vam escriure el nostre propi servei d'adaptadors a Go. Va llegir missatges codificats de Cap'n Proto de Kafka, els va convertir a TSV i els va inserir a ClickHouse per lots mitjançant la interfície HTTP. Més tard vam reescriure aquest servei per utilitzar la biblioteca Go juntament amb la nostra pròpia interfície ClickHouse per millorar el rendiment. En avaluar el rendiment de la recepció de paquets, vam descobrir una cosa important: va resultar que per a ClickHouse aquest rendiment depèn molt de la mida del paquet, és a dir, del nombre de files inserides al mateix temps. Per entendre per què passa això, hem estudiat com ClickHouse emmagatzema les dades.
El motor principal, o millor dit, una família de motors de taules utilitzats per ClickHouse per emmagatzemar dades, és MergeTree. Aquest motor és conceptualment similar a l'algorisme LSM utilitzat a Google BigTable o Apache Cassandra, però evita construir una taula de memòria intermèdia i escriu dades directament al disc. Això li proporciona un rendiment d'escriptura excel·lent, ja que cada paquet inserit només s'ordena per la clau primària "clau primària", es comprimeix i s'escriu al disc per formar un segment.
L'absència d'una taula de memòria o qualsevol concepte de "frescor" de les dades també fa que només es puguin afegir, el sistema no admet el canvi ni la supressió. A partir d'avui, l'única manera de suprimir dades és suprimir-les per mes natural, ja que els segments mai no creuen el límit d'un mes. L'equip de ClickHouse està treballant activament per fer que aquesta funció es pugui personalitzar. D'altra banda, fa que l'escriptura i la fusió de segments estiguin lliures de conflictes, de manera que rebeu escales de rendiment de manera lineal amb el nombre d'insercions paral·leles fins que es saturin les E/S o els nuclis.
Tanmateix, aquesta circumstància també significa que el sistema no és adequat per a paquets petits, per la qual cosa s'utilitzen els serveis i els inseridors de Kafka per a la memòria intermèdia. A més, ClickHouse en segon pla continua fusionant segments contínuament, de manera que moltes petites peces d'informació es combinaran i es gravaran més vegades, augmentant així la intensitat de l'enregistrament. Tanmateix, massa parts no relacionades provocaran una limitació agressiva de les insercions mentre la fusió continuï. Hem trobat que el millor compromís entre la ingestió de dades en temps real i el rendiment de la ingestió és acceptar un nombre limitat d'insercions per segon a la taula.
La clau per al rendiment de lectura de taules és la indexació i la ubicació de les dades al disc. Per molt ràpid que sigui el processament, quan el motor necessita escanejar terabytes de dades del disc i només utilitzar-ne una fracció, trigarà temps. ClickHouse és una botiga de columnes, de manera que cada segment conté un fitxer per a cada columna (columna) amb valors ordenats per a cada fila. Per tant, primer es poden saltar columnes senceres que no estan presents a la consulta i després es poden processar diverses cel·les en paral·lel amb l'execució vectoritzada. Per evitar una exploració completa, cada segment té un petit fitxer d'índex.
Atès que totes les columnes estan ordenades per la "clau primària", el fitxer d'índex només conté les etiquetes (files capturades) de cada fila enèsima, per tal de poder-les guardar a la memòria fins i tot per a taules molt grans. Per exemple, podeu establir la configuració predeterminada per "marcar cada fila 8192" i després la indexació "escassa" d'una taula amb 1 bilió. les línies que s'ajustin fàcilment a la memòria només prendrien 122 caràcters.
Desenvolupament del sistema
Es pot seguir el desenvolupament i la millora de Clickhouse i assegureu-vos que el procés de "créixer" està passant a un ritme impressionant.
Popularitat
Sembla que la popularitat de Clickhouse està creixent de manera exponencial, especialment a la comunitat de parla russa. La conferència High load 2018 de l'any passat (Moscou, 8-9 de novembre de 2018) va demostrar que monstres com vk.com i Badoo utilitzen Clickhouse, que insereix dades (per exemple, registres) de desenes de milers de servidors simultàniament. En un vídeo de 40 minuts . Aviat publicarem la transcripció a Habr per a la comoditat de treballar amb el material.
Aplicacions
Després de passar una estona investigant, crec que hi ha àrees on ClickHouse pot ser útil o capaç de substituir completament altres solucions més tradicionals i populars com MySQL, PostgreSQL, ELK, Google Big Query, Amazon RedShift, TimescaleDB, Hadoop, MapReduce, Pinot i Druida. A continuació es mostren els detalls de l'ús de ClickHouse per actualitzar o substituir completament el SGBD anterior.
Ampliació de MySQL i PostgreSQL
Més recentment, hem substituït parcialment MySQL per ClickHouse per a la plataforma de butlletins . El problema va ser que MySQL a causa d'un disseny mal concebut registrava cada correu electrònic enviat i cada enllaç d'aquest correu electrònic amb un hash base64, creant una taula MySQL enorme (email_stats). Després d'enviar només 10 milions de correus electrònics als subscriptors del servei, aquesta taula ocupava 150 GB d'espai de fitxers i MySQL va començar a ser "estúpid" en consultes senzilles. Per solucionar el problema de l'espai de fitxers, hem utilitzat correctament la compressió de la taula InnoDB, que la va reduir en un factor de 4. No obstant això, encara no té sentit emmagatzemar més de 20-30 milions de correus electrònics a MySQL només per llegir l'historial, ja que qualsevol consulta senzilla que per alguna raó hagi de fer una exploració completa resulta en intercanvi i E/S pesades. sobre el cap, sobre el qual rebíem regularment advertències de Zabbix.
Clickhouse utilitza dos algorismes de compressió que redueixen la quantitat de dades aproximadament , però en aquest cas concret, les dades eren especialment "comprimibles".
Substitució ELK
Segons la meva pròpia experiència, la pila ELK (ElasticSearch, Logstash i Kibana, en aquest cas concret ElasticSearch) requereix molts més recursos per executar-se dels necessaris per emmagatzemar els registres. ElasticSearch és un gran motor si voleu una bona cerca de registre de text complet (i no crec que la necessiteu), però em pregunto per què s'ha convertit en el motor de registre estàndard de facto. El seu rendiment d'ingestió, combinat amb Logstash, ens va generar problemes fins i tot amb càrregues de treball bastant lleugeres i va requerir l'addició de cada cop més memòria RAM i espai en disc. Com a base de dades, Clickhouse és millor que ElasticSearch pels motius següents:
- Suport dialectal SQL;
- El millor grau de compressió de les dades emmagatzemades;
- Suport per a la cerca Regex en lloc de la cerca de text complet;
- Millora de la programació de consultes i millor rendiment general.
Actualment, el problema més gran que sorgeix en comparar ClickHouse amb ELK és la manca de solucions per a la càrrega de registres, així com la manca de documentació i tutorials sobre aquest tema. Al mateix temps, cada usuari pot configurar ELK mitjançant el manual Digital Ocean, que és molt important per a la ràpida implementació d'aquestes tecnologies. Aquí hi ha un motor de base de dades, però encara no hi ha Filebeat per a ClickHouse. Si aquí està i un sistema per treballar amb registres , hi ha una eina per introduir dades del fitxer de registre a ClickHouse, però tot això requereix més temps. Tanmateix, ClickHouse encara lidera el camí per la seva senzillesa, de manera que fins i tot els principiants poden instal·lar-lo fàcilment i començar a utilitzar-lo completament en només 10 minuts.
Preferint solucions minimalistes, vaig intentar utilitzar FluentBit, una eina de càrrega de registres de memòria molt baixa, amb ClickHouse mentre intentava evitar utilitzar Kafka. Tanmateix, cal abordar les incompatibilitats menors, com ara abans que es pugui fer sense la capa de proxy que converteix les dades de FluentBit a ClickHouse.
Com a alternativa a Kibana, podeu utilitzar ClickHouse com a backend . Pel que tinc entès, això pot causar problemes de rendiment quan es representen un gran nombre de punts de dades, especialment amb versions anteriors de Grafana. A Qwintry, encara no ho hem provat, però les queixes al respecte apareixen de tant en tant al canal d'assistència de ClickHouse a Telegram.
Substitució de Google Big Query i Amazon RedShift (solució per a grans empreses)
El cas d'ús ideal per a BigQuery és carregar 1 TB de dades JSON i executar-hi consultes analítiques. Big Query és un gran producte la escalabilitat del qual és difícil de sobreestimar. Aquest és un programari molt més complex que ClickHouse que s'executa en un clúster intern, però des del punt de vista del client, té molt en comú amb ClickHouse. BigQuery pot "augmentar el preu" ràpidament un cop comenceu a pagar per cada SELECT, de manera que és una solució SaaS real amb tots els seus avantatges i contres.
ClickHouse és la millor opció quan executeu moltes consultes computacionalment costoses. Com més consultes SELECT realitzeu cada dia, més sentit tindrà substituir Big Query per ClickHouse, perquè aquesta substitució us estalviarà milers de dòlars quan es processin molts terabytes de dades. Això no s'aplica a les dades emmagatzemades, que és bastant barat de processar a Big Query.
En un article d'Alexander Zaitsev, cofundador d'Altinity descriu els avantatges d'aquesta migració de SGBD.
Substitució de TimescaleDB
TimescaleDB és una extensió PostgreSQL que optimitza el treball amb sèries temporals en una base de dades normal (, ).
Tot i que ClickHouse no és un competidor seriós en el nínxol de sèries temporals, però pel que fa a l'estructura columnar i l'execució de consultes vectorials, és molt més ràpid que TimescaleDB en la majoria dels casos de processament de consultes analítiques. Al mateix temps, el rendiment de la recepció de dades de paquets ClickHouse és aproximadament 3 vegades més gran, a més, utilitza 20 vegades menys espai en disc, la qual cosa és realment important per processar grans volums de dades històriques: .
A diferència de ClickHouse, l'única manera d'estalviar una mica d'espai al disc a TimescaleDB és utilitzar ZFS o sistemes de fitxers similars.
Les properes actualitzacions de ClickHouse probablement introduiran la compressió delta, cosa que la farà encara més adequada per processar i emmagatzemar dades de sèries temporals. TimescaleDB pot ser una millor opció que ClickHouse nua en els casos següents:
- petites instal·lacions amb molt poca memòria RAM (<3 GB);
- un gran nombre d'insercions petites que no voleu emmagatzemar en fragments grans;
- millor consistència, uniformitat i requisits d'ÀCID;
- suport PostGIS;
- combinar-se amb les taules PostgreSQL existents, ja que Timescale DB és essencialment PostgreSQL.
Competència amb els sistemes Hadoop i MapReduce
Hadoop i altres productes MapReduce poden realitzar molts càlculs complexos, però solen executar-se amb una latència enorme. ClickHouse soluciona aquest problema processant terabytes de dades i produint resultats gairebé a l'instant. Per tant, ClickHouse és molt més eficient per dur a terme una investigació analítica ràpida i interactiva, que hauria de ser d'interès per als científics de dades.
Competició amb Pinot i Druida
Els competidors més propers de ClickHouse són els productes de codi obert columnars i escalables linealment Pinot i Druid. A l'article es publica un treball excel·lent comparant aquests sistemes 1 de febrer de 2018
Aquest article s'ha d'actualitzar: diu que ClickHouse no admet les operacions d'ACTUALITZACIÓ i DELETE, cosa que no és del tot cert en relació a les últimes versions.
No tenim molta experiència amb aquests SGBD, però no m'agrada la complexitat de la infraestructura subjacent que es requereix per executar Druid i Pinot: són un munt de "parts mòbils" envoltades de Java des de tots els costats.
Druid i Pinot són projectes d'incubadores d'Apache, que Apache tracta amb detall a les seves pàgines de projectes GitHub. Pinot va aparèixer a la incubadora l'octubre de 2018 i Druid va néixer 8 mesos abans, al febrer.
La manca d'informació sobre com funciona AFS em planteja algunes preguntes, i potser estúpides. Em pregunto si els autors de Pinot es van adonar que la Fundació Apache està més disposada al Druid, i aquesta actitud cap a un competidor va causar un sentiment d'enveja? El desenvolupament de Druid es frenarà i el desenvolupament de Pinot s'accelerarà si els patrocinadors que donen suport al primer de sobte s'interessen pel segon?
Desavantatges de ClickHouse
Immaduresa: òbviament, aquesta encara és una tecnologia avorrida, però en qualsevol cas, no es veu res semblant a altres DBMS columnars.
Les insercions petites no funcionen bé a alta velocitat: les insercions s'han de dividir en trossos grans perquè el rendiment de les insercions petites es degrada en proporció al nombre de columnes de cada fila. Així és com ClickHouse emmagatzema les dades al disc: cada columna significa 1 fitxer o més, de manera que per inserir 1 fila que contingui 100 columnes, cal obrir i escriure almenys 100 fitxers. És per això que la memòria intermèdia d'inserció requereix un intermediari (tret que el propi client proporcioni la memòria intermèdia), normalment Kafka o algun tipus de sistema de cua. També podeu utilitzar el motor de taules de memòria intermèdia per copiar posteriorment grans blocs de dades a les taules MergeTree.
Les unions de taules estan limitades per la memòria RAM del servidor, però almenys hi són! Per exemple, Druid i Pinot no tenen aquestes connexions en absolut, ja que són difícils d'implementar directament en sistemes distribuïts que no admeten el moviment de grans blocs de dades entre nodes.
Troballes
En els propers anys, tenim previst fer un ús extensiu de ClickHouse a Qwintry, ja que aquest SGBD ofereix un excel·lent equilibri de rendiment, baixa sobrecàrrega, escalabilitat i simplicitat. Estic bastant segur que es propagarà ràpidament un cop la comunitat ClickHouse tingui més maneres d'utilitzar-lo en instal·lacions petites i mitjanes.
Alguns anuncis 🙂
Gràcies per quedar-te amb nosaltres. T'agraden els nostres articles? Vols veure més contingut interessant? Doneu-nos suport fent una comanda o recomanant als amics, , un anàleg únic dels servidors d'entrada, que vam inventar per a vosaltres: (disponible amb RAID1 i RAID10, fins a 24 nuclis i fins a 40 GB DDR4).
Dell R730xd 2 vegades més barat al centre de dades Equinix Tier IV a Amsterdam? Només aquí als Països Baixos! Dell R420 - 2x E5-2430 2.2 Ghz 6C 128 GB DDR3 2 x 960 GB SSD 1 Gbps 100 TB - a partir de 99 $! Llegeix sobre
Font: www.habr.com