🥇ClickHousera mugitzea: 3 urte geroago

Duela hiru urte Yandex taldeko Viktor Tarnavsky eta Alexey Milovidov eszenatokian High Load++ esan, zein ClickHouse den ona, eta nola ez den moteltzen. Eta hurrengo etapan egon zen Alexander Zaitsev с txostena mugitzeari buruz clickhouse beste DBMS analitiko batetik eta ondorioztatuta clickhouse, noski, ona, baina ez oso erosoa. Noiz 2016an konpainiak LifeStreet, non Alexander orduan lan egin zuen, multipetabyte sistema analitikoa itzuli zuen clickhouse, "adreilu horiko errepide" liluragarria zen, arrisku ezezagunez betea - clickhouse orduan meatze zelai bat zirudien.

Hiru urte geroago clickhouse askoz hobea bihurtu zen - garai honetan, Alexander Altinity konpainia sortu zuen, eta horrek ez du bakarrik mugitzen laguntzen clickhouse dozenaka proiektu, baina produktua bera ere hobetzen du Yandex-eko lankideekin batera. Orain clickhouse oraindik ez da arduragabeko ibilaldi bat, baina jada ez meatze-zelaia.

Alexander 2003az geroztik sistema banatuetan parte hartzen du, proiektu handiak garatzen MySQL, Oracle и Bertikala. Azkenean HighLoad++ 2019 Alexander, erabileraren aitzindarietako bat clickhouse, DBMS hau orain zer den kontatu zuen. Ezaugarri nagusiak ezagutuko ditugu clickhouse: nola desberdintzen den beste sistemetatik eta zein kasutan den eraginkorragoa erabiltzea. Adibideak erabiliz, kontuan ditzagun proiektuetan oinarritutako eraikuntza sistemak egiteko praktika freskoak eta frogatuak clickhouse.

Atzera begirakoa: duela 3 urte gertatutakoa

Duela hiru urte enpresa transferitu genuen LifeStreet on clickhouse datu-base analitiko desberdin batetik, eta iragarki-sarearen analitiken migrazioak honelakoa izan zen:

2016ko ekaina. urtean Iturburu irekia agertu clickhouse eta gure proiektua martxan jarri;
Abuztua. Kontzeptu Froga: iragarki-sare handia, azpiegitura eta 200-300 terabyte datu;
Urria. Lehenengo produkzio datuak;
abendua. Produktu-karga osoa - 10-50 milioi gertaera eguneko.
2017ko ekaina. Erabiltzaileen migrazio arrakastatsua clickhouse, 2,5 petabyte datu 60 zerbitzariko kluster batean.

Migrazioak aurrera egin ahala, ulermena hazi egin zen clickhouse sistema ona da, lan egiteko atsegina dena, baina Yandex-en barne-proiektua da. Hori dela eta, ñabardurak daude: Yandex-ek lehenik bere barneko bezeroei aurre egingo die eta gero komunitatearekin eta kanpoko erabiltzaileen beharrekin bakarrik, ClickHouse-k ez zuen enpresa mailara iritsi orduan arlo funtzional askotan. Beraz, 2017ko martxoan, Altinity sortu genuen egiteko clickhouse are azkarragoa eta erosoagoa Yandexentzat ez ezik, beste erabiltzaileentzat ere. Eta orain guk:

Horretan oinarritutako irtenbideak prestatzen eta eraikitzen laguntzen dugu clickhouse bezeroek kolpeak bete ez ditzaten, eta azkenean irtenbideak funtziona dezan;
24/7 laguntza eskaintzen dugu clickhouse- instalazioak;
Gure ekosistema proiektuak garatzen ditugu;
Nire buruarekin aktiboki konprometitu clickhouse, ezaugarri jakin batzuk ikusi nahi dituzten erabiltzaileen eskaerei erantzunez.

Eta noski, mugitzen laguntzen dugu clickhouse с MySQL, Bertikala, Oracle, Aran berdea, Redshift eta beste sistema batzuk. Askotariko lekualdatzeetan parte hartu dugu eta guztiak arrakastatsuak izan dira.

Zergatik mugitu ere clickhouse

Ez du moteltzen! Hau da arrazoi nagusia. clickhouse - Oso datu-base azkarra eszenatoki desberdinetarako:

Lan egiten duten pertsonen ausazko aipamenak clickhouse.

Eskalagarritasuna. Beste datu-base batzuetan, errendimendu ona lor dezakezu hardware pieza batean, baina clickhouse bertikalean ez ezik, horizontalean ere eska dezakezu zerbitzariak gehituz. Dena ez da nahi bezain ondo funtzionatzen, baina funtzionatzen du. Sistema hazi dezakezu zure negozioa hazten den heinean. Garrantzitsua da orain erabakiak mugarik ez izatea eta beti dago garapenerako aukera.

