Kalimi në ClickHouse: 3 vjet më vonë

Tre vjet më parë Viktor Tarnavsky dhe Alexey Milovidov nga Yandex në skenë Ngarkesë e lartë ++ tha, sa i mirë është ClickHouse dhe sa nuk ngadalësohet. Dhe në fazën tjetër ishte Aleksandër Zaitsev с raporti rreth lëvizjes në Shtëpi Kliko nga një DBMS tjetër analitike dhe me përfundimin se Shtëpi Kliko, sigurisht, i mirë, por jo shumë i përshtatshëm. Kur në vitin 2016 kompania Rruga e jetës, ku Aleksandri atëherë punonte, po konvertonte një sistem analitik me shumë petabajt në Shtëpi Kliko, ishte një "rrugë me tulla të verdha" magjepsëse plot me rreziqe të panjohura - Shtëpi Kliko atëherë dukej si një fushë e minuar.

Tre vjet më vonë Shtëpi Kliko u bë shumë më i mirë - gjatë kësaj kohe Aleksandri themeloi kompaninë Altinity, e cila jo vetëm që i ndihmon njerëzit të lëvizin Shtëpi Kliko dhjetëra projekte, por gjithashtu përmirëson vetë produktin së bashku me kolegët nga Yandex. Tani Shtëpi Kliko ende jo një shëtitje e shkujdesur, por jo më një fushë e minuar.

Alexander ka punuar me sisteme të shpërndara që nga viti 2003, duke zhvilluar projekte të mëdha në MySQL, Oracle и Vertikale. Në të fundit HighLoad ++ 2019 Aleksandri, një nga pionierët e përdorimit Shtëpi Kliko, tregoi se çfarë është tani kjo DBMS. Ne do të mësojmë për karakteristikat kryesore Shtëpi Kliko: si ndryshon nga sistemet e tjera dhe në cilat raste është më efektiv përdorimi i tij. Duke përdorur shembuj, ne do të shikojmë praktikat e fundit dhe të testuara nga projektet për ndërtimin e sistemeve bazuar në Shtëpi Kliko.

Retrospektivë: çfarë ndodhi 3 vjet më parë

Tre vjet më parë ne transferuam kompaninë Rruga e jetës mbi Shtëpi Kliko nga një tjetër bazë të dhënash analitike, dhe migrimi i analitikës së rrjetit të reklamave dukej kështu:

• Qershor 2016. Në Burim i hapur shfaq Shtëpi Kliko dhe projekti ynë filloi;
• gusht. Dëshmi e konceptit: rrjet i madh reklamash, infrastrukturë dhe 200-300 terabajt të dhëna;
• tetor. Të dhënat e para të prodhimit;
• dhjetor. Ngarkesa e plotë e produktit është 10-50 miliardë ngjarje në ditë.
• Qershor 2017. Migrimi i suksesshëm i përdoruesve në Shtëpi Kliko, 2,5 petabajt të dhëna në një grup prej 60 serverësh.

Gjatë procesit të migrimit, pati një kuptim në rritje për këtë Shtëpi Kliko është një sistem i mirë me të cilin është i këndshëm të punosh, por ky është një projekt i brendshëm i Yandex. Prandaj, ka nuanca: Yandex së pari do të merret me klientët e vet të brendshëm dhe vetëm më pas me komunitetin dhe nevojat e përdoruesve të jashtëm, dhe ClickHouse atëherë nuk arriti nivelin e ndërmarrjes në shumë fusha funksionale. Kjo është arsyeja pse ne themeluam Altinity në mars 2017 për të bërë Shtëpi Kliko edhe më i shpejtë dhe më i përshtatshëm jo vetëm për Yandex, por edhe për përdoruesit e tjerë. Dhe tani ne:

• Ne trajnojmë dhe ndihmojmë në ndërtimin e zgjidhjeve bazuar në Shtëpi Kliko në mënyrë që klientët të mos futen në telashe dhe në mënyrë që zgjidhja të funksionojë përfundimisht;
• Ne ofrojmë mbështetje 24/7 Shtëpi Kliko- instalimet;
• Ne zhvillojmë projektet tona të ekosistemit;
• Ne i përkushtohemi vetes në mënyrë aktive Shtëpi Kliko, duke iu përgjigjur kërkesave të përdoruesve që duan të shohin veçori të caktuara.

Dhe sigurisht, ne ndihmojmë me lëvizjen në Shtëpi Kliko с MySQL, Vertikale, Orakull, Kumbulla jeshile, RedShift dhe sisteme të tjera. Ne kemi qenë të përfshirë në një sërë lëvizjesh dhe të gjitha kanë qenë të suksesshme.

Pse të zhvendoseni në Shtëpi Kliko

Nuk ngadalëson! Kjo është arsyeja kryesore. Shtëpi Kliko - Baza e të dhënave shumë e shpejtë për skenarë të ndryshëm:

Citate të rastësishme nga njerëz që kanë punuar me njerëz për një kohë të gjatë Shtëpi Kliko.

