Ferhúzje nei ClickHouse: 3 jier letter

Trije jier lyn Viktor Tarnavsky en Alexey Milovidov út Yandex op it poadium HighLoad++ fertelde, hoe goed ClickHouse is, en hoe't it net fertrage. En op it folgjende poadium wie der Alexander Zaitsev с melde oer ferhúzjen nei klikhûs fan in oare analytyske DBMS en mei de konklúzje dat klikhûs, fansels, goed, mar net hiel handich. Wannear yn 2016 it bedriuw LifeStreet, dêr't Alexander doe wurke, wie it konvertearjen fan in multi-petabyte analytysk systeem nei klikhûs, it wie in fassinearjende "giele bakstienwei" fol mei ûnbekende gefaren - klikhûs doe like it op in minefjild.

Trije jier letter klikhûs waard folle better - yn dizze tiid Alexander stifte it bedriuw Altinity, dat net allinnich helpt minsken ferhúzje nei klikhûs tsientallen projekten, mar ek ferbetteret it produkt sels tegearre mei kollega út Yandex. No klikhûs noch altyd gjin soargeleaze kuiertocht, mar gjin mynfjild mear.

Alexander hat wurke mei ferspraat systemen sûnt 2003, it ûntwikkeljen fan grutte projekten op MySQL, Oracle и Fertikaal. Op de lêste HighLoad++ 2019 Alexander, ien fan 'e pioniers fan it brûken klikhûs, fertelde wat dizze DBMS no is. Wy sille leare oer de wichtichste funksjes klikhûs: hoe't it ferskilt fan oare systemen en yn hokker gefallen it effektiver is om it te brûken. Mei help fan foarbylden sille wy sjen nei resinte en projekt-teste praktiken foar it bouwen fan systemen basearre op klikhûs.

Retrospektyf: wat barde 3 jier lyn

Trije jier lyn hawwe wy it bedriuw oerdroegen LifeStreet op klikhûs fan in oare analytyske database, en de migraasje fan advertinsjenetwurkanalytika seach der sa út:

• juny 2016. Yn Iepen Boarne ferskynde klikhûs en ús projekt begûn;
• Augustus Bewiis fan konsept: grut reklame netwurk, ynfrastruktuer en 200-300 terabytes oan gegevens;
• Oktober. Earste produksjegegevens;
• Desimber. De folsleine produktlading is 10-50 miljard eveneminten per dei.
• june 2017. Súksesfolle migraasje fan brûkers nei klikhûs, 2,5 petabytes oan gegevens op in kluster fan 60 tsjinners.

Tidens it migraasjeproses wie d'r in groeiend begryp dat klikhûs is in goed systeem dat noflik is om mei te wurkjen, mar dit is in ynterne projekt fan Yandex. Dêrom binne d'r nuânses: Yandex sil earst omgean mei har eigen ynterne klanten en allinich dan mei de mienskip en de behoeften fan eksterne brûkers, en ClickHouse hat doe it bedriuwsnivo net berikt yn in protte funksjonele gebieten. Dêrom hawwe wy Altinity yn maart 2017 oprjochte om te meitsjen klikhûs noch flugger en handiger net allinnich foar Yandex, mar ek foar oare brûkers. En no wy:

• Wy traine en helpe te bouwen oplossingen basearre op klikhûs sadat klanten net yn de problemen komme, en sadat de oplossing úteinlik wurket;
• Wy jouwe 24/7 stipe klikhûs- ynstallaasjes;
• Wy ûntwikkelje ús eigen ekosysteemprojekten;
• Wy sette ús aktyf yn foar ússels klikhûs, reagearje op oanfragen fan brûkers dy't bepaalde funksjes sjen wolle.

En fansels, wy helpe mei ferhuzing nei klikhûs с MySQL, Fertikaal, Oracle, Greenplum, Redshift en oare systemen. Wy binne belutsen by in ferskaat oan bewegingen, en se hawwe allegear suksesfol west.

Wêrom ferhúzje nei klikhûs

Fertraget net! Dit is de wichtichste reden. klikhûs - heul rappe database foar ferskate senario's:

Willekeurige sitaten fan minsken dy't al lang mei minsken wurkje klikhûs.

Scalability. Op guon oare databank kinne jo berikke goede prestaasjes op ien stik hardware, mar klikhûs jo kinne net allinich fertikaal skaalje, mar ek horizontaal, gewoan troch tsjinners ta te foegjen. Alles wurket net sa soepel as wy wolle, mar it wurket. Jo kinne it systeem útwreidzje as jo bedriuw groeit. It is wichtich dat wy no net beheind wurde troch de oplossing en dat d'r altyd potinsjeel is foar ûntwikkeling.

