HighLoad++ Moszkva 2018, Kongresszusi terem. november 9., 15:00
Absztraktok és előadások:
Jurij Nasretdinov (VKontakte): a jelentés a ClickHouse cégünkben való bevezetésének tapasztalatairól fog beszélni - miért van szükségünk rá, mennyi adatot tárolunk, hogyan írjuk meg stb.
További anyagok:
Jurij Naszretdinov: - Sziasztok! A nevem Jurij Naszretdinov, ahogy már bemutattak. A VKontakte-nál dolgozom. Arról fogok beszélni, hogyan illesztünk be adatokat a ClickHouse-ba a szerverflottánkból (több tízezer).
Mik azok a rönkök és miért kell gyűjteni őket?
Amit elmondunk: mit csináltunk, miért volt szükségünk a „ClickHouse”-ra, miért választottuk, milyen teljesítményt érhet el hozzávetőlegesen anélkül, hogy bármit is külön konfigurálna. Tovább fogok mesélni a puffertáblákról, a velük kapcsolatos problémákról és a nyílt forráskódból kifejlesztett megoldásainkról - KittenHouse és Lighthouse.
Miért kellett egyáltalán bármit tennünk (a VKontakte-on mindig minden jó, igaz?). Hibakeresési naplókat akartunk gyűjteni (és több száz terabájtnyi adat volt ott), talán valahogy kényelmesebb lenne statisztikát számolni; és van egy több tízezer szerverből álló flottánk, amelyről mindezt meg kell tenni.
Miért döntöttünk? Valószínűleg voltak megoldásaink a naplók tárolására. Itt van egy ilyen nyilvános „Backend VK”. Nagyon ajánlom, hogy iratkozzon fel rá.
Mik azok a naplók? Ez egy olyan motor, amely üres tömböket ad vissza. A VK motorjait mások mikroszolgáltatásoknak hívják. És itt van egy mosolygós matrica (elég sok lájk). Hogy hogy? No, hallgass tovább!
Mi használható naplók tárolására? Lehetetlen nem beszélni Hadupról. Aztán például az Rsyslog (ezeket a naplókat fájlokban tárolja). LSD. Ki tudja, mi az LSD? Nem, nem ez az LSD. Fájlok tárolása is. Nos, a ClickHouse egy furcsa lehetőség.
Clickhouse és versenytársak: követelmények és lehetőségek
Mit akarunk? Szeretnénk elérni, hogy ne kelljen túl sokat törődnünk a működéssel, hogy a dobozból, lehetőleg minimális konfigurációval működjön. Sokat akarunk írni, és gyorsan. És szeretnénk megőrizni mindenféle hónapokig, évekig, vagyis hosszú ideig. Lehet, hogy meg akarunk érteni valami problémát, amivel odajöttek hozzánk, és azt mondták: "Valami nem működik itt", és ez 3 hónapja volt), és szeretnénk látni, mi történt 3 hónappal ezelőtt." Az adattömörítés – egyértelmű, hogy miért lenne plusz –, mert csökkenti az általa elfoglalt helyet.
És van egy érdekes követelményünk: néha megírjuk néhány parancs kimenetét (pl. naplók), ez meglehetősen könnyen lehet több, mint 4 kilobájt. És ha ez a dolog UDP-n keresztül működik, akkor nem kell költenie... nem lesz "rezsije" a kapcsolatnak, és sok szervernél ez pluszt jelent.
Lássuk, mit kínál nekünk a nyílt forráskód. Először is megvan a Logs Engine - ez a mi motorunk; Elvileg mindenre képes, még hosszú sorokat is tud írni. Nos, nem tömöríti átláthatóan az adatokat - ha akarjuk, magunk is tömöríthetünk nagy oszlopokat... természetesen nem akarjuk (ha lehetséges). Csak az a baj, hogy csak azt tudja odaadni, ami az emlékezetébe illik; A többi olvasásához be kell szereznie ennek a motornak a binlogját, és ennek megfelelően elég hosszú ideig tart.
Milyen egyéb lehetőségek vannak? Például: "Hadup". Könnyű kezelhetőség... Ki gondolja, hogy a Hadupot könnyű beállítani? A felvétellel persze nincs gond. Olvasás közben néha kérdések merülnek fel. Elvileg azt mondanám, hogy valószínűleg nem, főleg rönköknél. Hosszú távú tárolás - természetesen igen, adattömörítés - igen, hosszú karakterláncok - egyértelmű, hogy rögzíthet. De nagyszámú szerverről rögzíteni... Valamit akkor is csinálnod kell magadnak!
Rsyslog. Valójában tartalék opcióként használtuk, hogy a binlog kiírása nélkül el tudjuk olvasni, de nem tud hosszú sort írni, elvileg nem írhat 4 kilobájtnál többet. Az adattömörítést ugyanúgy magának kell elvégeznie. Az olvasás fájlokból fog történni.
Aztán ott van az LSD „badushka” fejlesztése. Lényegében ugyanaz, mint az “Rsyslog”: támogatja a hosszú karakterláncokat, de UDP-n keresztül nem működik, sőt, emiatt sajnos elég sok mindent át kell odaírni. Az LSD-t újra kell tervezni, hogy több tízezer szerverről tudjon rögzíteni.
És itt! Egy vicces lehetőség az ElasticSearch. Hogy is mondjam? Az olvasással jól áll, vagyis gyorsan olvas, de az írással nem túl jól. Először is, ha tömöríti az adatokat, akkor nagyon gyenge. Valószínűleg a teljes keresés nagyobb adatstruktúrákat igényel, mint az eredeti kötet. Nehéz kezelni, és gyakran adódnak vele problémák. És ismét, Elastic-ban rögzítünk – mindent magunknak kell csinálnunk.
Itt a ClickHouse természetesen ideális választás. Az egyetlen dolog, hogy a több tízezer szerverről történő rögzítés probléma. De legalább van egy probléma, megpróbálhatjuk valahogy megoldani. A jelentés többi része pedig erről a problémáról szól. Milyen teljesítményre számíthat a ClickHouse-tól?
Hogyan fogjuk beilleszteni? MergeTree
Ki ne hallott volna vagy tudna közületek a „ClickHouse”-ról? El kell mondanom, nem? Nagyon gyors. Az ott található beillesztés - 1-2 gigabit/másodperc, akár 10 gigabit/másodperc sebességű sorozatfelvételek valóban kibírják ezt a konfigurációt - van két 6 magos Xeon (vagyis nem is a legerősebb), 256 gigabájt RAM, 20 terabájt RAID-ben (nincs konfigurálva, alapértelmezett beállítások). Alexey Milovidov, a ClickHouse fejlesztője valószínűleg sírva ül, mert nem konfiguráltunk semmit (nekünk minden így működött). Ennek megfelelően, mondjuk körülbelül 6 milliárd sor/másodperc pásztázási sebesség érhető el, ha az adatokat jól tömörítjük. Ha szereti a % egy szöveges karakterláncot - 100 millió sort másodpercenként, vagyis elég gyorsnak tűnik.
Hogyan fogjuk beilleszteni? Nos, tudod, hogy a VK PHP-t használ. Minden egyes PHP-munkásból HTTP-n keresztül beszúrjuk a „ClickHouse”-ba, minden rekordhoz a MergeTree táblába. Ki lát problémát ebben a rendszerben? Valamiért nem mindenki emelte fel a kezét. Hadd mondjam el.
Először is, sok szerver van - ennek megfelelően sok kapcsolat lesz (rossz). Akkor jobb, ha másodpercenként legfeljebb egyszer szúr be adatokat a MergeTree-be. És ki tudja miért? Rendben rendben. Erről mesélek egy kicsit bővebben. További érdekes kérdés, hogy nem analitikázunk, nem kell az adatokat gazdagítanunk, nincs szükségünk közbenső szerverekre, hanem közvetlenül a „ClickHouse”-ba szeretnénk beilleszteni (lehetőleg minél közvetlenebb, annál jobb).
Ennek megfelelően hogyan történik a beillesztés a MergeTree-ben? Miért jobb, ha legfeljebb másodpercenként egyszer vagy ritkábban illeszt be? A tény az, hogy a „ClickHouse” egy oszlopos adatbázis, és az adatokat az elsődleges kulcs növekvő sorrendjében rendezi, és amikor beszúr, akkora fájlszám jön létre, amely legalább annyi oszlopban van, ahány oszlopban az adatok rendezve vannak. az elsődleges kulcs szerint növekvő sorrendben (egy külön könyvtár jön létre, minden beillesztéshez egy fájlkészlet a lemezen). Aztán jön a következő beillesztés, és a háttérben nagyobb „partíciókká” egyesülnek. Mivel az adatok rendezve vannak, lehetőség van két rendezett fájl „egyesítésére” anélkül, hogy sok memóriát fogyasztana.
De ahogy sejthető, ha minden beszúráshoz 10 fájlt ír, akkor a ClickHouse (vagy a szervere) gyorsan véget ér, ezért ajánlott nagy tételben beszúrni. Ennek megfelelően az első rendszert soha nem indítottuk gyártásba. Azonnal elindítottunk egyet, ami itt a 2. számú:
Itt képzeljük el, hogy körülbelül ezer szerveren indítottuk el, csak PHP van. És minden szerveren ott van a helyi ügynökünk, amit „Kittenhouse”-nak hívtunk, amely egy kapcsolatot tart fenn a „ClickHouse”-szal, és néhány másodpercenként szúr be adatokat. Az adatokat nem a MergeTree-be, hanem egy puffertáblába szúrja be, ami pontosan arra szolgál, hogy elkerülje a közvetlenül a MergeTree-be való azonnali beszúrást.
Munka puffertáblákkal
Ami? A puffertáblák olyan memóriadarabok, amelyek szilánkosak (vagyis gyakran beilleszthetők). Több darabból állnak, és mindegyik darab független pufferként működik, és külön-külön öblítik ki őket (ha sok darab van a pufferben, akkor másodpercenként sok betét lesz). Lehet olvasni ezekből a táblákból - ekkor elolvasod a puffer és a szülő tábla tartalmának egyesülését, de ebben a pillanatban az írás le van tiltva, ezért jobb nem onnan olvasni. A puffer táblák pedig nagyon jó QPS-t mutatnak, vagyis 3 ezer QPS-ig egyáltalán nem lesz gond a behelyezésnél. Egyértelmű, hogy ha a szerver áramszünet, akkor az adatok elveszhetnek, mert csak a memóriában tárolták.
Ugyanakkor a pufferes séma bonyolítja az ALTER-t, mert először le kell dobni a régi puffertáblát a régi sémával (az adatok nem tűnnek el sehol, mert a tábla törlése előtt kiürül). Ezután „módosítja” a szükséges táblát, és újra létrehozza a puffertáblát. Ennek megfelelően, amíg nincs puffertábla, az adatok nem fognak sehova áramlani, de legalább lokálisan lehet lemezen.
Mi az a Kittenhouse és hogyan működik?
Mi az a KittenHouse? Ez egy proxy. Találd ki milyen nyelven? A legtöbb hype-témát összegyűjtöttem a beszámolómban - „Clickhouse”, Menj, talán eszembe jut valami más. Igen, ez Go-ban van írva, mert nem igazán tudom, hogyan kell C-ben írni, nem is akarok.
Ennek megfelelően kapcsolatot tart fenn minden szerverrel, és tud írni a memóriába. Például, ha hibanaplókat írunk a Clickhouse-ba, akkor ha a Clickhouse-nak nincs ideje adatok beszúrására (végül is, ha túl sok van írva), akkor nem duzzasztjuk fel a memóriát - a többit egyszerűen kidobjuk. Mert ha több gigabitet írunk ki másodpercenként, akkor valószínűleg ki is dobhatunk néhányat. Kittenhouse képes erre. Ráadásul megbízható kézbesítést tud végrehajtani, azaz lemezre ír a helyi gépen, és minden alkalommal (ott, pár másodpercenként egyszer) megpróbál adatokat kézbesíteni ebből a fájlból. És először a szokásos értékek formátumot használtuk - nem valami bináris formátumot, hanem szöveges formátumot (mint a normál SQL-ben).
De aztán ez történt. Megbízható kézbesítést használtunk, naplót írtunk, majd döntöttünk (feltételes tesztfürt volt)... Több órára ki volt rakva, és újra előkerült, és ezer szerverről elindult egy beillesztés - kiderült, hogy a Clickhouse-ban még mindig van egy „Szál a kapcsolaton” - ennek megfelelően ezer kapcsolatnál egy aktív beillesztés körülbelül másfél ezer átlagos terheléshez vezet a szerveren. Meglepő módon a szerver elfogadta a kéréseket, de az adatok egy idő után is bekerültek; de a szervernek nagyon nehéz volt kiszolgálni...
Add hozzá az nginx-et
A Thread per connection modell ilyen megoldása az nginx. Telepítettük az nginx-et a Clickhouse elé, ezzel egyidejűleg beállítottuk a kiegyenlítést két replikához (a beillesztési sebességünk 2-szeresére nőtt, bár nem tény, hogy ennek így kellene lennie) és korlátoztuk a Clickhouse csatlakozások számát, a felfelé és ennek megfelelően több , mint 50 csatlakozásban, úgy tűnik, nincs értelme beilleszteni.
Aztán rájöttünk, hogy ennek a sémának általában vannak hátrányai, mert itt csak egy nginx van. Ennek megfelelően, ha ez az nginx összeomlik, a replikák jelenléte ellenére adatokat veszítünk, vagy legalábbis nem írunk sehova. Ezért készítettük el saját terheléselosztásunkat. Arra is rájöttünk, hogy a „Clickhouse” továbbra is alkalmas rönkök számára, és a „démon” is elkezdte írni a naplóit a „Clickhouse”-ba - őszintén szólva, nagyon kényelmes. Még mindig használjuk más „démonokhoz”.
Aztán felfedeztük ezt az érdekes problémát: ha nem szabványos beszúrási módszert használunk SQL módban, az egy teljes értékű AST alapú SQL elemzőt kényszerít ki, ami meglehetősen lassú. Ennek megfelelően olyan beállításokat adtunk hozzá, amelyek biztosítják, hogy ez soha ne forduljon elő. Csináltunk terheléselosztást, állapotfelmérést, hogy ha valaki meghal, akkor is hagyjuk az adatokat. Mostanra elég sok táblánk van, amelyekre különböző Clickhouse-fürtökre van szükségünk. És elkezdtünk más felhasználási módokon is gondolkodni – például naplókat akartunk írni az nginx modulokból, de nem tudják, hogyan kommunikáljanak az RPC-nkkel. Nos, szeretném megtanítani nekik, hogyan küldjenek legalább valahogy - például, hogy UDP-n keresztül fogadják az eseményeket a localhost-on, majd továbbítsák a Clickhouse-nak.
Egy lépésre a megoldástól
A végső séma így kezdett kinézni (a séma negyedik verziója): a Clickhouse előtt minden szerveren van nginx (ugyanazon a szerveren), és egyszerűen proxyzik a kéréseket a localhost felé, a kapcsolatok számát 50-re korlátozva. darabok. És ez a séma már egészen bevált, minden nagyon rendben volt vele.
Körülbelül egy hónapig éltünk így. Mindenki örült, táblákat adtak hozzá, tettek hozzá... Általánosságban kiderült, hogy a puffer táblák hozzáadása nem túl optimális (mondjuk így). Minden táblázatban 16 darabot csináltunk és néhány másodperces felvillanási időközzel; 20 asztalunk volt, és mindegyik táblázat 8 beszúrást kapott másodpercenként - és ezen a ponton elkezdődött a „Clickhouse”... a rekordok lassulni kezdtek. Még csak nem is mentek át... Az Nginx-nek alapból volt egy olyan érdekessége, hogy ha a kapcsolatok az upstreamben véget értek, akkor egyszerűen az 502-t adta vissza minden új kérésnek.
És itt van (most néztem meg magában a Clickhouse naplóit), hogy a kérelmek körülbelül fél százaléka sikertelen volt. Ennek megfelelően magas volt a lemezkihasználtság, sok volt az összevonás. Nos, mit csináltam? Természetesen nem törődtem azzal, hogy rájöjjek, miért pont a kapcsolat és az upstream véget ért.
Az nginx lecserélése fordított proxyra
Úgy döntöttem, hogy ezt magunknak kell kezelnünk, nem kell az nginxre bíznunk - az nginx nem tudja, milyen táblák vannak a Clickhouse-ban, és lecseréltem az nginx-et egy fordított proxyra, amit szintén magam írtam.
Mit csinál? A fasthttp „goshnoy” könyvtáron alapul, azaz gyorsan, majdnem olyan gyorsan, mint az nginx. Elnézést, Igor, ha itt van (megjegyzés: Igor Sysoev orosz programozó, aki létrehozta az nginx webszervert). Meg tudja érteni, hogy ezek milyen lekérdezések – INSERT vagy SELECT –, ennek megfelelően különböző kapcsolati készleteket tárol a különböző típusú lekérdezésekhez.
Ennek megfelelően, ha nincs is időnk a beillesztési kérések teljesítésére, a „kiválasztottak” átmennek, és fordítva. És puffertáblákba csoportosítja az adatokat - egy kis pufferrel: ha voltak hibák, szintaktikai hibák stb. - hogy azok ne befolyásolják nagymértékben a többi adatot, mert amikor egyszerűen beszúrtuk a puffertáblákba, kis "bachi" volt, és az összes szintaktikai hiba csak ezt a kis darabot érintette; és itt már nagy puffert fognak érinteni. A kicsi 1 megabájt, vagyis nem olyan kicsi.
A szinkronizálás beszúrása és lényegében az nginx lecserélése lényegében ugyanazt teszi, mint az nginx korábban – ehhez nem kell módosítania a helyi „Cicaházat”. És mivel fasthttp-t használ, nagyon gyors - másodpercenként több mint 100 ezer kérést kezdeményezhet egyetlen beillesztésre fordított proxyn keresztül. Elméletileg egy-egy sort beszúrhat a cicaház fordított proxyjába, de természetesen ezt nem tesszük.
A séma így kezdett kinézni: „Kittenhouse”, a fordított proxy sok kérést táblákba csoportosít, a puffertáblák pedig beillesztik a fő kérésekbe.
A gyilkos ideiglenes megoldás, a cica pedig végleges
Ez egy érdekes probléma... Használt már valaki fasthttp-t? Ki használta a fasthttp-t a POST kérésekkel? Valószínűleg ezt tényleg nem kellett volna megtenni, mert alapértelmezés szerint puffereli a kérés törzsét, és a puffer mérete 16 megabájt volt. A beillesztés egy bizonyos ponton leállt, és 16 megabájtos darabok kezdtek érkezni mind a tízezer szerverről, és mindegyiket pufferelték a memóriában, mielőtt elküldték volna a Clickhouse-nak. Ennek megfelelően a memória elfogyott, jött az Out-Of-Memory Killer, és megölte a fordított proxyt (vagy „Clickhouse”, amely elméletileg többet tudott „enni”, mint a fordított proxy). A ciklus megismétlődött. Nem túl kellemes probléma. Bár erre csak több hónapos működés után botlottunk.
Mit tettem? Megint nem igazán szeretem megérteni, hogy mi is történt pontosan. Szerintem elég nyilvánvaló, hogy nem szabad a memóriába pufferelni. A fasthttp-t nem tudtam javítani, pedig próbáltam. De megtaláltam a módját, hogy ne kelljen foltozni semmit, és kitaláltam a saját módszeremet HTTP-ben - ezt KITTEN-nek neveztem el. Nos, ez logikus - „VK”, „Cica”... Mi más?...
Ha egy kérés érkezik a szerverhez a Kitten metódussal, akkor a szervernek logikusan „miau” kell válaszolnia. Ha erre válaszol, akkor azt tekintjük, hogy megérti ezt a protokollt, és akkor elfogom a kapcsolatot (a fasthttp-nek van ilyen módszere), és a kapcsolat „nyers” módba kerül. Miért van szükségem rá? Szeretném szabályozni, hogyan történjen a TCP-kapcsolatokból történő olvasás. A TCP-nek van egy csodálatos tulajdonsága: ha senki sem olvas a másik oldalról, akkor az írás várakozni kezd, és a memóriát nem fordítják különösebben erre.
És így kb 50 ügyféltől olvasok egyszerre (ötventől, mert ötvenből biztosan elégnek kell lennie, még akkor is, ha másik DC-ről jön az árfolyam)... A fogyasztás ezzel a megközelítéssel legalább 20-szorosára csökkent, de őszintén szólva , pontosan nem tudtam lemérni, hogy hány óra, mert az már értelmetlen (már elérte a hibaszintet). A protokoll bináris, azaz tartalmazza a tábla nevét és adatait; nincsenek http fejlécek, így nem használtam webes socketet (nem kell kommunikálnom a böngészőkkel - készítettem egy protokollt, amely megfelel az igényeinknek). És minden rendben lett vele.
Szomorú a puffertábla
Nemrég találkoztunk a puffertáblák egy másik érdekes funkciójával. És ez a probléma már sokkal fájdalmasabb, mint a többi. Képzeljük el ezt a helyzetet: Ön már aktívan használja a Clickhouse-t, több tucat Clickhouse szerverrel rendelkezik, és vannak olyan kérései, amelyek beolvasása nagyon sokáig tart (mondjuk több mint 60 másodpercig); és jössz, és csináld meg az Altert ebben a pillanatban... Addig is az „Alter” előtt kezdődő „kiválasztások” nem fognak szerepelni ebben a táblázatban, az „Alter” nem indul el – valószínűleg a „Clickhouse” működésének néhány jellemzője ez a hely. Esetleg ez javítható? Vagy nem lehetséges?
Általában jól látható, hogy a valóságban ez nem olyan nagy probléma, de a puffer táblákkal ez fájdalmasabbá válik. Mert ha mondjuk az Ön „Alter” időtúllépései (és előfordulhat, hogy egy másik gazdagépen lejár – nem a tiéden, hanem például egy replikán), akkor... Törölte a puffertáblát, az „Alter”-et ( vagy más gazdagép) időtúllépést szenvedett. akkor „Alter” hiba lépett fel) - továbbra is gondoskodnia kell arról, hogy az adatok írása folytatódjon: visszaállítja a puffertáblákat (a szülőtáblával megegyező séma szerint), majd Az „Alter” átmegy, végül véget ér, és a tábla puffere sémájában kezd eltérni a szülőtől. Attól függően, hogy mi volt az „Alter”, előfordulhat, hogy a betét már nem megy ebbe a puffertáblába - ez nagyon szomorú.
Van egy ilyen jel is (talán valaki észrevette) - ezt query_thread_lognak hívják a Clickhouse új verzióiban. Alapértelmezés szerint egyes verziókban volt ilyen. Itt pár hónap alatt 840 millió rekordot halmoztunk fel (100 gigabájt). Ez annak köszönhető, hogy oda „beszúrásokat” írtak (talán egyébként most nem írják). Mint mondtam, a „beszúrásaink” kicsik – sok „beszúrásunk” volt a puffertáblákban. Egyértelmű, hogy ez le van tiltva – csak elmondom, mit láttam a szerverünkön. Miért? Ez egy újabb érv a puffertáblák használata ellen! Foltos nagyon szomorú.
Ki tudta, hogy ezt a fickót Spottynak hívják? A VK alkalmazottai felemelték a kezüket. RENDBEN.
A „KitttenHouse” terveiről
A terveket általában nem osztják meg, igaz? Hirtelen nem fogod teljesíteni őket, és nem fogsz jól kinézni mások szemében. De vállalom a kockázatot! A következőket szeretnénk tenni: a puffertáblák, úgy tűnik, még mindig mankónak számítanak, és magunknak kell pufferelnünk a beillesztést. De még mindig nem akarjuk lemezre pufferelni, ezért a beillesztést a memóriába puffereljük.
Ennek megfelelően, amikor egy „beszúrás” készül, az már nem lesz szinkron – már puffertáblaként fog működni, beszúr a szülőtáblába (na jó, valamikor később), és külön csatornán jelenti, hogy mely beillesztések mentek át és melyek Nincs.
Miért nem tudom elhagyni a szinkron betétet? Sokkal kényelmesebb. A helyzet az, hogy ha 10 ezer gazdagépről szúrsz be, akkor minden rendben van - minden gazdagéptől kapsz egy keveset, másodpercenként egyszer szúrod be, minden rendben van. De szeretném, ha ez a séma működne például két gépről, hogy nagy sebességgel lehessen letölteni - talán nem a maximumot hozza ki a Clickhouse-ból, de legalább 100 megabájtot írjon egy gépről egy fordított proxyn keresztül - ezt a sémának nagy és kis mennyiségre is méreteznie kell, így nem várhatunk egy másodpercet sem minden beillesztésre, tehát aszinkronnak kell lennie. És ugyanígy az aszinkron megerősítéseknek a beillesztés befejezése után kell érkezniük. Majd megtudjuk, hogy sikerült-e vagy sem.
A legfontosabb az, hogy ebben a sémában biztosan tudjuk, megtörtént-e a beillesztés vagy sem. Képzeld el ezt a helyzetet: van egy puffertáblád, írtál bele valamit, majd mondjuk a tábla írásvédett módba vált, és megpróbálta kiüríteni a puffert. Hová fognak menni az adatok? A pufferben maradnak. De ebben nem lehetünk biztosak - mi van, ha valami más hiba történik, ami miatt az adatok nem maradnak a pufferben... (Cím: Alexey Milovidov, Yandex, ClickHouse fejlesztő) Vagy marad? Mindig? Alexey meggyőz bennünket, hogy minden rendben lesz. Nincs okunk arra, hogy ne higgyünk neki. De mindegy: ha nem használunk puffertáblákat, akkor nem lesz velük probléma. Dupla annyi tábla létrehozása is kényelmetlen, bár elvileg nincs nagy probléma. Ez a terv.
Beszéljünk az olvasásról
Most beszéljünk az olvasásról. Ide írtuk a saját eszközünket is. Úgy tűnik, minek írd ide a saját hangszeredet?... És ki használta a Tabixot? Valahogy kevesen emelték fel a kezét... És ki elégedett a Tabix teljesítményével? Nos, nem vagyunk vele elégedettek, és nem túl kényelmes az adatok megtekintéséhez. Elemzésre jó, de csak megtekintésre nyilvánvalóan nincs optimalizálva. Szóval megírtam a sajátomat, saját felületemet.
Nagyon egyszerű - csak adatokat tud olvasni. Nem tudja, hogyan kell grafikát mutatni, nem tud semmit. De megmutathatja, hogy mire van szükségünk: például hány sor van a táblázatban, mennyi helyet foglal el (oszlopokra bontás nélkül), vagyis egy nagyon alap interfész az, amire szükségünk van.
És nagyon hasonlít a Sequel Pro-hoz, de csak a Twitter Bootstrap-jén és a második verzióján készült. Azt kérdezed: "Juri, miért a második verzióban?" Melyik évben? 2018? Általánosságban elmondható, hogy ezt elég régen megtettem a „Muscle” (MySQL) esetében, és csak néhány sort változtattam a lekérdezésekben, és elkezdett működni a „Clickhouse”-nál, amiért külön köszönet! Mivel az elemző nagyon hasonlít az „izom”-hoz, és a lekérdezések nagyon hasonlóak - nagyon kényelmes, különösen kezdetben.
Nos, képes szűrni a táblákat, meg tudja mutatni a tábla szerkezetét és tartalmát, lehetővé teszi a rendezést, az oszlopok szerinti szűrést, megmutatja az eredményt eredményező lekérdezést, az érintett sorokat (az eredmény hányat), azaz a alapvető dolgok az adatok megtekintéséhez. Elég gyors.
Van szerkesztő is. Őszintén, megpróbáltam ellopni a teljes szerkesztőt a Tabixtól, de nem sikerült. De valahogy működik. Elvileg ennyi.
A "Clickhouse" odúkhoz alkalmas
Szeretném elmondani, hogy a Clickhouse az összes leírt probléma ellenére nagyon jól használható rönkök számára. A legfontosabb, hogy megoldja a problémánkat - nagyon gyors, és lehetővé teszi a naplók oszlopok szerinti szűrését. A puffertáblák elvileg nem teljesítettek jól, de általában senki sem tudja, miért... Talán most már jobban tudja, hol lesznek problémái.
TCP? Általában a VK-ban szokás az UDP-t használni. És amikor TCP-t használtam... Persze senki nem mondta nekem: „Juri, mit beszélsz! Nem teheted, szükséged van UDP-re." Kiderült, hogy a TCP nem is olyan ijesztő. Az egyetlen dolog az, hogy ha több tízezer aktív vegyületet ír, akkor egy kicsit alaposabban kell elkészítenie; de lehetséges, és nagyon egyszerű.
Megígértem, hogy felteszem a „Kittenhouse”-t és a „Lighthouse”-t a HighLoad Siberia-ra, ha mindenki előfizet a nyilvános „VK backendünkre”... És tudod, nem mindenki iratkozott fel... Természetesen nem fogom követelni, hogy iratkozzon fel a mi oldalunkra. nyilvános. Még mindig túl sokan vagytok, valaki meg is sértődhet, de akkor is iratkozzatok fel (és itt olyan szemeket kell csinálnom, mint egy macskának). Ez az . Nagyon szépen köszönjük! A Github a miénk . A Clickhouse segítségével haja puha és selymes lesz.
moderátor: - Barátaim, most kérdések. Közvetlenül azután, hogy bemutatjuk az elismerő oklevelet és az Ön VHS-ről szóló jelentését.
Jurij Naszretdinov (a továbbiakban: YN): – Hogyan tudtad felvenni a riportomat VHS-re, ha éppen véget ért?
moderátor: – Azt sem lehet teljesen meghatározni, hogy a „Clickhouse” hogyan fog működni vagy sem! Barátaim, 5 perc a kérdésekre!
kérdések
A hallgatóság kérdése (a továbbiakban: Q): - Jó napot. Köszönöm szépen a beszámolót. Két kérdésem van. Kezdem egy komolytalannal: a diagramokon (3, 4, 7...) a "Cicaház" névben szereplő t betűk száma befolyásolja a macskák elégedettségét?
YN: - Mennyit?
Z: – t betű. Három t van, valahol három t körül.
YN: - Nem javítottam? Hát persze, hogy igen! Ezek különböző termékek – egész idő alatt csak becsaptalak. Oké, viccelek – nem számít. Ah, itt! Nem, ez ugyanaz, elgépeltem.
Z: - Köszönöm. A második kérdés komoly. Ha jól értem, a Clickhouse-ban a puffertáblák kizárólag a memóriában élnek, nincsenek lemezre pufferelve, és ennek megfelelően nem perzisztensek.
YN: - Igen.
Z: – Ezzel egyidejűleg a kliense a lemezre pufferel, ami bizonyos garanciát jelent ugyanezen naplók kézbesítésére. De ez semmiképpen sem garantált a Clickhouse-nál. Magyarázza el, hogyan történik a jótállás, minek köszönhetően?.. Itt van ez a mechanizmus részletesebben
YN: – Igen, elméletileg itt nincsenek ellentmondások, mert amikor a Clickhouse elesik, valójában millióféleképpen lehet észlelni. Ha a Clickhouse összeomlik (ha helytelenül végződik), akkor durván visszatekerhetsz egy kicsit a felírt naplódból, és attól a pillanattól kezdve kezdheted, amikor minden pontosan rendben volt. Tegyük fel, hogy visszatekersz egy percet, vagyis a rendszer egy perc alatt kimosott mindent.
Z: – Vagyis a „Cicaház” tovább tartja az ablakot, és leesés esetén felismeri és visszatekerheti?
YN: - De ez elméletben van. A gyakorlatban ezt nem tesszük, és a megbízható szállítás nullától a végtelenig tart. De átlagosan egyet. Meg vagyunk elégedve azzal, hogy ha a Clickhouse valamilyen okból összeomlik, vagy a szerverek „újraindulnak”, akkor veszítünk egy keveset. Minden más esetben semmi sem fog történni.
Z: - Helló. A kezdetektől fogva úgy tűnt számomra, hogy Ön valóban UDP-t fog használni a jelentés legelejétől fogva. Van http, minden... És az általad leírt problémák többségét, ha jól értem, ez a megoldás okozta...
YN: – Mire használjuk a TCP-t?
Z: - Lényegében igen.
YN: - Nem.
Z: – A fasthttp-vel voltak gondok, a kapcsolattal. Ha csak az UDP-t használta volna, időt spórolhatott volna magának. Nos, gondok lennének a hosszú üzenetekkel vagy valami mással...
YN: - Mivel?
Z: – Hosszú üzenetekkel, mert lehet, hogy nem fér bele az MTU-ba, valami más... Nos, lehetnek saját gondjaik. A kérdés az: miért nem az UDP?
YN: – Úgy gondolom, hogy a TCP/IP-t fejlesztő szerzők sokkal okosabbak nálam, és nálam jobban tudják, hogyan kell a csomagokat szerializálni (hogy menjenek), ugyanakkor állítsa be a küldési ablakot, ne terhelje túl a hálózatot, adjon visszajelzést arról, nem olvassa el, nem számítva a másik oldalra... Mindezek a problémák véleményem szerint az UDP-ben léteznének, csak még több kódot kellene írnom, mint amennyit már írtam, hogy magam implementáljam ugyanazt, és nagy valószínűséggel rosszul. Nem is igazán szeretek C-ben írni, nemhogy ott...
Z: - Csak kényelmes! Rendben elküldve, és ne várj semmit - teljesen aszinkron. Visszajött egy értesítés, hogy minden rendben van – ez azt jelenti, hogy megérkezett; Ha nem jön, az azt jelenti, hogy rossz.
YN: – Mindkettőre szükségem van – Kézbesítési garanciával és kézbesítési garancia nélkül is tudjam küldeni. Ez két különböző forgatókönyv. Nem kell elveszítenem néhány naplót, vagy nem kell elveszítenem azokat ésszerű határokon belül.
Z: - Nem vesztegetem az időt. Erről bővebben kell beszélni. Köszönöm.
moderátor: – Akinek kérdése van – kezet az égnek!
Z: - Hello, Sasha vagyok. Valahol a riport közepén megjelent az az érzés, hogy a TCP mellett egy kész megoldást is lehetett használni - valamiféle Kafkát.
YN: – Hát... mondtam, hogy nem akarok köztes szervereket használni, mert... Kafkában kiderül, hogy tízezer hostunk van; sőt, több tízezer házigazdánk van. Fájdalmas is lehet Kafkával proxy nélkül csinálni. Ezen kívül, ami a legfontosabb, továbbra is „latenciát” ad, plusz hostokat ad, amelyekre szükség van. De nem akarom, hogy legyenek – azt akarom…
Z: – De végül mégis így alakult.
YN: – Nem, nincsenek házigazdák! Ez mind működik Clickhouse gazdagépeken.
Z: - Nos, és a „Cicaház”, ami fordítva van – hol lakik?
YN: – A Clickhouse gazdagépen nem ír semmit a lemezre.
Z: - Tegyük fel.
moderátor: - Elégedett vagy? Adhatunk fizetést?
Z: - Igen tudsz. Valójában sok mankó van annak érdekében, hogy ugyanazt kapjuk, és most - az előző válasz a TCP témájában véleményem szerint ellentmond ennek a helyzetnek. Egyszerűen úgy érzem, hogy sokkal rövidebb idő alatt mindent meg lehetett volna tenni a térdemen.
YN: – És azt is, hogy miért nem akartam Kafkát használni, mert a Clickhouse Telegram chaten elég sok panasz érkezett, hogy például elvesztek Kafkától az üzenetek. Nem magától Kafkától, hanem Kafka és Clickhaus integrációjában; vagy valami nem kapcsolódott oda. Nagyjából akkor kellene Kafkának ügyfelet írni. Szerintem ennél egyszerűbb vagy megbízhatóbb megoldás nem létezik.
Z: – Mondd, miért nem próbáltál ki semmilyen sorban állást vagy valami közös buszt? Mivel azt mondja, hogy az aszinkronizálással elküldheti magát a naplókat a sorban, és aszinkron módon fogadhatja a választ a sorban?
YN: – Kérem, javasolja, milyen sorokat lehetne használni?
Z: – Bármelyik, akár garancia nélkül is, hogy rendben vannak. Valamiféle Redis, RMQ...
YN: – Van egy olyan érzésem, hogy a Redis nagy valószínűséggel még egy hoszton sem lesz képes ekkora beillesztést (több kiszolgáló értelemben), amelyik kihúzza a Clickhouse-t. Ezt semmilyen bizonyítékkal nem tudom alátámasztani (nem benchmarkoltam), de nekem úgy tűnik, hogy a Redis nem a legjobb megoldás itt. Elvileg ez a rendszer egy rögtönzött üzenetsornak tekinthető, de csak a „Clickhouse”-ra van szabva.
moderátor: – Yuri, köszönöm szépen. Azt javaslom, hogy itt fejezzük be a kérdéseket és válaszokat, és mondjuk meg, hogy a kérdést feltevők közül kinek adjuk át a könyvet.
YN: – Az első kérdést feltevőnek könyvet szeretnék adni.
moderátor: - Csodálatos! Nagy! Mesés! Nagyon köszönöm!
Néhány hirdetés 🙂
Köszönjük, hogy velünk tartott. Tetszenek cikkeink? További érdekes tartalmakat szeretne látni? Támogass minket rendeléssel vagy ajánlj ismerőseidnek, , a belépő szintű szerverek egyedülálló analógja, amelyet mi találtunk ki Önnek: (RAID1 és RAID10, akár 24 maggal és akár 40 GB DDR4-gyel is elérhető).
A Dell R730xd kétszer olcsóbb az amszterdami Equinix Tier IV adatközpontban? Csak itt Hollandiában! Dell R420 - 2x E5-2430 2.2 Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99 dollártól! Olvasni valamiről
Forrás: will.com