Shkallëzueshmëria. Në ndonjë bazë të dhënash tjetër mund të arrini performancë të mirë në një pjesë të harduerit, por Shtëpi Kliko ju mund të shkallëzoni jo vetëm vertikalisht, por edhe horizontalisht, thjesht duke shtuar serverë. Gjithçka nuk funksionon aq mirë sa do të donim, por funksionon. Ju mund ta zgjeroni sistemin ndërsa biznesi juaj rritet. Është e rëndësishme që ne të mos jemi të kufizuar nga zgjidhja tani dhe ka gjithmonë potencial për zhvillim.

Transportueshmëri. Nuk ka lidhje me një gjë. Për shembull, me Ndryshimi i Kuq i Amazonës Është e vështirë të lëvizësh diku. A Shtëpi Kliko mund ta instaloni në laptop, server, ta vendosni në cloud, të shkoni te Kubernetes — nuk ka kufizime në funksionimin e infrastrukturës. Kjo është e përshtatshme për të gjithë dhe ky është një avantazh i madh me të cilin nuk mund të mburren shumë baza të tjera të dhënash të ngjashme.

Lakueshmëri. Shtëpi Kliko nuk ndalet në një gjë, për shembull, Yandex.Metrica, por zhvillohet dhe përdoret në projekte dhe industri gjithnjë e më shumë të ndryshme. Mund të zgjerohet duke shtuar aftësi të reja për të zgjidhur probleme të reja. Për shembull, besohet se ruajtja e regjistrave në një bazë të dhënash është sjellje e keqe, kështu që ata dolën me Elasticsearch. Por falë fleksibilitetit Shtëpi Kliko, ju gjithashtu mund të ruani shkrimet në të, dhe shpesh kjo është edhe më mirë se sa në Elasticsearch - në Shtëpi Kliko kjo kërkon 10 herë më pak hekur.

Falas Open Source. Ju nuk duhet të paguani për asgjë. Nuk ka nevojë për të negociuar leje për të instaluar sistemin në laptop ose server. Asnjë tarifë e fshehur. Në të njëjtën kohë, asnjë teknologji tjetër e bazës së të dhënave me burim të hapur nuk mund të konkurrojë në shpejtësi Shtëpi Kliko. MySQL, MariaDB, Greenplum - të gjithë janë shumë më të ngadaltë.

Komuniteti, ngasja dhe argëtim... Kanë Shtëpi Kliko komunitet i shkëlqyer: takime, biseda dhe Alexey Milovidov, i cili na ngarkon të gjithëve me energjinë dhe optimizmin e tij.

Kalimi në ClickHouse

Per te shkuar ne Shtëpi Kliko për disa arsye, ju duhen vetëm tre gjëra:

• Kuptoni kufizimet Shtëpi Kliko dhe për çfarë nuk është i përshtatshëm.
• Perfitoj teknologjia dhe pikat e saj më të forta.
• Eksperimentoni. Edhe duke kuptuar se si funksionon Shtëpi Kliko, nuk është gjithmonë e mundur të parashikohet kur do të jetë më i shpejtë, kur do të jetë më i ngadalshëm, kur do të jetë më mirë dhe kur do të jetë më keq. Pra provojeni.

Problemi i lëvizjes

Ekziston vetëm një "por": nëse lëvizni në Shtëpi Kliko nga diçka tjetër, atëherë zakonisht diçka nuk shkon. Jemi mësuar me disa praktika dhe gjëra që funksionojnë në bazën e të dhënave tona të preferuara. Për shembull, kushdo që punon me SQBazat e të dhënave L e konsiderojnë të detyrueshëm grupin e mëposhtëm të funksioneve:

• transaksionet;
• kufizimet;
• qëndrueshmëri;
• treguesit e;
• PËRDITËSO/FSHI;
• NULL;
• milisekonda;
• kallëpe të tipit automatik;
• bashkime të shumta;
• ndarje arbitrare;
• mjetet e menaxhimit të grupimeve.

Rekrutimi është i detyrueshëm, por tre vjet më parë në Shtëpi Kliko Asnjë nga këto funksione nuk ishte i disponueshëm! Tani ka mbetur më pak se gjysma e asaj që nuk është zbatuar: transaksionet, kufizimet, Konsistenca, milisekonda dhe lloji i hedhjes.

Dhe gjëja kryesore është se në Shtëpi Kliko disa praktika dhe qasje standarde nuk funksionojnë ose funksionojnë ndryshe nga sa jemi mësuar. Gjithçka që shfaqet në Shtëpi Kliko, korrespondon "Mënyra ClickHouse", d.m.th. funksionet ndryshojnë nga bazat e tjera të të dhënave. Për shembull:

• Indekset nuk zgjidhen, por anashkalohen.
• PËRDITËSO/FSHI jo sinkron, por asinkron.
• Ka shumë bashkime, por nuk ka planifikues të pyetjeve. Mënyra se si ato kryhen më pas nuk është përgjithësisht shumë e qartë për njerëzit nga bota e bazës së të dhënave.

Skriptet e ClickHouse

Në vitin 1960, një matematikan amerikan me origjinë hungareze Wigner EP shkroi një artikull "Efektiviteti i paarsyeshëm i matematikës në shkencat natyrore” (“Efektiviteti i pakuptueshëm i matematikës në shkencat natyrore”) se bota përreth nesh për disa arsye përshkruhet mirë nga ligjet matematikore. Matematika është një shkencë abstrakte dhe ligjet fizike të shprehura në formë matematikore nuk janë të parëndësishme, dhe Wigner EP theksoi se kjo është shumë e çuditshme.

