HighLoad++ Moskva 2018, Kongressihoone. 9. november kell 15
Abstraktid ja esitlus:
Juri Nasretdinov (VKontakte): aruanne räägib ClickHouse'i juurutamise kogemustest meie ettevõttes - miks me seda vajame, kui palju andmeid salvestame, kuidas neid kirjutame jne.
Lisateave:
Juri Nasretdinov: - Tere kõigile! Minu nimi on Juri Nasretdinov, nagu mind juba tutvustati. Töötan VKontaktes. Räägin sellest, kuidas me oma serveripargist (kümneid tuhandeid) andmeid ClickHouse'i sisestame.
Mis on palgid ja miks neid koguda?
Mida me teile ütleme: mida me tegime, miks me vajasime “ClickHouse”-i, miks me selle valisime, millise jõudluse saate ligikaudu ilma midagi spetsiaalselt seadistamata. Räägin teile lähemalt puhvertabelitest, nendega esinenud probleemidest ja meie avatud lähtekoodist välja töötatud lahendustest – KittenHouse ja Lighthouse.
Miks me üldse midagi tegema pidime (VKontakte'is on kõik alati hästi, eks?). Tahtsime koguda silumisloge (ja andmeid oli seal sadu terabaite), ehk oleks kuidagi mugavam statistikat arvutada; ja meil on kümnetest tuhandetest serveritest koosnev park, kust seda kõike on vaja teha.
Miks me otsustasime? Tõenäoliselt olid meil lahendused palkide hoidmiseks. Siin on selline avalik "Backend VK". Soovitan soojalt see tellida.
Mis on palgid? See on mootor, mis tagastab tühjad massiivid. VK mootoreid nimetavad teised mikroteenusteks. Ja siin on naeratav kleebis (üsna palju meeldimisi). Kuidas nii? No kuula edasi!
Mida saab kasutada palkide säilitamiseks? Hadupist on võimatu rääkimata jätta. Siis näiteks Rsyslog (nende logide salvestamine failidesse). LSD. Kes teab, mis on LSD? Ei, mitte see LSD. Salvestage ka failid. Noh, ClickHouse on kummaline valik.
Clickhouse ja konkurendid: nõuded ja võimalused
Mida me tahame? Soovime tagada, et me ei peaks operatsiooni pärast liiga palju muretsema, et see toimiks karbist välja, eelistatavalt minimaalse konfiguratsiooniga. Tahame kirjutada palju ja kiiresti. Ja me tahame seda hoida kõikvõimalikke kuid, aastaid, see tähendab kaua. Võib-olla tahame mõista mõnda probleemi, millega nad meie poole pöördusid ja ütlesid: "Siin ei tööta midagi," ja see juhtus 3 kuud tagasi, ja me tahame näha, mis juhtus 3 kuud tagasi. Andmete tihendamine – on selge, miks see oleks pluss –, sest see vähendab kuluvat ruumi.
Ja meil on selline huvitav nõue: kirjutame mõnikord mõne käsu (näiteks logi) väljundi, see võib üsna lihtsalt olla üle 4 kilobaidi. Ja kui see asi töötab UDP kaudu, siis ei pea see kulutama... sellel ei ole ühenduse jaoks "üldikulusid" ja suure hulga serverite jaoks on see pluss.
Vaatame, mida avatud lähtekoodiga meile pakub. Esiteks on meil Logs Engine – see on meie mootor; Põhimõtteliselt saab ta kõigega hakkama, isegi pikki ridu kirjutada. Noh, see ei tihenda andmeid läbipaistvalt - me saame ise suuri veerge tihendada, kui tahame ... me muidugi ei taha (kui võimalik). Ainus probleem on selles, et ta saab ära anda ainult seda, mis talle mällu mahub; Ülejäänu lugemiseks peate hankima selle mootori binlogi ja vastavalt sellele kulub see üsna kaua aega.
Milliseid muid võimalusi on? Näiteks "Hadup". Kasutuslihtsus... Kes arvab, et Hadupit on lihtne seadistada? Salvestamisega muidugi probleeme pole. Lugedes tekib vahel küsimusi. Põhimõtteliselt ma ütleks, et ilmselt mitte, eriti palkide puhul. Pikaajaline salvestamine - muidugi, jah, andmete tihendamine - jah, pikad stringid - on selge, et saate salvestada. Aga salvestamine suurest hulgast serveritest... Midagi peab ikka ise tegema!
Rsyslog. Tegelikult kasutasime seda varuvalikuna, et saaksime seda lugeda ilma binlogi kustutamata, kuid see ei saa kirjutada pikki ridu, põhimõtteliselt ei saa see kirjutada rohkem kui 4 kilobaiti. Andmete tihendamine tuleb samamoodi ise teha. Lugemine toimub failidest.
Siis on LSD "badushka" arendamine. Sisuliselt sama mis “Rsyslog”: toetab pikki stringe, aga ei saa UDP kaudu töötada ja tegelikult tuleb seetõttu kahjuks päris palju asju sinna ümber kirjutada. LSD tuleb ümber kujundada, et oleks võimalik salvestada kümnetest tuhandetest serveritest.
Ja siin! Naljakas võimalus on ElasticSearch. Kuidas öelda? Lugemine läheb tal hästi ehk loeb kiiresti, aga kirjutamisega mitte eriti hästi. Esiteks, kui see tihendab andmeid, on see väga nõrk. Tõenäoliselt nõuab täielik otsing suuremaid andmestruktuure kui algne maht. Seda on raske opereerida ja sellega tekivad sageli probleemid. Ja jällegi Elasticus salvestamine – me peame kõik ise tegema.
Siin on ClickHouse muidugi ideaalne valik. Ainus asi on see, et kümnete tuhandete serverite salvestamine on probleem. Aga vähemalt on üks probleem, me saame proovida seda kuidagi lahendada. Ja ülejäänud aruanne käsitleb seda probleemi. Millist jõudlust võite ClickHouse'ilt oodata?
Kuidas me selle sisestame? MergeTree
Kes teist ei oleks “ClickHouse’ist” kuulnud või teaks? Ma pean sulle ütlema, kas pole? Väga kiiresti. Seal olev sisestus - 1-2 gigabitti sekundis, kuni 10 gigabitti sekundis katkestused võivad selle konfiguratsiooniga tegelikult vastu pidada - on kaks 6-tuumalist Xeoni (see tähendab isegi mitte kõige võimsamat), 256 gigabaiti muutmälu, 20 terabaiti RAID-is (keegi pole konfigureeritud, vaikesätted). ClickHouse'i arendaja Aleksei Milovidov istub ilmselt ja nutab, sest me ei konfigureerinud midagi (meie jaoks toimis kõik nii). Seega on andmete hästi tihendatud skaneerimiskiiruseks näiteks umbes 6 miljardit rida sekundis. Kui teile meeldib % tekstistringil - 100 miljonit rida sekundis, see tähendab, et see tundub üsna kiire.
Kuidas me selle sisestame? Noh, teate, et VK kasutab PHP-d. Sisestame iga PHP töötaja HTTP kaudu iga kirje jaoks "ClickHouse"i MergeTree tabelisse. Kes näeb selles skeemis probleemi? Millegipärast ei tõstnud kõik kätt. Las ma räägin sulle.
Esiteks on servereid palju - vastavalt sellele on ühendusi palju (halbu). Siis on parem sisestada andmeid MergeTree mitte sagedamini kui üks kord sekundis. Ja kes teab, miks? Olgu olgu. Ma räägin teile sellest veidi lähemalt. Veel üks huvitav küsimus on see, et me ei tegele analüütikaga, me ei pea andmeid rikastama, me ei vaja vaheservereid, tahame sisestada otse "ClickHouse'i" (soovitavalt - mida otsesemalt, seda parem).
Seega, kuidas toimub sisestamine MergeTree'is? Miks on parem sisestada sellesse mitte sagedamini kui kord sekundis või harvem? Fakt on see, et "ClickHouse" on veeruline andmebaas ja sorteerib andmed primaarvõtme kasvavas järjekorras ning sisestamisel luuakse failide arv, mis on vähemalt võrdne veergude arvuga, milles andmed sorteeritakse. primaarvõtme kasvavas järjekorras (luuakse eraldi kataloog, iga sisestuse jaoks on kettal failide komplekt). Siis tuleb järgmine sisestus ja taustal kombineeritakse need suuremateks “sektsioonideks”. Kuna andmed on sorteeritud, on võimalik kahte sorteeritud faili "liita" ilma palju mälu kulutamata.
Kuid nagu võite arvata, kui kirjutate iga sisestuse jaoks 10 faili, lõpeb ClickHouse (või teie server) kiiresti, seega on soovitatav sisestada suurte partiidena. Seetõttu ei käivitanud me esimest skeemi kunagi tootmisse. Käivitasime kohe ühe, millel siin nr 2 on:
Kujutage ette, et seal on umbes tuhat serverit, mille oleme käivitanud, on ainult PHP. Ja igas serveris on meie kohalik agent, mida me nimetasime "Kittenhouseks", mis hoiab ühte ühendust "ClickHouse'iga" ja sisestab andmeid iga paari sekundi tagant. Sisestab andmed mitte MergeTreesse, vaid puhvertabelisse, mis aitab täpselt vältida otse MergeTree sisestamist.
Puhvertabelitega töötamine
Mis see on? Puhvertabelid on tükk mälu, mis on killustatud (st seda saab sellesse sageli sisestada). Need koosnevad mitmest tükist ja igaüks neist töötab iseseisva puhvrina ja neid loputatakse iseseisvalt (kui teil on puhvris palju tükke, siis on sekundis palju sisestusi). Nendest tabelitest on võimalik lugeda - siis loed puhvri sisu ja ülemtabeli ühendust, kuid antud hetkel on kirjutamine blokeeritud, seega on parem sealt mitte lugeda. Ja puhvertabelid näitavad väga head QPS-i, see tähendab, et kuni 3 tuhande QPS-ni pole teil sisestamisel probleeme. Selge on see, et kui serveri toide kaob, siis võivad andmed kaotsi minna, kuna need salvestati ainult mällu.
Samas teeb puhvriga skeem ALTERi keeruliseks, sest esmalt tuleb vana skeemi juures vana puhvritabel maha visata (andmed ei kao kuhugi, sest need saavad enne tabeli kustutamist läbi). Seejärel "muudate" vajalikku tabelit ja loote puhvertabeli uuesti. Seega, kuigi puhvertabelit pole, ei liigu teie andmed kuhugi, kuid teil võivad need olla kettal vähemalt kohapeal.
Mis on Kittenhouse ja kuidas see töötab?
Mis on KittenHouse? See on puhverserver. Arva ära, mis keeles? Kogusin oma aruandesse kõige rohkem hype teemasid - “Clickhouse”, Mine, võib-olla meenub mulle midagi muud. Jah, see on kirjutatud Go keeles, sest ma ei tea, kuidas C-keeles kirjutada, ma ei taha.
Sellest lähtuvalt säilitab see ühenduse iga serveriga ja saab mällu kirjutada. Näiteks kui kirjutame Clickhouse’i vealogid, siis kui Clickhouse’il pole aega andmeid sisestada (ju kui kirjutatakse liiga palju), siis me mälu ei paisu – me viskame ülejäänu lihtsalt välja. Sest kui kirjutame vigu mitu gigabitti sekundis, siis saame ilmselt mõned välja visata. Kittenhouse saab sellega hakkama. Lisaks suudab see usaldusväärselt edastada, st kirjutada kohalikus masinas kettale ja kord iga kord (seal iga paari sekundi järel) proovib sellest failist andmeid edastada. Ja algul kasutasime tavalist väärtuste vormingut - mitte mingit binaarvormingut, vaid tekstivormingut (nagu tavalises SQL-is).
Siis aga juhtus see. Kasutasime usaldusväärset edastamist, kirjutasime logisid, siis otsustasime (see oli tingimuslik testklaster)... See pandi mitu tundi välja ja toodi uuesti üles ning tuhandest serverist algas sisestamine - selgus, et Clickhouse'is oli ikkagi "Ühenduse lõim" - vastavalt tuhande ühenduse korral põhjustab aktiivne sisestamine serveri keskmise koormuse umbes poolteist tuhat. Üllatuslikult võttis server päringuid vastu, kuid andmed sisestati siiski mõne aja pärast; aga serveril oli seda väga raske teenindada...
Lisage nginx
Selline lahendus mudeli Thread per connection jaoks on nginx. Paigaldasime Clickhouse'i ette nginxi, samal ajal seadistasime kahe koopia tasakaalustamise (meie sisestamise kiirus kasvas 2 korda, kuigi see pole tõsi, et see nii peaks olema) ja piirasime Clickhouse'i ühenduste arvu ülesvoolu ja vastavalt rohkem , kui 50 ühenduses, tundub, et pole mõtet sisestada.
Siis saime aru, et sellel skeemil on üldiselt miinuseid, sest meil on siin ainult üks nginx. Seega, kui see nginx jookseb kokku, hoolimata koopiate olemasolust, kaotame andmed või vähemalt ei kirjuta me kuhugi. Seetõttu tegime oma koormuse tasakaalustamise. Samuti mõistsime, et “Clickhouse” sobib endiselt palkidele ja “deemon” hakkas ka “Clickhouse'i” oma palke kirjutama - ausalt öeldes on see väga mugav. Me kasutame seda endiselt teiste "deemonite" jaoks.
Siis avastasime selle huvitava probleemi: kui kasutate SQL-režiimis mittestandardset sisestamismeetodit, sunnib see kasutama täisväärtuslikku AST-põhist SQL-i parserit, mis on üsna aeglane. Seetõttu oleme lisanud seaded tagamaks, et seda kunagi ei juhtuks. Tegime koormuse tasakaalustamise, tervisekontrolli, et kui sureb, siis jätame andmed ikka alles. Meil on nüüd üsna palju tabeleid, mida vajame erinevate Clickhouse klastrite jaoks. Ja hakkasime mõtlema ka muudele kasutusvõimalustele – näiteks tahtsime kirjutada logisid nginxi moodulitest, kuid nad ei tea, kuidas meie RPC-ga suhelda. Noh, ma tahaksin neile õpetada, kuidas vähemalt kuidagi saata - näiteks UDP kaudu localhostis sündmusi vastu võtta ja seejärel Clickhouse'ile edastada.
Üks samm lahendusest eemal
Lõplik skeem hakkas välja nägema selline (selle skeemi neljas versioon): igas Clickhouse'i ees olevas serveris on nginx (samas serveris) ja see lihtsalt edastab päringuid kohalikule hostile, mille ühenduste arv on piiratud 50 tükid. Ja see skeem töötas juba päris hästi, sellega oli kõik päris hästi.
Elasime nii umbes kuu aega. Kõik olid rahul, lisasid tabeleid, lisasid, lisasid... Üldiselt selgus, et see, kuidas me puhvertabeleid lisasime, ei olnud väga optimaalne (ütleme nii). Igas tabelis tegime 16 tükki ja paarisekundilise välguintervalli; meil oli 20 lauda ja iga tabel sai 8 lisamist sekundis - ja sel hetkel algas "Clickhouse"... rekordid hakkasid aeglustuma. Nad isegi ei läinud läbi... Nginxil oli vaikimisi nii huvitav asi, et kui ühendused lõppesid ülesvooluga, tagastas ta kõigile uutele päringutele lihtsalt "502".
Ja siin on meil (vaatasin just Clickhouse'i logisid) umbes pool protsenti taotlustest ebaõnnestus. Sellest lähtuvalt oli ketta kasutamine kõrge, liitmisi oli palju. No mis ma tegin? Loomulikult ei vaevunud ma aru saama, miks ühendus ja ülesvoolu täpselt lõppesid.
Nginxi asendamine pöördpuhverserveriga
Otsustasin, et peame seda ise haldama, me ei pea seda nginxi hooleks jätma - nginx ei tea, millised tabelid Clickhouse'is on, ja asendasin nginxi pöördpuhverserveriga, mille ka ise kirjutasin.
Mida ta teeb? See töötab fasthttp raamatukogu “goshnoy” alusel, st kiiresti, peaaegu sama kiiresti kui nginx. Vabandust, Igor, kui olete siin kohal (märkus: Igor Sysoev on vene programmeerija, kes lõi nginxi veebiserveri). See saab aru, mis tüüpi päringud need on – INSERT või SELECT – vastavalt sellele hoiab see erinevat tüüpi päringute jaoks erinevaid ühenduskogumeid.
Sellest lähtuvalt, isegi kui meil pole aega sisestamistaotluste lõpuleviimiseks, lähevad valikud läbi ja vastupidi. Ja see rühmitab andmed puhvertabelitesse – väikese puhvriga: kui esines vigu, süntaksivigu ja nii edasi – nii et need ei mõjutaks oluliselt ülejäänud andmeid, sest kui me lihtsalt puhvertabelitesse sisestasime, oli väike "bachi" ja kõik süntaksivead mõjutasid ainult seda väikest tükki; ja siin mõjutavad need juba suurt puhvrit. Väike on 1 megabait, st mitte nii väike.
Sünkroonimise sisestamine ja sisuliselt nginxi asendamine teeb sisuliselt sama asja, mida nginx tegi varem – selleks ei pea te kohalikku kassimaja muutma. Ja kuna see kasutab fasthttp-d, on see väga kiire - saate teha pöördpuhverserveri kaudu üksikute lisade jaoks rohkem kui 100 tuhat päringut sekundis. Teoreetiliselt saate kassipojamaja pöördpuhverserverisse sisestada ühe rea korraga, kuid loomulikult me seda ei tee.
Skeem hakkas välja nägema järgmine: "Kittenhouse", pöördpuhverserver rühmitab paljud päringud tabelitesse ja puhvertabelid lisavad need omakorda peamistesse.
Killer on ajutine lahendus, Kitten on püsiv
See on huvitav probleem... Kas keegi teist on kasutanud fasthttp? Kes kasutas POST-i päringutega fasthttp-d? Tõenäoliselt poleks seda pidanud tegema, sest see puhverdab vaikimisi päringu keha ja meie puhvri suuruseks määrati 16 megabaiti. Sisestamine lakkas mingil hetkel sammu pidamast ja kõigist kümnetest tuhandetest serveritest hakkasid saabuma 16-megabaidised jupid ning need puhverdati enne Clickhouse'i saatmist mällu. Sellest tulenevalt sai mälu otsa, mälu otsas tapja tuli ja tappis vastupidise puhverserveri (või "Clickhouse", mis võis teoreetiliselt "süüa" rohkem kui vastupidine puhverserver). Tsükkel kordus. Pole just meeldiv probleem. Kuigi me komistasime selle otsa alles pärast mitmekuulist tegutsemist.
Mis ma teinud olen? Jällegi, mulle ei meeldi väga aru saada, mis täpselt juhtus. Minu arvates on üsna ilmne, et te ei tohiks mällu puhverdada. Ma ei saanud fasthttp lappima, kuigi proovisin. Aga leidsin viisi, kuidas teha nii, et poleks vaja midagi lappida ja mõtlesin HTTP-s välja oma meetodi - panin selle nimeks KIISI. Noh, see on loogiline - "VK", "Kassipoeg" ... Mida veel?...
Kui serverisse tuleb taotlus Kitten meetodil, peaks server vastama "mjäu" - loogiliselt. Kui ta sellele vastab, siis loetakse, et ta saab sellest protokollist aru ja siis ma katkestan ühenduse (fasthttp-l on selline meetod) ja ühendus läheb “toores” režiimi. Miks ma seda vajan? Tahan kontrollida, kuidas TCP-ühendustest lugemine toimub. TCP-l on suurepärane omadus: kui keegi teiselt poolt ei loe, hakkab kirjutamine ootama ja mälu sellele eriti ei kulutata.
Ja nii ma lugesin korraga umbes 50 kliendi käest (viiekümnest sest viiekümnest peaks kindlasti piisama, isegi kui määr tuleb teisest DC-st)... Tarbimine on selle lähenemisega vähenenud vähemalt 20 korda, aga mina ausalt öeldes , ma ei saanud täpselt mõõta, mis kellaaeg, sest see on niigi mõttetu (on juba veataseme saavutanud). Protokoll on binaarne, see tähendab, et see sisaldab tabeli nime ja andmeid; http-päiseid pole, seega ei kasutanud ma veebipesa (mul pole vaja brauseriga suhelda - tegin meie vajadustele vastava protokolli). Ja temaga läks kõik hästi.
Puhverlaud on kurb
Hiljuti leidsime veel ühe huvitava puhvertabelite funktsiooni. Ja see probleem on juba palju valusam kui teised. Kujutagem ette seda olukorda: kasutate juba aktiivselt Clickhouse'i, teil on kümneid Clickhouse'i servereid ja teil on mõned päringud, mille lugemine võtab väga kaua aega (oletame, et üle 60 sekundi); ja te tulete ja teete Alterit sel hetkel... Vahepeal ei lisata sellesse tabelisse valikuid, mis algasid enne sõna Alter, "Alter" ei käivitu - tõenäoliselt on mõned funktsioonid, kuidas "Clickhouse" töötab see koht. Võib-olla saab seda parandada? Või pole see võimalik?
Üldiselt on selge, et tegelikkuses pole see nii suur probleem, kuid puhvertabelitega läheb see valusamaks. Sest kui, oletame, et teie "Alter" ajalõpud (ja see võib mõnel teisel hostil aeguda - mitte teie omal, vaid näiteks koopial), siis... Kustutasite puhvertabeli, oma "Alter" ( või mõni muu host) aegus. siis ilmnes tõrge "Muuda") - peate siiski veenduma, et andmete kirjutamine jätkub: loote puhvritabelid tagasi (sama skeemi järgi, mis vanemtabel), siis "Alter" läheb läbi, lõpeb lõpuks ja tabeli puhvri skeem hakkab erinema vanemast. Olenevalt sellest, mis oli "Alter", ei pruugi sisestus enam sellesse puhvertabelisse minna - see on väga kurb.
On ka selline märk (võib-olla keegi märkas seda) - Clickhouse'i uutes versioonides nimetatakse seda query_thread_log. Vaikimisi oli mõnes versioonis üks. Siin on meil paari kuuga kogunenud 840 miljonit plaati (100 gigabaiti). See on tingitud asjaolust, et sinna kirjutati “insertsid” (võib-olla, muide, neid praegu ei kirjutata). Nagu ma teile ütlesin, on meie "sisestamised" väikesed - meil oli puhvertabelites palju "sisendeid". On selge, et see on keelatud – ma lihtsalt räägin teile, mida nägin meie serveris. Miks? See on veel üks argument puhvertabelite kasutamise vastu! Spotty on väga kurb.
Kes teadis, et selle mehe nimi on Spotty? VK töötajad tõstsid käed. OKEI.
"KitttenHouse"i plaanidest
Plaane tavaliselt ei jagata, eks? Järsku sa ei täida neid ega näe teiste silmis eriti hea välja. Aga ma võtan riski! Tahame teha järgmist: mulle tundub, et puhverlauad on endiselt kargud ja me peame ise sisestuse puhverdama. Kuid me ei taha seda ikkagi kettale puhverdada, seega puhverdame sisestuse mällu.
Vastavalt sellele, kui "sisestamine" tehakse, ei ole see enam sünkroonne - see töötab juba puhvertabelina, sisestab ematabelisse (noh, millalgi hiljem) ja annab eraldi kanali kaudu teada, millised lisad on läbinud ja millised ei ole.
Miks ma ei saa sünkroonset sisestust lahkuda? See on palju mugavam. Fakt on see, et kui sisestate 10 tuhandest hostist, siis on kõik korras - saate igast hostist natukene, sisestate sinna kord sekundis, kõik on korras. Kuid ma tahaksin, et see skeem töötaks näiteks kahest masinast, nii et saate suure kiirusega alla laadida - võib-olla mitte Clickhouse'ist maksimumi saada, vaid kirjutada ühest masinast pöördpuhverserveri kaudu vähemalt 100 megabaiti sekundis - seda peab skeem skaleerima nii suurtele kui ka väikestele kogustele, nii et me ei saa iga sisestusega sekunditki oodata, seega peab see olema asünkroonne. Ja samamoodi peaksid asünkroonsed kinnitused tulema pärast sisestamise lõpetamist. Saame teada, kas see läks läbi või mitte.
Kõige tähtsam on see, et selles skeemis teame kindlalt, kas sisestamine toimus või mitte. Kujutage ette sellist olukorda: teil on puhvertabel, kirjutasite sinna midagi ja siis, oletame, et tabel läks kirjutuskaitstud režiimi ja proovis puhvrit tühjendada. Kuhu andmed lähevad? Need jäävad puhvrisse. Kuid me ei saa selles kindlad olla - mis siis, kui on mõni muu viga, mille tõttu andmed ei jää puhvrisse... (Aadressid Aleksei Milovidov, Yandex, ClickHouse'i arendaja) Või jääb? Alati? Aleksei veenab meid, et kõik saab korda. Meil pole põhjust teda mitte uskuda. Kuid ikkagi: kui me puhvertabeleid ei kasuta, siis pole nendega probleeme. Kahekordse arvu tabelite koostamine on samuti ebamugav, kuigi põhimõtteliselt suuri probleeme pole. See on plaan.
Räägime lugemisest
Räägime nüüd lugemisest. Kirjutasime siia ka oma tööriista. Näib, noh, milleks siia oma instrumenti kirjutada?.. Ja kes kasutas Tabixit? Kuidagi vähesed tõstsid käsi... Ja kes on Tabixi esitusega rahul? Noh, me ei ole sellega rahul ja see pole andmete vaatamiseks eriti mugav. Analüütika jaoks sobib see hästi, kuid lihtsalt vaatamiseks pole see selgelt optimeeritud. Nii et ma kirjutasin oma, oma liidese.
See on väga lihtne – see suudab ainult andmeid lugeda. Ta ei oska graafikat näidata, ei oska midagi teha. Kuid see võib näidata, mida me vajame: näiteks mitu rida tabelis on, kui palju ruumi see võtab (ilma seda veergudeks jagamata), see tähendab, et vajame väga lihtsat liidest.
Ja see näeb välja väga sarnane Sequel Pro-ga, kuid tehtud ainult Twitteri Bootstrapis ja teises versioonis. Küsite: "Juri, miks teisel versioonil?" Mis aasta? 2018? Üldiselt tegin seda päris ammu “Muscle” (MySQL) jaoks ja muutsin just sealsetes päringutes paar rida ning see hakkas “Clickhouse” jaoks tööle, mille eest erilised tänud! Kuna parser on väga sarnane “lihase” parserile ja päringud on väga sarnased - väga mugav, eriti alguses.
Noh, see võib filtreerida tabeleid, näidata tabeli struktuuri ja sisu, võimaldab sorteerida, filtreerida veergude järgi, näitab päringut, mille tulemuseks oli tulemus, mõjutatud ridu (mitu on tulemuseks), st põhilised asjad andmete vaatamiseks. Päris kiiresti.
Seal on ka toimetaja. Üritasin ausalt öeldes Tabixist kogu toimetaja varastada, kuid see ei õnnestunud. Aga kuidagi see toimib. Põhimõtteliselt on see kõik.
"Clickhouse" sobib urgudesse
Tahan teile öelda, et Clickhouse sobib kõigist kirjeldatud probleemidest hoolimata väga hästi palkide jaoks. Kõige tähtsam on see, et see lahendab meie probleemi - see on väga kiire ja võimaldab teil logisid veergude järgi filtreerida. Põhimõtteliselt pole puhvertabelid hästi toiminud, aga tavaliselt ei tea keegi, miks... Võib-olla nüüd teate paremini, kus teil probleeme tekib.
TCP? Üldiselt on VK-s tavaks kasutada UDP-d. Ja kui ma TCP-d kasutasin... Muidugi ei öelnud mulle keegi: “Juri, mis sa räägid! Sa ei saa, sa vajad UDP-d. Selgus, et TCP polegi nii hirmus. Ainus asi on see, et kui teil on kümneid tuhandeid aktiivseid ühendeid, mida kirjutate, peate selle pisut hoolikamalt ette valmistama; aga see on võimalik ja üsna lihtne.
Lubasin HighLoad Siberiasse postitada “Kittenhouse” ja “Lighthouse”, kui kõik tellivad meie avaliku “VK taustaprogrammi”... Ja teate, kõik ei tellinud... Muidugi ei nõua ma, et te meie lehe telliksite. avalik. Teid on ikka liiga palju, keegi võib isegi solvuda, aga siiski, palun tellige (ja siin ma pean tegema silmad nagu kassil). See on . Tänan teid väga! Github on meie oma . Clickhouse'iga on teie juuksed pehmed ja siidised.
Moderaator: - Sõbrad, nüüd küsimustele. Kohe pärast seda, kui oleme esitanud tänukirja ja teie VHS-i aruande.
Juri Nasretdinov (edaspidi YN): – Kuidas sa suutsid mu aruande VHS-i salvestada, kui see just lõppes?
Moderaator: – Samuti ei saa te täielikult kindlaks teha, kuidas "Clickhouse" töötab või mitte! Sõbrad, 5 minutit küsimuste esitamiseks!
küsimused
Küsimus publikult (edaspidi Q): - Tere päevast. Tänan teid väga raporti eest. Mul on kaks küsimust. Alustan millestki kergemeelsest: kas t-tähtede arv nimes "Kassimaja" skeemidel (3, 4, 7...) mõjutab kasside rahulolu?
YN: - Mille kogus?
Z: – täht t. Seal on kolm t-d, kuskil kolm t-d.
YN: - Kas ma ei parandanud seda? No muidugi teeb! Need on erinevad tooted – ma lihtsalt petsin teid kogu selle aja. Okei, ma teen nalja – vahet pole. Ah, just siin! Ei, see on sama asi, ma tegin kirjavea.
Z: - Aitäh. Teine küsimus on tõsine. Niipalju kui ma aru saan, elavad Clickhouse'is puhvertabelid eranditult mälus, neid ei puhverdata kettale ega ole seetõttu püsivad.
YN: - Jah.
Z: – Ja samal ajal puhverdab teie klient kettale, mis tähendab nende samade logide kohaletoimetamise teatud garantiid. Kuid see pole Clickhouse'is mingil juhul garanteeritud. Selgitage, kuidas garantii teostatakse, mille tõttu?.. Siin on see mehhanism täpsemalt
YN: – Jah, teoreetiliselt pole siin vastuolusid, sest kui Clickhouse kukub, saab seda tegelikult tuvastada miljonil erineval viisil. Kui Clickhouse jookseb kokku (kui see lõppeb valesti), võid jämedalt öeldes oma üleskirjutatud logi veidi tagasi kerida ja alustada hetkest, mil kõik oli täpselt korras. Oletame, et kerite minuti tagasi, see tähendab, et loetakse, et olete minuti jooksul kõik läbi loputanud.
Z: – See tähendab, et “Kittenhouse” hoiab akent kauem kinni ja suudab kukkumise korral selle ära tunda ja tagasi kerida?
YN: – Aga see on teoreetiliselt. Praktikas me seda ei tee ja usaldusväärne tarneaeg on nullist lõpmatuseni. Aga keskmiselt üks. Oleme rahul, et kui Clickhouse mingil põhjusel kokku jookseb või serverid "taaskäivituvad", siis kaotame natuke. Kõigil muudel juhtudel ei juhtu midagi.
Z: - Tere. Mulle tundus algusest peale, et kasutate tõesti UDP-d juba raporti algusest peale. Teil on http, kõik see... Ja enamik teie kirjeldatud probleemidest, nagu ma aru saan, on põhjustatud sellest konkreetsest lahendusest...
YN: – Mida me TCP-d kasutame?
Z: - Sisuliselt jah.
YN: - Ei.
Z: – Just fasthttp-ga oli probleeme, ühendusega oli probleeme. Kui oleksite just UDP-d kasutanud, oleksite säästnud aega. Noh, oleks probleeme pikkade sõnumitega või millegi muuga...
YN: - Millega?
Z: – Pikkade sõnumitega, kuna see ei pruugi MTU-sse mahtuda, midagi muud... Noh, võib olla oma probleeme. Küsimus on: miks mitte UDP?
YN: – Usun, et TCP/IP väljatöötanud autorid on minust palju targemad ja teavad minust paremini, kuidas pakette serialiseerida (et need läheks), samal ajal saateakent reguleerida, võrku mitte üle koormata, tagasisidet anda, mida ei loeta, arvestamata teisel poolel... Kõik need probleemid oleks minu meelest UDP-s olemas, ainult et sama asja ise juurutamiseks ja suure tõenäosusega peaksin kirjutama veel rohkem koodi kui juba kirjutasin halvasti. Mulle isegi ei meeldi C-keeles kirjutamine, rääkimata sellest...
Z: - Lihtsalt mugav! Saadetud ok ja ärge oodake midagi - see on täiesti asünkroonne. Tagasi tuli teade, et kõik on korras – see tähendab, et saabus; Kui seda ei tule, tähendab see, et see on halb.
YN: – Vajan mõlemat – pean saama saata nii tarnegarantiiga kui ka ilma garantiita. Need on kaks erinevat stsenaariumi. Ma pean mitte kaotama mõnda logi või mitte kaotama neid mõistlikkuse piires.
Z: — Ma ei raiska aega. Seda tuleb rohkem arutada. Aitäh.
Moderaator: – Kellel on küsimusi – käed taeva poole!
Z: - Tere, mina olen Sasha. Kuskil aruande keskel tekkis tunne, et lisaks TCP-le on võimalik kasutada ka valmislahendust - mingit Kafkat.
YN: – Noh... ma ütlesin, et ma ei taha vaheservereid kasutada, sest... Kafkas selgub, et meil on kümme tuhat hosti; tegelikult on meil rohkem – kümneid tuhandeid võõrustajaid. Kafkaga ilma puhverserverita võib olla valus teha. Lisaks, mis kõige tähtsam, see annab ikkagi "latentsuse", annab täiendavaid hoste, mis teil peavad olema. Aga ma ei taha neid saada – ma tahan...
Z: "Aga lõpuks läks see siiski nii."
YN: – Ei, võõrustajaid pole! See kõik töötab Clickhouse'i hostidel.
Z: - Noh, ja "Kittenhouse", mis on vastupidine - kus ta elab?
YN: - Clickhouse'i hostis ei kirjuta see kettale midagi.
Z: - Oletame.
Moderaator: - Kas sa oled rahul? Kas me saame teile palka anda?
Z: - Jah, sa saad. Tegelikult on sama asja saamiseks palju karkusid ja nüüd - eelmine vastus TCP teemal on minu arvates selle olukorraga vastuolus. Lihtsalt tundub, et kõike oleks saanud palju lühema ajaga põlvili teha.
YN: – Ja ka see, miks ma ei tahtnud Kafkat kasutada, sest Clickhouse Telegrami vestluses oli päris palju kaebusi, et näiteks Kafkalt on kirjad kadunud. Mitte Kafkast endast, vaid Kafka ja Clickhausi integratsioonist; või midagi ei haaku seal. Jämedalt öeldes oleks vaja siis Kafkale klient kirjutada. Ma ei usu, et oleks lihtsamat või usaldusväärsemat lahendust.
Z: – Ütle mulle, miks sa ei proovinud järjekordi ega mingit tavalist bussi? Kuna te ütlete, et asünkroonsusega saate logid ise läbi järjekorra saata ja vastuse saada asünkroonselt läbi järjekorra?
YN: – Palun soovitage, milliseid järjekordi võiks kasutada?
Z: – Kõik, isegi ilma garantiita, et need on korras. Mingi Redis, RMQ...
YN: – Mul on tunne, et Redis ei suuda suure tõenäosusega sellist sisestusmahtu tõmmata isegi ühele hostile (mitme serveri mõttes), mis Clickhouse’i välja tõmbab. Ma ei saa seda ühegi tõendiga kinnitada (ma pole seda võrdlenud), kuid mulle tundub, et Redis pole siin parim lahendus. Põhimõtteliselt võib seda süsteemi pidada improviseeritud sõnumijärjekorraks, kuid mis on kohandatud ainult "Clickhouse" jaoks.
Moderaator: – Juri, tänan sind väga. Teen ettepaneku lõpetada küsimused ja vastused siin ja öelda, kellele küsimuse esitajatest raamatu kingime.
YN: – Tahaksin kinkida esimesele küsimuse esitajale raamatu.
Moderaator: - Imeline! Suurepärane! Vapustav! Tänud!
Mõned reklaamid 🙂
Täname, et jäite meiega. Kas teile meeldivad meie artiklid? Kas soovite näha huvitavamat sisu? Toeta meid, esitades tellimuse või soovitades sõpradele, , algtaseme serverite ainulaadne analoog, mille me teie jaoks leiutasime: (saadaval RAID1 ja RAID10, kuni 24 tuuma ja kuni 40 GB DDR4-ga).
Dell R730xd 2x odavam Amsterdami Equinixi Tier IV andmekeskuses? Ainult siin Hollandis! Dell R420 – 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB – alates 99 dollarist! Millegi kohta lugema
Allikas: www.habr.com