Áprilisban az Avito mérnökei online találkozóra 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áljuk az adatbázis-kezelő rendszert és milyen nehézségeink adódnak.
A találkozó alapján cikket készítettünk a szakértők válaszaival a saját és nézői kérdéseinkre a biztonsági másolatokról, az adatok újraszalagolásáról, külső szótárakról, Golang-driver-ről és a ClickHouse verziófrissítéseiről. Ez segíthet azoknak a fejlesztőknek, akik már aktívan dolgoznak a Yandex DB-vel és érdeklik a jelenlegi és jövőbeli kilátások. Alapértelmezés szerint Alexey Milovidov válaszai, ha nincs másképp megjelölve.
Óvatosan, a vágás alatt sok szöveg vár. Reméljük, hogy a kérdésekkel foglalkozó tartalom segít tájékozódni.
Tartalom
Ha nem akarod elolvasni a szöveget, megtekintheted a találkozók felvételét . Az időbélyegek a videó első kommentjében találhatók.
A ClickHouse folyamatosan frissül, míg az adatok nem. Mit tegyünk ezzel?
A ClickHouse folyamatosan frissül, de az adatok, amelyeket optimize final feldolgoztunk, nem frissülnek és a biztonsági másolatban maradnak.
Tegyük fel, hogy valamilyen probléma merült fel, és az adatok elvesztek. Döntöttünk a helyreállítás mellett, és kiderült, hogy a régi partíciók, amelyek a biztonsági szervereken találhatók, nagyon eltérnek a jelenleg használt ClickHouse verziótól. Mit tegyünk ilyen helyzetben, és lehetséges-e ez?
Az a helyzet, amikor a régi formátumból állítod vissza az adatokat és az új verzió nem kapcsolódik hozzá, lehetetlen. Figyelünk arra, hogy az adatformátum a ClickHouse-ban mindig hátra kompatibilis maradjon. Ez sokkal fontosabb, mint a funkcionális visszafelé kompatibilitás, ha egy ritkán használt funkció viselkedése változott. Az adatok, amelyek a lemezen tárolódnak, az új ClickHouse verzió mindig képes elolvasni. Ez törvény.
Mik a legjobb gyakorlatok jelenleg a ClickHouse-ból történő adatbiztonsági másolat készítésére?
Hogyan készíthetünk biztonsági másolatokat úgy, hogy figyelembe vesszük az optimize final műveleteket, a terabájt méretű adatbázist, és azokat az adatokat, amelyeket feltételezhetően az elmúlt három napban frissítettek, majd további eljárás már nem történik velük?
Létrehozhatjuk a saját megoldásunkat, és a Bash-ben írhatunk: gyűjtsd össze ezeket a biztonsági másolatokat. Lehet, hogy semmi nem szükséges, és a bicikli már régóta feltalálták?
Először is a legjobb gyakorlatokról. A kollégáim mindig azt javasolják, hogy a biztonsági másolatokra vonatkozó kérdésekre válaszként említsük a "Yandex.Cloud" szolgáltatást, ahol ezt a feladatot már megoldották. Tehát használjátok, ha lehetőség van rá.
Nincs teljes megoldás, amely száz százalékig integrálva lenne a ClickHouse-ba a biztonsági mentésekhez. Léteznek bizonyos sablonok, amelyeket fel lehet használni. Ahhoz, hogy teljes megoldást kapjunk, vagy kicsit manuálisan kell dolgozni, vagy script alakban kell burkolatokat készíteni.
A legegyszerűbb megoldásokkal kezdem, és a legbonyolultabbakkal fejezem be az adatok mennyiségétől és a klaszter méretétől függően. Minél nagyobb a klaszter, annál bonyolultabbá válik a megoldás.
Ha az adatokat tartalmazó tábla csak néhány gigabájtot foglal el, a biztonsági mentést így készíthetjük el:
- A táblák definícióinak, azaz a metaadatoknak a mentése - show create table.
- Biztonsági mentés készítése a ClickHouse kliens segítségével - select * from table fájlba. Alapértelmezés szerint TabSeparated formátumú fájlt kapunk. Ha hatékonyabb megoldásra vágyunk, akkor Native formátumban is lehet.
Ha az adatok mennyisége nagyobb, a biztonsági mentés több időt és sok helyet fog igénybe venni. Ezt logikai biztonsági mentésnek nevezzük, ami nincs kötve a ClickHouse adatformátumhoz. Ha már van, akkor végső esetben a biztonsági mentést át tudja tölteni MySQL-be a helyreállításhoz.
Fejlettebb esetekben a ClickHouse beépített lehetőséget nyújt partíciók pillanatfelvételének létrehozására a helyi fájlrendszerben. Ez a lehetőség lekérdezés formájában érhető el alter table freeze partition. Vagy egyszerűen alter table freeze - ez az egész tábla pillanatfelvétele.
A pillanatfelvétel egy táblára konzisztens lesz egy shardon, így az egész klaszter konzisztens pillanatfelvételét ilyen módon nem lehet létrehozni. De a legtöbb feladathoz erre nincs szükség, elegendő, ha minden shardon végrehajtjuk a lekérdezést, és megkapjuk a konzisztens pillanatfelvételt. Ez hard linkként jön létre, és ezért nem foglal el további helyet. Ezt a pillanatfelvételt ezután átmásolja a biztonsági mentési szerverre vagy a biztonsági mentésekhez használt tárolóra.
Egy ilyen biztonsági mentés helyreállítása eléggé egyszerű. Első lépésként létrehozza a táblákat a meglévő tábladefinitiók alapján. Ezután átmásolja a megőrzött partíciós pillanatfelvételeket a Directory-Detached adatainak megfelelő táblákhoz, és végrehajtja a lekérdezést attach partition. Ez a megoldás teljes mértékben alkalmas a legkomolyabb adatmennyiségekre.
Néha szükség van valami sokkal menőbbre - olyan esetekben, amikor tíz vagy akár több száz terabyte van minden szerveren, és száz szerverünk van. Itt van egy megoldás, amelyet a "Yandex.Metrics" kollégáimtól lestem el. Nem ajánlanám mindenkinek - olvasd el, és döntsd el, hogy megfelel-e neked.
Először is, néhány nagy lemezpolcos szervert kell létrehozni. Ezután ezeken a szervereken fel kell állítani néhány ClickHouse szervert, és úgy kell konfigurálni őket, hogy másodlagos replikaként működjenek ugyanazokhoz a shardokhoz. Ezen a ponton a fájlrendszert vagy valamilyen eszközt kell használni, amely lehetővé teszi pillanatfelvételek készítését. Itt két lehetőség van. Az első lehetőség az LVM pillanatfelvételek, a második pedig a ZFS Linux alatt.
Ezután minden nap pillanatfelvételt kell készíteni, amely egy helyet foglal el. Természetesen, ha az adatok változnak, akkor az idő múlásával a hely mérete növekedni fog. Ezt a pillanatfelvételt bármikor elő lehet venni és az adatokat vissza lehet állítani, ilyen furcsa megoldás. Plusz, korlátozni kell a replikákat a konfigurációban, hogy ne próbáljanak vezetővé válni.
Lehetővé lehet-e tenni a replikák szabályozott lemaradását a klónokban?
Idén tervezi, hogy völgyeket készít a ClickHouse-ban. Lehet-e ezeken irányított replikaháttérrel szervezni? Szeretnénk ezzel megvédeni magunkat a nem kívánt forgatókönyvektől alternatívák és egyéb változások esetén.
Lehetséges-e bármilyen visszavonás az alternatívák számára? Például a meglévő völgyben azt mondani, hogy addig a pontig alkalmazd a változtatásokat, és ettől a ponttól kezdve hagyd abba a változtatások alkalmazását?
Ha a klaszterünkbe érkezik egy parancs, és tönkreteszi azt, akkor van egy feltételes replikánk, amely egy órás késésben van, ahol azt mondhatjuk, hogy használjuk őt a jelen pillanatban, de az utolsó tíz perc változásait nem alkalmazzuk?
Először is a replikák irányított késéséről. Ez a felhasználók részéről érkezett kérés volt, és létrehoztunk egy issue-t a Githubon azzal a kéréssel: "Ha valakinek szüksége van rá, like-oljatok, szívességgel jelöljétek be". Senki sem like-olt, és az issue-t lezárták. Ennek ellenére már most is lehetőség van erre, ha beállítod a ClickHouse-t. Igaz, csak a 20.3-as verziótól kezdve.
A ClickHouse folyamatosan a háttérben végzi az adatok egyesítését — merge. Amikor a merge megtörténik, egy bizonyos adatrészletet egy nagyobb darabra cserélünk. Eközben az előző adatrészek egy ideig továbbra is a lemezen maradnak.
Először is, ezek addig tárolódnak, amíg vannak select lekérdezések, amelyek használják őket, hogy biztosítsák a zökkenőmentes működést. A select lekérdezések nyugodtan olvasnak a régi darabokból.
Másodszor, van egy időbeli küszöb is — a régi adatrészek nyolc percig maradnak a lemezen. Ezt a nyolc percet be lehet állítani, akár egy napra is. Ez helyet foglal a lemezen: a forgalom függvényében lehet, hogy az elmúlt napban az adatok nem csak megduplázódnak, hanem akár ötször annyi is lehet. De súlyos probléma esetén le tudja állítani a ClickHouse szervert, és foglalkozhat a dolgokkal.
Most felmerül a kérdés, hogy ez hogyan véd meg az alterektől. Itt érdemes mélyebbre nézni, mert a régi ClickHouse verziókban az alter úgy működött, hogy egyszerűen közvetlenül megváltoztatta a darabokat. Van egy adatrészlet néhány fájllal, és mi például csinálunk alter drop column. Ilyenkor ez az oszlop fizikailag eltávolításra kerül az összes darabból.
De a 20.3 verziótól kezdve az alterek mechanizmusa teljesen megváltozott, és most a darabok mindig immutábilisak. Ezek egyáltalán nem változnak — az alterek most körülbelül úgy működnek, mint a mergek. Ahelyett, hogy a darabot a helyén változtatnánk meg, újat hozunk létre. Az új darabban a változatlan fájlok kemény linkekké válnak, és ha töröltünk egy oszlopot, egyszerűen nem lesz jelen az új darabban. A régi darab alapértelmezés szerint nyolc perc múlva törlődik, és itt lehet finomhangolni a fent említett beállításokat.
Ugyanez vonatkozik a mutációs típusú alterekre is. Amikor csinálja alter delete vagy alter update, ez nem változtatja meg a darabot, hanem újat készít. Aztán eltávolítja a régit.
Mi a teendő, ha változik a tábla szerkezete?
Hogyan lehet visszaállítani a biztonsági másolatot, amely régi sémával készült? A második kérdés a snapshotok és a fájlrendszeri eszközök esetében. A Btrfs megfelelő-e a ZFS helyett Linux LVM-en?
Ha csinálja attach partition Ha más felépítésű partíciókról van szó, a ClickHouse értesíteni fog róla, hogy ez nem lehetséges. A megoldás a következő. Először is létre kell hozni egy ideiglenes MergeTree típusú táblát a régi felépítéssel, csatolni kell oda az adatokat az 'attach' segítségével, majd végrehajtani egy 'alter' lekérdezést. Ezután vagy átmásolhatja, vagy áthelyezheti ezeket az adatokat, és újra elvégezheti az 'attach'-t, vagy használhatja a lekérdezést. alter table move partition.
Most a második kérdés - használható-e a Btrfs. Először is, ha van LVM, akkor elegendő az LVM pillanatfelvétele, és a fájlrendszer lehet ext4 is, ez nem számít. A Btrfs esetében minden az Ön tapasztalatától függ az üzemben tartással kapcsolatban. Ez egy érett fájlrendszer, de még mindig felmerül néhány kérdés arról, hogy hogyan fog felnőttként működni a konkrét forgatókönyvben. Nem javaslom a használatát, ha nincs Btrfs az éles környezetben.
Mik a legjobb gyakorlatok jelenleg az adatok újraszalagolásában?
A sharding áthelyezése összetett és sokrétű kérdés. Itt azonnal több lehetőség is kínálkozik a válaszra. Az egyik megközelítés szerint a ClickHouse-ban nincsen beépített lehetőség a sharding áthelyezésére. De félő, hogy ez a válasz senkinek sem fog tetszeni. Ezért egy másik megközelítésből azt is mondhatjuk, hogy a ClickHouse-nak sok módszere van az adatok sharding áthelyezésére.
Ha megtelik a cluster vagy nem bírja a terhelést, új szervereket ad hozzá. De ezek a szerverek alapértelmezés szerint üresek, nincsenek adatok rajtuk, és nincs terhelés. Az adatok áthelyezése szükséges ahhoz, hogy azok egyenletesen szétszóródjanak az új, megnövelt méretű cluster között.
Az első módszer, amellyel ezt megteheti, az, hogy egy részét a partícióknak átmásolja az új szerverekre a lekérdezés segítségével. alter table fetch partition. Például, ha hónapok szerint voltak partíciói, akkor az első hónapot 2017-ből átviszi az új szerverre, később pedig a harmadik hónapot másik új szerverre másolja. Így folytatja, amíg nagyjából egyenletesen el nem oszlik.
Az áthelyezés csak azok számára a partíciók számára valósítható meg, amelyek nem változnak írás közben. Az új partícióknál az írást le kell állítani, mert az áthelyezés nem atomikus. Különben dublikátumokat vagy hiányzó adatokat kaphat. Mindazonáltal ez a módszer gyakorlatias, és elég hatékonyan működik. A hálózaton már kész, tömörített partíciók kerülnek át, tehát az adatok nem tömörülnek és nem kódolódnak újra.
Ennek a módszernek van egy hátránya, amely a shardolási sémától függ, hogy elkötelezted-e magad ezen séma mellett, és milyen shardolási kulcsod volt. A te példádban, a metrikákkal kapcsolatos esetben a shardolási kulcs a path hash-je. Amikor a Distributed táblába kérdezel, az az összes shardra egyből megy a klaszterben, és onnan gyűjti össze az adatokat.
Ez azt jelenti, hogy valójában nem számít, hogy melyik shardon találhatóak az adatok. A lényeg az, hogy az egy útvonalon lévő adatok egy shardon találhatóak, de hogy pontosan melyiken, az nem lényeges. Ebben az esetben a kész partíciók áthelyezése nagyszerűen működik, mert a select lekérdezések során is, akár az átkonfigurálás előtt, akár után, a sémának nincs különösebb jelentősége – mindig teljes adatokat kapsz.
De vannak bonyolultabb esetek is. Ha az alkalmazás logikai szintjén egy speciális shardolási séma mellett kötelezed el magad, hogy ez az ügyfél egy adott shardon található, és a lekérdezést egyből oda küldheted, nem a Distributed táblába. Vagy használhatsz egy elég új ClickHouse verziót, és bekapcsoltad a beállítást optimize skip unused shards. Ebben az esetben a select lekérdezés során a where szakasz kifejezését elemezni fogják, és kiszámítják, hogy mely shardokra kell menni a shardolási séma szerint. Ez akkor működik, ha az adatok pontosan e shardolási séma szerint vannak elhelyezve. Ha manuálisan áthelyezted őket, a megfelelés megváltozhat.
Tehát ez az első módszer. Várom a válaszodat, hogy megfelel-e a módszer, vagy menjünk tovább.
Vladimir Kolobaev, az Avito vezető rendszeradminisztrátora: Alexej, az a módszer, amelyet említettél, nem illik jól, amikor a terhelést beleértve az olvasást is el kell osztani. Elvehetjük a havi partíciót, és átvihetjük a múlt hónapot egy másik node-ra, de amikor megérkezik a lekérdezés ezekre az adatokra, csak azt fogjuk terhelni. Pedig szeretnénk az egész klasztert terhelni, mert különben egy ideig az összes olvasási terhelés két shardon fog feldolgozódni.
Alexej Milovidov: A válasz itt furcsa - igen, rossz, de talán működni fog. Elmagyarázom, hogyan. Érdemes megnézni a terhelési forgatókönyvet, amely aadatai mögött áll. Ha ez a megfigyelési adat, akkor szinte biztosan elmondható, hogy a kérdések többsége friss adatokra vonatkozik.
Új szervereket telepített, áthelyezte a régi partíciókat, de azt is megváltoztatta, ahogyan a friss adatok rögzítve vannak. És a friss adatok eloszlanak az egész klaszteren. Így már öt perc elteltével a legutolsó öt perce vonatkozó kérdések egyenletesen terhelni fogják a klasztert, egy nap elteltével pedig a napi kérdések egyenletesen terhelni fogják a klasztert. Sajnos, a korábbi hónapra vonatkozó kérdések csak a klaszter egyes szervereihez fognak érkezni.
De gyakran nem lesznek kérések pontosan 2019 februárjára. Valószínűleg, ha a kérdések 2019-re vonatkoznak, akkor azok egész 2019-re vonatkoznak - egy nagy időintervallumra, nem pedig egy kis tartományra. Az ilyen kérdések is egyenletesen terhelni tudják a klasztert. De összességében az észrevétele teljesen helytálló, hogy ez egy ad hoc megoldás, amely nem osztja el teljesen egyenletesen az adatokat.
Van még néhány pontom a kérdés megválaszolására. Az egyik arról szól, hogyan lehet eredetileg úgy kialakítani a shardelési sémát, hogy a újra shardelés kevesebb fájdalommal járjon. Ez nem mindig lehetséges.
Például van egy megfigyelési adata. A megfigyelési adat három okból növekszik. Az első a történeti adatok felhalmozása. A második a forgalom növekedése. A harmadik pedig a megfigyelés alá eső dolgok számának növekedése. Új mikroszolgáltatások és metrikák jelennek meg, amelyeket meg kell őrizni.
Lehet, hogy ezek közül a legnagyobb növekedés a harmadik okkal kapcsolatos - ez a megfigyelés használatának növekedése. És ebben az esetben érdemes megvizsgálni a terhelés jellegét, hogy mik a legfontosabb kérdések a select műveletek során. A fő select kérdések valószínűleg egy bizonyos metrikavezeték kisebb csoportjából fognak érkezni.
Például a CPU használata bizonyos szervereken valamilyen szolgáltatás által. Ezért van egy bizonyos kulcsok alhalmaza, amely alapján ezeket az adatokat kinyerjük. Magának a kérésnek az adatokért valószínűleg elég egyszerű, és több tucat milliszekundum alatt végrehajtható. Monitorozási szolgáltatásokhoz és műszerfalakhoz használják. Remélem, jól értem.
Vlagyimir Kolobaev: A helyzet az, hogy nagyon gyakran hivatkozunk a történeti adatokra, mivel valós időben hasonlítjuk össze a jelenlegi állapotot a történettel. Számunkra fontos a gyors hozzáférés egy nagy mennyiségű adathez, és a ClickHouse ezzel kiválóan boldogul.
Teljesen igaza van, a legtöbb olvasási kérésünket az utolsó nap során tapasztaljuk, mint minden monitoring rendszer. Ugyanakkor a történeti adatokra is jelentős terhelés nehezedik. Ez elsősorban az értesítési rendszerből ered, amely harminc másodpercenként kérdezi a ClickHouse-t, hogy: „Add át nekem az elmúlt hat hét adatait. Most pedig építs nekem egy gördülő átlagot belőlük, és hasonlítsuk össze a jelenlegi értéket a történetivel.”
Szeretném mondani, hogy számunkra, az ilyen nagyon friss kérelmekhez van egy kisebb táblázatunk, amelyben mindössze két nap adatot tárolunk, és a fő kérelmek oda irányulnak. Az nagyobb shardolt táblába csak a nagy történeti kéréseket küldjük.
Alexej Milovidov: Sajnos a te forgatókönyvedhez nem igazán alkalmazható, de elmondom két rossz és bonyolult shardolási sémát, amelyet nem szabad használni, de amelyeket a barátaim szolgáltatásában használnak.
Van egy fő klaszter az "Yandex.Metrika" eseményeivel. Az események a lapmegtekintések, kattintások és átmenetek. A legtöbb kérés egy adott webhelyhez érkezik. Megnyitod a "Yandex.Metrika" szolgáltatást, van egy webhelyed — avito.ru, belépsz a jelentésbe, és a kérés a webhelyedre irányul.
De vannak más kérdések is — analitikai és globális, amelyeket belső elemzők végeznek. Megjegyzem, hogy a belső elemzők csak a "Yandex" szolgáltatásain kérdeznek. Ennek ellenére a "Yandex" szolgáltatásai jelentős részesedést képviselnek az összes adatban. Ezek nem konkrét számlálókra irányuló kérések, hanem szélesebb szűrés alapján.
Hogyan lehet a dátumokat úgy szervezni, hogy egyetlen számlálóval minden hatékonyan működjön, és a globális lekérdezések is? A nehézség abban rejlik, hogy a ClickHouse metrikás klaszterében a lekérdezések száma másodpercenként több ezer. Az ilyen nem triviális lekérdezéseket például egyetlen ClickHouse szerver nem bírja el másodpercenként több ezer esetén.
A klaszter mérete – több mint 600 szerver. Ha ebben a klaszterben egyszerűen csak egy elosztott táblát húzunk be, és elküldjük oda több ezer lekérdezést, akkor még rosszabb lesz, mint egyetlen szerverre küldeni őket. Másrészt az a lehetőség, hogy az adatok egyenletesen eloszlanak, és mi kérdezünk az összes szervertől, már ki van zárva.
Van egy diametrálisan ellentétes lehetőség. Képzelje el, ha az adatokat webhelyek szerint shardolnánk, és egy webhely lekérdezése egy shardra menne. Most a klaszter képes lenne kezelni tízezer lekérdezést másodpercenként, de egyetlen shardon valamilyen lekérdezés túl lassan futna. Az már nem bővíthető átviteli kapacitásban. Különösen, ha ez az avito.ru webhely. Nem árulok el nagy titkot, ha azt mondom, hogy az Avito az egyik leglátogatottabb webhely az orosz interneten. Egy shardon kezelni azt őrültség lenne.
Ezért a shardolási séma ügyesebben van megtervezve. Az egész klaszter fel van osztva néhány kisebb klaszterre, amelyeket rétegeknek nevezünk. Minden kisebb klaszterben tíz és néhány tucat shard található. Összesen harminckilenc ilyen kisebb klaszter van.
Hogyan skálázódik mindez? A kisebb klaszterek száma nem változik – ahogy néhány évvel ezelőtt harminckilenc volt, úgy az is maradt. De mindegyikükön belül fokozatosan növeljük a shardok számát az adatok felhalmozódásával. A shardolás sémája a következő – a kisebb klaszterek webhelyek szerint oszlanak, és hogy megértsük, melyik webhely melyik klaszteren található, egy külön Meta-adatbázist használunk MySQL-ben. Egy webhely – egy kisebb klaszteren. És ezen belül a shardolás látogatói azonosítók szerint zajlik.
Amikor rögzítjük őket, azokat a látogató azonosítójának maradéka szerint csoportosítjuk. De amikor új shardot adunk hozzá, a shardelési séma megváltozik, így továbbra is csoportosítunk, de más szám szerint osztunk. Ez azt jelenti, hogy egy látogató valójában több szerveren is elhelyezkedik, és erre nem lehet támaszkodni. Ezt kizárólag azért tettük, hogy az adatok jobban tömörüljenek. A lekérdezéseknél a Distributed táblába megyünk, amely a klaszterre néz, és több tucat szerverhez fordul. Ez egy ilyen bonyolult séma.
De a történetem nem lenne teljes, ha nem mondanám el, hogy ettől a sémától elálltunk. Az új sémában mindent megváltoztattunk, és az összes adatot a clickhouse-copier segítségével másoltuk.
Az új sémában az összes weboldal két kategóriába oszlik - nagy és kicsi. Nem tudom, hogyan választották ki a küszöböt, de az eredmény azt mutatja, hogy a nagy weboldalak egy klaszterre kerülnek, ahol 120 shard van, mindegyikben három replikával - tehát összesen 360 szerver. És a shardelési séma úgy van, hogy bármelyik lekérdezés azonnal minden shardhoz megy. Ha most a „Yandex.Metrikében” megnyitsz bármilyen jelentés oldalt az avito.ru számára, a lekérdezés 120 szerverre megy. Nagy weboldalból a runetben kevés van. És a lekérdezések nem ezernél, hanem még száz alatt vannak. Mindezt a Distributed tábla nyugodtan feldolgozza, amelyet mindegyikük 120 szerverrel kezel.
A második klaszter a kicsi weboldalak számára készült. Itt a shardelési séma a weboldal azonosítója alapján történik, és minden lekérdezés pontosan egy shardra megy.
A ClickHouse-ban van egy utility, a clickhouse-copier. Mesélhetne róla?
Azonnal elmondom, hogy ez a megoldás nagyobb terjedelmű és kissé kevésbé hatékony. Az előnye az, hogy teljesen szétdobja az adatokat a megadott séma szerint. De a segédprogram hátránya, hogy nem hajt végre új shardelést. Az adatokat az egyik klasztersémából a másik klasztersémába másolja.
Ez azt jelenti, hogy a működéséhez két klaszterre van szüksége. Ezek ugyanazon a szerveren is elhelyezkedhetnek, de ennek ellenére az adatok nem fognak inkrementálisan mozogni, hanem másolva lesznek.
Például négy szerver volt, most nyolc lett. Új Distributed táblát, új helyi táblákat hoz létre minden szerveren, és elindítja a clickhouse-copier-t, megadva benne a működési sémát, hogy honnan kell olvasnia, hogy el kell fogadnia az új sharding sémát és oda kell áthelyeznie az adatokat. Az Ön régi szerverein másfél szeres helyre lesz szüksége, mint ami jelenleg van, mivel a régi adatoknak ott kell maradniuk, és ezen felül érkezik egy rész a régi adatokból is. Ha előre gondolt arra, hogy az adatokat újból sharde-olni kell, és van elég hely, akkor ez a módszer megfelelő lesz.
Hogyan működik belül a clickhouse-copier? Az egész munkát feladatcsoportokra bontja, amelyek egy partíció feldolgozását végzik egy táblában egy shard-ban. Ezek a feladatok párhuzamosan futtathatók, és a clickhouse-copier különböző gépeken több példányban is futtatható, de amit egy partícióért tesz – az nem más, mint egy insert select. Az adatokat olvassák, kicsomagolják, újra sharde-olják, majd ismét tömörítik, valahova írják, és újrasortolják. Ez egy nehezebb megoldás.
Volt egy pilot dolog, amit újraszalagolásnak hívtak. Mi lett vele?
Volt egy kísérleti dolog 2017-ben, amely részhardozásnak nevezték. Az ClickHouse-ban még van is egy opció. Úgy értesültem, hogy ez nem vált be. Elmondaná, miért alakult így? Úgy tűnik, hogy nagyon aktuális lenne.
Az összes probléma abban rejlik, hogy ha szükséges az adatok helyben történő újbóli sharde-olása, akkor egy meglehetősen összetett szinkronizációra van szükség ahhoz, hogy ezt atomikusan végrehajtsuk. Amikor elkezdtük vizsgálni, hogyan van ez a szinkronizáció megszervezve, világossá vált, hogy alapvető problémák vannak. Ezek az alapvető problémák nemcsak elméletiek, hanem azonnal megmutatkoznak a gyakorlatban abban, amit nagyon egyszerűen el lehet magyarázni – semmi nem működik.
Lehet-e az összes adatdarabot egyesíteni a lassú meghajtókra történő áthelyezés előtt?
Kérdés a TTL-ről a move to slow disk opcióval a merge-ek kontextusában. Van-e mód, hogy a cron-on kívül minden darabot egybeolvasztva áthelyezzük őket lassú lemezekre?
A válasz a kérdésre, hogy lehet-e automatikusan összefűzni az összes darabot, mielőtt áthelyezik őket – nem. Szerintem erre nincs szükség. Lehet, hogy nem szükséges minden részt egybeolvasztani, hanem egyszerűen számíthatunk arra, hogy automatikusan áthelyezik őket a lassú lemezekre.
Két kritériumunk van az áthelyezési szabályokra. Az első a tárolási szint kitöltöttsége szerint működik. Ha a jelenlegi tárolási szinten kevesebb mint egy bizonyos százalék szabad hely van, kiválasztunk egy blokkot, és áthelyezzük egy lassabb tárolóra. Vagyis nem lassabbra, hanem a következőre — ahogyan beállította.
A második kritérium a méret. Ez a nagyobb blokkok áthelyezéséről szól. Beállíthatja a küszöböt a gyors lemezen található szabad helyre, és az adatok automatikusan átkerülnek.
Hogyan lehet átállni új ClickHouse verziókra, ha nincs lehetőség előre ellenőrizni a kompatibilitást?
Ez a téma rendszeresen felmerül különböző verziók figyelembevételével, és mégis. Mennyire biztonságos frissíteni az 19.11-ről 19.16-ra és például a 19.16-ról 20.3-ra. Hogyan lehet a legjobban áttérni az új verziókra, ha nincs lehetőség előre tesztelni a kompatibilitást egy homokozóban?
Itt van néhány „arany” szabály. Az első — . Nagy, de vannak benne különálló pontok a visszafelé nem kompatibilis változtatásokról. Ezekre a pontokra nem érdemes úgy tekinteni, mint piros zászlóra. Általában kisebb inkompatibilitásokról van szó, amelyek egyes határfunkciókhoz kapcsolódnak, amelyeket valószínűleg nem használ.
A második — ha nincs lehetőség a kompatibilitás homokozóban történő ellenőrzésére, és azonnal frissíteni szeretne a termelésben, az ajánlás az — ne tegye ezt. Először hozzon létre egy homokozót és ellenőrizze. Ha nincs tesztkörnyezet, akkor valószínűleg kicsi a cége, és így másolhatja az adatok egy részét a laptopjára, és meggyőződhet arról, hogy minden jól működik. A saját gépén akár több replikát is felállíthat. Vagy az új verziót valahol a közelben is telepítheti, és oda töltheti fel az adatok egy részét — tehát improvizált tesztkörnyezetet létrehozni.
Egy másik szabály — ne frissítse az új verzió megjelenése utáni héten a hibák kifogása és a következő gyors javítások miatt a termelésben. Nézzük meg a ClickHouse verziószámozását, hogy ne keveredjünk.
Van egy 20.3.4-es verzió. A 20 a kiadás évét jelöli — 2020-at. A belső tartalmat tekintve ennek nincs jelentősége, így ezt most figyelmen kívül hagyjuk. A következő szám 20.3. A második számot — jelen esetben a 3-at — minden alkalommal növeljük, amikor új funkciót adunk ki. Ha új képességet szeretnénk hozzáadni a ClickHouse-hoz, ezt a számot kötelezően növelnünk kell. Tehát a 20.4-es verzióban a ClickHouse még jobban fog működni. A harmadik szám — 20.3.4. Itt a 4 a patch-kiadások számát jelöli, amelyek során új funkciókat nem adtunk hozzá, de hibákat javítottunk. A 4 azt jelenti, hogy ezt négyszer csináltuk meg.
Nem kell azt gondolnod, hogy ez valami borzalmas dolog. Általában a felhasználó telepítheti a legfrissebb verziót, és az problémák nélkül fog működni egy évig. De képzeld el, hogy egy bitkép-feldolgozó funkcióban, amelyet kínai barátaink adtak hozzá, ha rossz argumentumot adsz meg, a szerver összeomlik. Ezt meg kell javítanunk. Kiadunk egy új patch-verziót, és a ClickHouse stabilabbá válik.
Ha a ClickHouse a termelésben fut, és megjelenik egy új ClickHouse verzió további funkciókkal — például a 20.4.1 — az első napon ne siettesd annak bevezetését a termelésbe. Miért is lenne rá szükséged? Ha még nem használod a ClickHouse-t, akkor telepítheted, és valószínűleg minden rendben lesz. De ha a ClickHouse már stabilan működik, akkor ügyelj a patch-kiadásokra és frissítésekre — milyen problémákat javítunk.
Kirill Shvakov: Szeretném kiegészíteni egy kicsit a tesztkörnyezetekről. Mindenki nagyon fél a tesztkörnyezetektől, és valamiért azt hiszik, hogy ha van egy nagy ClickHouse klasztered, akkor a tesztkörnyezetnek is ugyanolyan nagynak kell lennie, vagy legalább tízszer kisebbnek. Ez egyáltalán nem így van.
A saját példámból tudok beszélni. Van egy projektem, amiben van ClickHouse. A tesztkörnyezetünk — ami ehhez a projekthez tartozik — egy kis virtuális gép a Hetzner-nél húsz euróért, ahol mindent elindítottunk. Ehhez teljes automatizációval rendelkezünk Ansible-ben, ezért alapvetően mindegy, hogy fizikailag hova telepítjük — vas szerverekre vagy egyszerűen virtuális gépekre.
Mit lehet tenni? Jó lenne, ha a ClickHouse dokumentációjában lenne példa arról, hogyan lehet magunknak kis klasztert létrehozni - Dockerben, LXC-ben, esetleg elkészíteni egy Ansible playbookot, mert különböző embereknek eltérő telepítéseik vannak. Ez sokat leegyszerűsítene. Amikor az ember öt perc alatt felállít egy klasztert, sokkal könnyebb valamiben elmerülni. Így sokkal kényelmesebb, mert a termelési verziót üzembe állítani, amit nem ellenőriztél - az egy vakvágány. Néha működik, néha pedig nem. Ezért reménykedni a sikerben - rossz dolog.
Maxim Kotyakov, senior backend engineer, Avito: Kicsit kiegészítem a nagyvállalatok problémáira vonatkozó tesztkörnyezetekről. Van egy teljes értékű ClickHouse elfogadó klaszterünk, amely az adatmodellek és beállítások tekintetében pontos másolata a termelési környezetnek. Ez a klaszter meglehetősen gyenge tartályokban van telepítve, minimális erőforrásokkal. Oda a termelési adatok egy bizonyos százalékát írjuk, hála a Kafka áramlás replika lehetőségének. Ott minden szinkronizálva van és skálázva – mind kapacitásban, mind áramlásban, és elméletileg, más egyenlő feltételek mellett, a metrikák szerint úgy kell működnie, mint a termelési környezet. Minden potenciálisan robbanásveszélyes először erre a standra kerül, és ott néhány napig érlelődik a készenlétig. De természetesen ez a megoldás drága, nehéz, és nem elhanyagolható karbantartási költségekkel jár.
Alexej Milovidov: Elmondom, mit képvisel a tesztkörnyezetünk barátaink, a »Yandex.Metrics« részéről. Az egyik klaszter több mint 600 szerverből állt, a másik 360-ból, van egy harmadik és több klaszter is. Az egyik tesztkörnyezet egyszerűen két shard-ból áll, mindegyikben két replikával. Miért két shard? Hogy ne csak egy legyen. És a replikák is legyenek. Csak egy minimális mennyiség, amit meg lehet engedni magunknak.
Ez a tesztkörnyezet lehetővé teszi a lekérdezések működésének ellenőrzését, és nem történt-e valamilyen komoly hiba. De gyakran problémák más jellegűek merülnek fel, amikor minden működik, de vannak kisebb változások a terhelésben.
Példát hozok. Új ClickHouse verziót kívántunk telepíteni. Ezt a tesztkörnyezetre helyeztük, az automatizált tesztek lefutottak a »Yandex.Metrics«-ben, amelyek összehasonlítják az adatokat a régi verzióban és az újban, miközben végigfuttatják az egész csővezetéket. És természetesen a CI-nk zöld tesztjei is. Ellenkező esetben ezt a verziót nem is ajánlottuk volna.
Minden rendben van. Kezdjük el a termelésbe állítást. Üzenetet kapok, hogy a grafikonokon a terhelés többszörösére nőtt. Visszaállítjuk a verziót. Rámegyek a grafikonra, és látom: a terhelés valóban többszörösére nőtt a kiadáskor, majd visszaesett, amikor kiadták. Aztán elkezdjük visszaállítani a verziót. A terhelés ugyanúgy megnőtt és pontosan ugyanúgy visszaesett. Tehát a következtetés az, hogy a terhelés a kiadás miatt nőtt, ami nem meglepő.
Tovább már nehéz volt meggyőzni a kollégákat, hogy mégis telepítsék az új verziót. Azt mondom: "Minden rendben van, állítsátok be. Tartsatok ki, minden rendben lesz. Jelenleg a grafikonokon nőtt a terhelés, de ez normális. Tartsatok ki." Összességében ezt csináltuk, és minden — a verzió ki lett adva a termelésbe. De majdnem minden kiadáskor hasonló problémák merülnek fel.
A Kill query-nek meg kellene ölnie a lekérdezéseket, de nem teszi. Miért?
Egy felhasználó, egyfajta elemző, keresett meg, és létrehozott egy bizonyos lekérdezést, amely leállította a ClickHouse klaszteremet. Valamelyik node-ot vagy akár az egész klasztert — attól függően, hogy melyik replikába vagy shardba került a lekérdezés. Látom, hogy minden CPU-erőforrás ezen a szerveren lefulladt, minden piros. Eközben a ClickHouse a lekérdezésekre válaszol. Azt írom: "Kérlek, mutasd meg a process list-et, melyik lekérdezés okozta ezt a zűrzavart."
Megtalálom ezt a lekérdezést, és írok neki kill-t. És látom, hogy semmi nem történik. A szerverem leállt, a ClickHouse továbbra is ad nekem különböző parancsokat, mutatja, hogy a szerver él, és minden rendben van. De nekem gyengülés van az összes felhasználói lekérdezésben, elkezdődik a gyengülés a ClickHouse-ba íráskor, és az én kill query-m nem működik. Miért? Azt hittem, hogy a kill query-nek meg kellene ölnie a lekérdezéseket, de ez nem történik meg.
Most egy meglehetősen furcsa válasz következik. Az a helyzet, hogy a kill query nem öl meg lekérdezéseket.
A kill query egy kis jelzőt állít be, amelynek neve: "szeretném, ha ezt a lekérdezést megölnék". A lekérdezés a feldolgozás során minden blokkban ránéz erre a jelzőre. Ha be van állítva, a lekérdezés leállítja a működését. Tehát senki sem öli meg a lekérdezést, neki magának kell mindent ellenőriznie és leállnia. Ennek minden esetben működnie kell, amikor a lekérdezés adathalmozási állapotban van. Feldolgozza a következő adatblokkot, ellenőrzi a jelzőt, és leáll.
Ez nem működik olyan esetekben, ha a kérés blokkolva van valamilyen műveletre. Igaz, valószínűleg nem ez az ön esete, mert a szavai szerint rengeteg szervererőforrást használ. Lehet, hogy ez nem működik külső rendezés esetén és még néhány részletben. De összességében ennek nem szabadna megtörténnie, ez egy hiba. Az egyetlen tanács, amit adni tudok, az az, hogy frissítse a ClickHouse-t.
Hogyan lehet kiszámítani a válaszidőt olvasási terhelés esetén?
Van egy táblázat, amelyben aggregált adatok vannak a tételekről - különböző számlálók. A sorok száma körülbelül száz millió. Számíthatunk előrejelezhető válaszidőre, ha 1K RPS-t engedünk be 1K tételre?
A kontextusból ítélve olvasási terhelésről van szó, mert írás esetén nincsenek problémák - akár ezer, akár százezer, sőt néha több millió sort is be lehet illeszteni.
Az olvasási lekérdezések nagyon különbözőek lehetnek. A select 1 üzenetben a ClickHouse körülbelül tízezer lekérdezést tud végrehajtani másodpercenként, ezért még az egy kulcsra vonatkozó lekérdezések is némi erőforrást igényelnek. Az ilyen pontszerű lekérdezések bonyolultabbak, mint bármely kulcs-érték adatbázisban, mert minden olvasás esetén egy adatblokkot kell olvasni az index szerint. Az index nem minden egyes bejegyzést, hanem minden egyes tartományt címkéz. Tehát meg kell olvasni az egész tartományt - ez alapértelmezés szerint 8192 sor. És a tömörített adatblokkot 64 Kb-ról 1 Mb-ra kell kibővíteni. Általában az ilyen pontszerű lekérdezések néhány milliszekundumtól terjednek. De ez a legegyszerűbb eset.
Próbáljunk meg egyszerű aritmetikát végezni. Ha néhány milliszekundumot ezerszer megszorozunk, néhány másodpercet kapunk. Mintha nem lehetne ezer lekérdést másodpercenként kezelni, de valójában lehet, mert több processzormagunk van. Tehát elméletben a ClickHouse néha elbír ezer RPS-zel, de rövid lekérdezések esetében, kifejezetten pontszerűeknél.
Ha a ClickHouse klasztert szeretnénk skálázni az egyszerű lekérdezések mennyisége alapján, akkor a legegyszerűbbet javaslom - növelje meg a replikák számát, és küldje a lekérdéseket véletlenszerű replikákra. Ha az egyik replika akár ötszáz lekérdést is tud kezelni másodpercenként, ami teljesen reális, akkor három replika másfél ezer lekérdést fog tudni kezelni.
Néha persze a ClickHouse-t is be lehet állítani a legnagyobb számú pontszerű olvasásra. Ehhez mi szükséges? Először is — csökkenteni kell az index granularitását. Ezt azonban nem egyesekre, hanem figyelembe véve kell csökkenteni, hogy az indexben lévő bejegyzések száma több millió vagy akár tízmillió legyen a szerveren. Ha a táblázatban százmillió sor van, akkor a granularitás beállítható 64-re.
Csökkenteni lehet a tömörített blokk méretét. Ehhez vannak beállítások min compress block size, max compress block size. Ezeket csökkenthetjük, áthelyezhetjük az adatokat, és akkor a pontszerű lekérdezések gyorsabbak lesznek. De a ClickHouse még mindig nem egy key-value adatbázis. Nagy számú kis lekérdezés — ez egy anti-mintázat a terhelésre.
Kirill Shvakov: Adok egy tippet, ha ott normál számlálók vannak. Ez egy elég standard helyzet, amikor a ClickHouse-ban valamilyen számlálót tárolnak. Van egy felhasználóm, aki innen-onnan jött, meg egy harmadik mező, és valamit inkrementálisan kell növelni. Használj MySQL-t, csinálj egy egyedi kulcsot — MySQL-ben az duplikált kulcs, PostgreSQL-ben pedig konfliktus — és pluszként hozzáadod. Ez sokkal jobban fog működni.
Amikor kevesebb adata van, a ClickHouse használata különösen értelmetlen. Vannak hagyományos adatbázisok, és ezek jól kezelik ezt.
Mit érdemes finomítani a ClickHouse-ban, hogy több adat legyen a cache-ben?
Képzeljünk el egy helyzetet — a szervereken 256 GB RAM van, a napi rutinban a ClickHouse körülbelül 60-80 GB-ot használ, csúcsidőben pedig akár 130-ig is. Mit lehet aktiválni és finomhangolni, hogy több adat legyen a cache-ben, és így kevesebb legyen a lemezre való hozzáférés?
Általában a rendszer operációs rendszerének page cache-je jól kezeli ezt a feladatot. Ha egyszerűen megnyitod a top parancsot, és megnézed a cached vagy free értékeket — az is ki van írva, mennyi van cache-elve — láthatod, hogy az összes szabad memória a cache-re van fordítva. Ezeket az adatokat olvasáskor nem a lemezről, hanem a RAM-ból olvassák. Ezen kívül elmondhatom, hogy a cache hatékonyan használódik, mert éppen a tömörített adatokat cache-eli.
Ennek ellenére, ha szeretnéd még gyorsabbá tenni egyes egyszerű lekérdezéseket, van lehetőség a ClickHouse-on belüli cache aktiválására a kinyomtatott adatokban. Ezt úgy hívják, uncompressed cacheA config.xml fájlban beállíthatja az uncompressed cache size-ot a kívánt értékre – javaslom, hogy ne haladja meg a szabad RAM felét, mert a többi a page cache-re fog menni.
Ezen kívül két kérés szintű beállítás van. Az első beállítás – use uncompressed cache – a használatát aktiválja. Azt javaslom, hogy minden kéréshez kapcsolja be, kivéve a nehezeket, amelyek az összes adatot elolvashatják, és így kiüríthetik ezt a cache-t. A második beállítás pedig valami olyasmi, mint a maximális sorok száma a cache használatához. Ez automatikusan korlátozza a nagy lekérdezéseket, hogy azok kikerüljék a cache-t.
Hogyan lehet beállítani a storage_configuration-t a RAM-ban való tároláshoz?
Az új ClickHouse dokumentációban találtam egy részt, amely -ról szól. A leírásban van egy példa gyors SSD-vel.
Érdekes, hogy hogyan lehet ugyanezt beállítani a volume hot memory-val. És még egy kérdés. Hogyan működik a select ezzel az adatstruktúrával, fogja-e olvasni az összes adatot, vagy csak azt, ami a lemezen van, és komprimálódnak-e ezek az adatok a memóriában? És hogyan működik a prewhere szakasz ezen adatstruktúrák mellett?
Ez a beállítás befolyásolja az adathalmazonkénti tárolást, és a formátumuk semmilyen módon nem változik.
Nézzük meg részletesebben.
Lehetőség van az adatok tárolásának beállítására a RAM-ban. Minden, ami a lemezhez van konfigurálva – az az útvonal. Létrehoz egy tmpfs partíciót, amely egy adott úton van beágyazva a fájlrendszerbe. Ezt az utat megadja az adatainak tárolására a legforróbb partíció számára, ahová a darabok elkezdenek beérkezni és fel lesznek írva, minden rendben.
De nem javaslom ezt a gyenge megbízhatóság miatt, bár, ha legalább három replikája van különböző adatközpontokban, akkor az lehetséges. Ha kialakul a helyzet, elérhetőek lesznek az adatok. Képzeljük el, hogy a szerver hirtelen leállt, majd újra bekapcsolták. A partíció újra be lett mountolva, de ott üresség van. A ClickHouse szerver indításkor látja, hogy ezek a darabok hiányoznak, noha a ZooKeeper metaadatok szerint létezniük kellene. Megnézi, mely replikákon vannak, lekérdezi őket, és letölti. Így az adatok helyreállításra kerülnek.
Ebben az értelemben az adatok tárolása a RAM-ban alapjaiban nem különbözik a lemezen való tárolástól, mert az adatok lemezre írásakor azok is először a page cache-be kerülnek, és fizikailag késleltetve íródnak fel. Ez a fájlrendszer csatolásának módjától függ. De mindenesetre megemlítem, hogy a ClickHouse nem hajt végre fsync-et insert során.
Eközben az adatok a RAM-ban pontosan ugyanabban a formátumban kerülnek tárolásra, mint a lemezen. A select lekérdezés ugyanolyan módon választja ki az olvasandó darabokat, kiválasztja a szükséges adataintervalumokat, és elolvassa azokat. A prewhere teljesen ugyanúgy működik, függetlenül attól, hogy az adatok a RAM-ban vagy a lemezen voltak.
Meddig hatékony a Low Cardinality egyedi értékek számának tekintetében?
A Low Cardinality ügyesen van megoldva. Adattárakat alkot, de ezek helyi jellegűek. Egyrészt minden darabhoz saját adattár van, másrészt még egy darabon belül is eltérhetnek az egyes intervallumok. Amikor az egyedi értékek száma eléri a határértéket - véleményem szerint egy milliót - az adattár egyszerűen lemondásra kerül, és egy új jön létre.
A válasz összességében: minden helyi intervallum számára - mondjuk, minden egyes napra - körülbelül egymillió egyedi értéknél a Low Cardinality hatékony. Ezután egyszerű fallback történik, ahol sok különböző adattárat használnak, nem egyet. Működni fog úgy, mint egy szokásos string típusú oszlop, talán kicsit kevésbé hatékonyan, de jelentős teljesítményromlás nem fog bekövetkezni.
Mik a legjobb gyakorlatok az öt milliárd soros táblák teljes szöveg keresésére?
Különböző válaszlehetőségek léteznek. Az első - mondani, hogy a ClickHouse nem egy teljes szövegkereső rendszer. Erre vannak speciális rendszerek, például, és . Mindazonáltal egyre gyakrabban találkozom olyan emberekkel, akik azt mondják, hogy az Elasticsearch-ról a ClickHouse-ra váltanak.
Miért történik ez? Azzal magyarázzák, hogy az Elasticsearch bizonyos mennyiségeknél már nem tud megbirkózni a terheléssel, kezdve az indexek építésével. Az indexek túl terjengősek lesznek, és ha az adatokat egyszerűen átrakom ClickHouse-ba, akkor az sokkal hatékonyabban tárolódik volumene alapján. Eközben a keresési lekérdezések gyakran nem arról szóltak, hogy az összes adat között egy frázist találjunk a morfológiai figyelembevételével, hanem teljesen másról. Például az utolsó néhány óra logjaiban keresni valamilyen byte-al subsequence szerint.
Ebben az esetben a ClickHouse-ban olyan indexet hoz létre, amelynek első mezője a dátum időponttal. A legnagyobb adatmennyiség kizárólag a dátumtartomány alapján lesz szűrve. Az kiválasztott dátumtartományon belül általában már elvégezhető a teljes szöveges keresés akár brute force módszerrel is a like segítségével. A like operátor a ClickHouse-ban a legjobb like operátor, amit találhat. Ha talál jobbat, kérem, szóljon nekem.
De a like mindenképpen full scan. A full scan nemcsak CPU szempontjából lehet lassú, hanem lemez szempontjából is. Ha például naponta egy terabyte adat van, és Ön naponta keres egy szót, akkor le kell szkennelnie egy terabyte-ot. Valószínűleg normál merevlemezek vannak, és végül annyira leterheltek lesznek, hogy nem tud bejelentkezni erre a szerverre SSH-n.
Ebben az esetben hajlandó vagyok felajánlani még egy kis trükköt. Ez kísérleti jellegű – lehet, hogy működik, lehet, hogy nem. A ClickHouse-ban vannak teljes szöveges indexek trigram Bloom-szűrő formájában. Az Arenadata kollégái már kipróbálták ezeket az indexeket, és gyakran pontosan úgy működnek, ahogy kellene.
Ahhoz, hogy helyesen használhassa őket, jól kell értenie, hogy pontosan hogyan működnek: mit jelent a trigram Bloom-szűrő és hogyan válassza ki a méretét. Mondhatom, hogy ezek segítenek ritka kifejezések, al- vagy részszavak lekérdezésekor, amelyek ritkán fordulnak elő az adatokban. Ebben az esetben az indexek révén al-tartományok lesznek kiválasztva, és kevesebb adatot kell olvasni.
Nemrégiben a ClickHouse-ban még fejlettebb funkciók jelentek meg a teljes szöveges kereséshez. Először is a rengeteg al-sztring keresése egy átjáráson belül, beleértve a kis- és nagybetűk figyelembevételét, a kis- és nagybetűk figyelmen kívül hagyását, a UTF-8 támogatással vagy csak ASCII-ra korlátozva. Válassza ki a legmegfelelőbbet, amire szüksége van.
Megjelent több reguláris kifejezés keresése egy átjáráson belül is. Nem kell írnia, hogy X like egy al-sztring, vagy X like egy másik al-sztring. Egyszerűen írja be, és mindez maximálisan hatékonyan végrehajtódik.
Harmadszor – most van hozzáférhető reguláris kifejezések és al-sztringek közelítő keresése. Ha valaki elgépelte a szót, akkor az a legnagyobb megfelelés alapján lesz keresve.
Hogyan érdemes megszervezni a ClickHouse-hoz való hozzáférést sok felhasználó számára?
Mesélje el, hogyan lehet a legjobban megszervezni a hozzáférést egy nagy számú felhasználó és elemző számára. Hogyan lehet sorba állítani, priorizálni a kéréseket max párhuzamos lekérdezés, és milyen eszközökkel?
Ha a klaszter elég nagy, akkor jó megoldás lehet még két szerver felállítása, amelyek belépési pontként szolgálnak az elemzők számára. Tehát nem engedjük be az elemzőket a klaszter specifikus shardjaira, hanem egyszerűen létrehozunk két üres szervert, adatok nélkül, és ott beállítjuk a hozzáférési jogokat. E közben a felhasználói beállítások a megosztott lekérdezések során távoli szerverekre kerülnek. Tehát mindent ezeken a két szerveren konfigurálsz, és a beállítások hatással vannak az egész klaszterre.
Elvileg ezek a szerverek adatok nélkül vannak, de a RAM mérete nagyon fontos a lekérdezések végrehajtásához. A lemez szintén használható ideiglenes adatokhoz, ha külső aggregáció vagy külső rendezés van engedélyezve.
Fontos megnézni az összes lehetséges korlátozással kapcsolatos beállítást. Ha most belépek a "Yandex.Metrics" klaszterbe elemzőként és lekérdezést adok meg select count from hits, akkor azonnal kivételt kapok, hogy a lekérdezést nem tudom végrehajtani. A maximális számú sor, amit átfoghatok, száz milliárd, és a klaszterben összesen ötven trillió van egy táblázatban. Ez az első korlátozás.
Tegyük fel, hogy eltávolítom a sorok számára vonatkozó korlátozást, és újra végrehajtom a lekérdezést. Akkor a következő kivételt fogom látni - engedélyezve van a beállítás force index by date. Nem tudom végrehajtani a lekérdezést, ha nem adtam meg az időtartamot. Ne számíts arra, hogy az elemzők ezt manuálisan fogják megadni. A tipikus eset az, amikor meg van írva az időintervallum where event date between hét. Aztán csak nem a megfelelő helyen adták meg a zárójelet, és az and helyett or lett - or URL match. Ha nincs korlátozás, elkezdheti átvizsgálni az URL oszlopot, és egyszerűen rengeteg erőforrást pazarol el.
Ráadásul a ClickHouse-ban van két prioritásbeállítás. Sajnos nagyon primitívek. Az egyiket egyszerűen úgy hívják, hogy priorityHa a priority ≠ 0, és valamilyen prioritással rendelkező kérések futnak, de ugyanakkor egy alacsonyabb prioritású kérés fut, ami egy magasabb prioritást jelent, akkor a nagyobb prioritású kérés, ami alacsonyabb prioritást jelent, egyszerűen felfüggesztésre kerül, és egyáltalán nem fog működni ebben az időben.
Ez egy nagyon durva beállítás, és nem alkalmas olyan esetekre, amikor a klaszter folyamatos terhelés alatt áll. De ha rövid, impulzusos kérések fontosak, és a klaszter főként tétlen, ez a beállítás megfelelő lehet.
A következő prioritási beállítás OS szál prioritás. Ez egyszerűen beállítja az összes kérés végrehajtási szál fürkészője fürkészőjének nice értékét a Linuxban. Így-úgy működik, de mégis működik. Ha a legkisebb nice értéket állítjuk be - ami a legnagyobb számérték, így a legalacsonyabb prioritás - és a magas prioritású kéréseknek -19-et állítunk be, akkor a CPU körülbelül négyszer kevesebb alacsony prioritású kérést fog fogyasztani, mint a magas prioritásúakat.
Be kell állítani a maximális kérésidőt is - mondjuk öt percet. A kérés minimális végrehajtási sebessége - ez a legkeményebb. Ez a beállítás régóta létezik, és szükséges, hogy ne csak azt állítsuk, hogy a ClickHouse nem lassú, hanem hogy ezt érvényesítsük.
Képzelje el, hogy beállítja: ha egy kérés másodpercenként kevesebb mint egymillió sort dolgoz fel - ezt nem szabad csinálni. Ez szégyent hoz a jó nevünkre, a jó adatbázisunkra. Egyszerűen tiltsuk meg. Ott valójában két beállítás van. Az egyik a min.execution.speed - másodpercenként sorokban, a másik pedig a timeout before checking min execution speed - alapértelmezett időtartama tizenöt másodperc. Tehát tizenöt másodperc rendben van, de utána, ha lassú, akkor egyszerűen dobjon kivételt - szakítsa meg a kérést.
Be kell állítani a kvótákat is. A ClickHouse beépített kvótákat kínál, amelyek a forrásfelhasználást számolják. De sajnos nem fémforrások, mint a CPU, merevlemezek, hanem logikai források - a feldolgozott kérések, sorok és olvasott byte-ok száma. Például be lehet állítani maximum száz kérdést öt perc alatt és ezer kérdést óránként.
Miért fontos ez? Mert a részben a ClickHouse kliensből manuálisan végrehajtott analitikai lekérések fognak történni. Minden rendben lesz. De ha a cégedben fejlett elemzők vannak, ők írni fognak egy szkriptet, és a szkriptben lehet hiba. Ez a hiba oda vezet, hogy a lekérés végtelen ciklusban fog végrehajtódni. Ezt kell megvédeni.
Lehet-e egy kérdés eredményeit tíz kliensnek átadni?
Néhány felhasználónk van, akik szeretnek nagyon nagy lekérésekkel érkezni ugyanabban az időben. A lekérés nagy, alapvetően gyorsan fut, de mivel egyszerre sok ilyen lekérés van, ez nagyon fájdalmassá válik. Meg lehet-e valósítani, hogy ugyanazt a lekérést, amely tízszer érkezett, egyszer futtassuk, és az eredményét tíz kliensnek adjuk át?
A probléma az, hogy nekünk nincsenek meg a cache vagy a közbenső adatok eredményei. Van az operációs rendszer page cache-je, amely lehetővé teszi, hogy ne olvassuk újra az adatokat a lemezen, de sajnos az adatok akkor is ki fognak bontódni, deszerializálódni és újra feldolgozásra kerülni.
Szeretnénk ezt valahogyan elkerülni, akár a közbenső adatok cache-elésével, akár hasonló lekérések egy sorba állításával és az eredmények cache-elésével. Jelenleg van egy pull request, ami a lekérések cache-elését kínálja, de csak az in és join szekciók alt lekéréseihez — tehát a megoldás nem teljes.
Ennek ellenére nálunk is előfordul hasonló helyzet. Különösen a kanonikus példa a lapozással járó lekérések. Van egy jelentés, amelyben több oldal van, és a lekérés limit 10. Aztán ugyanaz, de limit 10,10. Majd következik a következő oldal. Miért számoljuk ezt minden alkalommal? De jelenleg megoldás nincs, és ezt nem lehet elkerülni.
Van egy alternatív megoldás, amely a ClickHouse mellé van telepítve — .
Kirill Shvakov: A ClickHouse Proxy-ban beépített ráta korlátozó és beépített eredmény cache található. Sok beállítást végeztek el, mert egy hasonló problémát oldottak meg. A Proxy képes korlátozni a lekéréseket, sorba állítva őket, és beállítani, hogy mennyi ideig él a lekérések cache-e. Ha a lekérések valóban azonosak voltak, a Proxy sokszor visszaadja őket, miközben a ClickHouse-ba csak egyszer látogat el.
Az Nginx-ben is van cache az ingyenes verzióban, és ez is működni fog. Az Nginx-nek még van beállítása, hogy ha a kérések egyszerre érkeznek, akkor lassítja a másikat, amíg az egyik végrehajtódik. De a ClickHouse Proxy beállítása sokkal jobb. Kifejezetten a ClickHouse-hoz, az ilyen kérésekhez készült, így jobban illeszkedik. És egyszerűen telepíthető.
Mi a teendő az aszinkron műveletekkel és a materializált nézetekkel?
Van egy probléma, hogy a replika motorral végzett műveletek aszinkronok – először az adatok íródnak, majd ezek összeolvadnak. Ha az adott táblázat alatt egy anyagtáblázat él, amelynek vannak aggregált adatai, akkor a duplikátumok be fognak íródni. Ha nincs valamilyen összetett logika, az adatok duplikálva lesznek. Mit lehet ezzel tenni?
Van egy nyilvánvaló megoldás – egy trigger létrehozása egy adott materializált nézet osztályhoz az aszinkron összeolvasztási művelet során. Van bármilyen „ezüst lövedék”, terv ezen funkciók megvalósítására?
Érdemes tisztázni, hogyan működik a deduplikáció. Amit most elmondok, nem tartozik a kérdéshez, de érdemes emlékezni rá.
A replikált táblázatba való beszúráskor teljesen deduplikáltak a beillesztett blokkok. Ha ugyanazt a blokkot másodszor is beillesztette, amely ugyanazon sorok ugyanabban a sorrendben tartalmazza, akkor az adatok deduplikálva lesznek. Az „Ok” választ fog kapni az insert parancsra, de valójában csak egy adathalmozódás lesz rögzítve, és az nem lesz duplikálva.
Erre van szükség a bizonyosság érdekében. Ha a beszúrás során „Ok”-at kapott, akkor az adatai be vannak írva. Ha hibát kapott a ClickHouse-tól, akkor azok nem lettek beírva, és a beszúrást ismételni kell. De ha a beszúrás során megszakadt a kapcsolat, akkor nem tudja, hogy az adatok be lettek-e írva vagy sem. Az egyetlen lehetőség, hogy ismételje meg a beszúrást. Ha az adatok valóban be lettek írva, és őket újra beillesztette, vannak deduplikációs blokkok. Ez szükséges az ütközések elkerülésére.
Fontos továbbá, hogy hogyan működik a materializált nézetek esetében. Ha az adatok deduplikálva lettek a fő táblázatba történő beszúráskor, akkor a materializált nézetbe is eljutnak.
Most kérdésről. Önnek bonyolultabb a helyzete, mert egyes sorok alapján készít duplikációkat. Tehát nem az egész csomag lett duplikálva, hanem konkrét sorok, és ezek a háttérben összeolvadnak. Valóban, az adatok összeolvadnak a fő táblázatban, míg a materializált nézetbe nem összesűrített adatok kerülnek, és a merge műveleteknél nem történik semmi a materializált nézetekkel. Mert a materializált nézet nem más, mint egy trigger az insert eseményhez. Más műveleteknél vele semmi extra nem történik.
Itt sajnos nem tudok örömet okozni. Csak konkrét megoldást kell keresni az esetre. Például, lehet-e a materializált nézetben is megtenni a replace eljárást, és talán a deduplikációs módszer is ugyanúgy működhet. De sajnos, ez nem mindig van így. Ha aggregáló, akkor nem fog működni.
Kirill Shvakov: Nálunk is volt egy kis barkácsolás a régi időkben. Volt egy probléma, hogy vannak reklámmegjelenítések, és vannak bizonyos adatok, amelyeket valós időben tudunk mutatni – ezek csak a megjelenítések. Ezek ritkán duplikálódnak, de ha ez megtörténik, akkor azt később mégis össze fogjuk olvasztani. És voltak olyan dolgok, amelyeket nem lehetett duplikálni – kattintások és az egész történet. De azokat is szinte azonnal meg akartuk mutatni.
Hogyan készültek a materializált nézetek? Volt néhány nézet, ahova közvetlenül írtunk – az nyers adatokra történő írás, és írás a nézetekbe. Ott egy idő után az adatok nem voltak túl pontosak, duplikálódtak stb. És van egy második rész a táblázatnak, ahol pontosan ugyanúgy néznek ki, mint a materializált nézetek, tehát a struktúrájuk teljesen azonos. Egy bizonyos időnként újraszámoljuk az adatokat, számláljuk azokat deduplikáltan, és írás a táblákba.
API-n keresztül jártunk el – a ClickHouse-on manuálisan ez nem fog működni. Az API nézi: amikor van egy utolsó hozzáadás dátuma a táblázatban, ahol garantáltan már pontos adatok találhatók, és kérdést intéz egy táblázathoz és a másikhoz. Az egyik lekérdezés választ ki egy meghatározott időintervallumig, a másiktól pedig hozzáválasztja azt, ami még nem lett számolva. Ez működik, de nem egyedül a ClickHouse eszközeivel.
Ha van API-a, például az elemzőknek, a felhasználóknak, akkor ez alapvetően egy lehetőség. Mindig újraszámlál, mindig számolsz. Ezt napi egyszer vagy más időpontban is megteheted. Te választod meg, hogy milyen időtartományt szeretnél, ami számodra nem szükséges és nem kritikus.
A ClickHouse-ban sok napló van. Hogyan láthatom mindazt, ami a szerverrel történik, valós időben?
A ClickHouse-nak nagyon sokféle naplója van, és ez a szám folyamatosan növekszik. Az új verziókban közülük néhány már alapértelmezés szerint be van kapcsolva, a régebbi verziókban pedig frissítéskor kell őket aktiválni. Ennek ellenére egyre több van belőlük. Szeretném látni a végén, hogy mi történik most velem a szerverrel, esetleg valamilyen összegző irányítópulton.
Nincs a csapatodban ClickHouse, vagy a barátaitok csapataiban olyan, akik keresztül már kész irányítópultokkal támogatnak, amelyek ezeknek a naplóknak a megjelenítésére készen állnak? Végső soron, csak úgy nézni a naplókat a ClickHouse-ban nagyszerű. De nagyon klassz lenne, ha ez már kész irányítópult formájában lenne. Ebből jó érzésem lenne.
Vannak irányítópultok, igaz, nem standardizáltak. A cégünknél körülbelül 60 csapat használja a ClickHouse-t, és a legfurcsább az, hogy sokuknak saját irányítópultjaik vannak, és azok egy kicsit eltérnek egymástól. Néhány csapat a Yandex.Cloud belső telepítését használja. Ott van néhány kész jelentés, bár nem minden szükséges. Másoknak a saját megoldásaik vannak.
A "Metrika" kollégáimnak van egy saját irányítópultja a Grafana-ban,nekem pedig van egy sajátom az ő klaszterükhöz. Ott nézek olyan dolgokat, mint a cache hit a kiemelés gyorsítótárához. És még bonyolultabb az, hogy különböző eszközöket használunk. A saját irányítópultomat egy nagyon régi eszközzel készítettem, ami Graphite-webnek hívják. Teljesen csúnyácska. És még most is ezt használom, bár a Grafana valószínűleg kényelmesebb és szebb lenne.
A dashboard's basic aspect is the same. These are system metrics for the cluster: CPU, memory, disk, network. Others include the number of concurrent requests, the number of concurrent merges, the number of requests per second, the maximum number of parts for MergeTree table partitions, replication lag, the size of the replication queue, the number of rows inserted per second, and the number of blocks inserted per second. This is all obtained from metrics, not logs.
Vlagyimir Kolobaev: Alexey, I would like to make a minor adjustment. There's Grafana. Grafana has a datasource, which is ClickHouse. This means I can make queries directly to ClickHouse from Grafana. ClickHouse has a table with logs, which is the same for everyone. I want to refer to this logs table in Grafana to see the requests my server makes. It would be great to have such a dashboard.
I created it myself. But I have a question—if everything is standardized and Grafana is used by everyone, why isn't there such an official dashboard in Yandex?
Kirill Shvakov: In fact, the datasource that connects to ClickHouse is currently supported by Altinity. And I just want to provide a direction for digging and pushing. You can ask them, because Yandex develops ClickHouse, not the ecosystem around it. Altinity is the main company currently promoting ClickHouse. They are not going to abandon it; they will continue to support it. Because, in principle, to upload a dashboard to the Grafana site, you just need to register and upload it—there are no particular issues.
Alexej Milovidov: In the past year, many profiling features have been added to ClickHouse. There are metrics for each query regarding resource usage. Recently, an even lower-level query profiler was added to see where each query spends every millisecond. But to use this functionality, I have to open the console client and type the query that I constantly forget. I saved it somewhere and I constantly forget where.
Azt szeretném, ha lenne egy eszköz, ami egyszerűen azt mutatja, hogy itt vannak a nehéz lekérdezések, csoportosítva a lekérdezés típusok szerint. Kattintsak valamire, és azt mondják, hogy ez nehéz ezért. Jelenleg nincs ilyen megoldás. És valóban elég furcsa, hogy amikor az emberek megkérdeznek: "Mondja, van valamilyen kész dashboard a Grafanához?", azt mondom: "Lépj a Grafana webhelyére, ott van a közösség 'Dashboardok', és ott van egy dashboard Dimkótól, van egy dashboard Kostyától. Mi ez, azt nem tudom, én nem használtam."
Hogyan lehet hatni a merge-ekre, hogy a szerver ne essen OOM állapotba?
Van egy táblázatom, amely csak egy partíciót tartalmaz, ez ReplacingMergeTree. Négy éve írom bele az adatokat. Kellett volna létrehoznom egy alternatívát, és törölnöm kellett volna néhány adatot.
Megtettem ezt, és a kérés feldolgozása során az összes szerver memóriája a klaszterben elfogyott, és a klaszter összes szervere egyszerre esett OOM állapotba. Aztán mindannyian felálltak, elkezdték végrehajtani a merge-t ugyanazon művelet, ezen adathalmazon, és újra OOM-ba estek. Aztán újra felálltak és újra estek. Ez a helyzet nem állt meg.
Aztán kiderült, hogy ez valójában egy hiba volt, amit a srácok javítottak. Ez nagyon jó, köszönöm szépen. De a keserű íz megmaradt. Most, amikor arra gondolok, hogy valamilyen merge-t kellene végeznem a táblázatban, mindig felmerül a kérdés – miért nem tudom valamilyen módon befolyásolni ezeket a merge-eket? Például korlátozni őket az igényelt memória mennyisége, vagy általában a számuk szerint, ami konkrétan ezt a táblázatot fogja feldolgozni.
Van egy táblázatom, ami „Metrikák” néven ismert, kérlek dolgozz fel engem kettő szálon. Ne hozz létre tíz vagy öt párhuzamos merge-t, csinálj kettőt. Azt gondolom, hogy kettőre elegendő lesz a memóriám, de lehet, hogy tíz feldolgozásához nem lesz elegendő. Miért marad a félelem? Mert a táblázat növekszik, és egyszer csak szembesülni fogok azzal a helyzettel, hogy nem is hiba miatt, hanem azért, mert az adatok olyan nagy mennyiségben fognak változni, hogy egyszerűen nem lesz elég memória a szerveren. És akkor a szerver OOM-ba fog esni a merge alatt. A mutációt vissza tudom vonni, de a merge-eket már nem.
Tudja, a merge során a szerver nem fog OOM-ba esni, mert a merge során a memóriát csak egy kis adathalmazon használja. Szóval minden rendben lesz, függetlenül az adatok mennyiségétől.
Vlagyimir Kolobaev: Rendben. Itt egy dolog van, hogy miután elvégeztem a hibajavítást, letöltöttem az új verziót, és egy másik, kisebb táblán, ahol sok partíció van, hasonló műveletet végeztem. A merge során a szerveren körülbelül 100 GB RAM-ot használt el. 150 GB volt foglalva, 100-at elfogyasztott, és maradt 50 GB szabad, így nem estem OOM-ba.
Mi véd meg most attól, hogy OOM-ba essek, ha tényleg 100 GB RAM-ot fogyaszt? Mi a teendő, ha véletlenül a RAM elfogy a merge alatt?
Alexej Milovidov: Igen, van az a probléma, hogy a RAM-felhasználás a merge-ek során nem korlátozódik. A második probléma pedig az, hogy ha egy merge ki van jelölve, azt el kell végezni, mert ez fel van írva a replikációs naplóba. A replikációs napló az a művelet, amely szükséges ahhoz, hogy a replikációt konzisztens állapotba hozza. Ha nem hajtunk végre manuális műveleteket, amelyek visszaállítják a replikációs naplót, a merge-t, úgy vagy úgy, el kell végezni.
Természetesen nem ártana egy RAM-korlátozás, ami "minden esetre" véd OOM ellen. Ez nem segít a merge végrehajtásában, újra el fog kezdődni, eljut egy küszöbig, kivételt fog dobni, majd újra elindulni - ebből nem lesz jó. De elvileg hasznos lenne ezt bevezetni.
Hogyan fog zajlani a Golang-illesztőprogram fejlesztése a ClickHouse-hoz?
A Golang-illesztőprogramot, amelyet Kirill Shvakov írt, most hivatalosan úgy tűnik, hogy a ClickHouse csapata támogatja. Ő , most már nagy és igazi.
Egy kis megjegyzés. Van egy csodálatos és mindenki által kedvelt tároló, amely a végtelen rend normális formáit biztosítja — ez a Vertica. Van saját hivatalos python-illesztőjük is, amelyet a Vertica fejlesztői támogatnak. És volt már olyan eset, amikor a tárolóverziók és az illesztőverziók nagyon eltértek egymástól, így az illesztő egy idő után leállt. A másik dolog pedig, hogy ennek a hivatalos illesztőnek a támogatása úgy tűnik, a „kötőelem” rendszerén keresztül történik — írsz nekik egy problémát, és az örökké ott lóg.
Két kérdésem van. Jelenleg Kirill Golang-illesztője szinte az alapértelmezett módja a Golang és a ClickHouse közötti kommunikációnak. Csak aki még mindig http interfészen keresztül kommunikál, mert úgy tetszik neki. Hogyan fog történni ennek az illesztőnek a fejlesztése? Szinkronizálni fogják-e valamilyen éles változással a tárolón belül? És mi a beadás menete?
Kirill Shvakov: Először is, hogyan működik ez bürokratikusan. Ezt a kérdést nem vitattuk meg, így válaszolni nem tudok.
Ahhoz, hogy válaszoljak a problémával kapcsolatos kérdésre, szükség van egy rövid történetre az illesztőről. Egy olyan cégnél dolgoztam, ahol sok adat volt. Ez egy reklámforgató volt, hatalmas eseményekkel, amelyeket el kellett tárolni valahol. Egy idő után megjelent a ClickHouse. Betöltöttük az adatokat, és egy ideig minden rendben volt, majd a ClickHouse leállt. Ekkor döntöttünk úgy, hogy nem szükséges.
Egy év múlva visszatértünk a ClickHouse használatának ötletéhez, és valahogy adatokat kellett írni oda. A helyzet az volt — a hardver nagyon gyenge, és kevés erőforrás áll rendelkezésre. De mindig így dolgoztunk, ezért a natív protokoll felé néztünk.
Mivel Go-on dolgoztunk, egyértelmű volt, hogy Go-ra van szükségünk egy illesztőre. Szinte teljes munkaidőben dolgoztam rajta — ez volt a munkám feladata. Egy idő után eljutottunk egy szintre, és alapvetően senki sem számított arra, hogy valaki más is használni fogja. Aztán a CloudFlare pontosan ugyanazzal a problémával érkezett, és egy ideig nagyon szoros együttműködésben dolgoztunk, mert nekik is hasonló feladataik voltak. Ráadásul ezt úgy tettük, hogy a ClickHouse-on belül, és magán az illesztőn is.
Valamikor egyszerűen abbahagytam velük való foglalkozást, mert a ClickHouse-szal és a munkámmal kapcsolatos aktivitásom kicsit megváltozott. Ezért nem zárulnak le az ügyek. Időnként olyan emberek commitálnak a repóba, akiknek valami szükségük van. Akkor megnézem a pull request-et, és néha még én is módosítok rajta, de ez ritkán fordul elő.
Vissza szeretnék térni a driverhez. Néhány évvel ezelőtt, amikor ez az egész elkezdődött, a ClickHouse is más volt, más lehetőségekkel. Most már értjük, hogyan lehetne átdolgozni a drivert, hogy jól működjön. Ha ez megtörténik, akkor a 2-es verzió minden esetben inkompatibilis lesz a felhalmozódott workaroundok miatt.
Azt nem tudom, hogyan lehetne ezt megszervezni. Magamnak nincs sok időm. Ha néhány ember dolgozni fog a driveren, akkor tudok segíteni nekik, és elmondani, hogy mit kell tenni. De a „Yandex” aktív részvételét a projekt fejlesztésében egyelőre nem beszéltük meg.
Alexej Milovidov: Valójában eddig semmiféle bürokrácia nincs ezekkel a driverekkel kapcsolatban. Az egyetlen dolog, hogy hivatalos szervezetbe kerültek, tehát ez a driver hivatalosan elismert megoldás a Go számára. Vannak más driverek is, de azok külön futnak.
Bennünket belső fejlesztés nem érint ezekkel a driverekkel kapcsolatban. A kérdés az, hogy tudunk-e felvenni egy külön embert, aki nem csak erre a driverre, hanem minden közösségi driver fejlesztésére fókuszál, vagy tudunk-e találni valakit kívülről.
A külső szótár nem töltődik be újraindítás után, amikor a lazy_load beállítás aktív. Mit lehet tenni?
Nálunk aktív a lazy_load beállítás, és a szerver újraindítása után a szótár automatikusan nem töltődik be. Csak akkor tölti be, amikor a felhasználó hívja meg ezt a szótárat. és az első híváskor hibát jelez. Van valamilyen mód a ClickHouse segítségével a szótárak automatikus betöltésére, vagy mindig nekünk kell kontrolálnunk, hogy készen legyenek, hogy a felhasználók ne kapjanak hibákat?
Lehet, hogy régi verziója van a ClickHouse-nak, ezért a szótár automatikusan nem töltődött be. Történhet ilyen?
Először is, a szótárakat kényszerített módon be lehet tölteni a következő lekérdezéssel: system reload dictionaries. Másodszor, a hiba kapcsán – ha a szótár már be volt töltve, akkor a lekérdezések azokkal az adatokkal működnek, amelyek már be lettek töltve. Ha a szótár még nem lett betöltve, akkor a lekérdezés ideje alatt fog betöltődni.
Nehéz szótárak számára ez nem igazán kényelmes. Például, ha egy millió sort kell lehívni a MySQL-ből. Valaki egyszerű selectet végez, de ez a select várni fog arra a bizonyos millió sorra. Itt két megoldás van. Az első - kikapcsolni a lazy_load-ot. A második - amikor a szerver elindul, mielőtt terhelést kapcsolnánk rá, létrehozni system reload dictionary vagy egyszerűen végrehajtani egy lekérdezést, ami használja a szótárat. Akkor a szótár be lesz töltve. Magunknak kell ellenőriznünk a szótárak elérhetőségét, ha a lazy_load be van kapcsolva, mert a ClickHouse automatikusan nem tölti be őket.
A legutolsó kérdésre a válasz - vagy régi a verzió, vagy debugolni kell.
Mi a teendő, ha a system reload dictionaries nem tölti be az összes szótárt, amennyiben legalább egy hiba miatt leáll?
Van még kérdés a system reload dictionaries-ről. Két szótárunk van - az egyik nem töltődik be, a másik betöltődik. A system reload dictionaries ilyen esetben nem tölt be egy szótárat sem, és konkrétan kell betölteni egyet a neve alapján a system reload dictionary segítségével. Ez is összefügg a ClickHouse verziójával?
Örömmel tájékoztatlak. Ez a viselkedés megváltozott. Tehát, ha frissíted a ClickHouse-t, ez is meg fog változni. Ha nem elégedett a jelenlegi viselkedéssel system reload dictionaries, frissítsd, és reméljük, hogy ez a jövőben javulni fog.
Van-e lehetőség a ClickHouse konfigurációs adatok beállítására anélkül, hogy azok hibák esetén megjelennének?
A következő kérdés a szótárral kapcsolatos hibák, nevezetesen a hitelesítő adatokra vonatkozik. A ClickHouse konfigurációs fájljában megadtuk a szótárral való csatlakozás hitelesítő adatait, és hiba esetén ezek a hitelesítő adatok és a jelszó válaszként megérkezik.
Ezt a hibát úgy oldottuk meg, hogy a hitelesítő adatokat az ODBC illesztőprogram konfigurációs fájljába vittük. Van valami mód a hitelesítések konfigurálására a ClickHouse konfigurációs fájljában, de ne hozzuk nyilvánosságra ezeket a hitelesítő adatokat a hibák esetén?
Itt valóban az a megoldás, hogy a hitelesítő adatokat az odbc.ini fájlban adjuk meg, míg a ClickHouse-ban csak az ODBC Data Source Name-t kell megadni. Más forrású szótáraknál ehhez nem lesz ilyen - sem a MySQL szótárhoz, sem másokhoz nem szabad látnod a jelszót a hibajelzésnél. Az ODBC esetében is utánanézek - ha van ilyen, azt egyszerűen el kell távolítani.
Bónusz: háttérképek a Zoomhoz a találkozókból
A képre kattintva a legkitartóbb olvasóknak bónusz háttérképek nyílnak meg a találkozókról. Tűzoltás a Avito technológiáinak kabalaival, megbeszélés a rendszergazda szobájában vagy a régi iskola számítógép klubjában, és napi tevékenység a híd alatt grafiti háttérrel.
Forrás: habr.com