Nga këndvështrimi im, Shtëpi Kliko - e njëjta çuditshmëri. Për të riformuluar Wigner, mund të themi këtë: efikasiteti i pakonceptueshëm është i habitshëm Shtëpi Kliko në një shumëllojshmëri të gjerë aplikacionesh analitike!

Për shembull, le të marrim Magazina e të dhënave në kohë reale, në të cilin të dhënat ngarkohen pothuajse vazhdimisht. Ne duam të marrim kërkesa prej saj me një vonesë të dytë. Ju lutemi - përdorni Shtëpi Kliko, sepse ky është skenari për të cilin është krijuar. Shtëpi Kliko pikërisht kështu përdoret jo vetëm në ueb, por edhe në marketing dhe analitikë financiare, AdTech, si dhe në Zbulimi i mashtrimitn. NË Magazina e të dhënave në kohë reale përdoret një skemë komplekse e strukturuar si "yll" ose "flokë dëbore", shumë tabela me BASHKOHU (nganjëherë të shumëfishta), dhe të dhënat zakonisht ruhen dhe ndryshohen në disa sisteme.

Le të marrim një skenar tjetër - Seritë kohore: monitorimi i pajisjeve, rrjeteve, statistikave të përdorimit, Interneti i gjërave. Këtu ndeshemi me ngjarje mjaft të thjeshta të renditura në kohë. Shtëpi Kliko nuk ishte zhvilluar fillimisht për këtë, por ka treguar se funksionon mirë, kjo është arsyeja pse kompanitë e mëdha përdorin Shtëpi Kliko si një depo për monitorimin e informacionit. Për të eksploruar nëse është i përshtatshëm Shtëpi Kliko për seritë kohore, ne bëmë një pikë referimi bazuar në qasjen dhe rezultatet InfluxDB и TimecaleDB - i specializuar seri kohore bazat e të dhënave. DoliQë Shtëpi Kliko, edhe pa optimizim për detyra të tilla, fiton në një fushë të huaj:

В seri kohore Zakonisht përdoret një tabelë e ngushtë - disa kolona të vogla. Shumë të dhëna mund të vijnë nga monitorimi - miliona regjistrime në sekondë - dhe ato zakonisht vijnë në breshëri të vogla (në kohë reale transmetim). Prandaj, nevojitet një skrip tjetër i futjes, dhe vetë pyetjet kanë specifikat e tyre.

Menaxhimi Identifikohu. Mbledhja e regjistrave në një bazë të dhënash është zakonisht e keqe, por Shtëpi Kliko kjo mund të bëhet me disa komente të përshkruara më sipër. Shumë kompani përdorin Shtëpi Kliko pikërisht për këtë qëllim. Në këtë rast, ne përdorim një tabelë të gjerë të sheshtë ku ruajmë të gjithë shkrimet (për shembull, në formë JSON), ose prerë në copa. Të dhënat zakonisht ngarkohen në grupe të mëdha (skedarë), dhe ne kërkojmë sipas disa fushave.

Për secilin prej këtyre funksioneve, zakonisht përdoren baza të të dhënave të specializuara. Shtëpi Kliko dikush mund t'i bëjë të gjitha dhe aq mirë sa i tejkalon ato. Le të hedhim një vështrim më të afërt seri kohore skenar, dhe si të "gatuaj" saktë Shtëpi Kliko për këtë skenar.

Seritë kohore

Aktualisht ky është skenari kryesor për të cilin Shtëpi Kliko konsiderohet zgjidhje standarde. Seritë kohore është një grup ngjarjesh të renditura në kohë, që përfaqësojnë ndryshime në një proces me kalimin e kohës. Për shembull, kjo mund të jetë rrahjet e zemrës në ditë ose numri i proceseve në sistem. Gjithçka që i jep kohës rriqra me disa dimensione është seri kohore:

Shumica e këtyre llojeve të ngjarjeve vijnë nga monitorimi. Kjo mund të jetë jo vetëm monitorimi i uebit, por edhe pajisjet reale: makina, sisteme industriale, IOT, fabrika apo taksi pa pilot, në bagazhin e të cilave Yandex tashmë po i vendos Shtëpi Kliko-server.

Për shembull, ka kompani që mbledhin të dhëna nga anijet. Çdo disa sekonda, sensorët në anijen e kontejnerit dërgojnë qindra matje të ndryshme. Inxhinierët i studiojnë ato, ndërtojnë modele dhe përpiqen të kuptojnë se sa me efikasitet përdoret anija, sepse një anije kontejneri nuk duhet të qëndrojë boshe as për një sekondë. Çdo ndërprerje është një humbje parash, kështu që është e rëndësishme të parashikohet rruga në mënyrë që ndalesat të jenë minimale.

Në ditët e sotme ka një rritje të bazave të të dhënave të specializuara që matin seri kohore. Online DB-motorët Bazat e të dhënave të ndryshme janë renditur disi, dhe ju mund t'i shikoni ato sipas llojit:

Lloji me rritje më të shpejtë është seritë kohores. Bazat e të dhënave grafike po rriten gjithashtu, por seritë kohores janë rritur më shpejt gjatë viteve të fundit. Përfaqësuesit tipikë të kësaj familje të bazave të të dhënave janë InfluxDB, Prometeu, KDB, TimecaleDB (ndërtuar mbi PostgreSQL), zgjidhje nga Amazona. Shtëpi Kliko mund të përdoret edhe këtu, dhe përdoret. Më lejoni t'ju jap disa shembuj publikë.

Një nga pionierët është kompania CloudFlare (CDN-ofruesi). Ata monitorojnë të tyren CDN përmes Shtëpi Kliko (DNS-kërkesat, HTTP-pyetje) me një ngarkesë të madhe - 6 milion ngjarje në sekondë. Gjithçka kalon Kafka, shkon në Shtëpi Kliko, i cili ofron mundësinë për të parë panelet e ngjarjeve në sistem në kohë reale.

Comcast - një nga liderët në telekomunikacion në SHBA: Internet, televizion dixhital, telefoni. Ata krijuan një sistem të ngjashëm kontrolli CDN brenda kornizës Open Source projekti Kontrolli i Trafikut Apache për të punuar me të dhënat tuaja të mëdha. Shtëpi Kliko përdoret si një backend për analitikë.

Perkona ndërtuar në Shtëpi Kliko brenda tuajën PMMpër të ruajtur monitorimin e të ndryshme MySQL.

Kërkesa specifike

Bazat e të dhënave të serive kohore kanë kërkesat e tyre specifike.

• Futje e shpejtë nga shumë agjentë. Duhet të fusim të dhëna nga shumë transmetime shumë shpejt. Shtëpi Kliko E bën mirë këtë sepse të gjitha futjet e tij nuk janë bllokuese. Çdo fut është një skedar i ri në disk, dhe insertet e vogla mund të futen në bufer në një mënyrë ose në një tjetër. NË Shtëpi Kliko Është më mirë të futni të dhëna në grupe të mëdha dhe jo në një rresht në të njëjtën kohë.
• Skema fleksibël. Në seri kohore ne zakonisht nuk e njohim plotësisht strukturën e të dhënave. Është e mundur të ndërtohet një sistem monitorimi për një aplikacion specifik, por më pas është e vështirë ta përdorësh atë për një aplikacion tjetër. Kjo kërkon një skemë më fleksibël. Shtëpi Kliko, ju lejon ta bëni këtë, edhe pse është një bazë e shtypur fort.
• Ruajtja efikase dhe harresa e të dhënave. Zakonisht në seri kohore një sasi e madhe të dhënash, kështu që ato duhet të ruhen sa më efikase të jetë e mundur. Për shembull, në InfluxDB kompresimi i mirë është tipari kryesor i tij. Por përveç ruajtjes, ju gjithashtu duhet të jeni në gjendje të "harroni" të dhënat e vjetra dhe të bëni një lloj të tillë marrja e mostrave — numërimi automatik i agregateve.
• Pyetje të shpejta mbi të dhënat e grumbulluara. Ndonjëherë është interesante të shikosh 5 minutat e fundit me një saktësi prej milisekondash, por në të dhënat mujore mund të mos nevojiten përpikëria e minutës ose e dytë - mjaftojnë statistikat e përgjithshme. Mbështetja e këtij lloji është e nevojshme, përndryshe një kërkesë për 3 muaj do të marrë një kohë shumë të gjatë për të përfunduar edhe brenda Shtëpi Kliko.
• Kërkesa si "pika e fundit, që nga». Këto janë tipike për seri kohore pyetje: shikoni matjen ose gjendjen e fundit të sistemit në një moment në kohë t. Këto nuk janë pyetje shumë të këndshme për një bazë të dhënash, por ju gjithashtu duhet të jeni në gjendje t'i kryeni ato.
• Seritë kohore “Ngjitje”.. Seritë kohore është një seri kohore. Nëse ka dy seri kohore, ato shpesh duhet të lidhen dhe të ndërlidhen. Nuk është e përshtatshme për ta bërë këtë në të gjitha bazat e të dhënave, veçanërisht me seritë kohore të pabarabarta: këtu janë disa pika kohore, ka të tjera. Ju mund të konsideroni mesataren, por papritmas do të ketë ende një vrimë atje, kështu që nuk është e qartë.

Le të shohim se si plotësohen këto kërkesa Shtëpi Kliko.

skemë

В Shtëpi Kliko skemë për seri kohore mund të bëhet në mënyra të ndryshme, në varësi të shkallës së rregullsisë së të dhënave. Është e mundur të ndërtohet një sistem mbi të dhëna të rregullta kur i dimë paraprakisht të gjitha matjet. Për shembull, unë e bëra këtë CloudFlare me monitorim CDN është një sistem i optimizuar mirë. Mund të ndërtoni një sistem më të përgjithshëm që monitoron të gjithë infrastrukturën dhe shërbimet e ndryshme. Në rastin e të dhënave të parregullta, ne nuk e dimë paraprakisht se çfarë po monitorojmë - dhe ky është ndoshta rasti më i zakonshëm.

