egy nyílt forráskódú oszlopos adatbázis-kezelő rendszer online analitikus lekérdezések feldolgozásához (OLAP), amelyet a Yandex hozott létre. A Yandex, a CloudFlare, a VK.com, a Badoo és más szolgáltatások világszerte használják igazán nagy mennyiségű adat tárolására (másodpercenként több ezer sor vagy lemezen tárolt petabájt adat beszúrása).
Egy normál, „karakterláncú” DBMS-ben, amelyre példa a MySQL, Postgres, MS SQL Server, az adatok a következő sorrendben tárolódnak:
Ebben az esetben az egy sorhoz kapcsolódó értékek fizikailag a közelben vannak tárolva. Az oszlopos DBMS-ekben a különböző oszlopokból származó értékeket külön-külön, az egy oszlopból származó adatokat pedig együtt tárolják:
Az oszlopos adatbázis-kezelő rendszerek példái a Vertica, Paraccel (Actian Matrix, Amazon Redshift), Sybase IQ, Exasol, Infobright, InfiniDB, MonetDB (VectorWise, Actian Vector), LucidDB, SAP HANA, Google Dremel, Google PowerDrill, Druid, kdb+.
Levéltovábbító cég 2018-ban kezdte használni a Clickhouse-t jelentéskészítéshez, és nagyon lenyűgözött egyszerűsége, méretezhetősége, SQL-támogatása és sebessége. Ennek a DBMS-nek a sebessége a varázslat határát súrolta.
Nyugalom
A Clickhouse egyetlen paranccsal telepíthető az Ubuntura. Ha ismeri az SQL-t, azonnal elkezdheti használni a Clickhouse-t igényeinek megfelelően. Ez azonban nem jelenti azt, hogy megteheti a „táblázat létrehozásának megjelenítését” a MySQL-ben, és másolja be az SQL-t a Clickhouse-ba.
A MySQL-hez képest fontos adattípusbeli különbségek vannak a táblaséma-definíciókban, így még mindig szüksége lesz egy kis időre a táblaséma-definíciók megváltoztatásához és a táblamotorok megtanulásához, hogy kényelmesen érezze magát.
A Clickhouse nagyszerűen működik további szoftverek nélkül, de ha replikációt szeretne használni, telepítenie kell a ZooKeeper-t. A lekérdezés teljesítményelemzése kiváló eredményeket mutat – a rendszertáblázatok minden információt tartalmaznak, és minden adat visszakereshető régi és unalmas SQL-lel.
termelékenység
- a Clickhouse és a Vertica és a MySQL összehasonlítása a szerverkonfigurációban: két aljzat Intel® Xeon® CPU E5-2650 v2 @ 2.60 GHz; 128 GiB RAM; md RAID-5 8 6TB SATA HDD-n, ext4.
- a Clickhouse összehasonlítása az Amazon RedShift felhőtárolóval.
- Blogrészletek :
A ClickHouse adatbázis felépítése nagyon egyszerű – a fürt összes csomópontja ugyanazokkal a funkciókkal rendelkezik, és csak a ZooKeeper-t használja koordinációra. Felépítettünk egy több csomópontból álló kis klasztert és tesztelést végeztünk, melynek során azt találtuk, hogy a rendszer meglehetősen lenyűgöző teljesítményt nyújt, ami megfelel az analitikus DBMS benchmarkokban megfogalmazott előnyöknek. Úgy döntöttünk, hogy közelebbről megvizsgáljuk a ClickHouse mögött meghúzódó koncepciót. A kutatás első akadálya az eszközök hiánya és a kis ClickHouse közösség volt, ezért elmélyültünk ennek a DBMS-nek a kialakításában, hogy megértsük, hogyan működik.
A ClickHouse nem támogatja az adatok közvetlen fogadását a Kafkától, mivel ez csak egy adatbázis, ezért saját adapterszolgáltatást írtunk a Go-ban. Beolvassa a Cap'n Proto kódolású Kafka üzeneteit, TSV-vé konvertálta, és a HTTP interfészen keresztül kötegekben beszúrta a ClickHouse-ba. Később ezt a szolgáltatást átírtuk, hogy a teljesítmény javítása érdekében a Go könyvtárat a ClickHouse saját felületével együtt használjuk. A csomagok fogadásának teljesítményét értékelve egy fontos dolgot fedeztünk fel - kiderült, hogy a ClickHouse esetében ez a teljesítmény erősen függ a csomag méretétől, vagyis az egyidejűleg beszúrt sorok számától. Hogy megértsük, miért történik ez, megvizsgáltuk, hogyan tárolja a ClickHouse az adatokat.
A ClickHouse által az adatok tárolására használt fő motor, vagy inkább táblázatmotorok családja a MergeTree. Ez a motor elvileg hasonló a Google BigTable vagy Apache Cassandra által használt LSM algoritmushoz, de elkerüli a közbenső memóriatábla létrehozását, és közvetlenül a lemezre írja az adatokat. Ez kiváló írási teljesítményt biztosít, mivel minden beszúrt csomag csak az elsődleges kulcs alapján kerül rendezésre, tömörítésre és lemezre írva egy szegmenst alkot.
A memóriatábla hiánya vagy az adatok „frissségének” fogalma azt is jelenti, hogy csak hozzáadhatók, a rendszer nem támogatja a módosítást vagy a törlést. Jelenleg az adatok törlésének egyetlen módja a naptári hónap szerinti törlés, mivel a szegmensek soha nem lépik át a hónaphatárt. A ClickHouse csapata aktívan dolgozik a funkció testreszabhatóságán. Másrészt a szegmensek írása és egyesítése versengésmentessé válik, így lineárisan fogadja az átviteli skálákat az egyidejű beillesztések számával, amíg az I/O vagy a magtelítettség meg nem történik.
Ez azonban azt is jelenti, hogy a rendszer nem alkalmas kis csomagokra, ezért a Kafka szolgáltatásokat és beszúrókat használják a pufferelésre. Ezután a ClickHouse a háttérben továbbra is folyamatosan szegmens-összevonást végez, így sok kis információ több alkalommal kerül összevonásra és rögzítésre, ezzel növelve a rögzítés intenzitását. Azonban a túl sok nem csatlakoztatott rész a betétek agresszív fojtását okozza mindaddig, amíg az egyesítés folytatódik. Azt találtuk, hogy a legjobb kompromisszum a valós idejű feldolgozás és a feldolgozási teljesítmény között az, ha másodpercenként korlátozott számú beszúrást viszünk be a táblázatba.
A táblázat olvasási teljesítményének kulcsa az indexelés és az adatok helye a lemezen. Nem számít, milyen gyors a feldolgozás, ha a motornak terabájtnyi adatot kell átvizsgálnia a lemezről, és csak egy részét kell felhasználnia, ez időbe telik. A ClickHouse egy oszlopos áruház, így minden szegmens minden oszlophoz (oszlophoz) tartalmaz egy fájlt, minden sorhoz rendezett értékekkel. Így először a lekérdezésből hiányzó teljes oszlopok kihagyhatók, majd vektorizált végrehajtással párhuzamosan több cella is feldolgozható. A teljes vizsgálat elkerülése érdekében minden szegmenshez tartozik egy kis indexfájl.
Tekintettel arra, hogy az összes oszlop az „elsődleges kulcs” szerint van rendezve, az indexfájl csak minden N. sor címkéit (rögzített sorait) tartalmazza, hogy azokat még nagyon nagy táblák esetén is a memóriában tudja tartani. Például beállíthatja az alapértelmezett beállításokat a „minden 8192. sor megjelölésére”, majd a táblázat „csekély” indexelésére 1 billiódal. A memóriába könnyen beilleszthető sorok mindössze 122 070 karaktert vesznek igénybe.
Rendszerfejlesztés
A Clickhouse fejlesztése és fejlesztése a címen követhető nyomon és győződjön meg arról, hogy a „felnövés” folyamata lenyűgöző ütemben zajlik.
Népszerűség
Úgy tűnik, hogy a Clickhouse népszerűsége exponenciálisan növekszik, különösen az orosz nyelvű közösségben. A tavalyi High load 2018 konferencia (Moszkva, 8. november 9-2018.) megmutatta, hogy az olyan szörnyek, mint a vk.com és a Badoo, a Clickhouse-t használják, amellyel több tízezer szerverről szúrnak be adatokat (például naplókat) egyszerre. 40 perces videóban . Hamarosan közzétesszük az átiratot a Habron, hogy megkönnyítsük az anyaggal való munkát.
alkalmazások
Némi kutatási idő után úgy gondolom, hogy vannak olyan területek, ahol a ClickHouse hasznos lehet, vagy teljesen felválthatna más hagyományos és népszerű megoldásokat, mint például a MySQL, PostgreSQL, ELK, Google Big Query, Amazon RedShift, TimescaleDB, Hadoop, MapReduce, Pinot és Druida. Az alábbiakban a ClickHouse használatának részleteit ismertetjük a fenti DBMS korszerűsítésére vagy teljes cseréjére.
A MySQL és a PostgreSQL képességeinek bővítése
Nemrég a MySQL-t részben a ClickHouse-ra cseréltük hírlevél-platformunkban . A probléma az volt, hogy a MySQL a rossz tervezés miatt minden elküldött e-mailt és az e-mailben található hivatkozásokat base64 hash-sel naplózta, és egy hatalmas MySQL táblát hozott létre (email_stats). Miután mindössze 10 millió e-mailt küldött a szolgáltatás előfizetőinek, ez a táblázat 150 GB fájlterületet foglalt el, és a MySQL kezdett „hülye lenni” az egyszerű lekérdezésekre. A fájlterület problémájának kijavításához sikeresen alkalmaztuk az InnoDB táblatömörítését, amely 4-szeresére csökkentette azt. Azonban továbbra sincs értelme 20-30 milliónál több e-mailt MySQL-ben tárolni pusztán az olvasási előzmények kedvéért, mivel minden egyszerű lekérdezés, amelyet valamilyen oknál fogva teljes vizsgálatot kell végezni, cserét eredményez, és sok /O terhelést, amivel kapcsolatban rendszeresen kaptunk figyelmeztetést a Zabbixtól.
A Clickhouse két tömörítési algoritmust használ, amelyek megközelítőleg csökkentik az adatmennyiséget , de ebben a konkrét esetben az adatok különösen "tömöríthetők" voltak.
ELK csere
Saját tapasztalataim alapján az ELK verem (ElasticSearch, Logstash és Kibana, jelen esetben ElasticSearch) sokkal több erőforrást igényel, mint amennyi a naplók tárolásához szükséges. Az ElasticSearch nagyszerű motor, ha jó teljes szöveges naplókeresésre van szüksége (amire szerintem nincs igazán szüksége), de kíváncsi vagyok, miért lett ez a de facto szabványos naplózómotor. A Logstash-val kombinált beviteli teljesítménye még meglehetősen kis terhelés esetén is problémákat okozott, és egyre több RAM-ot és lemezterületet igényelt. Adatbázisként a Clickhouse jobb, mint az ElasticSearch a következő okok miatt:
- SQL dialektus támogatás;
- A tárolt adatok legjobb tömörítési foka;
- A Regex reguláris kifejezések keresésének támogatása a teljes szöveges keresések helyett;
- Továbbfejlesztett lekérdezésütemezés és nagyobb általános teljesítmény.
Jelenleg a ClickHouse és az ELK összehasonlítása során felmerülő legnagyobb probléma a naplók feltöltésére szolgáló megoldások hiánya, valamint a témával kapcsolatos dokumentáció és oktatóanyagok hiánya. Ezenkívül minden felhasználó konfigurálhatja az ELK-t a Digital Ocean kézikönyv segítségével, ami nagyon fontos az ilyen technológiák gyors megvalósításához. Van adatbázismotor, de még nincs Filebeat for ClickHouse. Igen, ott van és egy rendszer a naplókkal való munkavégzéshez , van egy eszköz hogy a naplófájl adatait bevigye a ClickHouse-ba, de mindez több időt vesz igénybe. A ClickHouse azonban az egyszerűsége miatt továbbra is vezető szerepet tölt be, így a kezdők is könnyedén telepíthetik és 10 perc alatt teljesen működőképes használatba vehetik.
A minimalista megoldásokat részesítve előnyben, megpróbáltam a FluentBit-et, a nagyon kevés memóriával rendelkező naplók szállítására szolgáló eszközt használni a ClickHouse-szal együtt, miközben igyekeztem elkerülni a Kafka használatát. A kisebb összeférhetetlenségeket azonban orvosolni kell, mint pl előtt ez megtehető a proxy réteg nélkül, amely az adatokat FluentBitből ClickHouse-ba konvertálja.
Alternatív megoldásként a Kibana ClickHouse háttérprogramként is használható . Ha jól értem, ez teljesítményproblémákat okozhat nagyszámú adatpont renderelésekor, különösen a Grafana régebbi verzióinál. A Qwintrynél ezt még nem próbáltuk ki, de a Telegram ClickHouse támogatási csatornáján időről időre megjelennek ezzel kapcsolatos panaszok.
A Google Big Query és az Amazon RedShift (megoldás nagyvállalatok számára) leváltása
A BigQuery ideális felhasználási esete 1 TB JSON-adat betöltése és analitikai lekérdezések futtatása. A Big Query egy kiváló termék, amelynek méretezhetőségét nem lehet túlbecsülni. Ez sokkal összetettebb szoftver, mint a ClickHouse, amely belső fürtön fut, de a kliens szemszögéből nézve sok a közös a ClickHouse-szal. A BigQuery gyorsan megdrágulhat, ha elkezd fizetni a SELECT-enként, így ez egy igazi SaaS-megoldás minden előnyével és hátrányával együtt.
A ClickHouse a legjobb választás, ha sok számítási szempontból költséges lekérdezést futtat. Minél több SELECT lekérdezést futtat le naponta, annál értelmesebb a Big Queryt ClickHouse-ra cserélni, mert egy ilyen csere több ezer dollárt takaríthat meg, ha sok terabájt adatfeldolgozásról van szó. Ez nem vonatkozik a tárolt adatokra, amelyek feldolgozása a Big Queryben meglehetősen olcsó.
Alexander Zaicev, az Altinity társalapítójának cikkében beszél egy ilyen DBMS-migráció előnyeiről.
TimescaleDB csere
A TimescaleDB egy PostgreSQL kiterjesztés, amely optimalizálja az idősorok idősoraival való munkát egy normál adatbázisban (, ).
Bár a ClickHouse nem komoly versenytárs az idősorok, de az oszlopos szerkezetű és vektoros lekérdezés-végrehajtás résében, az analitikus lekérdezések feldolgozása legtöbb esetben sokkal gyorsabb, mint a TimescaleDB. Ugyanakkor a ClickHouse kötegelt adatok fogadásának teljesítménye körülbelül 3-szor nagyobb, és 20-szor kevesebb lemezterületet használ, ami nagyon fontos nagy mennyiségű előzményadat feldolgozásához: .
A ClickHouse-szal ellentétben a TimescaleDB lemezterületének egyetlen módja a ZFS vagy hasonló fájlrendszerek használata.
A ClickHouse közelgő frissítései valószínűleg delta tömörítést vezetnek be, ami még alkalmasabbá teszi az idősorok adatainak feldolgozására és tárolására. A TimescaleDB jobb választás lehet, mint a csupasz ClickHouse a következő esetekben:
- kis telepítések nagyon kevés RAM-mal (<3 GB);
- nagyszámú kis INSERT, amelyeket nem szeretne nagy töredékekre pufferelni;
- jobb konzisztencia, egységesség és savkövetelmények;
- PostGIS támogatás;
- a meglévő PostgreSQL táblákhoz való csatlakozás, mivel a Timescale DB lényegében PostgreSQL.
Verseny a Hadoop és MapReduce rendszerekkel
A Hadoop és más MapReduce termékek sok bonyolult számítást képesek elvégezni, de általában hatalmas késleltetéssel futnak. A ClickHouse terabájtnyi adat feldolgozásával és szinte azonnali eredményekkel orvosolja ezt a problémát. Így a ClickHouse sokkal hatékonyabban végez gyors, interaktív analitikus kutatásokat, amelyek érdekesek lehetnek az adatkutatók számára.
Verseny Pinot-val és Druidával
A ClickHouse legközelebbi versenytársai az oszlopos, lineárisan méretezhető nyílt forráskódú Pinot és Druid termékek. A cikkben egy kiváló munka található ezen rendszerek összehasonlításában 1. február 2018
Ez a cikk frissítésre szorul - azt írja, hogy a ClickHouse nem támogatja az UPDATE és DELETE műveleteket, ami nem teljesen igaz a legújabb verziókra.
Nincs sok tapasztalatunk ezekkel az adatbázisokkal, de nem igazán szeretem a Druid és Pinot futtatásához szükséges infrastruktúra összetettségét – ez egy egész csomó mozgó alkatrész, amelyet minden oldalról Java vesz körül.
A Druid és a Pinot Apache inkubátorprojektek, amelyek előrehaladásáról az Apache részletesen beszámol GitHub projektoldalain. Pinot 2018 októberében jelent meg az inkubátorban, Druid pedig 8 hónappal korábban – februárban – született.
Az AFS működésével kapcsolatos információk hiánya felvet bennem néhány, és talán ostoba kérdést. Érdekelne, hogy a Pinot szerzői észrevették-e, hogy az Apache Alapítvány kedvezőbb a druidákkal szemben, és ez a versenytárshoz való viszony irigységet váltott ki? Druid fejlődése lelassul, Pinot fejlődése felgyorsul, ha előbbi támogatói hirtelen érdeklődni kezdenek az utóbbi iránt?
A ClickHouse hátrányai
Éretlenség: Nyilvánvalóan ez még mindig nem egy unalmas technológia, de mindenesetre semmi ilyesmi nem figyelhető meg más oszlopos DBMS-ekben.
A kis lapkák nem teljesítenek jól nagy sebességgel: a betéteket nagyobb darabokra kell osztani, mert a kis lapkák teljesítménye az egyes sorban lévő oszlopok számával arányosan romlik. A ClickHouse így tárolja az adatokat a lemezen - minden oszlop 1 vagy több fájlt jelent, tehát 1 oszlopot tartalmazó sor beszúrásához legalább 100 fájlt kell megnyitnia és írnia. Ez az oka annak, hogy a beszúrások puffereléséhez közvetítőre van szükség (kivéve, ha maga az ügyfél biztosítja a pufferelést) - általában Kafka vagy valamilyen sorkezelő rendszer. Használhatja a puffertábla motort is, hogy később nagy adatdarabokat másoljon MergeTree táblákba.
A tábla csatlakozásokat a szerver RAM-ja korlátozza, de legalább ott vannak! Például a Druid és a Pinot egyáltalán nem rendelkeznek ilyen kapcsolatokkal, mivel nehéz közvetlenül megvalósítani azokat az elosztott rendszerekben, amelyek nem támogatják a nagy adattömbök csomópontok közötti mozgatását.
Álláspontja
Terveink szerint az elkövetkező években széles körben használjuk a ClickHouse-t a Qwintry-ben, mivel ez a DBMS kiváló egyensúlyt biztosít a teljesítmény, az alacsony általános költségek, a méretezhetőség és az egyszerűség között. Biztos vagyok benne, hogy gyorsan el fog terjedni, amint a ClickHouse közösség több módot talál a kis és közepes méretű telepítésekben való használatára.
Néhány hirdetés 🙂
Köszönjük, hogy velünk tartott. Tetszenek cikkeink? További érdekes tartalmakat szeretne látni? Támogass minket rendeléssel vagy ajánlj ismerőseidnek, , a belépő szintű szerverek egyedülálló analógja, amelyet mi találtunk ki Önnek: (RAID1 és RAID10, akár 24 maggal és akár 40 GB DDR4-gyel is elérhető).
A Dell R730xd kétszer olcsóbb az amszterdami Equinix Tier IV adatközpontban? Csak itt Hollandiában! Dell R420 - 2x E5-2430 2.2 Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99 dollártól! Olvasni valamiről
Forrás: will.com