Portabiliteit. Der is gjin hechting oan ien ding. Bygelyks, mei Amazon RedShift It is dreech om earne te ferhúzjen. IN klikhûs jo kinne it ynstallearje op jo laptop, server, ynsette it nei de wolk, gean nei Kubernetes - d'r binne gjin beheiningen foar de eksploitaasje fan 'e ynfrastruktuer. Dit is handich foar elkenien, en dit is in grut foardiel dat in protte oare ferlykbere databases net kinne opskeppe.

Fleksibiliteit. klikhûs stopet net by ien ding, bygelyks Yandex.Metrica, mar ûntwikkelet en wurdt brûkt yn mear en mear ferskillende projekten en yndustry. It kin útwreide wurde troch it tafoegjen fan nije mooglikheden om nije problemen op te lossen. Bygelyks, wurdt leaud dat it opslaan fan logs yn in databank is minne manieren, dus se kamen mei Elastyskesearch. Mar tank oan fleksibiliteit klikhûs, Jo kinne ek opslaan logs yn it, en faaks dit is noch better as yn Elastyskesearch - yn klikhûs dit fereasket 10 kear minder izer.

Frij Open Source. Jo hoege foar neat te beteljen. D'r is gjin ferlet om tastimming te ûnderhanneljen om it systeem op jo laptop of server te ynstallearjen. Gjin ferburgen fergoedingen. Tagelyk kin gjin oare Open Source-databasetechnology yn snelheid konkurrearje klikhûs. MySQL, MariaDB, Greenplum - se binne allegear folle stadiger.

Mienskip, ride en wille. Hast klikhûs poerbêst mienskip: meetups, petearen en Alexey Milovidov, dy't charges ús allegearre mei syn enerzjy en optimisme.

Ferhúzje nei ClickHouse

Gean nei klikhûs om ien of oare reden hawwe jo mar trije dingen nedich:

• Begryp de beheiningen klikhûs en wat it is net geskikt foar.
• Foardiel nimme technology en syn grutste sterke punten.
• Eksperimint. Sels begripe hoe't it wurket klikhûs, it is net altyd mooglik om te foarsizzen wannear't it flugger sil wêze, wannear't it stadiger sil, wannear't it better sil en wannear't it slimmer sil. Dus besykje it.

Moving probleem

Der is mar ien "mar": as jo ferhúzje nei klikhûs fan wat oars, dan giet meastal wat mis. Wy binne wend oan guon praktiken en dingen dy't wurkje yn ús favorite databank. Bygelyks, elkenien dy't wurket mei SQL-databases beskôgje de folgjende set funksjes ferplicht:

• transaksjes;
• beheiningen;
• konsistinsje;
• yndeksen;
• UPDATE / DELETE;
• NULLs;
• millisekonden;
• automatyske type casts;
• meardere joins;
• willekeurige partysjes;
• kluster behear ark.

Werving is ferplichte, mar trije jier lyn yn klikhûs Gjin fan dizze funksjes wiene beskikber! No bliuwt minder as de helte fan wat net útfierd is: transaksjes, beheiningen, Konsistinsje, millisekonden en type casting.

En it wichtichste is dat yn klikhûs guon standert praktiken en oanpak net wurkje of wurkje oars as wy binne wend oan. Alles dat ferskynt yn klikhûs, stimt oerien mei "ClickHouse manier", d.w.s. funksjes ferskille fan oare databases. Bygelyks:

• Yndeksen wurde net selektearre, mar oerslein.
• UPDATE / DELETE net syngroane, mar asynchronous.
• D'r binne meardere joins, mar d'r is gjin queryplanner. Hoe't se dan útfierd wurde, is foar minsken út de databankwrâld oer it algemien net sa dúdlik.

ClickHouse Scripts

Yn 1960, in Amerikaanske wiskundige fan Hongaarske komôf Wigner EP skreau in artikel "De ûnferstannige effektiviteit fan wiskunde yn 'e natuerwittenskippen" ("De ûnbegryplike effektiviteit fan wiskunde yn 'e natuerwittenskippen") dat de wrâld om ús hinne om ien of oare reden goed beskreaun wurdt troch wiskundige wetten. Wiskunde is in abstrakte wittenskip, en fysike wetten útdrukt yn wiskundige foarm binne net triviaal, en Wigner EP beklamme dat dit is hiel nuver.

