Mivel a ClickHouse egy speciális rendszer, használatánál fontos figyelembe venni az architektúra jellemzőit. Ebben a jelentésben Alexey a ClickHouse használata során előforduló gyakori hibák példáiról fog beszélni, amelyek eredménytelen munkához vezethetnek. Gyakorlati példák mutatják be, hogy egy vagy másik adatfeldolgozási séma kiválasztása hogyan változtathatja meg a teljesítményt nagyságrendekkel.
Sziasztok! A nevem Alexey, én készítem a ClickHouse-t.
Először is, azonnal sietek a kedvedre, ma nem árulom el, mi az a ClickHouse. Őszintén szólva elegem van belőle. Valahányszor elmondom, mi az. És valószínűleg már mindenki tudja.
Ehelyett elmondom, hogy milyen hibák lehetnek, vagyis hogyan használhatod helytelenül a ClickHouse-t. Valójában nem kell megijedni, mert a ClickHouse-t egyszerű, kényelmes és a dobozból kivehető rendszerként fejlesztjük. Telepítettem, semmi gond.
De még mindig figyelembe kell vennie, hogy ez a rendszer speciális, és könnyen találkozhat egy szokatlan használati esettel, amely kimozdítja ezt a rendszert a komfortzónájából.
Szóval, milyen gereblye van? Leginkább nyilvánvaló dolgokról fogok beszélni. Mindenki számára minden nyilvánvaló, mindenki mindent ért, és örülhet, hogy ilyen okos, aki pedig nem ért, tanul valami újat.
Az első és legegyszerűbb példa, amely sajnos gyakran előfordul, a nagyszámú betét kis tételekkel, azaz nagyszámú kis betét.
Ha figyelembe vesszük, hogy a ClickHouse hogyan hajtja végre a beillesztést, akkor egy kérésben legalább egy terabájt adatot küldhet. Nem probléma.
És lássuk, mi lenne a tipikus teljesítmény. Például van egy táblázatunk a Yandex.Metrica adataiból. Találatok. 105 néhány oszlop. 700 bájt tömörítetlen. És jó módon egymillió soros kötegekben fogunk beszúrni.
Beszúrjuk a MergeTree-t a táblázatba, kiderül, hogy másodpercenként félmillió sor. Nagy. Egy replikált táblázatban ez egy kicsit kisebb lesz, körülbelül 400 000 sor másodpercenként.
És ha engedélyezi a kvórum beszúrását, egy kicsit kevesebb, de még mindig megfelelő teljesítményt kap, másodpercenként 250 000 kifejezést. A kvórum beillesztése a ClickHouse* nem dokumentált funkciója.
* 2020-tól, .
Mi történik, ha valami rosszat teszel? Beszúrunk egy sort a MergeTree táblába, és másodpercenként 59 sort kapunk. Ez 10 000-szer lassabb. A ReplicatedMergeTree-ben – 6 sor másodpercenként. És ha a határozatképesség be van kapcsolva, akkor másodpercenként 2 sor jelenik meg. Véleményem szerint ez valami abszolút baromság. Hogy lehet így lelassítani? Még a pólómra is rá van írva, hogy a ClickHouse ne lassítson. De ennek ellenére néha előfordul.
Valójában ez a mi hiányosságunk. Könnyen csinálhattunk volna mindent jól, de nem tettük. És nem tettük meg, mert a forgatókönyvünk nem követelte meg. Nálunk már volt mészáros. Most kaptuk meg a tételeket a bejáratunknál, és nem volt probléma. Behelyezzük és minden jól működik. De természetesen mindenféle forgatókönyv lehetséges. Például, ha van egy csomó szerver, amelyeken adatok generálódnak. És nem olyan gyakran illesztenek be adatokat, de még mindig gyakori beszúrással végeznek. És ezt valahogy el kell kerülnünk.
Technikai szempontból a lényeg az, hogy amikor a ClickHouse-ban beszúrsz, az adatok nem kerülnek semmilyen memtable-ba. Nincs is igazi MergeTree naplószerkezetünk, hanem csak MergeTree, mert nincs se napló, se memTable. Egyszerűen azonnal beírjuk az adatokat a fájlrendszerbe, már oszlopokba rendezve. És ha 100 oszlopa van, akkor több mint 200 fájlt kell külön könyvtárba írni. Mindez nagyon körülményes.
És felmerül a kérdés: „Hogyan kell jól csinálni?” Ha a helyzet olyan, hogy továbbra is valamilyen módon rögzítenie kell az adatokat a ClickHouse-ban.
1. módszer. Ez a legegyszerűbb módja. Használjon valamilyen elosztott sort. Például Kafka. Egyszerűen kivonja az adatokat a Kafkából, és másodpercenként egyszer kötegeli. És minden rendben lesz, felveszed, minden jól működik.
A hátrányok közé tartozik, hogy a Kafka egy másik terjedelmes elosztott rendszer. Azt is megértem, ha már Kafka van a társaságában. Jó, kényelmes. De ha nem létezik, akkor háromszor gondolkodjon el, mielőtt újabb elosztott rendszert húzna a projektbe. Ezért érdemes alternatívákat fontolóra venni.
2. módszer. Ez egy régimódi alternatíva és egyben nagyon egyszerű. Van valamilyen szervere, ami előállítja a naplókat? És csak a naplóidat írja egy fájlba. És például másodpercenként egyszer átnevezzük ezt a fájlt, és letépünk egy újat. És egy külön szkript, akár cronon keresztül, akár valamilyen démonon keresztül, veszi a legrégebbi fájlt, és beírja a ClickHouse-ba. Ha másodpercenként egyszer rögzíti a naplókat, akkor minden rendben lesz.
De ennek a módszernek az a hátránya, hogy ha valahol eltűnik a szervered, amelyen a naplók generálódnak, akkor az adatok is eltűnnek.
3. módszer. Van egy másik érdekes módszer, amely egyáltalán nem igényel ideiglenes fájlokat. Például van valamilyen hirdetési pörgető vagy más érdekes démon, amely adatokat generál. És egy csomó adatot felhalmozhat közvetlenül a RAM-ban, a pufferben. És ha eltelt elég idő, félreteszed ezt a puffert, létrehozol egy újat, és egy külön szálban beilleszted a ClickHouse-ba, ami már felhalmozódott.
Másrészt kill -9-el az adatok is eltűnnek. Ha a szerver összeomlik, akkor ezek az adatok elvesznek. És egy másik probléma, hogy ha nem tud írni az adatbázisba, akkor az adatok felhalmozódnak a RAM-ban. És vagy a RAM elfogy, vagy egyszerűen elveszíted az adatokat.
4. módszer. Egy másik érdekes módszer. Van valamilyen szerverfolyamat. És azonnal tud adatokat küldeni a ClickHouse-nak, de ezt egyetlen kapcsolaton belül. Például küldtem egy http kérést átviteli kódolással: chunked with insert. És nem túl ritkán generál darabokat, minden sort elküldhetsz, bár ezeknek az adatoknak a keretezése többletköltséggel jár.
Ebben az esetben azonban az adatokat azonnal elküldjük a ClickHouse-nak. És a ClickHouse maga fogja pufferelni őket.
De problémák is felmerülnek. Mostantól elvesznek az adatok, beleértve a folyamat leállítását és a ClickHouse folyamat leállítását is, mivel ez egy hiányos beillesztés lesz. A ClickHouse-ban pedig a betétek atomosak egy bizonyos meghatározott küszöbértékig a sorok méretében. Elvileg ez egy érdekes módszer. Használható is.
5. módszer. Íme egy másik érdekes módszer. Ez egyfajta közösség által fejlesztett szerver az adatok kötegeléséhez. Én magam nem néztem meg, így nem tudok semmit sem garantálni. Magára a ClickHouse-ra azonban nem vállalunk garanciát. Ez is nyílt forráskódú, de másrészt előfordulhat, hogy megszokta bizonyos minőségi szabványokat, amelyeket megpróbálunk biztosítani. De ehhez a dologhoz - nem tudom, menjen a GitHubba, nézze meg a kódot. Talán valami normálisat írtak.
* 2020-tól szintén figyelembe kell venni .
6. módszer. Egy másik módszer a puffertáblák használata. Ennek a módszernek az az előnye, hogy nagyon könnyű elkezdeni használni. Hozzon létre egy puffertáblát, és helyezze be abba.
Hátránya, hogy a probléma nincs teljesen megoldva. Ha egy olyan ütemben, mint a MergeTree, másodpercenként egy köteggel kell az adatokat csoportosítania, akkor egy puffertáblázatban lévő sebességnél legalább másodpercenként több ezret kell csoportosítania. Ha több mint 10 000 másodpercenként, akkor is rossz lesz. És ha kötegekben helyezi be, akkor látta, hogy százezer sor/másodperc lesz. És ez már meglehetősen súlyos adatokon alapul.
És a puffertábláknak nincs naplója. És ha valami baj van a szerverrel, akkor az adatok elvesznek.
És bónuszként nemrégiben lehetőséget kaptunk a ClickHouse-nál, hogy adatokat kérjünk Kafkától. Van egy asztali motor - Kafka. Te csak alkotsz. És felakaszthat rá materializált ábrázolásokat. Ebben az esetben maga kinyeri az adatokat a Kafkától, és beilleszti azokat a szükséges táblázatokba.
És ami különösen örömteli ebben a lehetőségben, hogy nem mi tettük ezt. Ez egy közösségi funkció. És amikor azt mondom, hogy „közösségi jellemző”, minden megvetés nélkül értem. Elolvastuk a kódot, ellenőriztük, jól kell működnie.
* 2020-tól hasonló támogatás jelent meg a számára .
Mi lehet még kellemetlen vagy váratlan az adatok beszúrásakor? Ha beszúrja az értékeket, kérjen és írjon néhány számított kifejezést értékekbe. Például a now() is egy számított kifejezés. És ebben az esetben a ClickHouse kénytelen minden soron elindítani ezen kifejezések értelmezőjét, és a teljesítmény nagyságrendekkel csökken. Ezt jobb elkerülni.
* Jelenleg a probléma teljesen megoldódott, már nincs teljesítmény regresszió az VALUES kifejezések használatakor.
Egy másik példa, amikor problémák adódhatnak, amikor egy kötegben vannak adatok, amelyek egy csomó partícióhoz tartoznak. Alapértelmezés szerint a ClickHouse partíciók havi bontásban vannak. És ha beszúr egy millió sorból álló köteget, és több évre is vannak adatok, akkor ott több tucat partíció lesz. És ez egyenértékű azzal a ténnyel, hogy lesznek több tízszer kisebb méretű kötegek, mert belül mindig először partíciókra vannak osztva.
* Nemrég kísérleti módban a ClickHouse hozzáadta a RAM-ban lévő darabok és darabok kompakt formátumának támogatását előreírási naplóval, ami szinte teljesen megoldja a problémát.
Most nézzük a probléma második típusát – az adatbevitelt.
Az adatbevitel lehet szigorú vagy karakterlánc. Karakterlánc az, amikor éppen vetted, és kijelented, hogy az összes meződ string típusú. Ez szívás. Erre nincs szükség.
Találjuk ki, hogyan kell helyesen csinálni azokban az esetekben, amikor azt akarjuk mondani, hogy van valami mezőnk, egy karakterláncunk, és hagyjuk, hogy a ClickHouse kitalálja magától, és nem fogok zavarni. De még mindig megéri egy kis erőfeszítést tenni.
Például van egy IP-címünk. Egy esetben karakterláncként mentettük el. Például a 192.168.1.1. Egy másik esetben pedig UInt32* típusú szám lesz. 32 bit elég egy IPv4 címhez.
Először is, furcsa módon, az adatok körülbelül egyenlő mértékben lesznek tömörítve. Persze lesz különbség, de nem akkora. Tehát nincs különösebb probléma a lemez I/O-val.
De komoly különbség van a processzoridőben és a lekérdezés végrehajtási idejében.
Számoljuk meg az egyedi IP-címek számát, ha számként vannak tárolva. Ez másodpercenként 137 millió sort jelent. Ha ugyanez karakterláncok formájában van, akkor 37 millió sor másodpercenként. Nem tudom, miért történt ez a véletlen. Ezeket a kéréseket magam teljesítettem. De még mindig körülbelül 4-szer lassabb.
És ha kiszámítja a lemezterület különbségét, akkor is van különbség. A különbség pedig körülbelül egynegyede, mert elég sok az egyedi IP-cím. És ha lennének kis számú különböző jelentésű sorok, akkor azokat a szótár szerint könnyen megközelítőleg ugyanabba a kötetbe tömörítenék.
A négyszeres időkülönbség pedig nem az úton van. Persze lehet, hogy nem törődsz vele, de amikor ekkora különbséget látok, elszomorít.
Nézzünk különböző eseteket.
1. Egy eset, amikor kevés különböző egyedi értéke van. Ebben az esetben egy egyszerű gyakorlatot alkalmazunk, amelyet valószínűleg ismer és használhat bármely DBMS-hez. Ennek nem csak a ClickHouse számára van értelme. Csak írjon numerikus azonosítókat az adatbázisba. És konvertálhat karakterláncokká és vissza az alkalmazás oldalán.
Például van egy régiója. És megpróbálja elmenteni karakterláncként. És oda lesz írva: Moszkva és Moszkvai régió. És amikor azt látom, hogy „Moszkva”, az semmi, de amikor Moszkva, akkor valahogy teljesen szomorú lesz. Ennyi bájt.
Ehelyett egyszerűen felírjuk az Ulnt32 és 250 számokat. Nálunk 250 van a Yandexben, de az Öné eltérhet. Minden esetre elmondom, hogy a ClickHouse beépített képességgel rendelkezik a geobázissal való együttműködésre. Egyszerűen írjon fel egy könyvtárat a régiókkal, beleértve a hierarchikust is, azaz ott lesz Moszkva, Moszkvai régió és minden, amire szüksége van. És konvertálhat a kérés szintjén.
A második lehetőség megközelítőleg ugyanaz, de a ClickHouse-on belüli támogatással. Ez az Enum adattípus. Egyszerűen beírja az összes szükséges értéket az Enumba. Például adja meg az eszköz típusát, és írja oda: asztali számítógép, mobil, táblagép, TV. Összesen 4 lehetőség van.
Hátránya, hogy időnként cserélni kell. Csak egy lehetőség hozzáadva. Csináljunk asztalt. Valójában az alter table a ClickHouse-ban ingyenes. Különösen ingyenes az Enum számára, mert a lemezen lévő adatok nem változnak. Ennek ellenére az alter zárolást* kap az asztalon, és meg kell várnia, amíg az összes kijelölés végrehajtásra kerül. És csak ezt követően hajtják végre a módosítást, vagyis még mindig vannak kellemetlenségek.
* A ClickHouse legújabb verzióiban az ALTER teljesen nem blokkol.
Egy másik lehetőség, amely egészen egyedülálló a ClickHouse számára, a külső szótárak csatlakoztatása. Számokat írhat a ClickHouse-ba, és tárolhatja a könyvtárait az Ön számára megfelelő bármely rendszerben. Például használhatja: MySQL, Mongo, Postgres. Akár saját mikroszolgáltatást is létrehozhat, amely http-n keresztül küldi el ezeket az adatokat. ClickHouse szinten pedig írsz egy függvényt, ami ezeket az adatokat számokból karakterláncokká alakítja.
Ez egy speciális, de nagyon hatékony módja annak, hogy külső asztalon csatlakoztasson. És két lehetőség van. Az egyik kiviteli alakban ezek az adatok teljesen gyorsítótárban lesznek, teljes mértékben jelen lesznek a RAM-ban, és bizonyos gyakorisággal frissítik. És egy másik lehetőség, ha ezek az adatok nem férnek el a RAM-ba, akkor részben gyorsítótárazhatja.
Íme egy példa. Van Yandex.Direct. És van egy reklámcég és bannerek. Valószínűleg több tízmillió reklámcég létezik. És nagyjából belefértek a RAM-ba. És van több milliárd transzparens, ezek nem illenek. Mi pedig a MySQL gyorsítótárazott szótárát használjuk.
Az egyetlen probléma az, hogy a gyorsítótárazott szótár jól működik, ha a találati arány közel 100%. Ha kisebb, akkor az egyes adatkötegekhez tartozó lekérdezések feldolgozása során ténylegesen be kell vennie a hiányzó kulcsokat, és be kell szereznie az adatokat a MySQL-ből. A ClickHouse-szal kapcsolatban továbbra is garantálhatom, hogy - igen, nem lassul, nem beszélek más rendszerekről.
És bónuszként a szótárak egy nagyon egyszerű módja az adatok visszamenőleges frissítésének a ClickHouse-ban. Vagyis volt egy jelentés a reklámcégekről, a felhasználó egyszerűen megváltoztatta a hirdető céget, és minden régi adatban, minden jelentésben ez az adat is megváltozott. Ha közvetlenül a táblába ír sorokat, lehetetlen lesz frissíteni őket.
Egy másik módszer, amikor nem tudja, honnan szerezheti be a karakterláncok azonosítóit. egyszerűen kivonatozhatod. Sőt, a legegyszerűbb lehetőség egy 64 bites hash készítése.
Az egyetlen probléma az, hogy ha a hash 64 bites, akkor szinte biztosan lesznek ütközések. Mert ha ott van egymilliárd sor, akkor már észrevehetővé válik a valószínűség.
A reklámcégek nevét pedig nem lenne túl jó így kivonatolni. Ha a különböző cégek reklámkampányai összekeverednek, akkor valami érthetetlen lesz.
És van egy egyszerű trükk. Igaz, komoly adatokra sem nagyon alkalmas, de ha valami nem túl komoly, akkor csak adja hozzá a kliens azonosítót a szótár kulcsához. És akkor ütközések lesznek, de csak egy ügyfélen belül. És ezt a módszert használjuk a Yandex.Metrica linktérképeihez. Ott vannak URL-eink, tároljuk a hash-eket. És tudjuk, hogy természetesen vannak ütközések. De amikor az oldal megjelenik, figyelmen kívül hagyható annak a valószínűsége, hogy egy felhasználó egy oldalán néhány URL összeragad, és ez észrevehető.
Bónuszként sok művelethez elegendő a hash önmagában, és magukat a karakterláncokat nem kell sehol tárolni.
Egy másik példa, ha a karakterláncok rövidek, például webhelydomainek. Úgy tárolhatók, ahogy vannak. Vagy például a ru böngésző nyelve 2 bájt. Természetesen nagyon sajnálom a bájtokat, de ne aggódj, 2 bájt nem kár. Kérem, tartsa úgy, ahogy van, ne aggódjon.
Egy másik eset, amikor éppen ellenkezőleg, sok a sor, és nagyon sok az egyedi, és még a készlet is potenciálisan korlátlan. Tipikus példa erre a keresési kifejezések vagy URL-ek. Keresési kifejezések, beleértve az elírásokat is. Nézzük meg, hány egyedi keresési kifejezés van naponta. És kiderül, hogy ezek az események majdnem fele. És ebben az esetben azt gondolhatja, hogy normalizálni kell az adatokat, meg kell számolni az azonosítókat, és külön táblázatba kell tenni. De ezt nem kell megtenned. Csak tartsd meg ezeket a sorokat úgy, ahogy vannak.
Jobb, ha nem találsz ki semmit, mert ha külön tárolod, akkor össze kell kapcsolnod. És ez a csatlakozás a legjobb esetben egy véletlenszerű hozzáférés a memóriához, ha még elfér a memóriában. Ha nem illik, akkor gondok lesznek.
És ha az adatok a helyükön vannak tárolva, akkor egyszerűen kiolvassák a kívánt sorrendben a fájlrendszerből, és minden rendben van.
Ha van URL-je vagy más összetett hosszú karakterlánca, akkor érdemes megfontolni, hogy előre kiszámíthat valamilyen kivonatot, és azt külön oszlopba írja.
Az URL-ek esetében például a domaint külön tárolhatja. És ha valóban szüksége van egy domainre, akkor csak használja ezt az oszlopot, és az URL-ek ott lesznek, és nem is érinti őket.
Lássuk, mi a különbség. A ClickHouse egy speciális funkcióval rendelkezik, amely kiszámítja a tartományt. Nagyon gyors, optimalizáltuk. És hogy őszinte legyek, még az RFC-nek sem felel meg, de ennek ellenére mindent figyelembe vesz, amire szükségünk van.
És az egyik esetben egyszerűen megkapjuk az URL-eket és kiszámítjuk a domaint. Ez 166 ezredmásodpercig működik. És ha egy kész domaint veszünk, akkor kiderül, hogy csak 67 ezredmásodperc, azaz majdnem háromszor gyorsabb. És nem azért gyorsabb, mert számolnunk kell, hanem mert kevesebb adatot olvasunk.
Ez az oka annak, hogy egy kérés, amely lassabb, nagyobb, gigabájt/másodperc sebességgel rendelkezik. Mert több gigabájtot olvas. Ez teljesen felesleges adat. Úgy tűnik, hogy a kérés gyorsabban fut, de tovább tart a végrehajtása.
És ha megnézzük a lemezen lévő adatmennyiséget, akkor kiderül, hogy az URL 126 megabájt, a domain pedig csak 5 megabájt. Kiderül, hogy 25-ször kevesebb. Ennek ellenére a kérést csak 4-szer gyorsabban hajtják végre. De ez azért van, mert az adatok forróak. És ha hideg lenne, valószínűleg 25-ször gyorsabb lenne a lemez I/O miatt.
Egyébként, ha megbecsüljük, hogy mennyivel kisebb egy domain, mint egy URL, akkor körülbelül 4-szer kisebbnek bizonyul, de valamiért az adat 25-ször kevesebbet foglal a lemezen. Miért? A tömörítés miatt. És az URL tömörítve van, és a domain tömörítve van. De az URL gyakran egy csomó szemetet tartalmaz.
És természetesen megéri a megfelelő adattípusokat használni, amelyeket kifejezetten a kívánt értékekhez terveztek, vagy amelyek megfelelőek. Ha IPv4-et használ, tárolja az UInt32*-et. Ha IPv6, akkor FixedString(16), mert az IPv6 cím 128 bites, azaz közvetlenül bináris formátumban tárolva.
De mi van akkor, ha néha IPv4-címekkel, néha pedig IPv6-címekkel rendelkezik? Igen, mindkettőt tárolhatja. Egy oszlop az IPv4-hez, egy másik az IPv6-hoz. Természetesen van lehetőség az IPv4 megjelenítésére az IPv6-ban. Ez is működni fog, de ha gyakran van szüksége IPv4-címre a kérésekben, akkor jó lenne külön oszlopba tenni.
* A ClickHouse immár külön IPv4, IPv6 adattípusokkal rendelkezik, amelyek ugyanolyan hatékonyan tárolják az adatokat, mint a számok, de olyan kényelmesen, mint a karakterláncok.
Fontos megjegyezni azt is, hogy érdemes előre feldolgozni az adatokat. Például kap néhány nyers naplót. És lehet, hogy nem szabad azonnal a ClickHouse-ba tenni őket, bár nagyon csábító, hogy nem csinálsz semmit, és minden működni fog. De még mindig érdemes elvégezni a lehetséges számításokat.
Például a böngésző verziója. Valamelyik közeli részlegen, amire nem akarok ujjal mutogatni, a böngésző verziója így van tárolva, azaz karakterláncként: 12.3. Ezután jelentés készítéséhez veszik ezt a karakterláncot, és felosztják egy tömbre, majd a tömb első elemére. Természetesen minden lelassul. Megkérdeztem, miért csinálják ezt. Azt mondták, hogy nem szeretik az idő előtti optimalizálást. És nem szeretem az idő előtti pesszimizálást.
Tehát ebben az esetben helyesebb lenne 4 oszlopra osztani. Itt ne félj, mert ez a ClickHouse. A ClickHouse egy oszlopos adatbázis. És minél ügyesebb kis oszlopok, annál jobb. 5 BrowserVersion lesz, legyen 5 oszlop. Ez jó.
Most nézzük meg, mit tegyünk, ha sok nagyon hosszú karakterláncunk, nagyon hosszú tömbünk van. Egyáltalán nem kell őket a ClickHouse-ban tárolni. Ehelyett csak a ClickHouse-ban tárolhat azonosítót. És tedd ezeket a hosszú sorokat egy másik rendszerbe.
Például az egyik elemző szolgáltatásunk rendelkezik néhány eseményparaméterrel. És ha sok paraméter van az eseményekhez, akkor egyszerűen elmentjük az első 512-t, amelyik találkozik, mert az 512 nem kár.
Ha pedig nem tudja eldönteni az adattípusait, akkor a ClickHouse-ban is rögzítheti az adatokat, de egy ideiglenes napló típusú ideiglenes táblában, amely speciálisan az ideiglenes adatokra vonatkozik. Ezek után elemezheted, hogy milyen értékeloszlásod van ott, mi van ott általában, és létrehozhatod a megfelelő típusokat.
*A ClickHouse mostantól rendelkezik adattípussal amely lehetővé teszi a húrok hatékony tárolását kevesebb erőfeszítéssel.
Most nézzünk meg egy másik érdekes esetet. Néha a dolgok furcsán működnek az emberek számára. Bemegyek és megnézem ezt. És azonnal úgy tűnik, hogy ezt egy nagyon tapasztalt, okos rendszergazda tette, aki nagy tapasztalattal rendelkezik a MySQL 3.23-as verziójának beállításában.
Itt ezer táblázatot látunk, amelyek mindegyike rögzíti a ki tudja mit osztva ezres maradékot.
Elvileg tiszteletben tartom mások tapasztalatait, beleértve a szenvedés megértését, amelyet ezen a tapasztalaton keresztül szerezhetünk.
Az okok pedig többé-kevésbé egyértelműek. Ezek régi sztereotípiák, amelyek más rendszerekkel végzett munka során halmozódhattak fel. Például a MyISAM tábláknak nincs fürtözött elsődleges kulcsa. És az adatok felosztásának ez a módja kétségbeesett kísérlet lehet ugyanazon funkcionalitás elérésére.
Egy másik ok, hogy nehéz bármilyen módosítási műveletet végrehajtani nagy asztalokon. Minden blokkolva lesz. Bár a MySQL modern verzióiban ez a probléma már nem olyan súlyos.
Vagy például microsharding, de erről majd később.
A ClickHouse-ban erre nincs szükség, mert először is az elsődleges kulcs fürtözött, az adatok az elsődleges kulcs szerint vannak rendezve.
És néha az emberek megkérdezik tőlem: „Hogyan változik a tartománylekérdezések teljesítménye a ClickHouse-ban a táblázat méretétől függően?” Én azt mondom, hogy ez egyáltalán nem változik. Például van egy táblázatod milliárd sorral, és egy millió sorból álló tartományt olvasol. Minden rendben. Ha egy táblázatban billió sor van, és egymillió sort olvasol, akkor az majdnem ugyanannyi lesz.
Másodszor pedig mindenféle dologra, például kézi partíciókra nincs szükség. Ha bemész és megnézed, mi van a fájlrendszerben, látni fogod, hogy a táblázat elég nagy dolog. És van benne valami válaszfal. Vagyis a ClickHouse mindent megtesz helyetted, és nem kell szenvedned.
Az Alter in ClickHouse ingyenes, ha módosítja az add/drop oszlopot.
És nem szabad kis táblázatokat készíteni, mert ha 10 sor vagy 10 000 sor van egy táblázatban, akkor az teljesen mindegy. A ClickHouse egy olyan rendszer, amely az átviteli sebességet optimalizálja, nem a késleltetést, így nincs értelme 10 sort feldolgozni.
Helyes egy nagy asztal használata. Szabadulj meg a régi sztereotípiáktól, minden rendben lesz.
És bónuszként a legújabb verzióban lehetőségünk van tetszőleges particionálási kulcs létrehozására, hogy mindenféle karbantartási műveletet elvégezhessünk az egyes partíciókon.
Például sok kis táblára van szüksége, például amikor valamilyen köztes adatot kell feldolgozni, akkor darabokat kap, és átalakítást kell végrehajtania rajtuk, mielőtt a végső asztalra írna. Erre az esetre van egy csodálatos asztali motor - StripeLog. Olyan, mint a TinyLog, csak jobb.
* most a ClickHouse-nak is van .
Egy másik ellenminta a microsharding. Például adatokat kell szilánkolni, és 5 szervered lesz, holnap pedig 6 szerver lesz. És azon gondolkodik, hogyan lehet ezeket az adatokat újra kiegyensúlyozni. És ehelyett nem 5, hanem 1 szilánkra törsz. Ezután mindegyik mikroszilánkot leképezi egy külön szerverre. És például 000 ClickHouse-t kapsz egy szerveren. Külön példányok külön portokon vagy külön adatbázisokban.
De ez nem túl jó a ClickHouse-ban. Mert még egy ClickHouse-példány is megpróbálja felhasználni az összes rendelkezésre álló szervererőforrást egy kérés feldolgozásához. Vagyis van valamilyen szervered, és van benne például 56 processzormag. Olyan lekérdezést futtat, amely egy másodpercet vesz igénybe, és 56 magot fog használni. És ha 200 ClickHouse-t helyez el egy szerverre, akkor kiderül, hogy 10 000 szál fog elindulni. Általában minden nagyon rossz lesz.
Egy másik ok az, hogy a munka ezekben az esetekben egyenetlen lesz. Vannak, akik korábban, mások később. Ha mindez egy példányban történt, akkor a ClickHouse maga kitalálná, hogyan lehet helyesen elosztani az adatokat a szálak között.
És egy másik ok az, hogy a processzorok közötti kommunikáció TCP-n keresztül lesz. Az adatokat szerializálni, deszerializálni kell, és ez óriási számú mikroszilánk. Egyszerűen nem fog hatékonyan működni.
Egy másik antiminta, bár aligha nevezhető antimintának. Ez egy nagy mennyiségű előre összesítés.
Általánosságban elmondható, hogy az előzetes összesítés jó. Egymilliárd sora volt, összesítette, és 1 sor lett belőle, és most a lekérdezés azonnal végrehajtódik. Minden nagyszerű. Meg tudod csinálni. És ehhez még a ClickHouse-nak is van egy speciális táblatípusa, az AggregatingMergeTree, amely növekményes összesítést hajt végre az adatok beszúrásakor.
De vannak esetek, amikor úgy gondolja, hogy ilyen és ehhez hasonló adatokat fogunk összesíteni. És néhány szomszédos részlegben azt sem akarom megmondani, hogy melyik, SummingMergeTree táblákat használnak az elsődleges kulcs szerinti összegzésre, és körülbelül 20 oszlopot használnak elsődleges kulcsként. Minden esetre a titoktartás kedvéért megváltoztattam néhány oszlop nevét, de nagyjából ennyi.
És ilyen problémák merülnek fel. Először is, az adatmennyiség nem csökken túlságosan. Például háromszorosára csökken. Háromszor jó ár lenne, ha megengedheti magának azt a korlátlan elemzési képességet, amely akkor adódik, ha az adatok nincsenek összesítve. Ha az adatokat összesítjük, akkor az elemzés helyett csak szánalmas statisztikákat kapunk.
És mi olyan különleges benne? A helyzet az, hogy a szomszédos részlegről ezek az emberek néha elmennek és megkérik, hogy adjanak hozzá egy másik oszlopot az elsődleges kulcshoz. Vagyis így összesítettük az adatokat, de most egy kicsit többet szeretnénk. De a ClickHouse-nak nincs más elsődleges kulcsa. Ezért néhány szkriptet kell írnunk C++-ban. És nem szeretem a szkripteket, még akkor sem, ha C++-ban vannak.
És ha megnézzük, hogy a ClickHouse mire készült, akkor a nem összesített adatok pontosan az a forgatókönyv, amelyre megszülettek. Ha a ClickHouse-t nem összesített adatokhoz használja, akkor jól csinálja. Ha összesíti, ez néha megbocsátható.
Egy másik érdekes eset a végtelen ciklusban végzett lekérdezések. Néha felmegyek egy termelési szerverre, és ott megnézem a show processlist-t. És valahányszor felfedezem, hogy valami szörnyűség történik.
Például így. Azonnal világos, hogy egy kéréssel mindent meg lehet tenni. Csak írja be az url-t és a listát.
Miért rossz sok ilyen lekérdezés egy végtelen ciklusban? Ha nem használ indexet, akkor ugyanazon az adatokon sok áthalad. De ha például az indexet használjuk, akkor van egy elsődleges kulcsod a ru-hoz, és oda írod, hogy url = valami. És azt gondolja, hogy ha csak egy URL-t olvas ki a táblázatból, akkor minden rendben lesz. De valójában nem. Mert a ClickHouse mindent kötegben csinál.
Amikor egy bizonyos adattartományt kell elolvasnia, egy kicsit többet olvas, mert a ClickHouse indexe ritka. Ez az index nem teszi lehetővé, hogy egyetlen sort találjon a táblázatban, csak valamilyen tartományt. Az adatok pedig blokkokban vannak tömörítve. Egy sor elolvasásához ki kell venni az egész blokkot, és ki kell oldani. És ha egy csomó lekérdezést hajt végre, akkor sok átfedés lesz, és sok munkája lesz újra és újra.
És bónuszként megjegyezheti, hogy a ClickHouse-ban nem kell félnie attól, hogy akár megabájtokat és akár több száz megabájtot is átvigyen az IN szekcióba. Emlékszem a gyakorlatunkból, hogy ha a MySQL-ben egy csomó értéket áthelyezünk az IN szakaszba, például 100 megabájtnyi számot viszünk át oda, akkor a MySQL felemészti a 10 gigabájt memóriát, és semmi más nem történik vele, minden rosszul működik.
A második pedig az, hogy a ClickHouse-ban, ha a lekérdezések indexet használnak, akkor az mindig nem lassabb, mint egy teljes vizsgálat, azaz ha szinte a teljes táblát el kell olvasni, akkor szekvenciálisan megy, és beolvassa a teljes táblát. Általában magától kitalálja.
De ennek ellenére vannak nehézségek. Például az a tény, hogy az IN egy segédlekérdezéssel nem használja az indexet. De ez a mi problémánk, és meg kell oldanunk. Nincs itt semmi alapvető. Megjavítjuk*.
És még egy érdekesség, hogy ha nagyon hosszú kérésed van, és az elosztott kérés feldolgozása folyamatban van, akkor ez a nagyon hosszú kérés minden szerverre tömörítés nélkül kerül elküldésre. Például 100 megabájt és 500 szerver. Ennek megfelelően 50 gigabájtot fog átvinni a hálózaton. A rendszer továbbítja, majd minden sikeresen befejeződik.
* már használja; Mindent az ígéretek szerint javítottak.
És meglehetősen gyakori eset, amikor a kérések az API-tól érkeznek. Például létrehoztál valamilyen saját szolgáltatást. És ha valakinek szüksége van a szolgáltatására, akkor megnyitja az API-t, és szó szerint két nappal később látja, hogy valami érthetetlen történik. Minden túlterhelt, és olyan szörnyű kérések érkeznek, amelyeknek soha nem lett volna szabad megtörténnie.
És csak egy megoldás létezik. Ha megnyitotta az API-t, akkor le kell vágnia. Például vezessen be valamilyen kvótát. Nincs más normális lehetőség. Ellenkező esetben azonnal forgatókönyvet írnak, és gondok lesznek.
És a ClickHouse-nak van egy speciális funkciója - a kvótaszámítás. Ezenkívül átviheti kvótakulcsát. Ez például a belső felhasználói azonosító. A kvótákat pedig mindegyikre külön-külön számítják ki.
Most egy másik érdekesség. Ez manuális replikáció.
Sok olyan esetről tudok, amikor a ClickHouse beépített replikációs támogatása ellenére az emberek manuálisan replikálják a ClickHouse-t.
Mi az elv? Van egy adatfeldolgozási folyamata. És függetlenül működik például a különböző adatközpontokban. Ugyanazokat az adatokat ugyanúgy írod a ClickHouse-ban. Igaz, a gyakorlat azt mutatja, hogy az adatok továbbra is eltérnek a kód egyes funkciói miatt. Remélem a tiedben van.
És időnként továbbra is manuálisan kell szinkronizálnia. Például havonta egyszer az adminisztrátorok végeznek rsync-et.
Valójában sokkal egyszerűbb a ClickHouse-ba épített replikáció használata. De lehetnek ellenjavallatok, mert ehhez a ZooKeeper-t kell használni. A ZooKeeperről nem mondok semmi rosszat, elvileg működik a rendszer, de előfordul, hogy java-fóbia miatt nem használják az emberek, mert a ClickHouse egy olyan jó rendszer, C++-ban megírva, amit lehet használni, ill. minden rendben lesz. A ZooKeeper pedig java-ban van. És valahogy nem is akarod nézni, de akkor használhatod a kézi replikációt.
A ClickHouse egy praktikus rendszer. Figyelembe veszi az Ön igényeit. Ha manuális replikációja van, akkor létrehozhat egy elosztott táblát, amely megnézi a kézi replikákat, és feladatátvételt hajt végre közöttük. És van még egy speciális lehetőség is, amely lehetővé teszi a flopok elkerülését, még akkor is, ha a vonalak szisztematikusan eltérnek.
További problémák merülhetnek fel, ha primitív asztali motorokat használ. A ClickHouse egy olyan konstruktor, amely egy csomó különböző táblázatmotort tartalmaz. A dokumentációban leírtak szerint minden súlyos esetben használja a MergeTree család táblázatait. És az összes többi - ez így van, egyedi esetekre vagy tesztekre.
A MergeTree táblázatban nincs szükség dátumra és időre. Továbbra is használhatod. Ha nincs dátum és idő, írja be, hogy az alapértelmezett 2000. Ez működni fog, és nem igényel erőforrásokat.
A szerver új verziójában pedig még azt is megadhatja, hogy legyen egyéni particionálása partíciós kulcs nélkül. Ugyanaz lesz.
Másrészt használhat primitív asztali motorokat. Például töltse ki az adatokat egyszer, és nézze meg, csavarja és törölje. Használhatja a Log.
Vagy a StripeLog vagy a TinyLog kis mennyiségek tárolása közbenső feldolgozás céljából.
A memória akkor használható, ha kicsi az adatmennyiség, és egyszerűen mozgathat valamit a RAM-ban.
A ClickHouse nem igazán szereti a renormalizált adatokat.
Íme egy tipikus példa. Ez egy hatalmas számú URL. Tedd őket a következő táblázatba. Aztán úgy döntöttek, hogy JOIN-t csinálnak velük, de ez általában nem fog működni, mert a ClickHouse csak a Hash JOIN-t támogatja. Ha nincs elég RAM sok csatlakoztatandó adathoz, akkor a JOIN nem fog működni*.
Ha az adatok nagyszámúak, akkor ne aggódjon, denormalizált formában tárolja, az URL-ek közvetlenül a helyükön vannak a főtáblázatban.
* és most a ClickHouse-nak is van egyesítése, és olyan körülmények között működik, ahol a köztes adatok nem férnek be a RAM-ba. Ez azonban hatástalan, és az ajánlás érvényben marad.
Még egy-két példa, de már kétlem, hogy mintaellenesek-e vagy sem.
A ClickHouse-nak van egy ismert hibája. Nem tudja, hogyan kell frissíteni*. Bizonyos szempontból ez még jó is. Ha van néhány fontos adata, például könyvelés, akkor senki sem tudja elküldeni, mert nincsenek frissítések.
* A kötegelt módban történő frissítés és törlés támogatása már régen megjelent.
De van néhány speciális mód, amely lehetővé teszi a frissítéseket, mintha a háttérben lennének. Például olyan táblák, mint a ReplaceMergeTree. Frissítéseket végeznek a háttérben történő egyesítés során. Ezt az optimalizálási táblázat segítségével kényszerítheti ki. De ne tegye ezt túl gyakran, mert teljesen felülírja a partíciót.
A ClickHouse-ban lévő elosztott JOIN-eket szintén rosszul kezeli a lekérdezéstervező.
Rossz, de néha oké.
Csak a ClickHouse használata az adatok visszaolvasásához a select* használatával.
Nem javaslom a ClickHouse használatát nehézkes számításokhoz. De ez nem teljesen igaz, mert ettől az ajánlástól már távolodunk. És nemrég hozzáadtuk a gépi tanulási modellek alkalmazásának lehetőségét a ClickHouse - Catboost alkalmazásban. És ez zavar, mert azt gondolom: „Micsoda borzalom. Ennyi ciklus bájtonként! Nagyon utálom bájtokra pazarolni az órákat.
De ne féljen, telepítse a ClickHouse-t, minden rendben lesz. Ha valami, akkor van közösségünk. Egyébként a közösség te vagy. És ha bármilyen problémája van, legalább felkeresheti a chatünket, és remélhetőleg segíteni fognak.
kérdések
Köszönöm a beszámolót! Hol panaszkodhatok a ClickHouse összeomlása miatt?
Most személyesen nekem panaszkodhat.
Nemrég kezdtem el használni a ClickHouse-t. Azonnal elvetettem a klipi felületet.
Szerencsés vagy.
Kicsit később egy kis kiválasztással összeomlott a szerver.
Van tehetséged.
Megnyitottam egy GitHub hibát, de figyelmen kívül hagyták.
Meglátjuk.
Alexey becsapott, hogy részt vegyek a jelentésben, és megígérte, hogy elmondja, hogyan férhet hozzá a benne lévő adatokhoz.
Nagyon egyszerű.
Erre tegnap rájöttem. További konkrétumok.
Ott nincsenek szörnyű trükkök. Csak blokkonkénti tömörítés van. Az alapértelmezett az LZ4, engedélyezheti a ZSTD*-t. 64 kilobájttól 1 megabájtig blokkolja.
* Támogatják a speciális tömörítési kodekeket is, amelyek láncban használhatók más algoritmusokkal.
A blokkok csak nyers adatok?
Nem teljesen nyersen. Vannak tömbök. Ha van egy numerikus oszlop, akkor a sorban lévő számok egy tömbbe kerülnek.
Ez egyértelmű.
Alexey, egy példa, ami a uniqExact over IP-vel volt, vagyis az a tény, hogy a uniqExact több időt vesz igénybe a sorok, mint a számok alapján történő kiszámítása, és így tovább. Mi van akkor, ha a lektoráláskor cseleket használunk a fülünkkel és dobunk? Vagyis úgy tűnik, azt mondtad, hogy a mi lemezünkön nem nagyon különbözik. Ha sorokat olvasunk a lemezről és öntjük, akkor gyorsabbak lesznek az aggregátumaink vagy sem? Vagy itt még nyerünk egy kicsit? Nekem úgy tűnik, hogy ezt tesztelted, de valamiért nem jelezted a benchmarkban.
Szerintem lassabb lesz, mint casting nélkül. Ebben az esetben az IP-címet a karakterláncból kell elemezni. Természetesen a ClickHouse-nál az IP-címek elemzése is optimalizálva van. Nagyon igyekeztünk, de ott vannak a számok tízezredik alakban. Nagyon kényelmetlen. Másrészt az uniqExact függvény lassabban fog működni a karakterláncokon, nem csak azért, mert ezek karakterláncok, hanem azért is, mert az algoritmus más specializációja van kiválasztva. A karakterláncokat egyszerűen másképp dolgozzák fel.
Mi van, ha egy primitívebb adattípust választunk? Például felírtuk a felhasználói azonosítót, ami benne van, felírtuk egy sorként, majd összekevertük, szórakoztatóbb lesz vagy sem?
Kétlem. Szerintem még szomorúbb lesz, mert végül is a számok elemzése komoly probléma. Nekem úgy tűnik, hogy ez a kolléga még arról is beszámolót adott, hogy milyen nehéz a számokat tízezres alakban elemezni, de lehet, hogy nem.
Alexey, köszönöm szépen a beszámolót! És nagyon köszönöm a ClickHouse-t! Lenne egy kérdésem a tervekkel kapcsolatban. Tervezik-e a szótárak hiányos frissítését?
Vagyis részleges újraindítás?
Igen igen. Mint az a lehetőség, hogy ott MySQL mezőt lehet beállítani, azaz utána frissíteni, hogy csak ezek az adatok legyenek betöltve, ha nagyon nagy a szótár.
Nagyon érdekes funkció. És azt hiszem, valaki javasolta ezt a beszélgetésünkben. Talán még te is az voltál.
Nem hiszem.
Remek, most kiderült, hogy két kérés van. És lassan elkezdheti csinálni. De azonnal szeretném figyelmeztetni, hogy ezt a funkciót meglehetősen egyszerű megvalósítani. Azaz elméletileg csak a verziószámot kell beírni a táblázatba, majd beírni: verzió kevesebb, mint ilyen és olyan. Ez azt jelenti, hogy nagy valószínűséggel ezt fogjuk ajánlani a rajongóknak. Ön egy lelkes?
Igen, de sajnos nem C++-ban.
Tudnak a kollégái C++ nyelven írni?
Találok valakit.
Nagy*.
* a funkciót két hónappal a jelentés után adták hozzá – a kérdés szerzője fejlesztette ki és küldte el a sajátját .
Köszönöm!
Helló! Köszönöm a beszámolót! Említetted, hogy a ClickHouse nagyon jó az összes rendelkezésére álló erőforrás felhasználásában. A Luxoft melletti felszólaló pedig az Orosz Posta megoldásáról beszélt. Elmondta, hogy nagyon szerették a ClickHouse-t, de éppen azért nem használták a fő versenytárs helyett, mert felemésztette az összes CPU-t. És nem tudták beilleszteni az építészetükbe, a dokkolókkal ellátott ZooKeeperükbe. Lehet-e valahogy korlátozni a ClickHouse-t, hogy ne fogyasszon el mindent, ami elérhetővé válik számára?
Igen, lehetséges és nagyon egyszerű. Ha kevesebb magot akarsz fogyasztani, akkor csak írj set max_threads = 1. És ez az, egy magban hajtja végre a kérést. Ezenkívül különböző beállításokat adhat meg a különböző felhasználók számára. Szóval semmi gond. És mondd el a Luxoft-os kollégáidnak, hogy nem jó, hogy nem találták meg ezt a beállítást a dokumentációban.
Alexey, helló! Ezzel a kérdéssel kapcsolatban szeretnék kérdezni. Nem először hallom, hogy sokan kezdik használni a ClickHouse-t naplók tárolására. A jelentésnél azt mondtad, hogy ezt ne tedd, vagyis nem kell hosszú húrokat tárolnod. Mit gondolsz róla?
Először is, a naplók általában nem hosszú karakterláncok. Persze vannak kivételek. Például néhány java-ban írt szolgáltatás kivételt dob, azt naplózza. És így tovább egy végtelen ciklusban, és elfogy a hely a merevlemezen. A megoldás nagyon egyszerű. Ha a vonalak nagyon hosszúak, vágja le őket. Mit jelent a hosszú? Több tíz kilobájt rossz*.
* A ClickHouse legújabb verzióiban engedélyezve van az „adaptív index granularitás”, ami nagyrészt kiküszöböli a hosszú sorok tárolásának problémáját.
Normális egy kilobájt?
Ez normális.
Helló! Köszönöm a beszámolót! Már kérdeztem erről a chaten, de nem emlékszem, kaptam-e választ. Tervezik a WITH szekciót valamiképpen CTE-módra bővíteni?
Még nem. A WITH rovatunk kissé komolytalan. Ez olyan, mint egy kis funkció számunkra.
Megértem. Köszönöm!
Köszönjük a beszámolót! Nagyon érdekes! Globális kérdés. Tervezik-e az adattörlés módosítását, esetleg valamilyen csonk formájában?
Szükségszerűen. Ez az első feladatunk a sorban. Most aktívan gondolkodunk azon, hogyan csináljunk mindent helyesen. És el kell kezdenie nyomni a billentyűzetet*.
* megnyomta a billentyűzet gombjait, és mindent megtett.
Ez hatással lesz a rendszer teljesítményére vagy sem? Olyan gyors lesz a beillesztés, mint most?
Lehet, hogy maguk a törlések és maguk a frissítések is nagyon nehézek lesznek, de ez nem befolyásolja a kiválasztások vagy a beillesztések teljesítményét.
És még egy apró kérdés. Az előadáson az elsődleges kulcsról beszélt. Ennek megfelelően van particionálásunk, ami alapértelmezés szerint havi, igaz? És ha beállítunk egy dátumtartományt, amely belefér egy hónapba, akkor csak ez a partíció kerül beolvasásra, igaz?
Igen.
Kérdés. Ha nem tudunk kiválasztani egyetlen elsődleges kulcsot sem, akkor helyes-e ezt kifejezetten a „Dátum” mező szerint megtenni, hogy a háttérben kevésbé legyen átrendezve ezek az adatok, hogy rendezettebben illeszkedjenek? Ha nincsenek tartománylekérdezéseid, és még egyetlen elsődleges kulcsot sem tudsz kiválasztani, akkor érdemes dátumot tenni az elsődleges kulcsba?
Igen.
Lehet, hogy van értelme egy olyan mezőt tenni az elsődleges kulcsba, amely jobban tömöríti az adatokat, ha ez a mező szerint rendeződik. Például felhasználói azonosító. A felhasználó például ugyanarra a webhelyre megy. Ebben az esetben adja meg a felhasználói azonosítót és az időt. És akkor az adatok jobban tömörítve lesznek. Ami a dátumot illeti, ha valóban nincsenek és soha nem is vannak tartománylekérdezései a dátumokra vonatkozóan, akkor nem kell a dátumot beírnia az elsődleges kulcsba.
Rendben, köszönöm szépen!
Forrás: will.com