is in iepen boarne kolomsysteem foar databasebehear foar online analytyske query-ferwurking (OLAP), makke troch Yandex. It wurdt brûkt troch Yandex, CloudFlare, VK.com, Badoo en oare tsjinsten om 'e wrâld om echt grutte hoemannichten gegevens op te slaan (tûzenen rigen per sekonde ynfoegje of petabytes oan gegevens opslein op skiif).
Yn in gewoane "string" DBMS, foarbylden dêrfan binne MySQL, Postgres, MS SQL Server, wurde gegevens opslein yn 'e folgjende folchoarder:
Yn dit gefal wurde wearden relatearre oan ien rige fysyk yn 'e buert opslein. Yn kolomêre DBMS's wurde wearden fan ferskate kolommen apart opslein, en gegevens fan ien kolom wurde tegearre opslein:
Foarbylden fan columnar DBMS's binne Vertica, Paraccel (Actian Matrix, Amazon Redshift), Sybase IQ, Exasol, Infobright, InfiniDB, MonetDB (VectorWise, Actian Vector), LucidDB, SAP HANA, Google Dremel, Google PowerDrill, Druid, kdb+.
Mail forwarder bedriuw begon Clickhouse te brûken yn 2018 foar rapportaazje en wie tige ûnder de yndruk fan syn ienfâld, skalberens, SQL-stipe en snelheid. De snelheid fan dizze DBMS grinzet oan magy.
gemak
Clickhouse is ynstalleare op Ubuntu mei ien inkeld kommando. As jo SQL kenne, kinne jo fuortendaliks begjinne mei it brûken fan Clickhouse foar jo behoeften. Dit betsjut lykwols net dat jo "tabel oanmeitsje sjen litte" kinne dwaan yn MySQL en de SQL kopiearje en plakke yn Clickhouse.
Yn ferliking mei MySQL binne d'r wichtige ferskillen fan gegevenstype yn 'e tabelskema-definysjes, dus jo sille noch wat tiid nedich wêze om de tabelskema-definysjes te feroarjen en de tabelmotoren te learen om noflik te wurden.
Clickhouse wurket geweldich sûnder ekstra software, mar as jo replikaasje wolle brûke, moatte jo ZooKeeper ynstallearje. Analyse fan queryprestaasjes toant poerbêste resultaten - de systeemtabellen befetsje alle ynformaasje, en alle gegevens kinne wurde ophelle mei âlde en saaie SQL.
Produktiviteit
- fergelikingen fan Clickhouse mei Vertica en MySQL op de tsjinner konfiguraasje: twa sockets Intel® Xeon® CPU E5-2650 v2 @ 2.60GHz; 128 GiB RAM; md RAID-5 op 8 6TB SATA HDD, ext4.
- ferliking fan Clickhouse mei Amazon RedShift wolk opslach.
- Blog úttreksels :
De ClickHouse-database hat in heul ienfâldich ûntwerp - alle knooppunten yn it kluster hawwe deselde funksjonaliteit en brûke allinich ZooKeeper foar koördinaasje. Wy bouden in lyts kluster fan ferskate knooppunten en hawwe testen útfierd, wêryn't wy fûnen dat it systeem frijwat yndrukwekkende prestaasjes hat, wat oerienkomt mei de neamde foardielen yn analytyske DBMS-benchmarks. Wy besletten om it konsept efter ClickHouse in tichterby te besjen. It earste obstakel foar ûndersyk wie it gebrek oan ark en de lytse ClickHouse-mienskip, dus wy dûken yn it ûntwerp fan dizze DBMS om te begripen hoe't it wurket.
ClickHouse stipet gjin direkt ûntfangen fan gegevens fan Kafka, om't it gewoan in databank is, dus skreaunen wy ús eigen adaptertsjinst yn Go. It lêzen Cap'n Proto kodearre berjochten fan Kafka, konvertearre se nei TSV en ynfoege se yn ClickHouse yn batches fia de HTTP-ynterface. Wy hawwe letter dizze tsjinst opnij skreaun om de Go-bibleteek te brûken yn kombinaasje mei de eigen ynterface fan ClickHouse om prestaasjes te ferbetterjen. By it evaluearjen fan de prestaasjes fan it ûntfangen fan pakketten ûntdutsen wy in wichtich ding - it die bliken dat dizze prestaasje foar ClickHouse sterk hinget fan 'e grutte fan it pakket, dat is, it oantal tagelyk ynfoege rigen. Om te begripen wêrom dit bart, hawwe wy sjoen nei hoe't ClickHouse gegevens opslaat.
De haadmotor, of leaver famylje fan tabelmotoren, brûkt troch ClickHouse om gegevens op te slaan is MergeTree. Dizze motor is konseptueel fergelykber mei it LSM-algoritme brûkt yn Google BigTable of Apache Cassandra, mar foarkomt it bouwen fan in tuskenlizzende ûnthâldtabel en skriuwt gegevens direkt op skiif. Dit jout it poerbêste skriuwtrochput, om't elk ynfoege pakket allinich wurdt sorteare troch de primêre kaai, komprimearre en skreaun nei skiif om in segmint te foarmjen.
It ûntbrekken fan in ûnthâldtabel of in konsept fan "frisheid" fan gegevens betsjut ek dat se allinich kinne wurde tafoege; it systeem stipet gjin wizigjen of wiskjen. Op it stuit is de ienige manier om gegevens te wiskjen it per kalindermoanne te wiskjen, om't segminten noait in moannegrins oerstekke. It ClickHouse-team wurket aktyf om dizze funksje oanpasber te meitsjen. Oan 'e oare kant makket it skriuw- en gearfoegje segminten konfliktfrij, dus ûntfange trochstreamskalen lineêr mei it oantal tagelyk ynserts oant I/O as kearnferzadiging optreedt.
Dit betsjut lykwols ek dat it systeem net geskikt is foar lytse pakketten, sadat Kafka-tsjinsten en ynstekkers brûkt wurde foar buffering. Folgjende, ClickHouse op 'e eftergrûn bliuwt konstant it gearfoegjen fan segmenten út te fieren, sadat in protte lytse stikjes ynformaasje sille wurde kombinearre en mear kearen opnommen, sadat de opnameintensiteit ferheget. Tefolle net-ferbûne dielen sille lykwols agressive throttling fan ynserts feroarsaakje, salang't de fúzje trochgiet. Wy hawwe fûn dat it bêste kompromis tusken realtime ynname en yntakprestaasjes is om in beheind oantal ynserts per sekonde yn 'e tabel te nimmen.
De kaai foar tabellêsprestaasjes is yndeksearring en de lokaasje fan de gegevens op skiif. Nettsjinsteande hoe fluch de ferwurking is, as de motor terabytes oan gegevens fan 'e skiif moat scannen en allinich in diel dêrfan brûke, sil it tiid nimme. ClickHouse is in kolomwinkel, dus elk segmint befettet in bestân foar elke kolom (kolom) mei sorteare wearden foar elke rige. Op dizze manier kinne folsleine kolommen dy't ûntbrekke yn 'e query earst wurde oerslein, en dan kinne meardere sellen parallel wurde ferwurke mei vectorisearre útfiering. Om in folsleine scan te foarkommen, hat elk segmint in lyts yndeksbestân.
Mei it each op dat alle kolommen wurde sortearre troch de "primêre kaai", de yndeks triem befettet allinnich de labels (fongen rigen) fan elke Nde rige te kinnen hâlden se yn it ûnthâld sels foar hiel grutte tabellen. Jo kinne bygelyks de standertynstellingen ynstelle om "elke 8192nd rige te markearjen", dan "meager" yndeksearring fan in tabel mei 1 trillion. rigels dy't passe maklik yn it ûnthâld sil nimme allinne 122 tekens.
Systeemûntwikkeling
De ûntwikkeling en ferbettering fan Clickhouse is te folgjen op en soargje derfoar dat it proses fan "opgroeie" komt yn in yndrukwekkend tempo.
Popularity
De populariteit fan Clickhouse liket eksponentieel te groeien, benammen yn 'e Russysktalige mienskip. Ferline jier High load 2018 konferinsje (Moskou, 8-9 novimber 2018) liet sjen dat sokke meunsters as vk.com en Badoo Clickhouse brûke, wêrmei't se gegevens ynfoegje (bygelyks logs) fan tsientûzenen servers tagelyk. Yn in fideo fan 40 minuten . Meikoarten sille wy it transkripsje op Habr pleatse foar it gemak fan wurkjen mei it materiaal.
Applikaasjes
Nei't ik wat tiid bestege oan it ûndersykjen, tink ik dat d'r gebieten binne wêr't ClickHouse nuttich kin wêze of oare, mear tradisjonele en populêre oplossingen folslein kinne ferfange, lykas MySQL, PostgreSQL, ELK, Google Big Query, Amazon RedShift, TimescaleDB, Hadoop, MapReduce, Pinot en Druid. It folgjende beskriuwt de details fan it brûken fan ClickHouse om de boppesteande DBMS te modernisearjen of folslein te ferfangen.
It útwreidzjen fan de mooglikheden fan MySQL en PostgreSQL
Krekt koartlyn hawwe wy MySQL foar in part ferfongen troch ClickHouse foar ús nijsbriefplatfoarm . It probleem wie dat MySQL, fanwegen in min ûntwerp, elke ferstjoerde e-post en elke keppeling yn dy e-post oanmelde mei in base64-hash, wêrtroch in enoarme MySQL-tabel makke (email_stats). Nei it ferstjoeren fan mar 10 miljoen e-mails nei tsjinstabonnees, besette dizze tabel 150 GB fan triemromte, en MySQL begon "dom" te wêzen op ienfâldige fragen. Om it probleem fan bestânromte te reparearjen, hawwe wy mei súkses InnoDB-tabelkompresje brûkt dy't it mei in faktor fan 4 fermindere. It hat lykwols noch gjin sin om mear dan 20-30 miljoen e-mails yn MySQL op te slaan, allinich om 'e skiednis te lêzen, om't elke ienfâldige fraach dy't om ien of oare reden in folsleine scan moat dwaan resultearret yn ruil en in protte I /O load, neffens dêr't wy geregeld krigen warskôgings út Zabbix.
Clickhouse brûkt twa kompresje-algoritmen dy't it gegevensvolume mei sawat ferminderje , mar yn dit bysûndere gefal de gegevens wiene benammen "compressible".
It ferfangen fan ELK
Op grûn fan myn eigen ûnderfining fereasket de ELK-stapel (ElasticSearch, Logstash en Kibana, yn dit bysûndere gefal ElasticSearch) folle mear boarnen om te rinnen dan nedich is om logs op te slaan. ElasticSearch is in geweldige motor as jo in goede foltekst-logsykjen nedich binne (wat ik tink net dat jo echt nedich binne), mar ik freegje my ôf wêrom't it de de facto standert loggingmotor wurden is. De ynnameprestaasjes kombineare mei Logstash joech ús problemen sels ûnder frij lichte loads en easke ús om mear en mear RAM en skiifromte ta te foegjen. As database is Clickhouse better dan ElasticSearch om de folgjende redenen:
- SQL dialekt stipe;
- De bêste graad fan kompresje fan bewarre gegevens;
- Stipe foar sykopdrachten foar reguliere ekspresje fan Regex ynstee fan sykopdrachten mei folsleine tekst;
- Ferbettere query scheduling en hegere totale prestaasjes.
Op it stuit is it grutste probleem dat ûntstiet by it fergelykjen fan ClickHouse mei ELK it gebrek oan oplossings foar it uploaden fan logs, lykas ek it gebrek oan dokumintaasje en tutorials oer it ûnderwerp. Boppedat kin elke brûker ELK konfigurearje mei it Digital Ocean-hantlieding, wat heul wichtich is foar de rappe ymplemintaasje fan sokke technologyen. D'r is in databankmotor, mar d'r is noch gjin Filebeat foar ClickHouse. Ja, it is der en in systeem foar wurkjen mei logs , der is in ark om logtriemgegevens yn ClickHouse yn te fieren, mar dit alles nimt mear tiid. ClickHouse is lykwols noch altyd de lieder troch syn ienfâld, dus sels begjinners kinne it maklik ynstallearje en begjinne folslein funksjoneel te brûken yn mar 10 minuten.
De foarkar fan minimalistyske oplossingen besocht ik FluentBit te brûken, in ark foar it ferstjoeren fan logs mei heul lyts ûnthâld, tegearre mei ClickHouse, wylst ik besocht Kafka te brûken. Lytse ynkompatibiliteiten moatte lykwols oanpakt wurde, lykas foardat dit kin dien wurde sûnder de proxy-laach dy't de gegevens konvertearret fan FluentBit nei ClickHouse.
As alternatyf kin Kibana brûkt wurde as ClickHouse-backend . Fan wat ik begryp, kin dit prestaasjesproblemen feroarsaakje by it werjaan fan enoarme oantallen gegevenspunten, foaral mei âldere ferzjes fan Grafana. Wy hawwe dit noch net besocht by Qwintry, mar klachten hjiroer ferskine fan tiid ta tiid op it ClickHouse-stipekanaal yn Telegram.
Ferfanging fan Google Big Query en Amazon RedShift (oplossing foar grutte bedriuwen)
De ideale gebrûksgefal foar BigQuery is om 1 TB fan JSON-gegevens te laden en analytyske queries derop út te fieren. Big Query is in poerbêst produkt wêrfan de skalberens net te heech wurde kin. Dit is folle kompleksere software as ClickHouse, dy't rint op in ynterne kluster, mar út it eachpunt fan 'e kliïnt hat it in protte mienskiplik mei ClickHouse. BigQuery kin fluch djoer wurde as jo ienris begjinne te beteljen per SELECT, dus it is in echte SaaS-oplossing mei al syn foar- en neidielen.
ClickHouse is de bêste kar as jo in protte komputerysk djoere fragen útfiere. Hoe mear SELECT-fragen jo elke dei útfiere, hoe mear it makket om Big Query te ferfangen troch ClickHouse, om't sa'n ferfanging jo tûzenen dollars besparje kin as it giet om in protte terabytes oan gegevens dy't ferwurke wurde. Dit jildt net foar bewarre gegevens, dy't frij goedkeap is om te ferwurkjen yn Big Query.
Yn in artikel troch Altinity mei-oprjochter Alexander Zaitsev praat oer de foardielen fan sa'n DBMS-migraasje.
TimescaleDB ferfanging
TimescaleDB is in PostgreSQL-útwreiding dy't it wurkjen mei tiidsearjes yn in reguliere databank optimalisearret (, ).
Hoewol ClickHouse is gjin serieuze konkurrint yn 'e niche fan tiidrige, mar kolomstruktuer en eksekúsje fan fektorfragen, is it folle flugger as TimescaleDB yn' e measte gefallen fan analytyske query-ferwurking. Tagelyk is de prestaasjes fan it ûntfangen fan batchgegevens fan ClickHouse sawat 3 kear heger, en it brûkt ek 20 kear minder skiifromte, wat echt wichtich is foar it ferwurkjen fan grutte folumes histoaryske gegevens: .
Oars as ClickHouse, is de ienige manier om wat skiifromte yn TimescaleDB te bewarjen troch ZFS of ferlykbere triemsystemen te brûken.
Oankommende updates foar ClickHouse sille wierskynlik delta-kompresje yntrodusearje, wat it noch mear geskikt sil meitsje foar it ferwurkjen en opslaan fan tiidreeksgegevens. TimescaleDB kin in bettere kar wêze dan bleate ClickHouse yn 'e folgjende gefallen:
- lytse ynstallaasjes mei hiel lyts RAM (<3 GB);
- in grut oantal lytse INSERTs dat jo net wolle buffer yn grutte fragminten;
- bettere gearhing, uniformiteit en ACID easken;
- PostGIS-stipe;
- gearwurkje mei besteande PostgreSQL-tabellen, om't Timescale DB yn wêzen PostgreSQL is.
Konkurrinsje mei Hadoop en MapReduce systemen
Hadoop en oare MapReduce-produkten kinne in protte komplekse berekkeningen útfiere, mar se hawwe de neiging om te rinnen mei enoarme latencies. ClickHouse reparearret dit probleem troch terabytes oan gegevens te ferwurkjen en resultaten hast direkt te produsearjen. Sa is ClickHouse folle effektiver by it útfieren fan fluch, ynteraktyf analytysk ûndersyk, dat fan belang wêze moat foar gegevenswittenskippers.
Konkurrinsje mei Pinot en Druid
De neiste konkurrinten fan ClickHouse binne kolomme, lineêr skalberbere iepen boarne produkten Pinot en Druid. In treflik wurk te fergelykjen dizze systemen wurdt publisearre yn it artikel fan 1 febrewaris 2018
Dit artikel moat bywurke wurde - it seit dat ClickHouse gjin UPDATE- en DELETE-operaasjes stipet, wat net folslein wier is foar de lêste ferzjes.
Wy hawwe net in protte ûnderfining mei dizze databases, mar ik hâld net echt fan 'e kompleksiteit fan' e ynfrastruktuer dy't nedich is om Druid en Pinot út te fieren - it is in hiele stel bewegende dielen omjûn troch Java oan alle kanten.
Druid en Pinot binne Apache-ynkubatorprojekten, wêrfan de fuortgong yn detail wurdt behannele troch Apache op har GitHub-projektsiden. Pinot ferskynde yn 'e incubator yn oktober 2018, en Druid waard berne 8 moannen earder - yn febrewaris.
It gebrek oan ynformaasje oer hoe't AFS wurket ropt wat, en miskien domme, fragen foar my op. Ik freegje my ôf oft de Pinot-auteurs opfallen dat de Apache Foundation geunsticher is foar Druid, en oft dizze hâlding foar de konkurrint in gefoel fan oergeunst feroarsake? Sil de ûntwikkeling fan Druid fertrage en de ûntwikkeling fan Pinot fersnelle as de efterfolgers fan 'e eardere ynienen ynteressearre wurde yn' e lêste?
Neidielen fan ClickHouse
Unrypheid: Fansels is dit noch gjin saaie technology, mar yn alle gefallen wurdt neat as dit waarnommen yn oare kolomme DBMS's.
Lytse ynserts dogge net goed op hege snelheid: ynserts moatte wurde splitst yn gruttere brokken omdat de prestaasjes fan lytse ynserts degradearret yn ferhâlding mei it oantal kolommen yn elke rige. Dit is hoe't ClickHouse gegevens op skiif bewarret - elke kolom stiet foar 1 bestân of mear, dus om 1 rige mei 100 kolommen yn te foegjen, moatte jo op syn minst 100 bestannen iepenje en skriuwe. Dit is wêrom buffering ynfoegingen fereasket in middelman (útsein as de klant sels jout buffering) - meastal Kafka of in soarte fan wachtrige behear systeem. Jo kinne ek de Buffer-tabelmotor brûke om letter grutte stikken gegevens yn MergeTree-tabellen te kopiearjen.
Tabel joins wurde beheind troch de tsjinner fan RAM, mar op syn minst se binne dêr! Bygelyks, Druid en Pinot hawwe sokke ferbiningen hielendal net, om't se dreech binne direkt te realisearjen yn ferdielde systemen dy't gjin ferpleatse fan grutte stikken gegevens tusken knopen stypje.
befinings
Wy binne fan plan om ClickHouse yn 'e kommende jierren breed te brûken yn Qwintry, om't dizze DBMS in poerbêste balâns leveret fan prestaasjes, lege overhead, skalberens en ienfâld. Ik bin der wis fan dat it rap sil begjinne te fersprieden ienris de ClickHouse-mienskip komt mei mear manieren om it te brûken yn lytse oant middelgrutte ynstallaasjes.
Guon advertinsjes 🙂
Tankewol foar it bliuwen by ús. Hâld jo fan ús artikels? Wolle jo mear ynteressante ynhâld sjen? Stypje ús troch in bestelling te pleatsen of oan te befeljen oan freonen, , in unike analoog fan servers op yngongsnivo, dy't troch ús foar jo útfûn is: (beskikber mei RAID1 en RAID10, oant 24 kearnen en oant 40GB DDR4).
Dell R730xd 2 kear goedkeaper yn Equinix Tier IV data sintrum yn Amsterdam? Allinne hjir yn Nederlân! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - fan $99! Lêze oer
Boarne: www.habr.com