Út myn eachpunt, klikhûs - deselde nuverens. Om Wigner opnij te formulearjen, kinne wy ​​dit sizze: de ûnfoarstelbere effisjinsje is ferrassend klikhûs yn in grut ferskaat oan analytyske applikaasjes!

Bygelyks, lit ús nimme Real-Time Data Warehouse, wêryn gegevens hast kontinu laden wurde. Wy wolle der mei in twadde fertraging oanfragen fan ûntfange. Asjebleaft - brûk it klikhûs, om't dit it senario is wêrfoar it is ûntwurpen. klikhûs dit is krekt hoe't it wurdt brûkt net allinich op it web, mar ek yn marketing en finansjele analytyk, AdTech,as yn Fraude opspoarenn. YN Real-time Data Warehouse in kompleks strukturearre skema as "stjer" of "snievlok" wurdt brûkt, in protte tabellen mei JOIN (soms meardere), en de gegevens wurde meastal opslein en feroare yn guon systemen.

Litte wy in oar senario nimme - Tiidrige: tafersjoch op apparaten, netwurken, gebrûk statistyk, Ynternet fan dingen. Hjir komme wy frij ienfâldige foarfallen tsjin, oardere yn 'e tiid. klikhûs waard oarspronklik net ûntwikkele foar dit, mar hat sjen litten te wurkjen goed, dat is wêrom grutte bedriuwen brûke klikhûs as repository foar tafersjoch op ynformaasje. Om te ûndersykjen oft it geskikt is klikhûs foar tiidsearjes makken wy in benchmark basearre op 'e oanpak en resultaten InfluxDB и TiidskaalDB - spesjalisearre tiid-rige databases. It die bliken, dat klikhûs, sels sûnder optimisaasje foar sokke taken, wint op in frjemd fjild:

В tiid-rige Meastentiids wurdt in smelle tafel brûkt - ferskate lytse kolommen. In protte gegevens kinne komme fan tafersjoch - miljoenen records per sekonde - en se komme normaal yn lytse bursts (Echt-tiid streaming). Dêrom is in oar ynfoegjeskript nedich, en de fragen sels hawwe har eigen spesifikaasjes.

Logbehear. It sammeljen fan logs yn in databank is meastal min, mar klikhûs dit kin dien wurde mei guon opmerkings lykas hjirboppe beskreaun. In protte bedriuwen brûke klikhûs krekt foar dit doel. Yn dit gefal brûke wy in platte brede tafel wêr't wy de folsleine logs opslaan (bygelyks yn 'e foarm JSON), of yn stikken snije. Gegevens wurde meastal laden yn grutte batches (bestannen), en wy sykje troch guon fjild.

Foar elk fan dizze funksjes wurde meastal spesjalisearre databases brûkt. klikhûs men kin it allegearre en sa goed, dat it harren oertsjûget. Litte wy no in tichterby sjen tiid-rige senario, en hoe te "cook" korrekt klikhûs foar dit senario.

Tiid-Series

Op it stuit is dit it wichtichste senario wêrfoar klikhûs beskôge as de standert oplossing. Tiidrige is in set fan eveneminten oardere yn 'e tiid, fertsjintwurdiget feroarings yn guon proses oer de tiid. Dit kin bygelyks de hertslach per dei wêze as it oantal prosessen yn it systeem. Alles dat jout tiid tiken mei guon ôfmjittings is tiid-rige:

De measte fan dizze soarten eveneminten komme fan tafersjoch. Dit kin net allinich it kontrolearjen fan it web wêze, mar ek echte apparaten: auto's, yndustriële systemen, IoT, fabriken of ûnbemanne taksys, yn 'e kofferbak wêrfan Yandex al set klikhûs-tsjinner.

Der binne bygelyks bedriuwen dy't gegevens fan skippen sammelje. Elke pear sekonden stjoere sensoren op it kontenerskip hûnderten ferskillende mjittingen. Yngenieurs bestudearje se, bouwe modellen en besykje te begripen hoe effisjint it skip wurdt brûkt, om't in kontenerskip net ien sekonde idle moat. Elke downtime is in jildferlies, dus it is wichtich om de rûte te foarsizzen sadat stopjes minimaal binne.

Tsjintwurdich is d'r in groei fan spesjalisearre databases dy't mjitte tiid-rige. Op de side DB-motoren De ferskate databases wurde op ien of oare manier rangearre, en jo kinne se besjen op type:

It rapst groeiende type is tiid riges. Grafyske databases groeie ek, mar tiid riges binne de ôfrûne jierren hurder groeid. Typyske fertsjintwurdigers fan dizze famylje fan databases binne InfluxDB, Prometheus, KDB, TiidskaalDB (oanboud PostgreSQL), oplossings út Amazon. klikhûs kin hjir ek brûkt wurde, en wurdt brûkt. Lit my jo in pear iepenbiere foarbylden jaan.