Eramangarritasuna. Ez dago gauza bati atxikimendurik. Adibidez, rekin Amazon RedShift zaila norabait mugitzea. A clickhouse zure ordenagailu eramangarrian, zerbitzarian jar dezakezu, hodeian zabaldu, joan hona Kubernetes - ez dago azpiegituren funtzionamenduan murrizketarik. Guztiontzat komenigarria da, eta antzeko beste datu-base askok harro ezin duten abantaila handia da.

malgutasuna. clickhouse ez da gauza batean gelditzen, adibidez, Yandex.Metrica, baina gero eta proiektu eta industria ezberdin gehiagotan garatzen eta erabiltzen ari da. Arazo berriak konpontzeko funtzio berriak gehituz zabaldu daiteke. Adibidez, datu-base batean erregistroak gordetzea modu txarra dela uste da, beraz, horretarako asmatu zuten Elasticsearch. Baina malgutasunari esker clickhouse, erregistroak ere gorde ditzakezu bertan, eta askotan hau are hobea da Elasticsearch - urtean clickhouse 10 aldiz burdina gutxiago behar du.

Doakoa Open Source. Ez duzu ezer ordaindu behar. Ez da baimenik negoziatu behar sistema zure ordenagailu eramangarrian edo zerbitzarian jartzeko. Ez dago ezkutuko kuotarik. Aldi berean, Iturburu Irekiko datu-baseen beste teknologiarik ezin du lehiatu abiaduran clickhouse. MySQL, MariaDB, Greenplum - denak askoz motelagoak dira.

Komunitatea, gidatzea eta fun. Urtean clickhouse komunitate bikaina: topaketak, txatak eta Alexey Milovidov, bere energiaz eta baikortasunez kargatzen gaituena.

ClickHousera mugitzen

Hona aldatzeko clickhouse zerbaitekin, hiru gauza besterik ez dituzu behar:

Mugak ulertzea clickhouse eta zertarako ez den egokia.
Erabili onurak teknologia eta bere indargune handienak.
Esperimentua. Nola funtzionatzen duen ulertzea ere clickhouse, ez da beti aurreikusten noiz izango den azkarragoa, noiz izango den motelagoa, noiz izango den hobea eta noiz okerrago. Beraz, saiatu.

Mugitzearen arazoa

"Baina" bakarra dago: mugitzen bazara clickhouse beste zerbaitetik, orduan normalean zerbait gaizki doa. Gure gogoko datu-basean funtzionatzen duten praktika eta gauza batzuetara ohituta gaude. Adibidez, edonorekin lanean SQL datu-baseek derrigorrezko funtzio multzo hau hartzen dute:

transakzioak;
mugak;
koherentzia;
indizeek;
EGUNERATU/EZABATU;
NULLak;
milisegundoak;
motako bihurketa automatikoak;
juntadura anitzak;
partizio arbitrarioak;
klusterrak kudeatzeko tresnak.

Kontratazioa derrigorrezkoa da, baina duela hiru urte clickhouse Funtzio hauetako bat ere ez zegoen erabilgarri! Orain gauzatu gabekoen erdia baino gutxiago geratzen da: transakzioak, mugak, koherentzia, milisegundoak eta casting mota.

Eta gauza nagusia da clickhouse praktika eta planteamendu estandar batzuek ez dute funtzionatzen edo ez dute funtzionatzen ohituta gauden moduan. Bertan agertzen den guztia clickhouse, dagokio "klik etxea modua", alegia. funtzioak beste datu-baseetatik desberdinak dira. Adibidez:

Indizeak ez dira hautatzen, baina saltatu egiten dira.
EGUNERATU/EZABATU ez sinkronoa, asinkronoa baizik.
Elkartze anitz daude, baina ez dago kontsulta-planifikatzailerik. Nola exekutatzen diren, oro har, datu baseen munduko jendearentzat ez dago oso argi.

ClickHouse eszenatokiak

1960an, hungariar jatorriko matematikari estatubatuarra WignerEP artikulu bat idatzi zuenMatematikaren eraginkortasun zentzugabea natur zientzietan”(“Matematikaren eraginkortasun ulertezina natur zientzietan”) gure inguruko mundua arrazoiren batengatik ondo deskribatzen dute lege matematikoek. Matematika zientzia abstraktua da, eta forma matematikoan adierazitako lege fisikoak ez dira hutsalak, eta WignerEP hori oso bitxia dela azpimarratu du.

Nire ikuspuntutik, clickhouse - bitxikeria bera. Wigner birformulatzeko, hau esan dezakegu: harrigarria da pentsaezina den eraginkortasuna clickhouse aplikazio analitiko ugaritan!

