Áprilisban az Avito mérnökei online találkozókra gyűltek össze a ClickHouse fő fejlesztőjével, Alexey Milovidovval és Kirill Shvakovval, az Integros Golang fejlesztőjével. Megbeszéltük, hogyan használunk adatbázis-kezelő rendszert, és milyen nehézségekbe ütközünk.
A megbeszélés alapján összeállítottunk egy cikket, amelyben szakértők válaszoltak a mi és a hallgatóság kérdéseire a biztonsági mentésekkel, az adatok újrafelosztásával, a külső szótárakról, a Golang meghajtóról és a ClickHouse verziók frissítéséről. Hasznos lehet azoknak a fejlesztőknek, akik már aktívan dolgoznak a Yandex DBMS-sel, és érdeklődnek annak jelene és jövője iránt. Alapértelmezés szerint a válaszokat Alexey Milovidov adja, hacsak másképp nem írják.
Legyen óvatos, sok szöveg van a vágás alatt. Reméljük, hogy a kérdéseket tartalmazó tartalom segít eligazodni.
Tartalom
Ha nem szeretné elolvasni a szöveget, megtekintheti az összejövetelekről készült felvételt . Az időkódok a videó alatti első kommentben találhatók.
A ClickHouse folyamatosan frissül, de adataink nem. Mit kell tenni ellene?
A ClickHouse folyamatosan frissül, és a végső feldolgozásra optimalizált adataink nem frissülnek, és biztonsági másolatban vannak.
Tegyük fel, hogy volt valami probléma, és az adatok elvesztek. A visszaállítás mellett döntöttünk, és kiderült, hogy a régi partíciók, amelyek a biztonsági mentési szervereken vannak tárolva, nagyon eltérnek a ClickHouse jelenleg használt verziójától. Mi a teendő ilyen helyzetben, és lehetséges-e?
Lehetetlen az a helyzet, amikor visszaállította az adatokat egy régi formátumú biztonsági másolatból, de az nem csatlakozik az új verzióhoz. Gondoskodunk arról, hogy a ClickHouse adatformátuma mindig visszafelé kompatibilis maradjon. Ez sokkal fontosabb, mint a funkcionalitás visszafelé kompatibilitása, ha néhány ritkán használt funkció viselkedése megváltozott. A ClickHouse új verziójának mindig képesnek kell lennie a lemezen tárolt adatok olvasására. Ez a törvény.
Melyek a jelenlegi legjobb gyakorlatok a ClickHouse adatok biztonsági mentésére?
Hogyan készítsünk biztonsági másolatot, ha figyelembe vesszük, hogy van optimalizált végső műveletünk, hatalmas terabájt-adatbázisunk, és olyan adatok, amelyeket mondjuk az utolsó három napra frissítenek, és akkor nem történik semmilyen eljárás?
Elkészíthetjük saját megoldásunkat, és ráírhatjuk a bash-ra: gyûjtsük össze ezeket a biztonsági másolatokat ilyen-olyan módon. Lehet, hogy nem kell semmit mankózni, és a biciklit már régen feltalálták?
Kezdjük a legjobb gyakorlatokkal. Kollégáim mindig azt tanácsolják, hogy a biztonsági mentésekkel kapcsolatos kérdésekre válaszolva emlékeztesse őket a Yandex.Cloud szolgáltatásra, ahol ezt a problémát már megoldották. Tehát lehetőleg használd.
A biztonsági mentésekre nincs teljes megoldás, száz százalékban a ClickHouse-ba van beépítve. Van néhány üres, amit fel lehet használni. A teljes megoldás eléréséhez vagy egy kicsit manuálisan kell bütykölnie, vagy szkriptek formájában burkolókat kell létrehoznia.
A legegyszerűbb megoldásokkal kezdem, és a legkifinomultabbakkal fejezem be, az adatmennyiségtől és a klaszter méretétől függően. Minél nagyobb a klaszter, annál összetettebb lesz a megoldás.
Ha az adatokat tartalmazó tábla csak néhány gigabájtot foglal el, a biztonsági mentés a következőképpen történhet:
- Mentse el a tábladefiníciót, azaz a metaadatokat − táblázat létrehozása megjelenítése.
- Készítsen kiírást a ClickHouse kliens segítségével - válasszuk * az asztalról fájlhoz. Alapértelmezés szerint TabSeparated formátumban kap egy fájlt. Ha hatékonyabb akar lenni, megteheti natív formátumban.
Ha az adatmennyiség nagyobb, akkor a biztonsági mentés több időt és helyet igényel. Ezt logikai biztonsági mentésnek nevezzük, nincs a ClickHouse adatformátumhoz kötve. Ha igen, akkor utolsó lehetőségként készíthet biztonsági másolatot, és feltöltheti a MySQL-be helyreállítás céljából.
Fejlettebb esetekben a ClickHouse beépített képességgel rendelkezik, hogy pillanatképet készítsen a partíciókról a helyi fájlrendszerben. Ez a funkció kérésre elérhető asztal fagyasztó partíció módosítása. Vagy egyszerűen módosítsa az asztal lefagyasztását - ez egy pillanatkép az egész táblázatról.
A pillanatkép konzisztensen egy táblához, egy szilánkon jön létre, vagyis így lehetetlen konzisztens pillanatképet létrehozni a teljes fürtről. De a legtöbb feladatnál nincs ilyen igény, és elegendő egy kérést végrehajtani minden egyes szilánkon, és következetes pillanatképet kapni. Hardlinkek formájában jön létre, ezért nem foglal több helyet. Ezután másolja ezt a pillanatképet a biztonsági mentési kiszolgálóra vagy a biztonsági mentésekhez használt tárhelyre.
Egy ilyen biztonsági másolat visszaállítása meglehetősen egyszerű. Először hozzon létre táblákat a meglévő tábladefiníciók segítségével. Ezután másolja a partíciók mentett pillanatképeit ezekhez a táblákhoz a Directory-Detached mappába, és futtassa a lekérdezést partíció csatolása. Ez a megoldás nagyon alkalmas a legkomolyabb adatmennyiségek kezelésére.
Néha valami még menőbbre van szükség – olyan esetekben, amikor több tíz vagy akár több száz terabájt van minden szerveren és több száz szerveren. Van itt egy megoldás, amit a Yandex.Metrica kollégáimtól vettem át. Nem ajánlom mindenkinek – olvassa el és döntse el maga, hogy megfelelő-e vagy sem.
Először több szervert kell létrehoznia nagy lemezpolcokkal. Ezután ezeken a kiszolgálókon hozzon létre több ClickHouse szervert, és állítsa be őket úgy, hogy ugyanazon szilánkok másik replikájaként működjenek. Ezután használjon fájlrendszert vagy valamilyen eszközt ezeken a kiszolgálókon, amely lehetővé teszi pillanatképek készítését. Itt két lehetőség van. Az első lehetőség az LVM pillanatképek, a második lehetőség a ZFS Linuxon.
Ezt követően minden nap létre kell hoznia egy pillanatképet, amely hazudik és helyet foglal. Természetesen, ha az adatok változnak, a hely mennyisége idővel nő. Ezt a pillanatképet bármikor elő lehet venni, és vissza lehet állítani az adatokat, olyan furcsa megoldás. Ezenkívül korlátoznunk kell ezeket a replikákat a konfigurációban, hogy ne próbáljanak vezetővé válni.
Lehetséges lesz a replikák ellenőrzött késleltetése az aknákban?
Idén a ClickHouse-ban aknák készítését tervezi. Lehetséges-e megszervezni bennük a replikák ellenőrzött késését? Szeretnénk használni, hogy megvédjük magunkat a változásokkal és egyéb változtatásokkal járó negatív forgatókönyvektől.
Lehetséges valamilyen visszaállítást az alterekhez? Például egy meglévő aknában mondd, hogy eddig a pillanatig alkalmazza a változtatásokat, és ettől a pillanattól kezdve abbahagyja a változtatások alkalmazását?
Ha egy parancs érkezett a fürtünkbe, és eltörte, akkor van egy feltételes replikánk egy órás késéssel, ahol azt mondhatjuk, hogy jelenleg használjuk, de az utolsó tíz percben nem alkalmazzuk a változtatásokat?
Először is a replikák ellenőrzött késéséről. Volt egy ilyen kérés a felhasználóktól, és létrehoztunk egy problémát a Githubon a következő kéréssel: "Ha valakinek szüksége van erre, lájkolja, szíveskedjen." Senki nem szállított, és a probléma lezárult. Ezt a lehetőséget azonban már a ClickHouse beállításával is megkaphatja. Igaz, csak a 20.3-as verziótól kezdődően.
A ClickHouse folyamatosan adategyesítést végez a háttérben. Amikor az összevonás befejeződik, egy bizonyos adathalmaz lecserélődik egy nagyobb darabra. Ugyanakkor a korábban ott lévő adatok egy ideig a lemezen maradnak.
Először is, mindaddig tárolódnak, amíg vannak kiválasztott lekérdezések, amelyek használják őket, hogy biztosítsák a nem blokkoló működést. A kiválasztott lekérdezések könnyen kiolvashatók a régi darabokból.
Másodszor, van egy időküszöb is – a régi adatok nyolc percig hevernek a lemezen. Ez a nyolc perc testreszabható, és akár egy napra is alakítható. Ez lemezterületbe fog kerülni: az adatáramlástól függően kiderül, hogy az utolsó napon az adatmennyiség nemcsak megduplázódik, hanem akár ötszöröse is lehet. De ha komoly probléma van, leállíthatja a ClickHouse szervert, és mindent elintézhet.
Felmerül a kérdés, hogy ez hogyan véd az elváltozásoktól. Itt érdemes egy kicsit mélyebbre nézni, mert a ClickHouse régebbi verzióiban az alter úgy működött, hogy egyszerűen direkt cserélt darabokat. Egyes fájlokban adat van, és mi pl. csepp oszlop módosítása. Ezután ezt az oszlopot fizikailag eltávolítjuk az összes darabból.
De a 20.3-as verziótól kezdődően a módosítási mechanizmus teljesen megváltozott, és mostanra az adatok mindig megváltoztathatatlanok. Egyáltalán nem változnak – a módosítások ma már nagyjából ugyanúgy működnek, mint az egyesítések. Ahelyett, hogy egy darabot helyben cserélnénk, készítünk egy újat. Az új csonkban a nem változott fájlok keményhivatkozásokká válnak, és ha törölünk egy oszlopot, az egyszerűen hiányzik az új csonkból. A régi darab alapértelmezés szerint nyolc perc után törlődik, itt pedig a fent említett beállításokat lehet módosítani.
Ugyanez vonatkozik az olyan változásokra, mint a mutációk. Amikor megteszed módosítsa a törlést vagy frissítés módosítása, nem változtatja meg a darabot, hanem újat hoz létre. Aztán törli a régit.
Mi van, ha a táblázat szerkezete megváltozott?
Hogyan lehet visszaállítani a régi sémával készült biztonsági másolatot? A második kérdés pedig a pillanatképekkel és a fájlrendszer-eszközökkel kapcsolatos. Itt jó a Btrfs a ZFS helyett Linux LVM-en?
Ha te teszed partíció csatolása más szerkezetű partíciókat, akkor a ClickHouse közli, hogy ez nem lehetséges. Ez a megoldás. Az első az, hogy hozzon létre egy MergeTree típusú ideiglenes táblát a régi struktúrával, csatolja oda az adatokat az attach segítségével, és hajtson végre egy alter lekérdezést. Ezután átmásolhatja vagy átmásolhatja ezeket az adatokat, és újra csatolhatja, vagy kérhet táblamozgatás partíció módosítása.
Most a második kérdés az, hogy a Btrfs használható-e. Először is, ha LVM-ed van, akkor az LVM pillanatfelvételek elegendőek, és a fájlrendszer lehet ext4, nem számít. A Btrts esetében minden a használat során szerzett tapasztalatától függ. Ez egy kiforrott fájlrendszer, de továbbra is fennáll a gyanú, hogy a gyakorlatban miként fog működni minden egy adott forgatókönyv esetén. Nem javaslom ennek használatát, hacsak nincs Btrfs termelésben.
Melyek az adatok újrafelosztásának jelenlegi bevált gyakorlatai?
Az újrafelosztás kérdése összetett és sokrétű. Itt több lehetséges válasz is van. Elmehetsz az egyik oldalról, és ezt mondod: A ClickHouse nem rendelkezik beépített újrafelosztási funkcióval. De attól tartok, ez a válasz senkinek sem fog megfelelni. Ezért átléphet a másik oldalról, és azt mondhatja, hogy a ClickHouse-nak számos módja van az adatok újradarabolására.
Ha a fürtben elfogy a hely, vagy nem tudja kezelni a terhelést, új kiszolgálókat ad hozzá. De ezek a szerverek alapból üresek, nincs rajtuk adat, nincs terhelés. Át kell rendeznie az adatokat, hogy azok egyenletesen oszlajanak el az új, nagyobb fürtben.
Ennek első módja az, hogy a partíciók egy részét egy kéréssel új szerverekre másoljuk módosítsa a táblázatlekérő partíciót. Például havi bontásban rendelkezett partíciókkal, és 2017 első hónapját átmásolja egy új szerverre, majd a harmadik hónapot egy másik új szerverre. És ezt addig csinálod, amíg többé-kevésbé egyenletes lesz.
Az átvitel csak azokon a partíciókon hajtható végre, amelyek a rögzítés során nem változnak. Friss partícióknál a rögzítést le kell tiltani, mert az átvitelük nem atomi. Ellenkező esetben ismétlődő adatok vagy hiányosságok jelennek meg az adatokban. Ez a módszer azonban praktikus és meglehetősen hatékonyan működik. A kész tömörített partíciók továbbítása a hálózaton keresztül történik, vagyis az adatok nem tömörítve vagy újrakódolva.
Ennek a módszernek van egy hátránya, és a felosztási sémától függ, hogy vállalta-e ezt a felosztási sémát, milyen felosztási kulcsa volt. A metrikák esetére vonatkozó példában a felosztási kulcs az elérési út hash-je. Ha kiválaszt egy elosztott táblát, az egyszerre megy a fürt összes szilánkjához, és onnan veszi az adatokat.
Ez azt jelenti, hogy valójában nem számít Önnek, hogy melyik szilánkra milyen adatok kerültek. A lényeg az, hogy az egyik útvonalon lévő adatok egy szilánkra kerüljenek, de nem fontos, hogy melyik. Ebben az esetben a kész partíciók átvitele tökéletes, mert a kiválasztott lekérdezéseknél teljes adatot is kap - akár újrafelosztás előtt, akár után, a séma teljesen mindegy.
De vannak bonyolultabb esetek is. Ha alkalmazáslogikai szinten egy speciális felosztási sémára támaszkodik, akkor ez a kliens egy ilyen és olyan szilánkon található, és a kérést közvetlenül oda lehet küldeni, nem pedig az elosztott táblába. Vagy a ClickHouse egy meglehetősen friss verzióját használja, és engedélyezte a beállítást optimalizálja kihagyja a fel nem használt szilánkokat. Ebben az esetben a kiválasztási lekérdezés során a hol szakaszban lévő kifejezés elemzésre kerül, és kiszámításra kerül, hogy a felosztási séma szerint mely szilánkokat kell használni. Ez akkor működik, ha az adatok pontosan ennek a felosztási sémának megfelelően vannak felosztva. Ha manuálisan rendezte át őket, a levelezés megváltozhat.
Tehát ez az első számú módszer. És várom a válaszát, hogy megfelelő-e a módszer, vagy menjünk tovább.
Vladimir Kolobaev, az Avito vezető rendszergazdája: Alexey, az általad említett módszer nem működik túl jól, ha szét kell osztani a terhelést, beleértve az olvasást is. Átvihetünk egy partíciót, amely havi, és átviheti az előző hónapot egy másik csomópontra, de amikor erre az adatokra érkezik kérés, akkor csak azt töltjük be. De szeretnénk a teljes klasztert betölteni, mert különben egy ideig a teljes olvasási terhelést két szilánk dolgozza fel.
Alekszej Milovidov: A válasz itt furcsa – igen, rossz, de működhet. Elmagyarázom, pontosan hogyan. Érdemes megnézni az adatok mögött rejlő betöltési forgatókönyvet. Ha ez monitoring adatok, akkor szinte biztosan kijelenthetjük, hogy a kérések túlnyomó többsége friss adatokra vonatkozik.
Új szervereket telepített, régi partíciókat migrált, de megváltoztatta a friss adatok rögzítésének módját is. A friss adatok pedig szétszóródnak a klaszterben. Így már öt perc elteltével az utolsó öt percre vonatkozó kérések egyenletesen, egy nap után pedig a XNUMX órás kérések egyenletesen töltik be a fürtöt. Az előző hónapra vonatkozó kérések pedig sajnos csak a fürtszerverek egy részére fognak eljutni.
De gyakran nem lesznek kifejezetten 2019 februárjára vonatkozó kérései. Valószínűleg, ha a kérelmek 2019-re vonatkoznak, akkor az egész 2019-re vonatkoznak - hosszú időre, és nem valami kis tartományra. És az ilyen kérések egyenletesen tudják betölteni a klasztert. De általánosságban teljesen helytálló a megjegyzésed, miszerint ez egy ad hoc megoldás, ami nem oszlatja el teljesen egyenletesen az adatokat.
Van még néhány megjegyzésem a kérdés megválaszolásához. Az egyik arról szól, hogyan kell kezdetben megtervezni egy felosztási sémát úgy, hogy az újrafelosztás kevesebb fájdalmat okozzon. Ez nem mindig lehetséges.
Például vannak megfigyelési adatai. A megfigyelési adatok három okból nőnek. Az első a történelmi adatok felhalmozása. A második a forgalom növekedése. A harmadik pedig az ellenőrzés alá vont dolgok számának növekedése. Vannak új mikroszolgáltatások és mérőszámok, amelyeket el kell menteni.
Elképzelhető, hogy ezek közül a legnagyobb növekedés a harmadik okhoz - a monitorozás használatának növekedéséhez - köthető. És ebben az esetben érdemes megnézni a terhelés jellegét, mik a fő kiválasztási lekérdezések. Az alapvető kiválasztási lekérdezések nagy valószínűséggel a mutatók bizonyos részhalmazán fognak alapulni.
Például néhány szolgáltatás CPU-használata egyes szervereken. Kiderült, hogy van egy bizonyos kulcscsoport, amellyel ezeket az adatokat kapja. Maga az adatok kérése pedig valószínűleg meglehetősen egyszerű, és több tíz ezredmásodperc alatt fejeződik be. Felügyeleti szolgáltatások és műszerfalak. Remélem ezt jól értem.
Vladimir Kolobaev: Az a helyzet, hogy nagyon gyakran történelmi adatokra hivatkozunk, mivel valós időben hasonlítjuk össze a jelenlegi helyzetet a történelmivel. Számunkra pedig fontos, hogy nagy mennyiségű adathoz gyorsan hozzáférjünk, és a ClickHouse kiváló munkát végez ezzel.
Teljesen igazad van, a legtöbb olvasási kérést az utolsó napon tapasztaljuk, mint minden megfigyelő rendszer. Ugyanakkor a történelmi adatok terhelése is meglehetősen nagy. Ez alapvetően egy riasztórendszertől származik, amely harminc másodpercenként körbejár, és azt mondja a ClickHouse-nak: „Adja meg az elmúlt hat hét adatait. Most építs fel belőlük egyfajta mozgóátlagot, és hasonlítsuk össze a jelenlegi értéket a történelmi értékkel.”
Szeretném elmondani, hogy az ilyen nagyon friss kérésekhez van egy másik kis táblázatunk, amelyben csak két nap adatot tárolunk, és abba repülnek a fő kérések. Csak nagy előzménylekérdezéseket küldünk a nagy szilánkos táblára.
Alekszej Milovidov: Sajnos ez rosszul alkalmazható az Ön forgatókönyvére, de elmondok egy leírást két rossz és bonyolult felosztási sémáról, amelyeket nem kell használni, de amelyeket a barátaim szolgáltatásában használnak.
Van egy fő klaszter a Yandex.Metrica eseményekkel. Az események oldalmegtekintések, kattintások és konverziók. A legtöbb kérés egy adott webhelyhez érkezik. Megnyitja a Yandex.Metrica szolgáltatást, van egy webhelye - avito.ru, ugorjon a jelentésre, és egy kérés érkezik a webhelyére.
De vannak más – analitikai és globális – kérések is, amelyeket belső elemzők fogalmaznak meg. Minden esetre megjegyzem, hogy a belső elemzők csak a Yandex szolgáltatásait kérik. Ennek ellenére még a Yandex-szolgáltatások is az összes adat jelentős részét foglalják el. Ezek nem konkrét számlálókra, hanem szélesebb körű szűrésre vonatkozó kérések.
Hogyan lehet úgy rendszerezni az adatokat, hogy minden hatékonyan működjön egy számlálónál és a globális lekérdezéseknél is? Egy másik nehézség az, hogy a ClickHouse-ban a Metrics-fürtre vonatkozó kérések száma másodpercenként több ezer. Ugyanakkor egy ClickHouse szerver nem képes kezelni a nem triviális kéréseket, például másodpercenként több ezer.
A fürt mérete hatszáz-valahány szerver. Ha egyszerűen áthúz egy elosztott táblát erre a fürtre, és több ezer kérést küld oda, az még rosszabb lesz, mintha egyetlen szerverre küldené azokat. Azt viszont azonnal elvetjük, hogy az adatok egyenletesen oszlanak el, és minden szerverről lekérjük.
Van egy teljesen ellentétes lehetőség. Képzelje el, ha az adatokat több webhelyre osztjuk fel, és egy webhelyre vonatkozó kérés egy szilánkra érkezik. Most a fürt képes lesz tízezer kérést kezelni másodpercenként, de egy szilánkon bármelyik kérés túl lassan fog működni. Az átviteli teljesítmény szempontjából már nem skálázódik. Különösen, ha ez az avito.ru webhely. Nem árulom el a titkot, ha azt mondom, hogy az Avito a RuNet egyik leglátogatottabb oldala. És egy szilánkon feldolgozni őrültség lenne.
Ezért a felosztási sémát ravaszabb módon tervezték. Az egész klaszter több klaszterre oszlik, amelyeket rétegeknek nevezünk. Minden klaszter egy tucattól több tucatig terjedő szilánkot tartalmaz. Összesen harminckilenc ilyen klaszter van.
Hogyan méretezett mindez? A klaszterek száma nem változik – ahogy néhány éve harminckilenc volt, az is marad. De mindegyiken belül fokozatosan növeljük a szilánkok számát az adatok felhalmozásával. A felosztási séma pedig a következő: ezek a fürtök webhelyekre vannak osztva, és annak megértéséhez, hogy melyik webhely melyik klaszteren található, egy külön MySQL metabázist használnak. Egy webhely - egy klaszteren. Benne pedig a szilánkolás a látogatói azonosítók szerint történik.
Felvételkor elosztjuk őket a látogatóazonosító felosztásának maradékával. Új szilánk hozzáadásakor azonban a felosztási séma megváltozik; folytatjuk a felosztást, de az osztás maradékával egy másik számmal. Ez azt jelenti, hogy egy látogató már több szerveren található, és erre nem számíthat. Ez kizárólag az adatok jobb tömörítése érdekében történik. A kérések benyújtásakor pedig az Elosztott táblára lépünk, amely a klasztert nézi, és több tucat szerverhez fér hozzá. Ez egy olyan hülye terv.
De a történetem hiányos lesz, ha nem mondom, hogy feladtuk ezt a rendszert. Az új sémában mindent megváltoztattunk, és az összes adatot a clickhouse-copier segítségével másoltuk át.
Az új rendszerben minden webhely két kategóriába van osztva - nagy és kicsi. Nem tudom, hogyan választották ki a küszöböt, de az eredmény az volt, hogy a nagy webhelyeket egy fürtben rögzítik, ahol 120 szilánk van, mindegyik három replikával - azaz 360 szerver. A felosztási séma pedig olyan, hogy minden kérés egyszerre jut el az összes szilánkhoz. Ha most megnyit egy jelentésoldalt az avito.ru számára a Yandex.Metricában, a kérés 120 szerverhez fog eljutni. A RuNetben kevés nagy webhely található. A kérések pedig nem ezresek másodpercenként, hanem még száznál is kevesebbek. Mindezt csendben szétrágja a Distributed tábla, amit mindegyikük 120 szerverrel dolgoz fel.
A második klaszter pedig a kis helyek számára készült. Itt van egy felosztási séma, amely a webhely azonosítóján alapul, és minden kérés pontosan egy szilánkhoz érkezik.
A ClickHouse rendelkezik egy clickhouse-másoló segédprogrammal. Tudsz mesélni róla?
Azonnal elmondom, hogy ez a megoldás körülményesebb és valamivel kevésbé produktív. Előnye, hogy az Ön által megadott mintának megfelelően teljesen elkeni az adatokat. De a segédprogram hátránya, hogy egyáltalán nem szilánkodik újra. Adatokat másol az egyik fürtsémából egy másik fürtsémába.
Ez azt jelenti, hogy a működéséhez két klaszternek kell lennie. Elhelyezkedhetnek ugyanazokon a szervereken, de ennek ellenére az adatok nem fokozatosan kerülnek áthelyezésre, hanem másolásra kerülnek.
Például négy szerver volt, most nyolc. Létrehozol egy új Distributed táblát az összes szerveren, új helyi táblákat és elindítod a clickhouse-copiert, jelezve benne azt a munkasémát, amit onnan kell kiolvasnia, elfogadod az új sharding sémát és oda továbbítod az adatokat. A régi szervereken pedig másfélszer több hely kell majd, mint most, mert a régi adatoknak rajtuk kell maradniuk, és rájuk érkezik a régi adatok fele. Ha előre úgy gondolta, hogy az adatokat újra kell vágni, és van hely, akkor ez a módszer megfelelő.
Hogyan működik a clickhouse-másoló belül? Az összes munkát feladatkészletre bontja egy tábla egy partíciójának feldolgozásához egy szilánkon. Mindezek a feladatok párhuzamosan is végrehajthatók, és a clickhouse-copier több példányban is futtatható különböző gépeken, de amit egy partíciónál csinál, az nem más, mint egy insert select. Az adatokat kiolvassák, kicsomagolják, újraparticionálják, majd újra tömörítik, valahova írják, és újra rendezik. Ez keményebb döntés.
Volt egy kísérleti dolga, az úgynevezett resharding. Mi van vele?
2017-ben volt egy kísérleti dolga, az úgynevezett resharding. Még a ClickHouse-ban is van lehetőség. Ha jól értem, nem szállt fel. Meg tudná mondani, miért történt ez? Nagyon relevánsnak tűnik.
Az egész probléma az, hogy ha szükség van az adatok helyben történő újravágására, akkor nagyon bonyolult szinkronizálásra van szükség ahhoz, hogy ezt atomosan meg lehessen tenni. Amikor elkezdtük megvizsgálni, hogyan működik ez a szinkronizálás, világossá vált, hogy alapvető problémák vannak. És ezek az alapvető problémák nemcsak elméletiek, hanem azonnal a gyakorlatban is megmutatkoztak valami nagyon egyszerűen megmagyarázható formában - semmi sem működik.
Lehetséges az összes adat egyesítése, mielőtt lassú lemezekre helyezné át?
Kérdés a TTL-ről a lassú lemezre váltás opcióval az egyesítések összefüggésében. Van-e mód a cronon kívül arra, hogy az összes alkatrészt egyesítsék egybe, mielőtt lassú lemezekre helyeznék?
A kérdésre adott válasz az, hogy az összes darabot valahogy automatikusan egybe lehet ragasztani az átvitel előtt - nem. Szerintem erre nincs szükség. Nem kell az összes alkatrészt egybe olvasztani, egyszerűen számítani kell arra, hogy automatikusan átkerülnek a lassú lemezekre.
Az átigazolási szabályokhoz két kritériumunk van. Az első olyan, ahogy meg van töltve. Ha az aktuális tárterületen egy bizonyos százaléknál kevesebb szabad hely van, kiválasztunk egy darabot, és áthelyezzük lassabb tárhelyre. Illetve nem lassabb, hanem a következő - ahogy beállítod.
A második kritérium a méret. Arról van szó, hogy nagy darabokat kell mozgatni. A küszöbértéket a gyorslemezen lévő szabad hely szerint állíthatja be, és az adatok átvitele automatikusan megtörténik.
Hogyan lehet áttérni a ClickHouse új verzióira, ha nincs mód a kompatibilitás előzetes ellenőrzésére?
Ezt a témát rendszeresen megvitatják figyelembe véve a különböző változatokat, és mégis. Mennyire biztonságos a 19.11-es verzióról 19.16-ra és például a 19.16-ról 20.3-ra frissíteni. Mi a legjobb módja annak, hogy áttérjünk az új verziókra anélkül, hogy a kompatibilitást előre ellenőrizni kellene a homokozóban?
Számos „arany” szabály létezik. Első - . Nagy, de külön bekezdések vannak a visszafelé nem kompatibilis változtatásokról. Ne kezelje ezeket a pontokat piros zászlóként. Ezek általában kisebb összeférhetetlenségek, amelyek olyan élfunkciókat tartalmaznak, amelyeket nagy valószínűséggel nem használ.
Másodszor, ha nincs mód a kompatibilitás ellenőrzésére a sandboxban, és azonnal frissíteni szeretné a termelést, akkor azt javasoljuk, hogy ezt ne tegye meg. Először hozzon létre egy homokozót, és tesztelje. Ha nincs tesztkörnyezet, akkor valószínűleg nincs túl nagy cége, ami azt jelenti, hogy átmásolhatja az adatok egy részét a laptopjára, és megbizonyosodhat arról, hogy minden megfelelően működik rajta. Akár több replikát is létrehozhat helyben a gépén. Vagy felvehet egy új verziót valahol a közelben, és feltöltheti az adatok egy részét oda - azaz létrehozhat egy rögtönzött tesztkörnyezetet.
Egy másik szabály, hogy a verzió megjelenése után egy hétig ne frissítsünk a gyártási hibák és az azt követő gyorsjavítások miatt. Találjuk ki a ClickHouse verziók számozását, hogy ne keveredjünk össze.
Van 20.3.4-es verzió. A 20-as szám a gyártási évet jelöli - 2020. A benne lévő dolgok szempontjából ez nem számít, ezért nem fogunk rá figyelni. Következő - 20.3. Minden alkalommal növeljük a második számot - jelen esetben 3-at -, amikor kiadunk egy kiadást valamilyen új funkcióval. Ha szeretnénk hozzáadni valamilyen funkciót a ClickHouse-hoz, akkor ezt a számot növelnünk kell. Vagyis a 20.4-es verzióban a ClickHouse még jobban fog működni. A harmadik számjegy a 20.3.4. Itt 4 azoknak a javításoknak a száma, amelyekben nem adtunk hozzá új funkciókat, de javítottunk néhány hibát. A 4 pedig azt jelenti, hogy négyszer csináltuk meg.
Ne gondolja, hogy ez valami szörnyű. Általában a felhasználó telepítheti a legújabb verziót, és az éves üzemidővel probléma nélkül fog működni. De képzeljük el, hogy néhány bittérkép-feldolgozási funkcióban, amelyet kínai elvtársak adtak hozzá, a szerver összeomlik, ha helytelen argumentumot ad át. Felelősségünk van ennek kijavításáért. Kiadunk egy új patch verziót, és a ClickHouse stabilabb lesz.
Ha a ClickHouse éles verzióban fut, és megjelenik a ClickHouse új verziója további funkciókkal - például a 20.4.1 a legelső, akkor ne rohanjon az első napon a gyártásba. Miért is van rá szükség? Ha még nem használja a ClickHouse-t, akkor telepítheti, és nagy valószínűséggel minden rendben lesz. De ha a ClickHouse már stabilan működik, akkor figyelje a javításokat és frissítéseket, hogy lássa, milyen problémákat javítunk ki.
Kirill Svakov: Szeretnék hozzátenni egy kicsit a tesztkörnyezetekről. Mindenki nagyon fél a tesztkörnyezetektől, és valamiért úgy gondolják, hogy ha nagyon nagy ClickHouse klaszterrel rendelkezik, akkor a tesztkörnyezet nem lehet kevesebb, vagy legalább tízszer kisebb. Egyáltalán nem így van.
A saját példámból tudom megmondani. Van egy projektem, és van ClickHouse. A tesztkörnyezetünk csak neki való – ez egy kis virtuális gép a Hetznerben húsz euróért, ahol abszolút minden telepítve van. Ehhez teljesen automatizáltunk az Ansible-ben, és ezért elvileg nem mindegy, hogy hova menjünk - hardveres szerverekre vagy csak virtuális gépekre telepítve.
Mit lehet tenni? Jó lenne példát mutatni a ClickHouse dokumentációjában arra vonatkozóan, hogyan helyezhet üzembe egy kis fürtöt saját otthonában – a Dockerben, az LXC-ben, talán hozzon létre egy Ansible játékkönyvet, mert a különböző embereknek eltérő a telepítése. Ez sokat fog egyszerűsíteni. Ha öt perc alatt vesz és telepít egy fürtöt, sokkal könnyebb megpróbálni kitalálni valamit. Ez sokkal kényelmesebb, mert egy olyan éles verzióba való begurulás, amelyet még nem teszteltél, út a semmibe. Néha működik, néha nem. Ezért rossz reménykedni a sikerben.
Maxim Kotyakov, vezető háttérmérnök, Avito: Hozzáteszek egy kicsit a tesztkörnyezetekről a nagyvállalatok által tapasztalt problémák sorozatából. Teljes értékű ClickHouse elfogadó klaszterrel rendelkezünk, adatsémákat és beállításokat tekintve pontos másolata a gyártásban lévőnek. Ez a fürt meglehetősen leromlott tárolókban van telepítve, minimális erőforrásokkal. A termelési adatok egy bizonyos százalékát oda írjuk, szerencsére a kafkai folyamot meg lehet reprodukálni. Ott minden szinkronizált és méretezve van - mind a kapacitás, mind az áramlás tekintetében, és elméletileg, ha minden más egyenlő, a mérőszámok tekintetében termelésként kell viselkednie. Minden robbanásveszélyes dolgot először erre az állványra kell görgetni, és néhány napig ott hagyni, amíg készen nem áll. De természetesen ez a megoldás drága, bonyolult és nem nulla támogatási költséggel jár.
Alekszej Milovidov: Elmondom, milyen a Yandex.Metrica barátaink tesztkörnyezete. Az egyik fürtben 600 páratlan szerver volt, egy másikban 360, és van egy harmadik és több fürt. Az egyik tesztkörnyezete egyszerűen két szilánk, mindegyikben két replikával. Miért két szilánk? Hogy ne legyél egyedül. És legyenek replikák is. Csak egy bizonyos minimális összeg, amit megengedhet magának.
Ez a tesztkörnyezet lehetővé teszi annak ellenőrzését, hogy a lekérdezések működnek-e, és nem történt-e valami nagyobb hiba. De gyakran teljesen más jellegű problémák merülnek fel, amikor minden működik, de vannak apró változások a terhelésben.
Hadd mondjak egy példát. Úgy döntöttünk, hogy telepítjük a ClickHouse új verzióját. Felkerült egy tesztkörnyezetre, magában a Yandex.Metricában végeztek automatizált teszteket, amelyek összehasonlítják a régi és az új verzió adatait, a teljes folyamatot futtatva. És természetesen a CI zöld tesztjei. Különben nem is javasoltuk volna ezt a verziót.
Minden rendben. Megkezdjük a termelést. Üzenetet kapok, hogy a grafikonok terhelése többszörösére nőtt. Visszaállítjuk a verziót. Megnézem a grafikont, és látom: a terhelés többszörösére nőtt a kihelyezés során, és visszacsökkent, amikor kigördültek. Aztán elkezdtük visszaforgatni a verziót. És a terhelés ugyanúgy nőtt, és ugyanúgy visszaesett. A következtetés tehát a következő: az elrendezés miatt nőtt a terhelés, semmi meglepő.
Ezután nehéz volt meggyőzni a kollégákat az új verzió telepítéséről. Azt mondom: „Rendben van, gurulj ki. Tartsa az ujjait, minden menni fog. Most nőtt a grafikonok terhelése, de minden rendben van. Kitartás." Általánosságban elmondható, hogy ezt tettük, és ennyi - a verziót gyártásra bocsátották. De szinte minden elrendezésnél hasonló problémák merülnek fel.
A Kill query állítólag megöli a lekérdezéseket, de nem teszi. Miért?
Egy felhasználó, valamilyen elemző, odajött hozzám, és létrehozott egy kérést, amely behelyezte a ClickHouse klaszteremet. Néhány csomópont vagy teljes fürt, attól függően, hogy a kérés melyik replikához vagy szilánkhoz ment. Látom, hogy ezen a szerveren az összes CPU erőforrás egy polcon van, minden piros. Ugyanakkor a ClickHouse maga válaszol a kérésekre. És azt írom: "Kérlek, mutasd meg a folyamatlistát, milyen kérés generálta ezt az őrületet."
Megtalálom ezt a kérést és írok rá killt. És látom, hogy nem történik semmi. A szerverem egy polcon van, a ClickHouse aztán kiad néhány parancsot, megmutatja, hogy a szerver él, és minden remek. De az összes felhasználói kérésben van degradáció, a leromlás a ClickHouse rekordjaival kezdődik, és a kill lekérdezésem nem működik. Miért? Azt hittem, hogy a kill query-nek meg kell ölnie a lekérdezéseket, de nem így van.
Most egy meglehetősen furcsa válasz lesz. A lényeg az, hogy a kill query nem öli meg a lekérdezéseket.
A Kill query bejelöli a „Azt akarom, hogy ezt a lekérdezést töröljék” nevű kis négyzetet. És maga a kérés is ezt a jelzőt nézi az egyes blokkok feldolgozása során. Ha be van állítva, a kérés leáll. Kiderül, hogy senki sem öli meg a kérést, neki magának kell mindent ellenőriznie és abbahagynia. És ennek minden olyan esetben működnie kell, amikor a kérés adatblokkok feldolgozási állapotában van. Feldolgozza a következő adatblokkot, ellenőrzi a zászlót, és leállítja.
Ez nem működik olyan esetekben, amikor a kérés blokkolva van bizonyos műveleteknél. Igaz, valószínűleg nem ez a te eseted, mert szerinted rengeteg szerver erőforrást használ. Lehetséges, hogy ez nem működik külső rendezés esetén és néhány egyéb részletben. De általában ennek nem szabad megtörténnie, ez egy hiba. És az egyetlen dolog, amit ajánlani tudok, az a ClickHouse frissítése.
Hogyan lehet kiszámítani a válaszidőt olvasási terhelés alatt?
Van egy táblázat, amely a tételek összesítését tárolja - különféle számlálókat. A vonalak száma megközelítőleg százmillió. Számíthatunk előre kiszámítható válaszidővel, ha 1K RPS-t adunk 1 tételhez?
A szövegkörnyezetből ítélve az olvasási terhelésről beszélünk, mert az írással nincs gond - akár ezer, akár százezer, sőt néha több millió sor is beilleszthető.
Az olvasási kérések nagyon eltérőek. A Select 1-ben a ClickHouse körülbelül több tízezer kérést tud végrehajtani másodpercenként, így még egy kulcsra vonatkozó kérések is igényelnek bizonyos erőforrásokat. És az ilyen pontlekérdezések nehezebbek lesznek, mint egyes kulcsérték-adatbázisokban, mivel minden olvasáshoz egy adatblokkot indexenként kell beolvasni. Indexünk nem minden rekordot, hanem minden tartományt címez. Vagyis a teljes tartományt el kell olvasnia - ez alapértelmezés szerint 8192 sor. És a tömörített adatblokkot 64 KB-ról 1 MB-ra kell kicsomagolnia. Az ilyen célzott lekérdezések végrehajtása általában néhány milliszekundumot vesz igénybe. De ez a legegyszerűbb lehetőség.
Próbáljunk meg néhány egyszerű aritmetikát. Ha megszoroz néhány milliszekundumot ezerrel, akkor néhány másodpercet kap. Mintha lehetetlen lépést tartani a másodpercenkénti ezer kéréssel, de valójában lehetséges, mert több processzormagunk van. Tehát elvileg a ClickHouse néha 1000 RPS-t is tud tartani, de rövid kérések esetén kifejezetten célzottakat.
Ha egy ClickHouse-fürtöt az egyszerű kérések számával kell méreteznie, akkor a legegyszerűbb dolgot ajánlom - növelje a replikák számát, és küldje el a kéréseket egy véletlenszerű replikára. Ha egy replika ötszáz kérést tartalmaz másodpercenként, ami teljesen reális, akkor három replika másfél ezret kezel.
Néha természetesen beállíthatja a ClickHouse-t a maximális számú pontleolvasásra. Mi kell ehhez? Az első az index részletességének csökkentése. Ebben az esetben nem egyre kell csökkenteni, hanem azon az alapon, hogy szerverenként több millió vagy tízmillió lesz az index bejegyzéseinek száma. Ha a táblázat százmillió soros, akkor a részletesség 64-re állítható.
Csökkentheti a tömörített blokk méretét. Erre vannak beállítások min tömörítési blokkméret, max tömörítési blokkméret. Csökkenthetők, újratölthetők adatokkal, és akkor gyorsabbak lesznek a célzott lekérdezések. Ennek ellenére a ClickHouse nem kulcs-érték adatbázis. A kis kérések nagy száma terhelési antiminta.
Kirill Svakov: Tanácsot adok, ha vannak ott rendes számlák. Ez egy meglehetősen szokásos helyzet, amikor a ClickHouse tárol valamilyen számlálót. Van egy felhasználóm, ő ilyen-olyan országból származik, meg valami harmadik területről, és valamit fokozatosan növelnem kell. Vegyük a MySQL-t, készítsünk egyedi kulcsot – a MySQL-ben ez egy duplikált kulcs, a PostgreSQL-ben pedig ütközés – és adjunk hozzá egy pluszjelet. Ez sokkal jobban fog működni.
Ha nincs sok adatunk, nincs sok értelme a ClickHouse használatának. Vannak rendszeres adatbázisok, és ezt jól teszik.
Mit módosíthatok a ClickHouse-ban, hogy több adat legyen a gyorsítótárban?
Képzeljünk el egy helyzetet - a szerverek 256 GB RAM-mal rendelkeznek, a ClickHouse a napi rutinban körülbelül 60-80 GB-ot vesz igénybe, csúcsidőben - akár 130-at. Mit lehet engedélyezni és módosítani, hogy több adat legyen a gyorsítótárban, és ennek megfelelően kevesebb utazás van a lemezre?
Általában az operációs rendszer oldal-gyorsítótára jó munkát végez erre. Ha csak a tetejét nyitod meg, nézd meg a gyorsítótárban vagy szabadban - azt is kiírja, hogy mennyi van a gyorsítótárban -, akkor észre fogod venni, hogy az összes szabad memóriát a gyorsítótárhoz használják. És amikor ezeket az adatokat olvassa, akkor nem a lemezről, hanem a RAM-ból lesz kiolvasva. Ugyanakkor elmondhatom, hogy a gyorsítótárat hatékonyan használják, mert a tömörített adatok kerülnek gyorsítótárba.
Ha azonban néhány egyszerű lekérdezést még jobban fel szeretne gyorsítani, akkor a ClickHouse-on belül engedélyezheti a gyorsítótárat a kicsomagolt adatokban. Ez az úgynevezett tömörítetlen gyorsítótár. A config.xml konfigurációs fájlban állítsa be a tömörítetlen gyorsítótár méretét a szükséges értékre - azt javaslom, hogy legfeljebb a szabad RAM fele, mert a többi az oldal gyorsítótára alá kerül.
Ezen kívül két kérésszint-beállítás létezik. Első beállítás - használjon tömörítetlen gyorsítótárat - tartalmazza a használatát. Javasoljuk, hogy minden kérés esetén engedélyezze, kivéve a nehéz kéréseket, amelyek képesek elolvasni az összes adatot és kiüríteni a gyorsítótárat. A második beállítás pedig valami olyasmi, mint a gyorsítótár használatához szükséges sorok maximális száma. Automatikusan korlátozza a nagy lekérdezéseket, hogy azok megkerüljék a gyorsítótárat.
Hogyan konfigurálhatom a storage_configuration paramétert a RAM-ban való tároláshoz?
Az új ClickHouse dokumentációban elolvastam a kapcsolódó részt . A leírás egy példát tartalmaz gyors SSD-re.
Kíváncsi vagyok, hogy lehet ugyanezt beállítani volume hot memóriával. És még egy kérdés. Hogyan működik a select ezzel az adatszervezéssel, a teljes készletet olvassa, vagy csak a lemezen lévőt, és ezek az adatok tömörítve vannak a memóriában? És hogy működik a prewhere rész egy ilyen adatszervezéssel?
Ez a beállítás az adattömbök tárolását érinti, és a formátumuk semmilyen módon nem változik.
Nézzük meg közelebbről.
Beállíthatja az adattárolást a RAM-ban. A lemezhez csak az elérési útja van beállítva. Létrehoz egy tmpfs partíciót, amely a fájlrendszer valamelyik elérési útjára van csatlakoztatva. Ezt az elérési utat adja meg a legforróbb partíció adattárolási útvonalaként, az adatok elkezdenek érkezni és oda íródnak, minden rendben.
De nem ajánlom ezt az alacsony megbízhatóság miatt, bár ha legalább három replikája van különböző adatközpontokban, akkor ez lehetséges. Ha bármi történik, az adatok visszaállnak. Képzeljük el, hogy a szerver hirtelen kikapcsolt, majd újra bekapcsolt. A partíció újra fel lett szerelve, de nem volt ott semmi. Amikor a ClickHouse szerver elindul, látja, hogy nincsenek benne ezek a darabok, pedig a ZooKeeper metaadatai szerint ott kellene lenniük. Megnézi, hogy mely replikákon vannak, lekéri és letölti. Így az adatok helyreállnak.
Ebben az értelemben az adatok tárolása a RAM-ban nem különbözik alapvetően a lemezen való tárolástól, mivel az adatok lemezre írásakor azok is először az oldal gyorsítótárába kerülnek, majd fizikailag később kerülnek kiírásra. Ez a fájlrendszer beillesztési lehetőségétől függ. De minden esetre elmondom, hogy a ClickHouse nem szinkronizál beillesztéskor.
Ebben az esetben a RAM-ban lévő adatok pontosan ugyanolyan formátumban kerülnek tárolásra, mint a lemezen. A kiválasztó lekérdezés ugyanígy kiválasztja az olvasandó darabokat, kiválasztja a darabokban a szükséges adattartományokat, és beolvassa azokat. És a prewhere pontosan ugyanúgy működik, függetlenül attól, hogy az adatok a RAM-ban vagy a lemezen voltak.
Hány egyedi értékig hatékony a Low Cardinality?
A Low Cardinality ügyesen van megtervezve. Adatszótárakat állít össze, de azok helyiek. Először is, minden darabhoz különböző szótárak vannak, másodszor pedig még egy darabon belül is eltérőek lehetnek az egyes tartományokhoz. Amikor az egyedi értékek száma elér egy küszöbértéket – azt hiszem, egymilliót –, a szótár egyszerűen a polcra kerül, és létrejön egy új.
A válasz általános: minden helyi tartományban - mondjuk minden napra - valahol akár egymillió egyedi érték is hatékony az alacsony kardinalitás. Utána egyszerűen lesz egy tartalék, amelyben sok különböző szótárat fognak használni, és nem csak egyet. Körülbelül ugyanúgy fog működni, mint egy normál karakterlánc, talán egy kicsit kevésbé hatékony, de nem lesz komoly teljesítményromlás.
Melyek a legjobb gyakorlatok egy ötmilliárd soros táblázatban történő teljes szöveges kereséshez?
Különféle válaszok vannak. Az első az, hogy a ClickHouse nem teljes szövegű keresőmotor. Vannak erre speciális rendszerek, pl. и . Azonban egyre gyakrabban látom, hogy az emberek azt mondják, hogy az Elasticsearch-ről a ClickHouse-ra váltanak.
Miért történik ez? Ezt azzal magyarázzák, hogy az Elasticsearch bizonyos mennyiségeknél már nem birkózik meg a terheléssel, kezdve az indexek felépítésével. Az indexek túlságosan körülményessé válnak, és ha egyszerűen átvisszük az adatokat a ClickHouse-ba, kiderül, hogy azok tárolása többszörösen hatékonyabb a mennyiségben. Ugyanakkor a keresési lekérdezések gyakran nem olyanok voltak, hogy a morfológiát figyelembe véve a teljes adatmennyiségben valamilyen kifejezést kellett találni, hanem teljesen másokat. Keressen például néhány bájtsorozatot a naplókban az elmúlt néhány óra során.
Ebben az esetben létrehoz egy indexet a ClickHouse-ban, amelynek első mezője a dátum és az idő lesz. A legnagyobb adatlezárás pedig a dátumtartományon fog alapulni. A kiválasztott dátumtartományon belül főszabály szerint már teljes szöveges keresést is lehet végezni, akár brute force módszerrel, like használatával. A ClickHouse hasonló operátora a leghatékonyabb hasonló operátor. Ha találsz jobbat, szólj.
De mégis, mint egy teljes vizsgálat. A teljes vizsgálat pedig nem csak a CPU-n, hanem a lemezen is lassú lehet. Ha hirtelen napi egy terabájtnyi adata van, és a nap folyamán keres egy szót, akkor a terabájtot kell átvizsgálnia. És valószínűleg normál merevlemezeken van, és a végén úgy fognak betölteni, hogy nem fogod tudni elérni ezt a szervert SSH-n keresztül.
Ebben az esetben kész vagyok még egy apró trükköt ajánlani. Kísérleti jellegű – lehet, hogy működik, lehet, hogy nem. A ClickHouse teljes szövegű indexekkel rendelkezik trigram Bloom szűrők formájában. Az Arenadata munkatársai már kipróbálták ezeket az indexeket, és gyakran pontosan úgy működnek, ahogyan azt tervezték.
Ahhoz, hogy helyesen használhassa őket, alaposan ismernie kell a működésüket: mi az a trigram Bloom szűrő, és hogyan kell kiválasztani a méretét. Elmondhatom, hogy segítenek lekérdezni néhány ritka kifejezést, részstringet, amelyek ritkán találhatók meg az adatokban. Ebben az esetben az altartományokat indexek választják ki, és kevesebb adat kerül beolvasásra.
Nemrég a ClickHouse még fejlettebb funkciókat adott hozzá a teljes szöveges kereséshez. Ez először is egy csomó részkarakterlánc keresése egy lépésben, beleértve a kis- és nagybetűk megkülönböztetését, az UTF-8 támogatásával vagy csak az ASCII-t támogató opciókat. Válassza ki a leghatékonyabbat, amelyre szüksége van.
Megjelent a több reguláris kifejezés egy lépésben történő keresése is. Nem kell X-et úgy írnia, mint egy részkarakterláncot, vagy X-et egy másik részkarakterláncként. Azonnal írsz, és minden a lehető leghatékonyabban történik.
Harmadszor, most van egy hozzávetőleges keresés a reguláris kifejezésekre és egy hozzávetőleges keresés az alkarakterláncokra. Ha valaki rosszul írt egy szót, a rendszer a maximális egyezést keresi.
Mi a legjobb módja a ClickHouse-hoz való hozzáférés megszervezésének nagyszámú felhasználó számára?
Mondja el, hogyan lehet a legjobban megszervezni a hozzáférést nagyszámú fogyasztó és elemző számára. Hogyan alakítsunk ki várólista, adjunk prioritást legfeljebb egyidejű lekérdezéseknek, és milyen eszközökkel?
Ha elég nagy a fürt, akkor jó megoldás lenne még két szerver felemelése, ami az elemzők belépési pontja lesz. Vagyis ne engedje meg az elemzőknek, hogy hozzáférjenek a fürt egyes szilánkjaihoz, hanem egyszerűen hozzon létre két üres kiszolgálót, adatok nélkül, és konfigurálja rajtuk a hozzáférési jogokat. Ebben az esetben az elosztott kérések felhasználói beállításai a távoli szerverekre kerülnek átvitelre. Vagyis ezen a két szerveren mindent beállít, és a beállítások az egész fürtre kihatnak.
Ezeken a szervereken elvileg nincsenek adatok, de a rajtuk lévő RAM mennyisége nagyon fontos a kérések végrehajtásához. A lemez ideiglenes adatok tárolására is használható, ha a külső összesítés vagy külső rendezés engedélyezve van.
Fontos, hogy megnézzük azokat a beállításokat, amelyek az összes lehetséges korláthoz kapcsolódnak. Ha most a Yandex.Metrica klaszterhez megyek elemzőnek és kérek egy kérést válassza ki a találatok számát, akkor azonnal kivételt kapok, hogy nem tudom teljesíteni a kérést. A beolvasható sorok maximális száma százmilliárd, és összesen ötven billió van belőlük a fürt egy táblázatában. Ez az első korlátozás.
Tegyük fel, hogy eltávolítom a sorkorlátot, és újra futtatom a lekérdezést. Ekkor a következő kivételt fogom látni - a beállítás engedélyezve erő index dátum szerint. Nem tudom befejezni a lekérdezést, ha nem adtam meg dátumtartományt. Nem kell elemzőkre hagyatkoznia a manuális megadáshoz. Tipikus eset az, amikor egy dátumtartományt írnak, ahol az esemény dátuma hét között van. Aztán egyszerűen rossz helyen adtak meg egy zárójelet, és az és helyett kiderült, hogy vagy - vagy URL-egyezik. Ha nincs korlátozás, akkor feltérképezi az URL oszlopot, és rengeteg erőforrást pazarol el.
Ezenkívül a ClickHouse két prioritási beállítással rendelkezik. Sajnos nagyon primitívek. Az egyiket egyszerűen hívják prioritás. Ha prioritás ≠ 0, és bizonyos prioritású kérések végrehajtása történik, de egy kisebb prioritási értékű kérést hajtanak végre, ami magasabb prioritást jelent, akkor nagyobb prioritású kérést, ami alacsonyabb prioritást jelent. , egyszerűen fel van függesztve, és ezalatt egyáltalán nem fog működni.
Ez egy nagyon durva beállítás, és nem alkalmas olyan esetekben, amikor a fürt állandó terhelésű. De ha vannak fontos rövid, sorozatos kérései, és a fürt többnyire tétlen, akkor ez a beállítás megfelelő.
A következő prioritási beállítást hívják meg OS szál prioritás. Egyszerűen beállítja a szép értéket a Linux ütemező összes kérésvégrehajtási szálához. Ez így-úgy működik, de még mindig működik. Ha beállítja a minimális szép értéket - ez a legnagyobb érték, és ezért a legalacsonyabb prioritású -, és -19-et állít be a magas prioritású kérésekhez, akkor a CPU körülbelül négyszer kevesebbet fogyaszt az alacsony prioritású kérésekből, mint a magas prioritásúaknál.
Ezenkívül be kell állítania a kérés maximális végrehajtási idejét - mondjuk öt percet. A lekérdezés végrehajtásának minimális sebessége a legmenőbb dolog. Ez a beállítás már régóta létezik, és nem csak azt kell állítani, hogy a ClickHouse nem lassít, hanem erőltetni is kell.
Képzelje el, beállítja: ha egy lekérdezés kevesebb, mint egymillió sort dolgoz fel másodpercenként, akkor ezt nem teheti meg. Ez megszégyeníti jó hírünket, jó adatbázisunkat. Ezt tiltsuk be. Valójában két beállítás van. Az egyiket hívják min végrehajtási sebesség - sor/másodpercben, és a másodpercet timeout-nak hívják a minimális végrehajtási sebesség ellenőrzése előtt - alapértelmezés szerint tizenöt másodperc. Vagyis tizenöt másodperc lehetséges, majd ha lassú, akkor csak dobjon egy kivételt, és szakítsa meg a kérést.
Kvótákat is be kell állítani. A ClickHouse beépített kvóta funkcióval rendelkezik, amely számolja az erőforrás-felhasználást. De sajnos nem a hardver erőforrások, például a CPU, a lemezek, hanem a logikai erőforrások - a feldolgozott kérések száma, a sorok és az olvasott bájtok. És például legfeljebb száz kérést konfigurálhat öt percen belül, és óránként ezer kérést.
Miért fontos? Mivel egyes analitikai lekérdezéseket manuálisan hajtanak végre közvetlenül a ClickHouse kliensből. És minden rendben lesz. De ha vannak haladó elemzők a cégedben, akkor ők írnak egy szkriptet, és előfordulhat, hogy hiba van a szkriptben. Ez a hiba pedig a kérés végtelen ciklusban történő végrehajtását eredményezi. Ez az, amitől meg kell védenünk magunkat.
Meg lehet adni egy lekérdezés eredményét tíz ügyfélnek?
Számos felhasználónk van, akik szeretnek egyszerre nagy kérésekkel jelentkezni. A kérés nagy és elvileg gyorsan teljesíthető, de mivel sok ilyen kérés van egyszerre, nagyon fájdalmassá válik. Lehetséges-e ugyanazt a kérést, amely egymás után tízszer érkezett, egyszer végrehajtani, és tíz ügyfélnek adni az eredményt?
A probléma az, hogy nem rendelkezünk a közbenső adatok gyorsítótárának vagy gyorsítótárának eredményeivel. Az operációs rendszernek van egy oldalgyorsítótára, amely megakadályozza, hogy újra olvassa el az adatokat a lemezről, de sajnos az adatok továbbra is kitömörítve, deszerializálva és újrafeldolgozásra kerülnek.
Ezt szeretném valahogy elkerülni, akár a közbenső adatok gyorsítótárazásával, akár úgy, hogy a hasonló lekérdezéseket valamilyen sorban sorakozom, és hozzáadok egy eredmény-gyorsítótárat. Jelenleg van egy lehívási kérésünk fejlesztés alatt, amely egy kérés-gyorsítótárat ad hozzá, de csak a be- és csatlakozási szakaszokban található segédlekérdezésekhez - vagyis a megoldás nem teljes.
Azonban mi is szembesülünk egy ilyen helyzettel. Különösen kanonikus példa az oldalszámozott lekérdezések. Van egy jelentés, annak több oldala van, és van 10-es határigénylés. Akkor ugyanez, de limit 10,10. Aztán egy következő oldal. A kérdés pedig az, hogy miért számoljuk mindezt minden alkalommal? De most nincs megoldás, és nem is lehet elkerülni.
Van egy alternatív megoldás, amelyet oldalkocsiként helyeznek el a ClickHouse mellett - .
Kirill Svakov: A ClickHouse Proxy beépített sebességkorlátozóval és beépített eredmények gyorsítótárral rendelkezik. Nagyon sok beállítást végeztek ott, mert egy hasonló probléma megoldása zajlott. A proxy lehetővé teszi a kérések korlátozását sorba állításával, és konfigurálja a kérés gyorsítótárának élettartamát. Ha a kérések valóban ugyanazok voltak, a Proxy sokszor elküldi őket, de csak egyszer megy a ClickHouse-hoz.
Az Nginxnek van gyorsítótára is az ingyenes verzióban, és ez is működni fog. Az Nginx-nek még olyan beállításai is vannak, hogy ha a kérések egyszerre érkeznek, akkor lelassítja a többieket, amíg az egyik be nem fejeződik. De a ClickHouse Proxyban sokkal jobban sikerült a beállítás. Kifejezetten a ClickHouse-nak készült, kifejezetten ezekre a kérésekre, így alkalmasabb. Nos, könnyű telepíteni.
Mi a helyzet az aszinkron műveletekkel és a materializált nézetekkel?
Probléma van, hogy a visszajátszó motorral végzett műveletek aszinkronok - először az adatok íródnak, majd összeomlanak. Ha egy materializált tábla néhány aggregátummal él a jel alatt, akkor duplikátumokat írnak rá. És ha nincs összetett logika, akkor az adatok megkettőződnek. Mit tehetsz ellene?
Létezik egy kézenfekvő megoldás – trigger implementálása a matviewok bizonyos osztályán az aszinkron összecsukási művelet során. Vannak-e ezüstgolyók, vagy tervezik hasonló funkciók megvalósítását?
Érdemes megérteni, hogyan működik a deduplikáció. Amit most elmondok, az nem vonatkozik a kérdésre, de hátha érdemes megjegyezni.
Replikált táblába történő beszúráskor a teljes beszúrt blokk duplikációja megszűnik. Ha újra beszúrja ugyanazt a blokkot, amely ugyanannyi sorból áll, ugyanabban a sorrendben, akkor az adatok duplikálódnak. A beszúrásra válaszul „Ok”-t kap, de valójában egy adatcsomag kerül kiírásra, és nem duplikálódik.
Ez a bizonyosság érdekében szükséges. Ha a beillesztés során az „Ok” üzenetet kapja, akkor az adatok beszúrásra kerültek. Ha hibaüzenetet kap a ClickHouse-tól, az azt jelenti, hogy nem kerültek beillesztésre, és meg kell ismételnie a beillesztést. De ha a kapcsolat megszakad a beillesztés során, akkor nem tudja, hogy az adat bekerült-e vagy sem. Az egyetlen lehetőség az, hogy ismételje meg a beillesztést. Ha az adatokat ténylegesen beszúrták, és újra beszúrta, akkor blokk-deduplikáció történik. Erre az ismétlődések elkerülése érdekében van szükség.
És az is fontos, hogyan működik a materializált nézetek esetében. Ha az adatok a főtáblába beillesztéskor deduplikálva lettek, akkor az sem kerül be a materializált nézetbe.
Most a kérdésről. Az Ön helyzete bonyolultabb, mert az egyes sorok másolatait rögzíti. Vagyis nem a teljes csomag duplikálódik, hanem bizonyos sorok, és ezek a háttérben összeesnek. Valójában az adatok összeomlanak a főtáblában, de az össze nem csukott adatok a materializált nézetbe kerülnek, és az összevonások során semmi sem történik a materializált nézetekkel. Mert a materializált nézet nem más, mint egy beillesztési trigger. Más műveletek során semmi további nem történik vele.
És nem tudlak itt boldoggá tenni. Csak konkrét megoldást kell keresnie erre az esetre. Például lehetséges-e újrajátszani egy materializált nézetben, és a deduplikációs módszer ugyanúgy működhet. De sajnos nem mindig. Ha összesít, akkor nem fog működni.
Kirill Svakov: A napokban mankóépítésünk is volt. Probléma volt, hogy vannak hirdetési megjelenítések, és vannak olyan adatok, amelyeket valós időben tudunk megjeleníteni - ezek csak megjelenítések. Ritkán duplikálják őket, de ha ez megtörténik, később úgyis összecsukjuk őket. És voltak dolgok, amiket nem lehetett megismételni – kattintások és ez az egész történet. De szinte azonnal meg is akartam mutatni őket.
Hogyan születtek a megvalósult nézetek? Voltak nézetek, ahol közvetlenül írták – nyers adatokra, és nézetekre írták. Ott valamikor nem túl helyesek az adatok, duplikálódnak stb. És van egy második része a táblázatnak, ahol pontosan ugyanúgy néznek ki, mint a materializált nézetek, vagyis teljesen azonosak a felépítésükben. Időnként újraszámoljuk az adatokat, megszámoljuk az adatokat duplikátumok nélkül, írunk ezekbe a táblákba.
Átmentünk az API-n – ez manuálisan nem fog működni a ClickHouse-ban. Az API pedig úgy néz ki: amikor nálam van az utolsó kiegészítés dátuma a táblában, ahol garantáltan már ki lett számítva a helyes adat, és kér egy táblát, meg egy másik táblát. Az egyikből a kérés kiválaszt egy bizonyos időtartamot, a másiktól pedig azt kapja, amit még nem számoltak ki. És működik, de nem egyedül a ClickHouse-on keresztül.
Ha van valamilyen API - elemzőknek, felhasználóknak -, akkor elvileg ez egy lehetőség. Mindig számolsz, mindig számolsz. Ezt megteheti naponta egyszer vagy máskor is. Olyan tartományt választ magának, amelyre nincs szüksége, és amely nem kritikus.
A ClickHouse-nak sok naplója van. Hogyan láthatok egy pillantással mindent, ami a szerverrel történik?
A ClickHouse nagyon sok különböző naplót tartalmaz, és ez a szám növekszik. Az új verziókban ezek egy része még alapértelmezés szerint is engedélyezve van, a régebbi verziókban frissítéskor engedélyezni kell. Azonban egyre többen vannak. Végső soron szeretném látni, hogy most mi történik a szerveremmel, esetleg valami összefoglaló műszerfalon.
Van olyan ClickHouse csapata vagy barátai csapata, amelyek támogatják a kész irányítópultok bizonyos funkcióit, amelyek késztermékként jelenítik meg ezeket a naplókat? Végső soron nagyszerű, ha csak a naplókat nézegeti a ClickHouse-ban. De nagyon menő lenne, ha már műszerfal formájában készülne. kikapnám tőle.
Vannak műszerfalak, bár ezek nincsenek szabványosítva. Cégünkben körülbelül 60 csapat használja a ClickHouse-t, és a legfurcsább, hogy sokuknak van saját maguknak készített dashboardja, és kicsit más is. Egyes csapatok belső Yandex.Cloud telepítést használnak. Vannak kész jelentések, bár nem minden szükséges. Másoknak megvan a sajátjuk.
A Metricából származó kollégáimnak saját műszerfaluk van a Grafanában, nekem pedig az ő klaszterükhöz. Olyan dolgokat nézek, mint például a gyorsítótár találata a serif gyorsítótárhoz. És még nehezebb, hogy különböző eszközöket használunk. Az irányítópultomat egy nagyon régi Graphite-web nevű eszközzel készítettem el. Teljesen csúnya. És továbbra is így használom, bár a Grafana valószínűleg kényelmesebb és szebb lenne.
A műszerfalak alapja ugyanaz. Ezek a fürt rendszermérői: CPU, memória, lemez, hálózat. Egyebek – egyidejű kérések száma, egyidejű egyesítések száma, kérések száma másodpercenként, darabok maximális száma MergeTree táblapartíciókhoz, replikációs késés, replikációs sor mérete, beillesztett sorok száma másodpercenként, beillesztett blokkok száma másodpercenként. Ez minden, amit nem naplókból, hanem metrikákból kapunk.
Vladimir Kolobaev: Alexey, szeretném egy kicsit javítani. Ott van Grafana. A Grafana rendelkezik egy adatforrással, amely a ClickHouse. Azaz közvetlenül a ClickHouse felé tudok kérni a Grafanától. A ClickHouse-nak van egy táblázata naplókkal, mindenki számára ugyanaz. Ennek eredményeként hozzá akarok férni ehhez a naplótáblázathoz a Grafanában, és látni szeretném a szerverem által küldött kéréseket. Jó lenne egy ilyen műszerfal.
Én magam bicikliztem. De van egy kérdésem - ha mindez szabványosított, és a Grafana-t mindenki használja, miért nincs a Yandexnek ilyen hivatalos műszerfala?
Kirill Svakov: Valójában a ClickHouse-hoz tartozó adatforrás már támogatja az Altinity-t. És csak egy vektort szeretnék adni arról, hogy hol kell ásni és kit tolni. Megkérdezheti őket, mert a Yandex továbbra is a ClickHouse-t gyártja, és nem a körülötte lévő sztorit. Az Altinity a fő cég, amely jelenleg a ClickHouse-t népszerűsíti. Nem hagyják el, hanem támogatják. Mert elvileg egy műszerfal feltöltéséhez a Grafana weboldalára csak regisztrálni és feltölteni kell – nincs különösebb probléma.
Alekszej Milovidov: Az elmúlt év során a ClickHouse számos lekérdezés-profilozó képességgel bővült. Minden erőforrás-felhasználási kérelemhez vannak mérőszámok. Nemrég pedig egy még alacsonyabb szintű lekérdezésprofilozót adtunk hozzá, hogy megtudjuk, hová költ egy lekérdezés ezredmásodpercenként. De ennek a funkciónak a használatához meg kell nyitnom a konzolklienst, és be kell írnom egy kérést, amit mindig elfelejtek. Elmentettem valahova, és folyamatosan elfelejtem, hogy pontosan hol.
Bárcsak lenne egy eszköz, amely csak azt mondta volna, hogy itt vannak a nehéz lekérdezései, lekérdezési osztályok szerint csoportosítva. Megnyomtam az egyiket, és azt mondták, hogy ezért nehéz. Ilyen megoldás most nincs. És tényleg elég furcsa, hogy amikor az emberek azt kérdezik tőlem: „Mondd, vannak kész irányítópultok a Grafana számára?”, azt mondom: „Menj a Grafana webhelyére, ott van a „Dashboards” közösség, és van egy irányítópult. a Dimkától, van egy műszerfal a Kostyantól. Nem tudom, mi az, én magam nem használtam."
Hogyan lehet befolyásolni az egyesítéseket, hogy a szerver ne ütközzön az OOM-ba?
Van egy táblám, csak egy partíció van a táblában, ez a ReplaceingMergeTree. Négy éve írok bele adatokat. Változtatnom kellett rajta, és törölnem kellett néhány adatot.
Ezt megtettem, és a kérés feldolgozása során a fürt összes kiszolgálójának összes memóriája elfogyott, és a fürt összes kiszolgálója OOM-ba ment. Aztán mindannyian együtt felkeltek, elkezdték egyesíteni ugyanazt a műveletet, ezt az adatblokkot, és újra beleestek az OOM-ba. Aztán újra felálltak és újra elestek. És ez a dolog nem állt meg.
Aztán kiderült, hogy ez valójában egy hiba, amit a srácok javítottak. Ez nagyon klassz, köszönöm szépen. De maradvány maradt. És most, amikor arra gondolok, hogy valamiféle összevonást készítsek a táblázatban, van egy kérdésem - miért nem tudom valahogy befolyásolni ezeket az összevonásokat? Például korlátozza őket a szükséges RAM mennyiségével, vagy elvileg azzal a mennyiséggel, amely ezt a táblát feldolgozza.
Van egy „Metrics” nevű táblázatom, kérem, dolgozza fel nekem két szálban. Nem kell párhuzamosan tíz-öt összevonást létrehozni, hanem kettőben. Azt hiszem, van elég memóriám kettőre, de lehet, hogy nem lesz elég tíz feldolgozásához. Miért marad fenn a félelem? Mert a táblázat növekszik, és egyszer olyan helyzetbe kerülök, ami elvileg már nem hiba miatt van, hanem mert akkora mennyiségben változnak az adatok, hogy egyszerűen nem lesz elég memória a szerver. Ezután a szerver összeomlik az OOM-ba az egyesítéskor. Sőt, törölhetem a mutációt, de Merji már nincs ott.
Tudod, egyesítéskor a szerver nem fog OOM-ba kerülni, mert egyesítéskor a RAM mennyiségét csak egy kis adattartományra használják fel. Így az adatmennyiségtől függetlenül minden rendben lesz.
Vladimir Kolobaev: Bírság. Itt az a pillanat, hogy a hiba kijavítása után letöltöttem magamnak egy új verziót, és egy másik asztalon, egy kisebben, ahol sok partíció van, hasonló műveletet végeztem. Az összevonás során pedig körülbelül 100 GB RAM égett el a szerveren. 150 foglaltam, 100 megettem, és 50 GB-os ablakom maradt, így nem estem bele az OOM-ba.
Jelenleg mi véd meg attól, hogy beleesjek az OOM-ba, ha ténylegesen 100 GB RAM-ot fogyaszt? Mi a teendő, ha hirtelen elfogy a RAM az egyesítéseken?
Alekszej Milovidov: Van egy olyan probléma, hogy a RAM fogyasztása kifejezetten összevonásra nincs korlátozva. A második probléma pedig az, hogy ha valamilyen összevonást rendeltek hozzá, akkor azt végre kell hajtani, mert a replikációs naplóban rögzítve van. A replikációs napló azokat a műveleteket tartalmazza, amelyek a replika konzisztens állapotba hozásához szükségesek. Ha nem hajt végre olyan manuális manipulációkat, amelyek visszaállítják ezt a replikációs naplót, akkor az egyesítést így vagy úgy végre kell hajtani.
Természetesen nem lenne felesleges egy RAM korlátozás, amely „csak abban az esetben” véd az OOM ellen. Ez nem segíti az egyesítés befejezését, újraindul, elér valamilyen küszöböt, kivételt dob, majd újraindul - ebből semmi jó nem lesz. De elvileg hasznos lenne bevezetni ezt a korlátozást.
Hogyan fejlesztik a Golang illesztőprogramot a ClickHouse-hoz?
A Golang drivert, amelyet Kirill Shvakov írt, immár hivatalosan is támogatja a ClickHouse csapata. Ő , most már nagy és igazi.
Egy kis megjegyzés. Van egy csodálatos és szeretett tárháza a végtelen rend normál formáinak – ez a Vertica. Saját hivatalos python-illesztőprogramjuk is van, amelyet a Vertica fejlesztői támogatnak. És többször előfordult, hogy a tárolóverziók és az illesztőprogram-verziók drámaian eltértek egymástól, és az illesztőprogram egy ponton leállt. És a második pont. Számomra úgy tűnik, hogy ennek a hivatalos illesztőprogramnak a támogatását a „bimbó” rendszer végzi - írsz nekik egy problémát, és örökre lefagy.
Két kérdésem van. Most a Kirill Golang illesztőprogramja szinte az alapértelmezett módja a Golang és a ClickHouse közötti kommunikációnak. Kivéve, ha valaki mégis a http felületen keresztül kommunikál, mert neki így tetszik. Hogyan folytatódik ennek a meghajtónak a fejlesztése? Szinkronizálva lesz-e magában a tárolóban bekövetkező törésekkel? És mi az eljárás egy probléma mérlegelésére?
Kirill Svakov: Az első az, hogy minden bürokratikusan van megszervezve. Erről a pontról nem esett szó, így nincs mit válaszolnom.
A problémával kapcsolatos kérdés megválaszolásához szükségünk van az illesztőprogram egy kis történetére. Egy olyan cégnél dolgoztam, ahol sok adat volt. Ez egy reklámforgató volt, hatalmas számú eseményrel, amelyeket valahol el kellett tárolni. És egy ponton megjelent a ClickHouse. Feltöltöttük adatokkal, és először minden rendben volt, de aztán a ClickHouse összeomlott. Abban a pillanatban úgy döntöttünk, hogy nincs rá szükségünk.
Egy évvel később visszatértünk a ClickHouse használatának ötletéhez, és valahogy oda kellett írnunk az adatokat. A bevezető üzenet ez volt: nagyon gyenge a hardver, kevés az erőforrás. De mindig is így dolgoztunk, ezért a natív protokoll felé néztünk.
Mivel Go-ban dolgoztunk, egyértelmű volt, hogy szükségünk van egy Go-sofőrre. Szinte teljes munkaidőben csináltam – ez volt a munkafeladatom. Elhoztuk egy bizonyos pontig, és elvileg senki sem feltételezte, hogy rajtunk kívül más is használni fogja. Aztán a CloudFlare pontosan ugyanezzel a problémával jött, és egy ideig nagyon gördülékenyen dolgoztunk velük, mert ugyanazok a feladataik voltak. Sőt, ezt a ClickHouse-ban magunk és a driverben is megtettük.
Valamikor egyszerűen abbahagytam, mert a ClickHouse-szal és a munkával kapcsolatos tevékenységem kicsit megváltozott. Ezért a kérdések nincsenek lezárva. Időnként az emberek, akiknek szükségük van valamire, maguk is elkötelezik magukat az adattár mellett. Aztán megnézem a pull kérést, és néha magam is szerkesztek valamit, de ez ritkán fordul elő.
Vissza akarok térni a sofőrhöz. Néhány évvel ezelőtt, amikor ez az egész elkezdődött, a ClickHouse is más volt, és más képességekkel. Most már megértjük, hogyan kell átépíteni az illesztőprogramot, hogy jól működjön. Ha ez megtörténik, akkor a 2-es verzió a felgyülemlett mankók miatt mindenképpen összeférhetetlen lesz.
Nem tudom, hogyan kell megszervezni ezt az ügyet. magamnak nincs sok időm. Ha néhányan befejezik a sofőrt, tudok segíteni nekik, és megmondom, mit tegyenek. De a Yandex aktív részvételét a projekt fejlesztésében még nem vitatták meg.
Alekszej Milovidov: Valójában ezekkel a sofőrökkel kapcsolatban még nincs bürokrácia. Az egyetlen dolog, hogy egy hivatalos szervezethez vannak benyújtva, vagyis ez az illesztőprogram a Go hivatalos alapértelmezett megoldása. Vannak más meghajtók is, de azok külön jönnek.
Ezekhez a meghajtókhoz nincs belső fejlesztésünk. A kérdés az, hogy tudunk-e egyéni embert felvenni, de nem ehhez a sofőrhöz, hanem az összes közösségi sofőr fejlesztéséhez, vagy találunk valakit kívülről.
A külső szótár nem töltődik be újraindítás után, ha a lazy_load beállítás engedélyezve van. Mit kell tenni?
Engedélyeztük a lazy_load beállítást, és a szerver újraindítása után a szótár nem töltődik be magától. Csak akkor jelenik meg, ha a felhasználó hozzáfér ehhez a szótárhoz. És amikor először hozzáférek, hibát jelez. Lehetséges-e valamilyen módon automatikusan betölteni a szótárakat a ClickHouse segítségével, vagy mindig saját kezűleg kell ellenőriznie a készenlétüket, hogy a felhasználók ne kapjanak hibákat?
Talán a ClickHouse régi verziója van, így a szótár nem töltődött be automatikusan. Lehet, hogy ez a helyzet?
Először is, a szótárak kényszeríthetők lekérdezéssel rendszer újratöltési szótárak. Másodszor, ami a hibát illeti - ha a szótár már be van töltve, akkor a lekérdezések a betöltött adatok alapján működnek. Ha a szótár még nincs betöltve, akkor közvetlenül a kérés során töltődik be.
Ez nem túl kényelmes a nehéz szótárak számára. Például egy millió sort kell kihúznia a MySQL-ből. Valaki egyszerű kiválasztást végez, de ez a kijelölés ugyanarra a millió sorra vár. Itt két megoldás létezik. Az első a lazy_load kikapcsolása. Másodszor, amikor a szerver működik, mielőtt ráterhelné, tegye meg rendszer újratöltési szótár vagy egyszerűen csak végezzen egy szótárt használó lekérdezést. Ezután a szótár betöltődik. A szótárak elérhetőségét szabályozni kell a lazy_load beállítás engedélyezésével, mert a ClickHouse nem tölti be őket automatikusan.
Az utolsó kérdésre a válasz az, hogy vagy régi a verzió, vagy hibakeresésre szorul.
Mi a teendő azzal, hogy a rendszer-újratöltő szótárak egyikét sem tölti be a sok szótár közül, ha legalább az egyik hibával összeomlik?
Van még egy kérdés a rendszer újratöltési szótáraival kapcsolatban. Két szótárunk van – az egyik nincs betöltve, a másik be van töltve. Ebben az esetben a Rendszer újratöltési szótárak nem töltenek be szótárt, és pontról pontra kell betölteni egy adott szót a rendszer újratöltési szótár segítségével. Ez is a ClickHouse verzióhoz kapcsolódik?
Boldoggá akarlak tenni. Ez a viselkedés megváltozott. Ez azt jelenti, hogy ha frissíted a ClickHouse-t, az is megváltozik. Ha nem elégedett jelenlegi viselkedésével rendszer újratöltési szótárak, frissítse, és reméljük, jobbra fog változni.
Van mód a ClickHouse konfigurációban konfigurálni a részleteket, de hiba esetén nem jeleníteni?
A következő kérdés a szótárral kapcsolatos hibákra vonatkozik, nevezetesen a részletekre. A szótár ClickHouse konfigurációjában megadtuk a csatlakozási adatokat, és ha hiba van, akkor válaszként megkapjuk ezeket az adatokat és jelszót.
Ezt a hibát úgy oldottuk meg, hogy részleteket adtunk az ODBC illesztőprogram konfigurációjához. Van valami mód a ClickHouse konfigurációban a részletek konfigurálására, de hiba esetén ne jelenítse meg ezeket a részleteket?
Az igazi megoldás itt az, hogy ezeket a hitelesítő adatokat az odbc.ini fájlban adja meg, és magában a ClickHouse-ban csak az ODBC adatforrás nevét adja meg. Ez nem fog megtörténni más szótári forrásoknál - sem a MySQL-lel rendelkező szótárnál, sem a többinél, nem szabad látnia a jelszót, amikor hibaüzenetet kap. Az ODBC esetében is megnézem - ha létezik, csak el kell távolítania.
Bónusz: hátterek a Zoomhoz az összejövetelekből
A képre kattintva bónusz hátterek nyílnak meg az összejövetelekről a legkitartóbb olvasók előtt. Együtt oltjuk a tüzet az Avito technológiai kabalafigurákkal, tanácskozunk a rendszergazdai szobából vagy a régi iskolai számítástechnikai klubból érkezett kollégákkal, és napi összejöveteleket tartunk a híd alatt a graffitik hátterében.
Forrás: will.com