Ien fan de pioniers is it bedriuw CloudFlare (CDN-oanbieder). Se kontrolearje har CDN через klikhûs (DNS-oanfragen, HTTP-queries) mei in enoarme lading - 6 miljoen eveneminten per sekonde. Alles giet troch Kafka, giet nei klikhûs, dy't de kâns biedt om dashboards fan eveneminten yn it systeem yn echt tiid te sjen.

Comcast - ien fan 'e lieders yn telekommunikaasje yn' e FS: Ynternet, digitale televyzje, telefony. Se makken in ferlykber kontrôlesysteem CDN binnen it ramt Open Source it projekt Apache Traffic Control om te wurkjen mei jo enoarme gegevens. klikhûs brûkt as backend foar analytics.

percona ynboud klikhûs yn dyn PMMte bewarjen tafersjoch fan ferskate MySQL.

Spesifike easken

Time-searje databases hawwe har eigen spesifike easken.

• Snelle ynfoegje fan in protte aginten. Wy moatte gegevens fan in protte streamen heul fluch ynfoegje. klikhûs It docht dit goed, om't al syn ynserts net blokkearje. Elk ynfoegje is in nije triem op skiif, en lytse ynfoegingen kinne wurde buffered yn ien of oare wize. YN klikhûs It is better om gegevens yn grutte batches yn te foegjen as ien rigel tagelyk.
• Fleksibele skema. de tiid-rige wy kenne de gegevensstruktuer meastentiids net folslein. It is mooglik om in tafersjochsysteem te bouwen foar in spesifike applikaasje, mar dan is it lestich om it te brûken foar in oare applikaasje. Dit freget om in fleksibeler skema. klikhûs, kinne jo dwaan dit, ek al is it in sterk typearre basis.
• Effisjinte opslach en ferjitten fan gegevens. Gewoanlik yn tiid-rige in grutte hoemannichte gegevens, sadat se sa effisjint mooglik opslein wurde moatte. Bygelyks, at InfluxDB goede kompresje is syn wichtichste skaaimerk. Mar neist it opslaan, moatte jo ek âlde gegevens "ferjitte" kinne en wat dwaan downsampling - automatyske tellen fan aggregaten.
• Snelle fragen oer aggregearre gegevens. Soms is it nijsgjirrich om te sjen nei de lêste 5 minuten mei in krektens fan millisekonden, mar op moanlikse gegevens minuten of twadde granularity kin net nedich wêze - algemiene statistiken binne genôch. Stipe fan dit soarte is nedich, oars sil in fersyk foar 3 moannen in heul lang duorje om sels yn te foltôgjen klikhûs.
• Fersiken lykas "lêste punt, as fan». Dizze binne typysk foar tiid-rige queries: sjoch op de lêste mjitting of steat fan it systeem op in momint yn 'e tiid t. Dit binne net heul noflike fragen foar in databank, mar jo moatte se ek útfiere kinne.
• "Gluing" tiid rige. Tiidrige is in tiid rige. As d'r twa tiidsearjes binne, moatte se faak ferbûn en korreleare wurde. It is net handich om dit te dwaan op alle databases, benammen mei unaligned tiidsearjes: hjir binne guon tiidpunten, der binne oaren. Jo kinne beskôgje gemiddelde, mar ynienen sil der noch in gat dêr, dus it is net dúdlik.

Litte wy sjen hoe't dizze easken foldien wurde klikhûs.

De regeling

В klikhûs skema foar tiid-rige kin dien wurde op ferskate wizen, ôfhinklik fan de graad fan regelmjittigens fan de gegevens. It is mooglik om in systeem op reguliere gegevens te bouwen as wy alle metriken fan tefoaren kenne. Bygelyks, ik die dit CloudFlare mei tafersjoch CDN is in goed optimalisearre systeem. Jo kinne in mear algemien systeem bouwe dat de heule ynfrastruktuer en ferskate tsjinsten kontrolearret. Yn it gefal fan ûnregelmjittige gegevens witte wy net fan tefoaren wat wy kontrolearje - en dit is wierskynlik it meast foarkommende gefal.

Reguliere gegevens. Pylder. It skema is ienfâldich - kolommen mei de fereaske soarten:

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

Dit is in gewoane tabel dy't in soarte fan systeemladingsaktiviteit kontrolearret (brûker, systeem, idle, nice). Ienfâldich en handich, mar net fleksibel. As wy in fleksibeler skema wolle, dan kinne wy ​​arrays brûke.