Adibidez, har dezagun Denbora errealeko datu biltegia, eta bertan datuak ia etengabe kargatzen dira. Haren eskaerak bigarren atzerapen batekin jaso nahi ditugu. Mesedez, erabili clickhouseeszenatoki honetarako diseinatu baitzen. clickhouse horrela erabiltzen da sarean ez ezik, marketin eta finantza analitikan ere, AdTech, baita in Iruzurraren detekzioan. IN Data errealeko biltegia "izarra" edo "elur maluta" bezalako eskema egituratu konplexua erabiltzen da, taula askorekin ELKARTU (batzuetan anitz), eta datuak sistema batzuetan gorde eta aldatu ohi dira.

Har dezagun beste eszenatoki bat - Denbora Seriea: monitorizazio gailuak, sareak, erabilera-estatistikak, gauzen interneta. Hemen denboran ordenatutako gertaera nahiko sinpleekin elkartzen gara. clickhouse jatorriz ez zen horretarako garatu, baina ondo erakutsi du, beraz, enpresa handiek erabiltzen dute clickhouse informazioa kontrolatzeko biltegi gisa. Ea egokitzen den clickhouse denbora-serieetarako, planteamendu eta emaitzetan oinarritutako erreferentzia bat egin dugu InfluxDB и Denbora eskalaDB — espezializatua denborazko serieak datu-baseak. Gertatu zenThat clickhouse, zereginetarako optimizatu gabe ere, atzerriko eremu batean ere irabazten du:

В denborazko serieak normalean taula estu bat erabiltzen da - hainbat zutabe txiki. Monitorizaziotik datu asko etor daitezke -segundoko milioika erregistro- eta normalean txertaketa txikietan etortzen dira (real-time streaming). Hori dela eta, beste txertatzeko script bat behar dugu, eta kontsultak beraiek - berezko zehaztasun batzuekin.

Saioa Kudeaketa. Datu-basean erregistroak biltzea txarra da normalean, baina bertan clickhouse hau goian azaldutako iruzkin batzuekin egin daiteke. Enpresa askok erabiltzen dute clickhouse horretarako bakarrik. Kasu honetan, mahai zabal lau bat erabiltzen da, non erregistro osoa gordetzen dugun (adibidez, formularioan JSON), edo zatitan moztu. Datuak sorta handietan kargatzen dira (fitxategiak), eta eremuren bat bilatzen ari gara.

Funtzio horietako bakoitzerako, datu-base espezializatuak erabili ohi dira. clickhouse dena egin dezake eta hain ondo non errendimenduan gainditzen dituen. Ikus dezagun orain hurbilagotik denborazko serieak gidoia, eta nola "sukaldatu" clickhouse eszenatoki honen pean.

Denbora Seriea

Hau da gaur egun horren eszenatoki nagusia clickhouse irtenbide estandartzat hartzen da. Denbora-serieak denboran zehar prozesu batzuetan izandako aldaketak adierazten dituen denbora-ordenatutako gertakarien multzoa da. Adibidez, eguneko bihotz taupadak edo sistemako prozesu kopurua izan daiteke. Dimentsio batzuekin denborak ematen duen guztia da denborazko serieak:

Gertaera horietako gehienak monitorizaziotik datoz. Hau web monitorizazioa ez ezik, benetako gailuak ere izan daitezke: autoak, sistema industrialak, IoT, fabrikak edo tripulaziorik gabeko taxiak, Yandex dagoeneko jartzen ari den maletarrean clickhouse-zerbitzaria.

Esaterako, badira itsasontzietako datuak biltzen dituzten enpresak. Segundo gutxitan, edukiontzi-ontzi bateko sentsoreek ehunka neurketa ezberdin bidaltzen dituzte. Ingeniariek horiek aztertzen dituzte, ereduak eraikitzen dituzte eta ontzia zein eraginkortasunez erabiltzen den ulertzen saiatzen dira, edukiontzi-ontzi batek ez duelako segundo batean geldirik egon behar. Edozein geldialdi-denbora dirua xahutzea da, beraz, garrantzitsua da ibilbidea aurreikustea, aparkalekua gutxien izan dadin.

Orain neurtzen duten datu-base espezializatuen hazkundea dago denborazko serieak. Gunean DB-Motorrak nolabait datu-base desberdinak sailkatuta daude, eta motaren arabera ikus daitezke:

Bizkorren hazten den mota denbora serieas. Datu-base grafikoak ere hazten ari dira, baina denbora serieaAzken urteotan azkarrago hazten ari dira. Datu-baseen familia honetako ordezkari tipikoak dira InfluxDB, Prometeo, KDB, Denbora eskalaDB (gainean eraikia PostgreSQL), irtenbideak Amazon. clickhouse hemen ere erabil daiteke, eta erabiltzen da. Adibide publiko batzuk emango dizkizut.

Aitzindarietako bat enpresa da CloudFlare (CDNhornitzailea). Haien jarraipena egiten dute CDN bidez clickhouse (DNS- eskaerak, HTTP-eskaerak) karga handiarekin - 6 milioi gertaera segundoko. Dena pasatzen da Kafka, doa clickhouse, sistemako gertaeren panelak denbora errealean ikusteko aukera ematen duena.

Comcast - Estatu Batuetako telekomunikazioen liderretako bat: Internet, telebista digitala, telefonia. Antzeko kontrol sistema bat sortu zuten CDN esparruan Open Source proiektua Apache Trafiko Kontrola zure datu erraldoiekin lan egiteko. clickhouse analitiketarako backend gisa erabiltzen da.

percona barnean eraikia clickhouse zure barruan PMMjarraipen desberdina jarraitzeko MySQL.

Baldintza espezifikoak

Denbora-serieen datu-baseek beren eskakizun zehatzak dituzte.

Eragile askoren txertatze azkarra. Korronte askotako datuak oso azkar txertatu behar ditugu. clickhouse ondo egiten du, blokeatu gabeko txertaketa guztiak dituelako. Edozein sartu diskoan dagoen fitxategi berria da, eta txertaketa txikiak era batera edo bestera gorde daitezke. IN clickhouse hobe da datuak sorta handietan txertatzea, lerro bat aldi berean baino.
Zirkuitu Malgua. Urtean denborazko serieak normalean ez dugu datuen egitura guztiz ezagutzen. Posible da aplikazio zehatz baterako jarraipen-sistema bat eraikitzea, baina gero zaila da beste aplikazio baterako erabiltzea. Horrek eskema malguagoa eskatzen du. clickhouse, hau egiteko aukera ematen du, nahiz eta oso idatzitako oinarria izan.
Biltegiratze eraginkorra eta datuak ahaztea. Normalean barruan denborazko serieak datu kopuru handi bat, beraz, ahalik eta modu eraginkorrenean gorde behar dira. Adibidez, at InfluxDB konpresio ona da bere ezaugarri nagusia. Baina biltegiratzeaz gain, datu zaharrak "ahaztu" eta batzuk egiteko ere gai izan behar duzu azpilaginketa — Agregatuen zenbaketa automatikoa.
Datu agregatuei buruzko kontsulta azkarrak. Batzuetan interesgarria da azken 5 minutuak milisegundoko zehaztasunarekin aztertzea, baina hileroko datuetan baliteke minutu edo segunduko granulartasuna behar ez izatea; nahikoa da estatistika orokorrak. Mota honetako laguntza beharrezkoa da, bestela 3 hilabeteko eskaera bat oso denbora luzez gauzatuko da baita ere clickhouse.
" bezalako eskaerakazken puntua, aurrera». Hauek ohikoak dira denborazko serieak eskaerak: azken neurketa edo sistemaren egoera une batean begiratu t. Datu-baserako, ez dira oso kontsulta atseginak, baina exekutatzeko gai izan behar dute.
"itsatsi" denbora serieak. Denbora-serieak denbora serie bat da. Bi denbora serie badaude, askotan konektatu eta korrelazionatu behar dira. Ez da komenigarria datu-base guztietan egitea, batez ere lerrokatu gabeko denbora serieekin: hona hemen denbora-marka batzuk, beste batzuk. Batez bestekoa kontuan hartu dezakezu, baina bat-batean oraindik zulo bat egongo da, beraz, ez dago argi.

Ikus dezagun nola betetzen diren baldintza hauek clickhouse.

Eskema

В clickhouse eskema denborazko serieak modu ezberdinetan egin daiteke, datuen erregulartasun mailaren arabera. Posible da sistema bat eraikitzea datu arruntekin, metrika guztiak aldez aurretik ezagutzen ditugunean. Esaterako, egin CloudFlare jarraipenarekin CDN ondo optimizatutako sistema da. Azpiegitura osoa, zerbitzu desberdinak kontrolatzen dituen sistema orokorrago bat eraiki dezakezu. Datu irregularren kasuan, ez dakigu aldez aurretik zer kontrolatzen ari garen –eta seguruenik hori da kasurik ohikoena–.

Datu arruntak. Zutabeak. Eskema sinplea da - zutabeak beharrezko motak dituztenak:

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);