Të dhëna të rregullta. Kolonat. Skema është e thjeshtë - kolona me llojet e kërkuara:

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

Kjo është një tabelë e rregullt që monitoron një lloj aktiviteti të ngarkimit të sistemit (përdorues, sistem, i papunë, bukur). E thjeshtë dhe e përshtatshme, por jo fleksibël. Nëse duam një skemë më fleksibël, atëherë mund të përdorim vargje.

Të dhëna të parregullta. Vargjeve:

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

Strukturë mbivendosur janë dy vargje: metrikë.emër и metrikë.vlera. Këtu mund të ruani të dhëna të tilla arbitrare monitorimi si një grup emrash dhe një grup matjesh për secilën ngjarje. Për optimizim të mëtejshëm, në vend të një strukture të tillë, mund të bëni disa. Për shembull, një për shket-vlera, një tjetër - për int- do të thotë sepse int Unë dua të ruaj në mënyrë më efikase.

Por një strukturë e tillë është më e vështirë për t'u aksesuar. Ju do të duhet të përdorni një ndërtim të veçantë, duke përdorur funksione të veçanta për të nxjerrë vlerat e së pari indeksit dhe më pas grupit:

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

Por ende funksionon mjaft shpejt. Një mënyrë tjetër për të ruajtur të dhëna të parregullta është me rresht.

Të dhëna të parregullta. Vargjet. Në këtë metodë tradicionale, pa vargje, emrat dhe vlerat ruhen njëkohësisht. Nëse 5 matje vijnë nga një pajisje njëherësh, 000 rreshta gjenerohen në bazën e të dhënave:

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

Shtëpi Kliko përballon këtë - ka zgjerime të veçanta Shtëpi Kliko SQL. Për shembull, maxNëse - një funksion i veçantë që llogarit maksimumin me një metrikë kur plotësohet një kusht. Ju mund të shkruani disa shprehje të tilla në një kërkesë dhe menjëherë të llogarisni vlerën për disa metrikë.

Le të krahasojmë tre qasje:

Detalet

Këtu kam shtuar "Madhësia e të dhënave të diskut" për disa grupe të dhënash testimi. Në rastin e kolonave, ne kemi madhësinë më të vogël të të dhënave: kompresimin maksimal, shpejtësinë maksimale të pyetjes, por ne paguajmë duke pasur nevojë të regjistrojmë gjithçka menjëherë.

Në rastin e vargjeve, gjithçka është pak më keq. Të dhënat janë ende të ngjeshura mirë dhe mund të ruhet një model i parregullt. Por Shtëpi Kliko - një bazë të dhënash kolone, dhe kur fillojmë të ruajmë gjithçka në një grup, ajo kthehet në një rresht, dhe ne paguajmë për fleksibilitet me efikasitet. Për çdo operacion, do të duhet të lexoni të gjithë grupin në memorie, pastaj të gjeni elementin e dëshiruar në të - dhe nëse grupi rritet, atëherë shpejtësia zvogëlohet.

Në një nga kompanitë që përdor këtë qasje (për shembull, Uber), vargjet priten në copa me 128 elementë. Të dhënat nga disa mijëra metrikë me një vëllim prej 200 TB të dhënash/ditë ruhen jo në një grup, por në 10 ose 30 grupe me logjikë të veçantë ruajtjeje.

Qasja më e thjeshtë është me vargje. Por të dhënat janë të ngjeshura dobët, madhësia e tabelës është e madhe dhe madje edhe kur pyetjet bazohen në disa metrika, ClickHouse nuk funksionon në mënyrë optimale.

Skema hibride

Le të supozojmë se kemi zgjedhur një qark vargu. Por nëse e dimë se shumica e paneleve tona tregojnë vetëm matjet e përdoruesve dhe të sistemit, ne mund t'i materializojmë këto metrika në kolona nga një grup në nivelin e tabelës në këtë mënyrë:

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

Gjatë futjes Shtëpi Kliko do t'i numërojë automatikisht. Në këtë mënyrë ju mund të kombinoni biznesin me kënaqësinë: skema është fleksibël dhe e përgjithshme, por ne kemi nxjerrë kolonat më të përdorura. Vini re se kjo nuk kërkonte ndryshimin e insertit dhe ETLe cila vazhdon të fusë vargje në tabelë. Ne sapo bëmë TABELA ALTER, shtoi disa altoparlantë dhe morëm një skemë hibride dhe më të shpejtë që mund të filloni ta përdorni menjëherë.

Kodekët dhe kompresimi

Për seri kohore Ka rëndësi se sa mirë i paketoni të dhënat sepse sasia e informacionit mund të jetë shumë e madhe. NË Shtëpi Kliko Ekziston një grup mjetesh për të arritur një efekt kompresimi prej 1:10, 1:20 dhe ndonjëherë më shumë. Kjo do të thotë që 1 TB të dhëna të papaketuara në disk zë 50-100 GB. Madhësia më e vogël është e mirë, të dhënat mund të lexohen dhe përpunohen më shpejt.

Për të arritur një nivel të lartë të kompresimit, Shtëpi Kliko mbështet kodekët e mëposhtëm:

Shembull i tabelës:

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

Këtu ne përcaktojmë kodekun DoubleDelta në një rast, në të dytën - Bandit, dhe ne patjetër do të shtojmë më shumë LZ4 ngjeshja. Si rezultat, madhësia e të dhënave në disk zvogëlohet shumë:

Kjo tregon se sa hapësirë ​​zënë të njëjtat të dhëna, por duke përdorur kodekë dhe kompresime të ndryshme:

• në një skedar GZIP në disk;
• në ClickHouse pa kodekë, por me kompresim ZSTD;
• në ClickHouse me kodekë dhe kompresim LZ4 dhe ZSTD.

Mund të shihet se tabelat me kodekë zënë shumë më pak hapësirë.

Madhësia ka rëndësi

Jo më pak e rëndësishme zgjedh lloji i saktë i të dhënave:

Në të gjithë shembujt e mësipërm që përdora Noton64. Por nëse zgjedhim Noton32, atëherë do të ishte edhe më mirë. Këtë e kanë treguar mirë djemtë nga Perkona në artikullin e lidhur më sipër. Është e rëndësishme të përdorni llojin më kompakt që është i përshtatshëm për detyrën: edhe më pak për madhësinë e diskut sesa për shpejtësinë e pyetjes. Shtëpi Kliko shumë i ndjeshëm ndaj kësaj.

Nëse mund të përdorni intxnumx në vend të intxnumx, atëherë prisni një rritje pothuajse të dyfishtë të performancës. Të dhënat marrin më pak memorie dhe e gjithë "aritmetika" funksionon shumë më shpejt. Shtëpi Kliko Në brendësi është një sistem i shtypur në mënyrë strikte, shfrytëzon në maksimum të gjitha mundësitë që ofrojnë sistemet moderne.

Grumbullimi dhe Pamje të Materializuara

Grumbullimi dhe pamjet e materializuara ju lejojnë të krijoni agregate për raste të ndryshme:

Për shembull, mund të keni të dhëna burimore jo të grumbulluara dhe mund t'u bashkëngjitni atyre pamje të ndryshme të materializuara me përmbledhje automatike përmes një motori të veçantë SummingMergeTree (SMT). SMT është një strukturë e veçantë e të dhënave grumbulluese që llogarit automatikisht agregatët. Të dhënat e papërpunuara futen në bazën e të dhënave, ato grumbullohen automatikisht dhe panelet e kontrollit mund të përdoren menjëherë në të.

TTL - "harroj" të dhënat e vjetra

Si të "harroni" të dhënat që nuk nevojiten më? Shtëpi Kliko di si ta bëjë këtë. Kur krijoni tabela, mund të specifikoni TTL shprehjet: për shembull, që ne ruajmë të dhënat minuta për një ditë, të dhënat ditore për 30 ditë dhe nuk prekim kurrë të dhënat javore ose mujore:

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

Shumështresore - ndani të dhënat nëpër disqe

Duke e çuar më tej këtë ide, të dhënat mund të ruhen në Shtëpi Kliko në vende të ndryshme. Supozoni se duam të ruajmë të dhëna të nxehta për javën e fundit në një lokal shumë të shpejtë SSD, dhe ne vendosim më shumë të dhëna historike në një vend tjetër. NË Shtëpi Kliko kjo tani është e mundur:

Ju mund të konfiguroni një politikë ruajtjeje (politika e ruajtjes) Kështu që Shtëpi Kliko do të transferojë automatikisht të dhënat me arritjen e kushteve të caktuara në një ruajtje tjetër.

Por kjo nuk është e gjitha. Në nivelin e një tabele specifike, ju mund të përcaktoni rregulla saktësisht kur të dhënat shkojnë në ruajtje të ftohtë. Për shembull, të dhënat ruhen në një disk shumë të shpejtë për 7 ditë, dhe gjithçka që është më e vjetër transferohet në një të ngadaltë. Kjo është e mirë sepse ju lejon të mbani sistemin në performancën maksimale, duke kontrolluar kostot dhe duke mos humbur para për të dhëna të ftohta:

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

Karakteristika unike Shtëpi Kliko

Pothuajse në çdo gjë Shtëpi Kliko Ka të tilla "theksime", por ato kompensohen nga ekskluziviteti - diçka që nuk është në bazat e të dhënave të tjera. Për shembull, këtu janë disa nga veçoritë unike Shtëpi Kliko:

• vargjeve. Në Shtëpi Kliko mbështetje shumë e mirë për vargje, si dhe aftësi për të kryer llogaritje komplekse mbi to.
• Përmbledhja e strukturave të të dhënave. Kjo është një nga "tiparet vrasëse" Shtëpi Kliko. Përkundër faktit se djemtë nga Yandex thonë se ne nuk duam të grumbullojmë të dhëna, gjithçka është grumbulluar në Shtëpi Kliko, sepse është i shpejtë dhe i përshtatshëm.
• Pamje të materializuara. Së bashku me strukturat e të dhënave të grumbulluara, pamjet e materializuara ju lejojnë të bëni të përshtatshme në kohë reale grumbullimi.
• ClickHouse SQL. Kjo është një zgjatje gjuhësore SQL me disa veçori shtesë dhe ekskluzive që disponohen vetëm në Shtëpi Kliko. Më parë, ishte si një zgjerim nga njëra anë dhe një disavantazh nga ana tjetër. Tani pothuajse të gjitha disavantazhet në krahasim me SQL 92 e hoqëm, tani është vetëm një zgjatje.
• lambda-shprehjet. A janë ata ende në ndonjë bazë të dhënash?
• ML-mbështetje. Kjo është e disponueshme në baza të ndryshme të dhënash, disa janë më të mira, disa janë më keq.
• burim i hapur. Mund të zgjerohemi Shtëpi Kliko së bashku. Tani në Shtëpi Kliko rreth 500 kontribues dhe ky numër është vazhdimisht në rritje.

Pyetje të ndërlikuara

В Shtëpi Kliko ka shumë mënyra të ndryshme për të bërë të njëjtën gjë. Për shembull, mund të ktheni vlerën e fundit nga një tabelë në tre mënyra të ndryshme për CPU (ka edhe një të katërt, por është edhe më ekzotik).

E para tregon se sa i përshtatshëm është për të bërë Shtëpi Kliko pyet kur doni ta kontrolloni atë tufë të përfshira në nënpyetje. Kjo është diçka që personalisht më ka munguar në bazat e tjera të të dhënave. Nëse dua të krahasoj diçka me një nënpyetje, atëherë në bazat e të dhënave të tjera vetëm një skalar mund të krahasohet me të, por për disa kolona duhet të shkruaj BASHKOHU. Në Shtëpi Kliko mund të përdorni tuple:

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

Metoda e dytë bën të njëjtën gjë, por përdor një funksion agregat argMax:

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

В Shtëpi Kliko ka disa dhjetëra funksione agregate, dhe nëse përdorni kombinatorë, atëherë sipas ligjeve të kombinatorikës do të merrni rreth një mijë prej tyre. ArgMax - një nga funksionet që llogarit vlerën maksimale: kërkesa kthen vlerën përdorimi_përdorues, në të cilën arrihet vlera maksimale krijuar_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 — “ngjitja” e rreshtave me kohë të ndryshme. Ky është një veçori unike për bazat e të dhënave që disponohet vetëm në kdb+. Nëse ka dy seri kohore me kohë të ndryshme, ASOF JOIN ju lejon të lëvizni dhe bashkoni ato në një kërkesë. Për secilën vlerë në një seri kohore, gjendet vlera më e afërt në tjetrën dhe ato kthehen në të njëjtën linjë:

Funksionet analitike

Në standard SQL-2003 mund te shkruani keshtu:

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;

В Shtëpi Kliko Ju nuk mund ta bëni këtë - nuk e mbështet standardin SQL-2003 dhe ndoshta nuk do ta bëjë kurrë. Në vend të kësaj, në Shtëpi Kliko Është zakon të shkruhet kështu:

Unë premtova lambdas - ja ku janë!

Ky është një analog i pyetjes analitike në standard SQL-2003: ai numëron dallimin mes të dyjave vula kohore, kohëzgjatja, numri rendor - gjithçka që ne zakonisht e konsiderojmë funksione analitike. NË Shtëpi Kliko Ne i numërojmë ato përmes vargjeve: së pari i kolapsim të dhënat në një grup, më pas bëjmë gjithçka që duam në grup dhe më pas i zgjerojmë përsëri. Nuk është shumë i përshtatshëm, kërkon të paktën një dashuri për programimin funksional, por është shumë fleksibël.

Karakteristika të veçanta

Përveç kësaj, në Shtëpi Kliko shumë funksione të specializuara. Për shembull, si të përcaktohet se sa seanca po zhvillohen njëkohësisht? Një detyrë tipike monitorimi është përcaktimi i ngarkesës maksimale me një kërkesë. NË Shtëpi Kliko Ekziston një funksion i veçantë për këtë:

Në përgjithësi, ClickHouse ka funksione të veçanta për shumë qëllime:

• runningDifference, runningAcumulate, fqinj;
• sumMap(çelësi, vlera);
• timeSeriesGroupSum (uid, vula kohore, vlera);
• timeSeriesGroupRateSum (uid, vula kohore, vlera);
• skewPop, skewSamp, kurtPop, kurtSamp;
• ME MBUSHJE / ME KRAVA;
• Regresioni Linear i thjeshtë, Regresioni Linear stokastik.

Kjo nuk është një listë e plotë e funksioneve, gjithsej janë 500-600. Këshillë: të gjitha funksionet në Shtëpi Kliko është në tabelën e sistemit (jo të gjitha janë të dokumentuara, por të gjitha janë interesante):

select * from system.functions order by name

Shtëpi Kliko ruan shumë informacione rreth vetes, duke përfshirë tabelat e regjistrave, pyetës_log, regjistri i gjurmëve, regjistri i operacioneve me blloqe të dhënash (pjesë_log), regjistri i metrikës dhe regjistri i sistemit, të cilin zakonisht i shkruan në disk. Metrika e regjistrit është seri kohore в Shtëpi Kliko në fakt Shtëpi Kliko: Baza e të dhënave në vetvete mund të luajë një rol seri kohore bazat e të dhënave, duke “gllabëruar” veten.