Unregelmjittige gegevens. Arrays:

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

struktuer Nêsten binne twa arrays: metrics.name и metrics.value. Hjir kinne jo sokke willekeurige tafersjochgegevens opslaan as in array fan nammen en in array fan mjittingen foar elk barren. Foar fierdere optimalisaasje, ynstee fan ien sa'n struktuer, kinne jo ferskate meitsje. Bygelyks, ien foar driuwe-wearde, oar - foar int- betsjut omdat int Ik wol effisjinter bewarje.

Mar sa'n struktuer is dreger te berikken. Jo moatte in spesjale konstruksje brûke, mei help fan spesjale funksjes om de wearden fan earst de yndeks en dan de array út te lûken:

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

Mar it wurket noch altyd frij fluch. In oare manier om unregelmjittige gegevens op te slaan is per rigel.

Unregelmjittige gegevens. Strings. Yn dizze tradisjonele metoade, sûnder arrays, wurde nammen en wearden tagelyk opslein. As 5 mjittingen fan ien apparaat tagelyk komme, wurde 000 rigen generearre yn 'e databank:

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

klikhûs omgaat mei dit - it hat spesjale tafoegings klikhûs SQL. Bygelyks maxIf - in spesjale funksje dy't it maksimum troch in metrysk berekkent as oan ien of oare betingst foldien is. Jo kinne ferskate sokke útdrukkingen yn ien fersyk skriuwe en fuortendaliks de wearde foar ferskate metriken berekkenje.

Litte wy trije oanpak fergelykje:

details

Hjir haw ik tafoege "Disk Data Grutte" foar guon test gegevens set. Yn it gefal fan kolommen hawwe wy de lytste gegevensgrutte: maksimale kompresje, maksimale query-snelheid, mar wy betelje troch alles yn ien kear op te nimmen.

Yn it gefal fan arrays is alles wat slimmer. De gegevens binne noch goed komprimearre en in unregelmjittich patroan kin wurde opslein. Mar klikhûs - in columnar databank, en as wy begjinne te bewarjen alles yn in rige, it feroaret yn in rige ien, en wy betelje foar fleksibiliteit mei effisjinsje. Foar elke operaasje moatte jo de heule array yn it ûnthâld lêze, dan it winske elemint dêryn fine - en as de array groeit, dan wurdt de snelheid degradearre.

Yn ien fan 'e bedriuwen dy't dizze oanpak brûkt (bgl. uber), arrays wurde snien yn stikken fan 128 eleminten. Gegevens fan ferskate tûzen metriken mei in folume fan 200 TB oan gegevens / dei wurde opslein net yn ien array, mar yn 10 of 30 arrays mei spesjale opslachlogika.

De ienfâldichste oanpak is mei snaren. Mar de gegevens binne min komprimearre, de tabelgrutte is grut, en sels as queries basearre binne op ferskate metriken, wurket ClickHouse net optimaal.

Hybride skema

Lit ús oannimme dat wy hawwe keazen in array circuit. Mar as wy witte dat de measte fan ús dashboards allinich brûkers- en systeemmetriken sjen litte, kinne wy ​​dizze metriken ek materialisearje yn kolommen fan in array op tabelnivo op dizze manier:

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

By it ynfoegjen klikhûs sil automatysk telle se. Op dizze manier kinne jo bedriuw mei wille kombinearje: it skema is fleksibel en algemien, mar wy hawwe de meast brûkte kolommen útlutsen. Tink derom dat dit net nedich feroarjen fan de ynfoegje en ETLdy't bliuwt ynfoegje arrays yn 'e tabel. Wy diene gewoan ALTER TABEL, in pear sprekkers tafoege en wy krigen in hybride en flugger skema dat jo direkt kinne begjinne te brûken.

Codecs en kompresje

foar tiid-rige It makket út hoe goed jo de gegevens ynpakke, om't de hoemannichte ynformaasje heul grut kin wêze. YN klikhûs D'r is in set ark om in kompresje-effekt te berikken fan 1:10, 1:20, en soms mear. Dit betsjut dat 1 TB oan útpakte gegevens op 'e skiif 50-100 GB nimt. Lytsere grutte is goed, gegevens kinne wurde lêzen en ferwurke flugger.

Om in heech nivo fan kompresje te berikken, klikhûs stipet de folgjende codecs:

Foarbyld tabel:

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