Hau sistemaren abioko jarduera motaren bat kontrolatzen duen taula arrunta da (erabiltzaile, sistema, s info, politak). Sinplea eta erosoa, baina ez malgua. Eskema malguagoa nahi badugu, matrizeak erabil ditzakegu.

Datu irregularrak. Arrayak:

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 ...

Egitura Habiaratua bi array dira: metrika.izena и metrika.balioa. Hemen jarraipen-datu arbitrarioak gorde ditzakezu izen-matrize bat eta gertaera bakoitzeko neurketa-matrize bat. Gehiago optimizatzeko, halako egitura batzuk egin daitezke baten ordez. Adibidez, batentzat float-balioa, beste bat -rentzat int-esanahia, zeren int Eraginkorrago gorde nahi dut.

Baina horrelako egitura bat sartzea zailagoa da. Eraikuntza berezi bat erabili beharko duzu, funtzio bereziak erabiliz balioak ateratzeko indizearen lehenik, eta gero matrizearen:

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

Baina oraindik nahikoa azkar funtzionatzen du. Datu irregularrak gordetzeko beste modu bat errenkadak dira.

Datu irregularrak. Kateak. Metodo tradizional honetan, matrizerik gabe, izenak eta balioak aldi berean gordetzen dira. Gailu batetik 5 neurketa aldi berean badatoz, 000 errenkada sortzen dira datu-basean:

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', ...)

clickhouse horri aurre egiten dio - luzapen bereziak ditu clickhouse SQL. Adibidez maxIf - Baldintzaren bat betetzen denean metrikaren arabera maximoa kalkulatzen duen funtzio berezi bat. Horrelako hainbat esamolde idatz ditzakezu kontsulta batean eta berehala kalkulatu hainbat metrikaren balioa.

Konpara ditzagun hiru ikuspegi:

Xehetasunak

Hemen "Datuen tamaina diskoan" gehitu dut probako datu multzo batzuetarako. Zutabeen kasuan, datu-tamaina txikiena dugu: konpresio maximoa, kontsulta-abiadura maximoa, baina dena aldi berean konpondu beharrez ordaintzen dugu.

Array-en kasuan, gauzak apur bat okerragoak dira. Datuak oraindik ondo konprimitzen dira eta posible da eredu irregular bat gordetzea. Baina clickhouse - zutabeen datu-base bat, eta dena array batean gordetzen hasten garenean, kate batean bihurtzen da, eta malgutasuna eraginkortasunez ordaintzen dugu. Edozein eragiketa egiteko, array osoa irakurri beharko duzu memorian, eta gero bertan aurkitu nahi duzun elementua - eta array-a hazten bada, abiadura degradatzen da.

Ikuspegi hori erabiltzen duen enpresetako batean (adibidez, Ubera), matrizeak 128 elementuko zatitan mozten dira. Eguneko 200 TBko datuen bolumena duten milaka neurgailuren datuak ez dira array batean gordetzen, biltegiratze logika bereziko 10 edo 30 matrizetan baizik.

Hurbilketa errazena kateekin da. Baina datuak gaizki konprimituta daude, taularen tamaina handia da eta kontsultak hainbat metrikatan oinarritzen direnean ere, ClickHouse-k ez du modu egokian funtzionatzen.

eskema hibridoa

Demagun array-eskema bat aukeratu dugula. Baina badakigu gure aginte-panel gehienek erabiltzaileen eta sistemaren neurketak soilik erakusten dituztela, neurri hauek taula mailan dagoen matrize bateko zutabeetan ere gauzatu ditzakegu modu honetan:

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);

Itsatsitakoan clickhouse automatikoki zenbatuko ditu. Horrela negozioak plazerarekin uztartu ditzakezu: eskema malgua eta orokorra da, baina gehien erabiltzen diren zutabeak atera ditugu. Kontuan hartzen dut horrek ez zuela txertaketa aldatzea eskatzen eta ETL, taulan matrizeak txertatzen jarraitzen duena. Egin berri dugu ALTER TABLE, bozgorailu pare bat gehitu eta berehala erabiltzen has zaitezkeen eskema hibrido eta azkarragoa lortu du.

Kodekak eta konpresioa

For denborazko serieak garrantzitsua da datuak zenbateraino biltzen dituzun, informazio-sorta oso handia izan baitaiteke. IN clickhouse 1:10, 1:20 eta batzuetan konpresioaren efektua lortzeko tresna multzo bat dago. Horrek esan nahi du diskoan konprimitu gabeko datu 1 TB 50-100 GB hartzen dituela. Tamaina txikiagoa ona da, datuak azkarrago irakurri eta prozesatu daitezke.

Konpresio maila altua lortzeko, clickhouse honako codec hauek onartzen ditu:

Taula adibidea:

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);

