is 'n oopbron-kolomêre databasisbestuurstelsel vir aanlyn analitiese navraagverwerking (OLAP) geskep deur Yandex. Dit word deur Yandex, CloudFlare, VK.com, Badoo en ander dienste regoor die wêreld gebruik om werklik groot hoeveelhede data te stoor (invoeging van duisende rye per sekonde of petagrepe data gestoor op skyf).
In 'n normale "string" DBMS, waarvan voorbeelde MySQL, Postgres, MS SQL Server is, word data in hierdie volgorde gestoor:
In hierdie geval word die waardes wat met dieselfde lyn verband hou, fisies langs mekaar gestoor. In kolomme DBMS word waardes van verskillende kolomme afsonderlik gestoor, en die data van een kolom word saam gestoor:
Voorbeelde van kolomvormige DBBS'e is Vertica, Paraccel (Actian Matrix, Amazon Redshift), Sybase IQ, Exasol, Infobright, InfiniDB, MonetDB (VectorWise, Actian Vector), LucidDB, SAP HANA, Google Dremel, Google PowerDrill, Druid, kdb+.
Die maatskappy is 'n posversending Ek het Clickhouse in 2018 vir verslaggewing begin gebruik en was baie beïndruk met die eenvoud, skaalbaarheid, SQL-ondersteuning en spoed. Die spoed van hierdie DBMS het aan magie gegrens.
Eenvoud
Clickhouse installeer op Ubuntu met 'n enkele opdrag. As jy SQL ken, kan jy dadelik Clickhouse vir jou behoeftes begin gebruik. Dit beteken egter nie dat jy kan "wys skep tabel" in MySQL en kopieer-plak SQL in Clickhouse.
In vergelyking met MySQL, is daar belangrike datatipe verskille in die tabelskema-definisies in hierdie DBBS, so jy het nog tyd nodig om die tabelskema-definisies te verander en die tabel-enjins te leer om gemaklik te raak.
Clickhouse werk uitstekend sonder enige bykomende sagteware, maar as jy replikasie wil gebruik, sal jy ZooKeeper moet installeer. Navraagprestasie-analise toon uitstekende resultate - die stelseltabelle bevat al die inligting, en al die data kan verkry word deur ou en vervelige SQL te gebruik.
produktiwiteit
- Clickhouse versus Vertica en MySQL vergelykings op konfigurasie bediener: twee voetstukke Intel® Xeon® CPU E5-2650 v2 @ 2.60GHz; 128 GiB RAM; md RAID-5 op 8 6TB SATA HDD, ext4.
- vergelyking van Clickhouse met Amazon RedShift-wolkberging.
- Blog uittreksels :
Die ClickHouse-databasis het 'n baie eenvoudige ontwerp - alle nodusse in die groep het dieselfde funksionaliteit en gebruik slegs ZooKeeper vir koördinasie. Ons het 'n klein groepie van verskeie nodusse gebou en toetse uitgevoer, waartydens ons gevind het dat die stelsel nogal indrukwekkende werkverrigting het, wat ooreenstem met die beweerde voordele in analitiese DBMS-maatstawwe. Ons het besluit om die konsep agter ClickHouse van nader te bekyk. Die eerste struikelblok vir navorsing was die gebrek aan gereedskap en die klein gemeenskap van ClickHouse, so ons het in die ontwerp van hierdie DBBS gedelf om te verstaan hoe dit werk.
ClickHouse ondersteun nie die ontvangs van data direk vanaf Kafka nie, aangesien dit net 'n databasis is, so ons het ons eie adapterdiens in Go geskryf. Dit het Cap'n Proto-gekodeerde boodskappe van Kafka gelees, dit na TSV omgeskakel en dit in groepe in ClickHouse ingevoeg via die HTTP-koppelvlak. Ons het later hierdie diens herskryf om die Go-biblioteek te gebruik in samewerking met ons eie ClickHouse-koppelvlak om werkverrigting te verbeter. Toe ons die prestasie van die ontvangs van pakkies evalueer, het ons 'n belangrike ding ontdek - dit het geblyk dat vir ClickHouse hierdie prestasie sterk afhang van die grootte van die pakkie, dit wil sê die aantal rye wat op dieselfde tyd ingevoeg word. Om te verstaan hoekom dit gebeur, het ons bestudeer hoe ClickHouse data stoor.
Die hoofenjin, of liewer, 'n familie van tafelenjins wat deur ClickHouse gebruik word om data te stoor, is MergeTree. Hierdie enjin is konseptueel soortgelyk aan die LSM-algoritme wat in Google BigTable of Apache Cassandra gebruik word, maar vermy die bou van 'n intermediêre geheuetabel en skryf data direk na skyf. Dit gee dit uitstekende skryfdeurset, aangesien elke ingevoegde pakkie slegs volgens die "primêre sleutel" primêre sleutel gesorteer word, saamgepers en na skyf geskryf word om 'n segment te vorm.
Die afwesigheid van 'n geheuetabel of enige konsep van "varsheid" van data beteken ook dat hulle slegs bygevoeg kan word, die stelsel ondersteun nie verandering of uitvee nie. Van vandag af is die enigste manier om data uit te vee om dit volgens kalendermaand uit te vee, aangesien segmente nooit 'n maandgrens oorsteek nie. Die ClickHouse-span werk aktief daaraan om hierdie kenmerk aanpasbaar te maak. Aan die ander kant maak dit skryf en samevoeging van segmente twisvry, dus ontvang deursetskale lineêr met die aantal parallelle invoegings totdat I/O of kerns versadig is.
Hierdie omstandigheid beteken egter ook dat die stelsel nie geskik is vir klein pakkies nie, daarom word Kafka-dienste en invoegers vir buffering gebruik. Verder, ClickHouse in die agtergrond gaan voort om voortdurend die segmente saam te voeg, sodat baie klein stukkies inligting gekombineer en meer keer opgeneem sal word, en sodoende die opname-intensiteit verhoog. Te veel onverwante dele sal egter aggressiewe versmoring van insetsels veroorsaak solank die samesmelting voortduur. Ons het gevind dat die beste kompromie tussen intydse data-inname en inname-prestasie is om 'n beperkte aantal invoegings per sekonde in die tabel te aanvaar.
Die sleutel tot tabelleesprestasie is die indeksering en ligging van die data op skyf. Dit maak nie saak hoe vinnig die verwerking is nie, wanneer die enjin teragrepe data vanaf skyf moet skandeer en net 'n fraksie daarvan gebruik, sal dit tyd neem. ClickHouse is 'n kolomwinkel, so elke segment bevat 'n lêer vir elke kolom (kolom) met gesorteerde waardes vir elke ry. Hele kolomme wat nie in die navraag teenwoordig is nie, kan dus eers oorgeslaan word, en dan kan verskeie selle parallel met gevektoriseerde uitvoering verwerk word. Om 'n volledige skandering te vermy, het elke segment 'n klein indekslêer.
Aangesien alle kolomme volgens die "primêre sleutel" gesorteer is, bevat die indekslêer slegs die etikette (gevange rye) van elke Nde ry, om dit selfs vir baie groot tabelle in die geheue te kan hou. Byvoorbeeld, jy kan die verstekinstellings stel om "elke 8192ste ry te merk", dan "karige" indeksering van 'n tabel met 1 triljoen. reëls wat maklik in die geheue pas, sal slegs 122 070 karakters neem.
Stelselontwikkeling
Die ontwikkeling en verbetering van Clickhouse kan opgespoor word en maak seker dat die proses van "grootword" teen 'n indrukwekkende tempo plaasvind.
Gewildheid
Dit blyk dat Clickhouse se gewildheid eksponensieel groei, veral in die Russiessprekende gemeenskap. Verlede jaar se High load 2018-konferensie (Moskou, 8-9 November 2018) het getoon dat monsters soos vk.com en Badoo Clickhouse gebruik, wat data (byvoorbeeld logs) van tienduisende bedieners gelyktydig invoeg. In 'n 40 minute video . Binnekort sal ons die transkripsie op Habr plaas vir die gerief om met die materiaal te werk.
aansoeke
Nadat ek 'n geruime tyd daaraan bestee het, dink ek daar is gebiede waar ClickHouse nuttig kan wees of ander meer tradisionele en gewilde oplossings heeltemal kan vervang soos MySQL, PostgreSQL, ELK, Google Big Query, Amazon RedShift, TimescaleDB, Hadoop, MapReduce, Pinot en Druïde. Die volgende is die besonderhede van die gebruik van ClickHouse om die bogenoemde DBBS op te gradeer of heeltemal te vervang.
Uitbreiding van MySQL en PostgreSQL
Mees onlangs het ons MySQL gedeeltelik vervang met ClickHouse vir die nuusbriefplatform . Die probleem was dat MySQL as gevolg van ondeurdagte ontwerp elke e-pos wat gestuur is en elke skakel in daardie e-pos aangeteken het met 'n base64-hash, wat 'n groot MySQL-tabel (email_stats) geskep het. Nadat slegs 10 miljoen e-posse aan die diens se intekenare gestuur is, het hierdie tafel 150 GB lêerspasie in beslag geneem, en MySQL het "dom" begin raak op eenvoudige navrae. Om die lêerspasieprobleem op te los, het ons InnoDB-tabelkompressie suksesvol gebruik, wat dit met 'n faktor van 4 verminder het. Dit maak egter steeds nie sin om meer as 20-30 miljoen e-posse in MySQL te stoor net ter wille van die lees van geskiedenis nie, aangesien enige eenvoudige navraag wat om een of ander rede 'n volledige skandering moet doen, lei tot ruil en swaar I/O oorhoofs, waaroor ons gereeld Zabbix-waarskuwings ontvang het.
Clickhouse gebruik twee kompressie-algoritmes wat die hoeveelheid data met ongeveer verminder , maar in hierdie spesifieke geval was die data veral "saamdrukbaar".
ELK vervanging
Op grond van my eie ervaring, vereis die ELK-stapel (ElasticSearch, Logstash en Kibana, in hierdie spesifieke geval ElasticSearch) baie meer hulpbronne om te hardloop as wat nodig is om logs te stoor. ElasticSearch is 'n wonderlike enjin as jy goeie volteks-logsoektog wil hê (en ek dink nie jy het dit regtig nodig nie), maar ek wonder hoekom dit die de facto-standaard-log-enjin geword het. Die innameprestasie daarvan, gekombineer met Logstash, het ons selfs by redelik ligte werkladings probleme gegee en het die byvoeging van meer en meer RAM en skyfspasie vereis. As 'n databasis is Clickhouse om die volgende redes beter as ElasticSearch:
- SQL dialek ondersteuning;
- Die beste mate van kompressie van gestoorde data;
- Ondersteuning vir Regex-soektog in plaas van voltekssoektog;
- Verbeterde navraagskedulering en beter algehele prestasie.
Tans is die grootste probleem wat ontstaan wanneer ClickHouse met ELK vergelyk word, die gebrek aan oplossings vir die oplaai van logs, sowel as die gebrek aan dokumentasie en tutoriale oor hierdie onderwerp. Terselfdertyd kan elke gebruiker ELK opstel deur die Digital Ocean-handleiding te gebruik, wat baie belangrik is vir die vinnige implementering van sulke tegnologieë. Daar is 'n databasis-enjin hier, maar daar is nog geen Filebeat vir ClickHouse nie. Ja daar is en 'n stelsel om met logs te werk , daar is 'n hulpmiddel loglêerdata in ClickHouse in te voer, maar dit alles neem meer tyd. ClickHouse is egter steeds die voorloper as gevolg van sy eenvoud, so selfs beginners kan dit maklik installeer en ten volle funksionele gebruik in net 10 minute begin.
Om minimalistiese oplossings te verkies, het ek probeer om FluentBit, 'n baie lae geheue-logoplaai-instrument, met ClickHouse te gebruik, terwyl ek probeer het om Kafka te vermy. Geringe onversoenbaarheid moet egter aangespreek word, soos voordat dit gedoen kan word sonder die proxy-laag wat data van FluentBit na ClickHouse omskakel.
As 'n alternatief vir Kibana, kan jy ClickHouse as 'n backend gebruik . Sover ek verstaan, kan dit prestasieprobleme veroorsaak wanneer 'n groot aantal datapunte gelewer word, veral met ouer weergawes van Grafana. In Qwintry het ons dit nog nie probeer nie, maar klagtes hieroor verskyn van tyd tot tyd op die ClickHouse-ondersteuningskanaal in Telegram.
Vervanging van Google Big Query en Amazon RedShift (oplossing vir groot maatskappye)
Die ideale gebruiksgeval vir BigQuery is om 1 TB JSON-data te laai en analitiese navrae daarop uit te voer. Big Query is 'n wonderlike produk waarvan die skaalbaarheid moeilik is om te oorskat. Dit is baie meer komplekse sagteware as ClickHouse wat op 'n interne groepering loop, maar vanuit die kliënt se oogpunt het dit baie in gemeen met ClickHouse. BigQuery kan vinnig "prys" sodra jy vir elke SELECT begin betaal, so dit is 'n regte SaaS-oplossing met al sy voor- en nadele.
ClickHouse is die beste keuse wanneer jy baie rekenkundig duur navrae uitvoer. Hoe meer SELECT-navrae jy elke dag uitvoer, hoe meer sin maak dit om Big Query met ClickHouse te vervang, want so 'n vervanging sal jou duisende dollars bespaar wanneer dit kom by baie teragrepe se data wat verwerk word. Dit is nie van toepassing op gestoorde data nie, wat redelik goedkoop is om in Big Query te verwerk.
In 'n artikel deur Alexander Zaitsev, medestigter van Altinity beskryf die voordele van so 'n DBMS-migrasie.
TydskaalDB-vervanging
TimescaleDB is 'n PostgreSQL-uitbreiding wat die werk met tydreekse in 'n gewone databasis optimaliseer (, ).
Alhoewel ClickHouse nie 'n ernstige mededinger in die tydreeksnis is nie, maar in terme van kolomstruktuur en vektornavraaguitvoering, is dit baie vinniger as TimescaleDB in die meeste gevalle van die verwerking van analitiese navrae. Terselfdertyd is die prestasie van die ontvangs van ClickHouse-pakkiedata ongeveer 3 keer hoër, en dit gebruik ook 20 keer minder skyfspasie, wat regtig belangrik is vir die verwerking van groot volumes historiese data: .
Anders as ClickHouse, is die enigste manier om skyfspasie in TimescaleDB te bespaar om ZFS of soortgelyke lêerstelsels te gebruik.
Komende opdaterings aan ClickHouse sal waarskynlik delta-kompressie bekendstel, wat dit selfs meer geskik sal maak vir die verwerking en berging van tydreeksdata. TimescaleDB kan 'n beter keuse wees as blote ClickHouse in die volgende gevalle:
- klein installasies met baie min RAM (<3 GB);
- 'n groot aantal klein INSERTS wat jy nie in groot fragmente wil buffer nie;
- beter konsekwentheid, eenvormigheid en SUUR vereistes;
- PostGIS-ondersteuning;
- smelt saam met bestaande PostgreSQL-tabelle, aangesien Timescale DB in wese PostgreSQL is.
Kompetisie met Hadoop- en MapReduce-stelsels
Hadoop en ander MapReduce-produkte kan baie komplekse berekeninge uitvoer, maar hulle is geneig om met groot latency te werk. ClickHouse los hierdie probleem op deur teragrepe data te verwerk en resultate byna onmiddellik te lewer. ClickHouse is dus baie meer doeltreffend om vinnige, interaktiewe analitiese navorsing uit te voer, wat vir datawetenskaplikes van belang behoort te wees.
Kompetisie met Pinot en Druid
ClickHouse se naaste mededingers is die kolomvormige, lineêr skaalbare oopbronprodukte Pinot en Druid. 'n Uitstekende werk om hierdie stelsels te vergelyk, word in die artikel gepubliseer 1 Februarie 2018
Hierdie artikel moet opgedateer word - dit sê dat ClickHouse nie UPDATE- en DELETE-bewerkings ondersteun nie, wat nie heeltemal waar is met betrekking tot die nuutste weergawes nie.
Ons het nie veel ondervinding met hierdie DBBS'e nie, maar ek hou nie van die kompleksiteit van die onderliggende infrastruktuur wat nodig is om Druid en Pinot te laat loop nie - dit is 'n hele klomp "bewegende dele" omring deur Java van alle kante.
Druid en Pinot is Apache-broeikasprojekte, wat in detail deur Apache op hul GitHub-projekbladsye gedek word. Pinot het in Oktober 2018 in die broeikas verskyn, en Druid is 8 maande vroeër gebore - in Februarie.
Die gebrek aan inligting oor hoe AFS werk, laat 'n paar, en miskien dom, vrae vir my ontstaan. Ek wonder of die skrywers van Pinot opgemerk het dat die Apache-stigting meer geneig is tot Druïde, en het so 'n houding teenoor 'n mededinger 'n gevoel van afguns veroorsaak? Sal die ontwikkeling van Druid verlangsaam en die ontwikkeling van Pinot versnel as die borge wat eersgenoemde ondersteun skielik in laasgenoemde belangstel?
Nadele van ClickHouse
Onvolwassenheid: Dit is natuurlik steeds 'n vervelige tegnologie, maar in elk geval word niks soos hierdie in ander kolomme DBBS gesien nie.
Klein insetsels presteer nie goed teen hoë spoed nie: insetsels moet in groot stukke verdeel word omdat die werkverrigting van klein insetsels verswak in verhouding tot die aantal kolomme in elke ry. Dit is hoe ClickHouse data op skyf stoor - elke kolom beteken 1 lêer of meer, dus om 1 ry met 100 kolomme in te voeg, moet jy ten minste 100 lêers oopmaak en skryf. Dit is hoekom invoegbuffer 'n tussenganger vereis (tensy die kliënt self buffering verskaf) - gewoonlik Kafka of 'n soort toustelsel. Jy kan ook die Buffer tabel-enjin gebruik om later groot stukke data in MergeTree-tabelle te kopieer.
Tafelaansluitings word beperk deur bediener-RAM, maar hulle is ten minste daar! Druid en Pinot het byvoorbeeld glad nie sulke verbindings nie, aangesien dit moeilik is om direk te implementeer in verspreide stelsels wat nie die verskuiwing van groot stukke data tussen nodusse ondersteun nie.
Bevindinge
In die komende jare beplan ons om uitgebreide gebruik te maak van ClickHouse in Qwintry, aangesien hierdie DBMS 'n uitstekende balans van werkverrigting, lae bokoste, skaalbaarheid en eenvoud bied. Ek is redelik seker dat dit vinnig sal versprei sodra die ClickHouse-gemeenskap met meer maniere vorendag kom om dit in klein en medium installasies te gebruik.
Sommige advertensies 🙂
Dankie dat jy by ons gebly het. Hou jy van ons artikels? Wil jy meer interessante inhoud sien? Ondersteun ons deur 'n bestelling te plaas of by vriende aan te beveel, , 'n unieke analoog van intreevlakbedieners, wat deur ons vir jou uitgevind is: (beskikbaar met RAID1 en RAID10, tot 24 kerne en tot 40 GB DDR4).
Dell R730xd 2x goedkoper in Equinix Tier IV-datasentrum in Amsterdam? Net hier in Nederland! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - vanaf $99! Lees van
Bron: will.com