Hjir definiearje wy de codec DoubleDelta yn ien gefal, yn it twadde - Gorilla, en wy sille grif tafoegje mear LZ4 kompresje. As resultaat wurdt de grutte fan 'e gegevens op skiif sterk fermindere:

Dit lit sjen hoefolle romte deselde gegevens ynnimme, mar mei ferskate codecs en kompresjes:

• yn in GZIP-bestân op skiif;
• yn ClickHouse sûnder codecs, mar mei ZSTD-kompresje;
• yn ClickHouse mei codecs en kompresje LZ4 en ZSTD.

It kin sjoen wurde dat tabellen mei codecs folle minder romte nimme.

Grutte saken

Net minder wichtich kies juste gegevenstype:

Yn alle foarbylden hjirboppe haw ik brûkt Float 64. Mar as wy kieze Float 32, dan soe dat noch better wêze. Dit waard goed oantoand troch de jonges fan Perkona yn it hjirboppe keppele artikel. It is wichtich om it meast kompakte type te brûken dat geskikt is foar de taak: noch minder foar skiifgrutte as foar querysnelheid. klikhûs tige gefoelich foar dit.

As jo ​​kinne brûke intxnumx вместо intxnumx, ferwachtsje dan in hast twa kear ferheging fan prestaasjes. De gegevens nimt minder ûnthâld, en alle "rekenen" wurket folle flugger. klikhûs yntern is it in tige strang typearre systeem; it makket maksimaal gebrûk fan alle mooglikheden dy't moderne systemen biede.

Aggregaasje en Materialisearre werjeften

Aggregaasje en materialisearre werjeften kinne jo aggregaten meitsje foar ferskate gelegenheden:

Jo kinne bygelyks net-aggregearre boarnegegevens hawwe, en jo kinne ferskate materialisearre werjeften oan har heakje mei automatyske gearfetting fia in spesjale motor SummingMergeTree (SMT). SMT is in spesjale aggregearjende gegevensstruktuer dy't aggregaten automatysk berekkent. Raw gegevens wurde ynfoege yn de databank, it wurdt automatysk aggregearre, en dashboards kinne wurde brûkt fuortendaliks op it.

TTL - "ferjitte" âlde gegevens

Hoe kinne jo gegevens "ferjitte" dy't net mear nedich binne? klikhûs wit hoe te dwaan dit. By it meitsjen fan tabellen, kinne jo oantsjutte TTL útdrukkingen: bygelyks dat wy minútgegevens foar ien dei opslaan, deistige gegevens foar 30 dagen, en nea wyklikse of moanlikse gegevens oanreitsje:

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

Multi-tier - dielen gegevens oer skiven

Troch dit idee fierder te nimmen, kinne gegevens wurde opslein yn klikhûs op ferskate plakken. Stel dat wy hot gegevens foar de lêste wike wolle opslaan op in heul rappe lokale SSD, en wy sette mear histoaryske gegevens op in oar plak. YN klikhûs dit is no mooglik:

Jo kinne in opslachbelied konfigurearje (opslach belied) Dus klikhûs sil automatysk gegevens oerdrage by it berikken fan bepaalde betingsten nei in oare opslach.

Mar dat is net alles. Op it nivo fan in spesifike tabel kinne jo regels definiearje foar krekt wannear't de gegevens yn kâlde opslach geane. Bygelyks, gegevens wurde opslein op in hiel flugge skiif foar 7 dagen, en alles dat is âlder wurdt oerdroegen oan in trage. Dit is goed, om't jo it systeem op maksimale prestaasjes kinne hâlde, wylst de kosten kontrolearje en gjin jild fergrieme oan kâlde gegevens:

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

Unike kânsen klikhûs

Yn hast alles klikhûs D'r binne sokke "hichtepunten", mar se wurde kompensearre troch eksklusiviteit - iets dat net yn oare databases is. Hjir binne bygelyks guon fan 'e unike funksjes klikhûs:

• Arrays. de klikhûs heul goede stipe foar arrays, lykas de mooglikheid om komplekse berekkeningen derop út te fieren.
• Aggregearjen fan gegevensstruktueren. Dit is ien fan 'e "killer funksjes" klikhûs. Nettsjinsteande it feit dat de jonges fan Yandex sizze dat wy gjin gegevens wolle aggregearje, is alles aggregearre yn klikhûs, want it is fluch en handich.
• Materialisearre werjeften. Tegearre mei it aggregearjen fan gegevensstruktueren kinne materialisearre werjeften jo handich meitsje Echt-tiid aggregaasje.
• ClickHouse SQL. Dit is in taalútwreiding SQL mei wat ekstra en eksklusive funksjes dy't allinnich beskikber binne yn klikhûs. Earder wie it oan de iene kant in útwreiding en oan de oare kant in neidiel. No hast alle neidielen ferlike mei SQL 92 wy hawwe it fuorthelle, no is it mar in útwreiding.
• Lambda- útdrukkingen. Binne se noch yn in databank?
• ML-stypje. Dit is beskikber yn ferskate databases, guon binne better, guon binne slimmer.
• iepen Boarne. Wy kinne útwreidzje klikhûs mei-inoar. No yn klikhûs oer 500 meiwurkers, en dit oantal wurdt hieltyd groeit.