Hemen kodeka definitzen dugu Delta Bikoitza kasu batean, bigarrenean Gorilla, eta ziurtatu gehiago gehitzen duzula LZ4 konpresioa. Ondorioz, diskoko datuen tamaina asko murrizten da:

Honek datu berdinek zenbat leku hartzen duten erakusten du, baina kodek eta konpresio desberdinak erabiliz:

diskoko GZIP fitxategi batean;
ClickHousen kodek gabe, baina ZSTD konpresioarekin;
ClickHousen LZ4 eta ZSTD kodek eta konpresioarekin.

Kodekak dituzten taulek askoz leku gutxiago hartzen dutela ikus daiteke.

Tamaina gaiak

Ez da hain garrantzitsua Birbidali datu mota zuzena:

Goiko adibide guztietan erabili ditudan Karroza64. Baina aukeratzen badugu Karroza32orduan are hobea izango litzateke. Hau ondo frogatu zuten Perkonako mutilek goiko estekan dagoen artikuluan. Garrantzitsua da zereginari egokitzen zaion mota trinkoena erabiltzea: are gutxiago diskoaren tamainarako kontsulta-abiadurarako baino. clickhouse oso sentibera.

Erabili ahal baduzu intxnumx ordez intxnumx, orduan errendimendua ia bikoitza handitzea espero da. Datuek memoria gutxiago hartzen dute, eta "aritmetika" guztiak askoz azkarrago funtzionatzen du. clickhouse bere barruan oso zorrotz idatzitako sistema bat dago, sistema modernoek ematen dituzten aukera guztiak aprobetxatzen ditu.

Agregazioa eta Ikuspegi materializatuak

Agregazio eta ikuspegi materializatuei esker, hainbat alditarako agregatuak egin ditzakezu:

Esate baterako, iturburu-datuak ez-agregatuak izan ditzakezu, eta materializatutako hainbat ikuspegi erantsi ditzakezu batuketa automatikoarekin motor berezi baten bidez. SummingMergeTree (SMT). SMT agregatuak automatikoki zenbatzen dituen datu-egitura berezi bat da. Datu gordinak datu-basean txertatzen dira, automatikoki batzen dira eta aginte-panelak berehala erabil daitezke.

TTL - "ahaztu" datu zaharrak

Nola “ahaztu” jada beharrezkoak ez diren datuak? clickhouse badaki nola egin. Taulak sortzerakoan, zehaztu dezakezu TTL esamoldeak: adibidez, minutuko datuak egun baterako gordetzen ditugula, eguneko datuak 30 egunetarako, eta ez ditugula inoiz asteko edo hileko datuak ukitzen:

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 */

maila anitzeko - datuak diskoen artean zatitzea

Ideia hau garatuz, datuak gorde daitezke clickhouse leku ezberdinetan. Demagun azken asteko datu beroak toki oso azkar batean gorde nahi ditugula SSD, eta beste leku batean datu historiko gehiago gehitzen ditugu. IN clickhouse orain posible da:

Atxikipen politika konfigura dezakezu (biltegiratze politika) Beraz clickhouse automatikoki transferituko ditu datuak beste biltegiratze batera baldintza batzuk betetzen direnean.

Baina hori ez da guztia. Taula jakin baten mailan, datuak hotz biltegiratzera transferitzen direneko arauak defini ditzakezu. Esaterako, 7 eguneko datuak oso disko azkar batean daude, eta zaharragoa dena geldo batera transferitzen da. Hau ona da sistemari errendimendurik handiena mantentzea ahalbidetzen duelako, kostuak kontrolatuz eta datu hotzetan dirurik gastatu gabe:

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

Ezaugarri bereziak clickhouse

Ia dena barruan clickhouse badaude halako "aipagarrienak", baina esklusiboak berdintzen ditu - beste datu-baseetan ez dagoena. Adibidez, hona hemen ezaugarri berezi batzuk clickhouse:

Arrayak. Urtean clickhouse arrayetarako oso euskarri ona, baita haietan kalkulu konplexuak egiteko gaitasuna ere.
Datu-egiturak agregatzea. Hau da "hiltzaileen ezaugarrietako bat" clickhouse. Yandex-eko mutilek daturik ez dugula batu nahi esan arren, dena bateratuta dago. clickhouseazkarra eta erosoa delako.
Ikuspegi materializatuak. Datu-egiturekin bateratzearekin batera, materializatutako bistak erosoa egiteko aukera ematen dute real-time batuketa.
ClickHouse SQL. Hau hizkuntza luzapena da SQL bakarrik eskuragarri dauden ezaugarri osagarri eta esklusibo batzuekin clickhouse. Aurretik, luzapen bat zen, alde batetik, eta desabantaila bestetik. Orain ia gabezia guztiak alderatuta SQL 92 kendu dugu, orain luzapen bat besterik ez da.
Lambda-esamoldeak. Oraindik datu-baseren batean al daude?
ML-laguntza. Hau datu-base ezberdinetan dago, batzuk hobeak dira, beste batzuk okerragoak.
kode irekia. Zabaldu dezakegu clickhouse elkarrekin. Orain sartu clickhouse 500 laguntzaile inguru, eta kopuru hori etengabe hazten ari da.