Kjo është gjithashtu një gjë unike - pasi ne bëjmë një punë të mirë për të seri kohore, pse nuk mund të ruajmë gjithçka që na nevojitet brenda vetes? Ne nuk kemi nevojë Prometeu, çdo gjë e mbajmë për vete. Lidhur grafana dhe ne monitorojmë veten. Megjithatë, nëse Shtëpi Kliko bie, ne nuk do të shohim pse, kështu që ata zakonisht nuk e bëjnë këtë.

Grup i madh ose shumë i vogël Shtëpi Kliko

Çfarë është më mirë - një grup i madh apo shumë ClickHouses të vegjël? Qasja tradicionale ndaj DWH është një grup i madh në të cilin qarqet ndahen për çdo aplikacion. Erdhëm te administratori i bazës së të dhënave - na jep një diagram, dhe ata na dhanë një:

В Shtëpi Kliko ju mund ta bëni ndryshe. Ju mund ta bëni çdo aplikacion tuajin Shtëpi Kliko:

Ne nuk kemi më nevojë për monstruozin e madh DWH dhe administratorë të vështirë. Ne mund t'i japim çdo aplikacioni të vetin Shtëpi Kliko, dhe zhvilluesi mund ta bëjë vetë, pasi Shtëpi Kliko shumë e lehtë për t'u instaluar dhe nuk kërkon administrim kompleks:

Por nëse kemi shumë Shtëpi Kliko, dhe duhet ta instaloni shpesh, atëherë dëshironi ta automatizoni këtë proces. Për këtë ne, për shembull, mund të përdorim Kubernetes и klikim shtëpie-operator. NË Kubernetes ClickHouse mund ta vendosësh “on-click”: Unë mund të klikoj një buton, të ekzekutoj manifestin dhe baza e të dhënave është gati. Mund të krijoj menjëherë një diagram, të filloj të ngarkoj metrikë atje dhe në 5 minuta kam gati një panel kontrolli grafana. Është kaq e thjeshtë!

Rezultati?

Pra, Shtëpi Kliko - Kjo:

• shpejt. Të gjithë e dinë këtë.
• Просто. Pak e diskutueshme, por besoj se është e vështirë në stërvitje, e lehtë në luftim. Nëse e kuptoni se si Shtëpi Kliko funksionon, atëherë gjithçka është shumë e thjeshtë.
• universalisht. Është i përshtatshëm për skenarë të ndryshëm: DWH, Seritë kohore, Ruajtja e regjistrave. Por nuk është kështu OLTP baza e të dhënave, kështu që mos u përpiqni të bëni inserte dhe lexime të shkurtra atje.
• Interesant. Ndoshta ai që punon me Shtëpi Kliko, përjetoi shumë momente interesante në kuptimin e mirë dhe të keq. Për shembull, doli një version i ri, gjithçka pushoi së funksionuari. Ose kur keni luftuar me një detyrë për dy ditë, por pasi keni bërë një pyetje në bisedën në Telegram, detyra është zgjidhur në dy minuta. Ose si në konferencën në raportin e Lesha Milovidov, një pamje nga ekrani Shtëpi Kliko prishi transmetimin Ngarkesë e lartë ++. Një gjë e tillë ndodh gjatë gjithë kohës dhe na e vështirëson jetën. Shtëpi Kliko e ndritshme dhe interesante!

Ju mund të shikoni prezantimin këtu.

Takimi i shumëpritur i zhvilluesve të sistemeve me ngarkesë të lartë në Ngarkesë e lartë ++ do të zhvillohet më 9 dhe 10 nëntor në Skolkovë. Më në fund, kjo do të jetë një konferencë jashtë linje (megjithëse me të gjitha masat paraprake), pasi energjia e HighLoad++ nuk mund të paketohet në internet.

Për konferencën, ne gjejmë dhe ju tregojmë raste për aftësitë maksimale të teknologjisë: HighLoad++ ishte, është dhe do të jetë i vetmi vend ku mund të mësoni brenda dy ditësh se si funksionojnë Facebook, Yandex, VKontakte, Google dhe Amazon.

Duke i mbajtur takimet tona pa ndërprerje që nga viti 2007, këtë vit do të takohemi për herë të 14-të. Gjatë kësaj kohe, konferenca është rritur 10 herë; vitin e kaluar, ngjarja kryesore e industrisë mblodhi së bashku 3339 pjesëmarrës, 165 folës, raporte dhe takime, dhe 16 këngë u zhvilluan njëkohësisht.
Vitin e kaluar ka pasur 20 autobusë, 5280 litra çaj dhe kafe, 1650 litra pije frutash dhe 10200 shishe ujë. Dhe 2640 kilogramë ushqime, 16 pjata dhe 000 gota. Meqë ra fjala, me paratë e mbledhura nga letra e ricikluar, mbollëm 25 fidanë lisi :)

Ju mund të blini bileta këtu, merrni lajme rreth konferencës - këtu, dhe flisni në të gjitha rrjetet sociale: Telegram, Facebook, Vkontakte и Twitter.

Burimi: www.habr.com