Tûke fragen

В klikhûs d'r binne in protte ferskillende manieren om itselde ding te dwaan. Jo kinne bygelyks werom de lêste wearde út in tabel yn trije ferskillende wizen foar CPU (der is ek in fjirde, mar it is noch eksoatysker).

De earste lit sjen hoe handich it is om yn te dwaan klikhûs queries as jo wolle kontrolearje dat tuple opnommen yn 'e subquery. Dit is iets dat ik persoanlik echt miste yn oare databases. As ik wat fergelykje wol mei in subquery, dan kin yn oare databases allinich in skalaar mei fergelike wurde, mar foar ferskate kolommen moat ik skriuwe JOIN. de klikhûs jo kinne tuple brûke:

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

De twadde metoade docht itselde ding, mar brûkt in aggregaatfunksje argMax:

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

В klikhûs D'r binne ferskate tsientallen aggregaatfunksjes, en as jo kombinators brûke, dan sille jo neffens de wetten fan kombinatorika sa'n tûzen krije. ArgMax - ien fan 'e funksjes dy't de maksimale wearde berekkent: it fersyk jout de wearde werom usage_user, wêrby't de maksimale wearde wurdt berikt makke_at:

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

ASOF JOIN - "lijm" rigen mei ferskillende tiden. Dit is in unike funksje foar databases dy't allinnich beskikber is yn kdb+. As d'r twa tiidsearjes binne mei ferskillende tiden, ASOF JOIN kinne jo ferpleatse en gearfoegje se yn ien fersyk. Foar elke wearde yn ien tiidrige wurdt de tichtste wearde yn 'e oare fûn, en se wurde weromjûn op deselde rigel:

Analytyske funksjes

Yn de standert SQL-2003 jo kinne sa skriuwe:

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;

В klikhûs Jo kinne dat net dwaan - it stipet de standert net SQL-2003 en wierskynlik sil it noait dwaan. Ynstee, yn klikhûs It is gewoanlik om sa te skriuwen:

Ik beloofde lambda's - hjir binne se!

Dit is in analoog fan 'e analytyske query yn' e standert SQL-2003: hy telt it ferskil tusken de twa tiidstempel, doer, rangnûmer - alles dat wy normaal beskôgje analytyske funksjes. YN klikhûs Wy telle se troch arrays: earst brekke wy de gegevens yn in array, dêrnei dogge wy alles wat wy wolle op 'e array, en dan wreidzje wy it werom. It is net heul handich, it fereasket op syn minst in leafde foar funksjonele programmearring, mar it is heul fleksibel.

Special Features

Boppedat, yn klikhûs in protte spesjalisearre funksjes. Hoe kinne jo bygelyks bepale hoefolle sesjes tagelyk plakfine? In typyske tafersjochtaak is om de maksimale lading te bepalen mei ien fersyk. YN klikhûs Der is in spesjale funksje foar dit doel:

Yn 't algemien hat ClickHouse spesjale funksjes foar in protte doelen:

• runningDifference, runningAccumulate, buorman;
• sumMap(kaai, wearde);
• timeSeriesGroupSum(uid, timestamp, value);
• timeSeriesGroupRateSum(uid, timestamp, value);
• skewPop, skewSamp, kurtPop, kurtSamp;
• WITH FILL / WITH TIES;
• simpleLinearRegression, stochasticLinearRegression.

Dit is net in folsleine list fan funksjes, der binne 500-600 yn totaal. Hint: alle funksjes yn klikhûs is yn 'e systeemtabel (net allegear binne dokumintearre, mar allegear binne ynteressant):

select * from system.functions order by name

klikhûs it bewarret in soad ynformaasje oer himsels, ynklusyf log tabellen, query_log, trace log, log fan operaasjes mei gegevensblokken (diel_log), metrike log, en systeem log, dat it normaal skriuwt op skiif. Log metriken is tiid-rige в klikhûs yn feite klikhûs: De databank sels kin in rol spylje tiid-rige databases, en dus sels "opsnuorje".