Kontsulta zailak

В clickhouse gauza bera egiteko hainbat modu daude. Adibidez, hiru modu ezberdin daude taula bateko azken balioa itzultzeko CPU (laugarren bat ere badago, baina are exotikoagoa da).

Lehenengoak erakusten du zein erosoa den bertan egitea clickhouse kontsultak hori egiaztatu nahi duzunean tupla azpikontsultan jasotakoa. Pertsonalki beste datu-base batzuetan falta zitzaidan zerbait da. Zerbait azpikontsulta batekin alderatu nahi badut, beste datu-base batzuetan eskalar bat baino ezin da konparatu, eta hainbat zutabetarako idatzi behar dut ELKARTU. Urtean clickhouse tupla erabil dezakezu:

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

Bigarren moduak gauza bera egiten du baina funtzio agregatua erabiltzen du argMax:

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

В clickhouse hainbat dozena funtzio agregatu daude, eta konbinatzaileak erabiltzen badituzu, konbinatoriaren legeen arabera, horietako mila inguru lortzen dituzu. ArgMax - balio maximoa zenbatzen duen funtzioetako bat: kontsultak balioa itzultzen du erabilera_erabiltzailea, zeinetan gehienezko baliora iristen den sortu_at:

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

BATU ASOF - denbora ezberdineko errenkadak "kolatzea". Hau datu-baseetarako ezaugarri berezia da eta bertan bakarrik dago eskuragarri kdb+. Denbora ezberdineko bi denbora serie badaude, BATU ASOF eskaera batean aldatzeko eta itsasteko aukera ematen du. Denbora serie bateko balio bakoitzeko, beste bateko baliorik hurbilena aurkitzen da, eta lerro berean itzultzen dira:

Funtzio Analitikoak

Estandarra SQL-2003 honela idatzi dezakezu:

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;

В clickhouse hau ez da posible - ez du estandarra onartzen SQL-2003 eta seguruenik ez du inoiz egingo. Horren ordez, in clickhouse Ohikoa da honela idaztea:

Lambdak agindu nituen - hemen daude!

Hau estandarrean kontsulta analitiko baten analogoa da SQL-2003: biren arteko aldea zenbatzen du denbora-zigilua, iraupena, zenbaki ordinala - normalean funtzio analitikotzat hartzen dugun guztia. IN clickhouse matrizeen bidez zenbatzen ditugu: lehenik datuak array batean tolesten ditugu, ondoren nahi duguna egiten dugu matrizean, eta gero berriro zabaltzen ditugu. Ez da oso erosoa, programazio funtzionalarekiko maitasuna eskatzen du gutxienez, baina oso malgua da.

Ezaugarri bereziak

Gainera, barruan clickhouse ezaugarri espezializatu asko. Adibidez, nola zehaztu zenbat saio ari diren aldi berean martxan? Jarraipenerako ohiko zeregina eskaera bakarrean gehienezko karga zehaztea da. IN clickhouse horretarako funtzio berezi bat dago:

Oro har, ClickHousek funtzio bereziak ditu helburu askotarako:

runningDifference, runningAcumulatu, bizilaguna;
sumMap(gakoa, balioa);
timeSeriesGroupSum (uid, denbora-zigilua, balioa);
timeSeriesGroupRateSum(uid, denbora-zigilua, balioa);
skewPop, skewSamp, kurtPop, kurtSamp;
BETEKIN / GRABATAKIN;
SimpleLinearRegression, stochasticLinearRegression.

Hau ez da ezaugarrien zerrenda osoa, 500-600 besterik ez daude. Aholkua: funtzio guztiak barne clickhouse sistemaren taulan dago (guztiak ez daude dokumentatuta, baina guztiak interesgarriak dira):

select * from system.functions order by name

clickhouse bere buruari buruzko informazio asko gordetzen du, besteak beste erregistro-taulak, kontsulta_erregistroa, traza-erregistroa, eragiketa-erregistroa datu-blokeekin (zati_erregistroa), neurrien erregistroa eta sistemaren erregistroa, normalean diskoan idazten duena. Metrikoen erregistroa da denborazko serieak в clickhouse izan ere clickhouse: datu-baseak berak izan dezake zeregina denborazko serieak datu-baseak, horrela bere burua "irensten".