Dit is ek in unyk ding - sûnt wy dogge in goede baan foar tiid-rige, Wêrom kinne wy ​​net bewarje alles wat wy nedich binne yn ússels? Wy hawwe net nedich Prometheus, wy hâlde alles foar ússels. Ferbûn grafana en wy kontrolearje ússels. Lykwols, as klikhûs falt, wy sille net sjen wêrom, sadat se meastentiids net dogge dat.

Grutte kluster of in protte lytse klikhûs

Wat is better - ien grut kluster of in protte lytse ClickHouses? Tradisjonele oanpak fan DWH is in grut kluster wêryn circuits wurde tawiisd foar eltse applikaasje. Wy kamen by de databasebehearder - jou ús in diagram, en se joegen ús ien:

В klikhûs do kinst it oars. Jo kinne elke applikaasje jo eigen meitsje klikhûs:

Wy hawwe de grutte meunsterlike net mear nedich DWH en intractable admins. Wy kinne elke applikaasje syn eigen jaan klikhûs, en de ûntwikkelder kin it sels dwaan, sûnt klikhûs heul maklik te ynstallearjen en hat gjin komplekse administraasje nedich:

Mar as wy hawwe in protte klikhûs, en jo moatte it faak ynstallearje, dan wolle jo dit proses automatisearje. Dêrfoar kinne wy ​​bygelyks brûke Kubernetes и klikhûs-operator. YN Kubernetes ClickHouse do kinst sette it "op-klik": Ik kin klikke op in knop, rinne it manifest en de databank is klear. Ik kin fuortendaliks meitsje in diagram, begjinne te uploaden metrics dêr, en yn 5 minuten Ik haw in dashboard klear grafana. It is sa ienfâldich!

Wat op it ein?

En sa, klikhûs - Dit:

• Fluch. Elkenien wit dit.
• Simply. In bytsje kontroversjeel, mar ik leau dat it lestich is yn training, maklik yn gefjocht. As jo ​​begripe hoe klikhûs it wurket, dan is alles hiel ienfâldich.
• Universeel. It is geskikt foar ferskate senario's: DWH, Time Series, Log Storage. Mar it is net OLTP databank, dus besykje net koarte ynfoegingen en lêzings te dwaan.
• Interesting. Wierskynlik dejinge dy't mei wurket klikhûs, belibbe in protte nijsgjirrige mominten yn in goed en min sin. Bygelyks, in nije release kaam út, alles stoppe mei wurkjen. Of as jo twa dagen mei in taak wrakselje, mar nei't jo in fraach stelle yn Telegram-chat, waard de taak yn twa minuten oplost. Of lykas by de konferinsje by it ferslach fan Lesha Milovidov, in skermôfbylding fan klikhûs bruts de útstjoering HighLoad++. Dit soarte fan ding bart de hiele tiid en makket ús libben lestich. klikhûs helder en nijsgjirrich!

Jo kinne de presintaasje besjen hjir.

De langverwachte gearkomste fan ûntwikkelders fan hege-load systemen by HighLoad++ sil plakfine op 9 en 10 novimber yn Skolkovo. Uteinlik sil dit in offline konferinsje wêze (hoewol mei alle foarsoarchsmaatregels yn plak), om't de enerzjy fan HighLoad ++ net online kin wurde ferpakt.

Foar de konferinsje fine en litte wy jo gefallen sjen oer de maksimale mooglikheden fan technology: HighLoad++ wie, is en sil it ienige plak wêze wêr't jo yn twa dagen kinne leare hoe't Facebook, Yandex, VKontakte, Google en Amazon wurkje.

Sûnt 2007 sûnder ûnderbrekking ús gearkomsten hâlden hawwe, sille wy dit jier foar de 14e kear gearkomme. Yn dizze tiid is de konferinsje 10 kear groeid; ferline jier brocht it wichtige yndustryevenemint 3339 dielnimmers, 165 sprekkers, rapporten en gearkomsten byinoar, en 16 spoaren rûnen tagelyk.
Ferline jier rieden der 20 bussen, 5280 liter tee en kofje, 1650 liter fruitdrank en 10200 flessen wetter. En nochris 2640 kilogram iten, 16 borden en 000 kopkes. Trouwens, mei it jild ophelle út recycled papier, hawwe wy 25 iken seedlings plante :)

Jo kinne keapje kaartsjes hjir, krije nijs oer de konferinsje - hjir, en praat op alle sosjale netwurken: Telegram, facebook, Vkontakte и Twitter.

Boarne: www.habr.com