Hau ere gauza berezia da, lan ona egiten ari garelako denborazko serieakzergatik ezin dugu gure baitan gorde behar dugun guztia? Ez dugu behar Prometeo, dena geure baitan gordetzen dugu. Konektatuta Grafana eta geure buruaren jarraipena egiten dugu. Hala ere, bada clickhouse erorketak, ez dugu ikusiko -zergatik- horregatik normalean ez dute hori egiten.

Multzo handia edo txiki asko clickhouse

Zer da hobea - kluster handi bat edo ClickHouses txiki asko? Ikuspegi tradizionala DWH kluster handi bat da eta bertan aplikazio bakoitzerako eskemak esleitzen dira. Datu-basearen administratzailera iritsi ginen - eman eskema bat eta eman ziguten:

В clickhouse ezberdin egin dezakezu. Aplikazio bakoitza zurea egin dezakezu clickhouse:

Ez dugu gehiago munstro handiaren beharrik DWH eta administrari konponezinak. Aplikazio bakoitzari berea eman diezaiokegu clickhouse, eta garatzaileak berak egin dezake, geroztik clickhouse oso erraza da instalatzen eta ez du administrazio konplexurik behar:

Baina asko badugu clickhouse, eta askotan ezarri behar duzu, orduan prozesu hau automatizatu nahi duzu. Horretarako, adibidez, erabil dezakegu Kubernetes и clickhouse-operadore. IN Kubernetes ClickHouse "on klik" jar dezakezu: botoi bat sakatu dezaket, manifestua exekutatu eta datu-basea prest dago. Berehala sor dezakezu eskema bat, neurketak bertan kargatzen has zaitezke eta 5 minuturen buruan aginte-panela prest daukat Grafana. Hain sinplea da!

Emaitza?

Horrela, clickhouse - Hau:

azkar. Denek dakite hau.
besterik. Apur bat eztabaidagarria, baina ikastea zaila dela iruditzen zait, borrokatzea erraza. Nola ulertzen baduzu clickhouse funtzionatzen du, orduan dena oso erraza da.
Unibertsalki. Egoera ezberdinetarako egokia da: DWH, Denbora Seriea, Erregistro Biltegiratzea. Baina ez da OLTP datu-basea, beraz, ez saiatu txertaketa eta irakurketa laburrak egiten bertan.
Interesgarria. Seguruenik, lan egiten duena clickhouse, minutu interesgarri asko bizi izan zituen zentzu onean eta txarrean. Adibidez, kaleratze berri bat atera zen, dena funtzionatzeari utzi zion. Edo bi egunetan zeregin batekin borrokatu zenuenean, baina Telegrameko txatean galdera baten ondoren, zeregina bi minututan konpondu zen. Edo, Lesha Milovidoven txosteneko hitzaldian bezala, pantaila-argazki bat clickhouse emankizuna hautsi zuen High Load++. Gauza mota hauek uneoro gertatzen dira eta gure bizitza egiten dute clickhouse argia eta interesgarria!

Aurkezpena ikusi ahal izango da Hemen.

Karga handiko sistemen garatzaileen aspaldiko bilera High Load++ azaroaren 9an eta 10ean izango da Skolkovon. Azkenik, lineaz kanpoko konferentzia bat izango da (neurri guztiekin bada ere), HighLoad++-ren energia ezin baita linean paketatu.

Jardunaldirako, teknologiaren aukeren gehieneko kasuak aurkitu eta erakusten dizkizugu: HighLoad ++ izan zen, da eta izango da bi egunetan Facebook, Yandex, VKontakte, Google eta Amazon nola funtzionatzen duten ikasteko leku bakarra.

2007tik gure bilerak etenik gabe eginda, aurten 14. aldiz elkartuko gara. Denbora horretan, biltzarra 10 aldiz hazi da, iaz industriaren funtsezko ekitaldiak 3339 parte hartzaile bildu zituen, 165 txosten eta topaketen hizlari, eta 16 abesti aldi berean jotzen ari ziren.
Iaz 20 autobus zeuden zuretzat, 5280 litro te eta kafe, 1650 litro fruta edari eta 10200 botila ur. Eta beste 2640 kilo janari, 16 plater eta 000 edalontzi. Bide batez, birziklatutako paperarekin bildutako diruarekin 25 haritz kimu landatu ditugu 🙂

Sarrerak eros daitezke Hemen, jaso hitzaldiari buruzko berriak — Hemen, eta hitz egin sare sozial guztietan: Telegrama, Facebook, Vkontakte и Twitter.

Iturria: www.habr.com

ClickHousera mugitzea: 3 urte geroago