Az elmúlt néhány évben az idősoros adatbázisok egy szokatlan dologból (nagyon specializálódott, amelyet nyílt megfigyelő rendszerekben (és konkrét megoldásokhoz kötve), vagy Big Data projektekben használnak) „fogyasztói termékké” váltak. Az Orosz Föderáció területén külön köszönet illeti a Yandexet és a ClickHouse-t. Eddig a pontig, ha nagy mennyiségű idősoros adatot kellett tárolnia, akkor vagy meg kellett birkóznia egy hatalmas Hadoop-verem felépítésével és karbantartásával, vagy az egyes rendszerekhez egyedi protokollokkal kellett kommunikálnia.
Úgy tűnhet, hogy 2019-ben egy cikk, amelyről érdemes a TSDB-t használni, egyetlen mondatból áll majd: „csak használd a ClickHouse-t”. De... vannak árnyalatok.
Valóban, a ClickHouse aktívan fejlődik, nő a felhasználói bázis, és nagyon aktív a támogatás, de vajon túszai lettünk a ClickHouse nyilvános sikerének, amely háttérbe szorított más, talán hatékonyabb/megbízhatóbb megoldásokat?
Tavaly év elején kezdtük meg saját monitoring rendszerünk átdolgozását, melynek során felmerült az adattárolásra alkalmas adatbázis kiválasztásának kérdése. Ennek a választásnak a történetéről szeretnék itt beszélni.
Probléma nyilatkozat
Először is egy szükséges előszó. Miért van egyáltalán szükségünk saját monitoring rendszerre, és hogyan tervezték?
2008-ban kezdtük el a támogató szolgáltatásokat nyújtani, és 2010-re világossá vált, hogy az akkori megoldásokkal (az Isten bocsáss meg, Kaktusz, Zabbix) nehézzé vált az adatok összesítése a kliens infrastruktúrájában lezajló folyamatokról. és a kialakuló Grafit).
Főbb követelményeink a következők voltak:
- támogatás (akkoriban - több tucat, a jövőben - több száz) ügyfél egy rendszeren belül, és egyidejűleg egy központi riasztáskezelő rendszer jelenléte;
- rugalmasság a riasztási rendszer kezelésében (a riasztások eszkalációja az ügyeletesek között, ütemezés, tudásbázis);
- a grafikonok mély részletezésének képessége (A Zabbix akkoriban a grafikonokat képek formájában renderelte);
- nagy mennyiségű adat hosszú távú tárolása (egy év vagy több) és a gyors visszakeresés lehetősége.
Ebben a cikkben az utolsó pontra vagyunk kíváncsiak.
Ha már a tárolásnál tartunk, a követelmények a következők voltak:
- a rendszernek gyorsan kell működnie;
- kívánatos, hogy a rendszer rendelkezzen SQL interfésszel;
- a rendszernek stabilnak kell lennie, aktív felhasználói bázissal és támogatással kell rendelkeznie (mikor szembesültünk azzal, hogy olyan rendszereket kell támogatni, mint a MemcacheDB, amelyet már nem fejlesztettek ki, vagy a MooseFS elosztott tárhely, amelynek hibakövetőjét kínai nyelven tartották: megismételjük ezt a történetet a projektünk nem akarta);
- megfelelés a CAP tételnek: Konzisztencia (kötelező) - az adatoknak naprakésznek kell lenniük, nem szeretnénk, hogy a riasztáskezelő rendszer ne kapjon új adatokat és ne köpjön ki riasztásokat az adatok meg nem érkezéséről minden projekt esetében; Partíciótűrés (kötelező) - nem akarunk Split Brain rendszert kapni; Elérhetőség (nem kritikus, ha van aktív replika) - baleset esetén saját magunk is át tudunk kapcsolni a tartalék rendszerre, kód segítségével.
Furcsa módon abban az időben a MySQL bizonyult számunkra az ideális megoldásnak. Adatstruktúránk rendkívül egyszerű volt: szerverazonosító, számlálóazonosító, időbélyeg és érték; a forró adatok gyors mintavételét nagy pufferkészlet, a historikus adatok mintavételezését pedig SSD biztosította.
Így kaptunk egy mintát friss kéthetes adatokból, 200 ms-ig egészen az adatok teljes megjelenítése előtti részletességgel, és elég sokáig ebben a rendszerben éltünk.
Közben telt az idő, és nőtt az adatok mennyisége. 2016-ra az adatmennyiség elérte a több tíz terabájtot, ami jelentős kiadást jelentett a bérelt SSD tárhely kapcsán.
Ekkorra már aktívan elterjedtek az oszlopos adatbázisok, amelyekről elkezdtünk aktívan gondolkodni: az oszlopos adatbázisokban az adatok, mint érthető, oszlopokban tárolódnak, és ha ránézünk az adatainkra, könnyen látható egy nagy az ismétlődések száma, ha oszlopos adatbázist használ, tömörítéssel tömörítse azt.
A cég kulcsrendszere azonban továbbra is stabilan működött, és nem akartam másra váltással kísérletezni.
2017-ben, a San José-i Percona Live konferencián a Clickhouse fejlesztői valószínűleg először jelentették be magukat. Első pillantásra a rendszer készen áll a gyártásra (na jó, a Yandex.Metrica egy kemény termelési rendszer), a támogatás gyors és egyszerű volt, és ami a legfontosabb, a működés egyszerű. 2018 óta megkezdtük az átállási folyamatot. De addigra már rengeteg „felnőtt” és időtesztelt TSDB rendszer létezett, és úgy döntöttünk, hogy jelentős időt fordítunk az alternatívák összehasonlítására annak érdekében, hogy megbizonyosodjunk arról, hogy a Clickhouse-nak nincs alternatív megoldása az igényeinknek megfelelően.
A már meghatározott tárolási követelmények mellett újak jelentek meg:
- az új rendszernek legalább ugyanolyan teljesítményt kell nyújtania, mint a MySQL-nek ugyanannyi hardveren;
- az új rendszer tárolása lényegesen kevesebb helyet foglaljon;
- A DBMS-nek továbbra is könnyen kezelhetőnek kell lennie;
- Az alkalmazást minimálisan akartam módosítani a DBMS megváltoztatásakor.
Milyen rendszerekkel kezdtünk foglalkozni?
Apache Hive/Apache Impala
Egy régi, csatában tesztelt Hadoop verem. Lényegében ez egy SQL interfész, amely az adatok natív formátumú HDFS-en történő tárolására épül.
Profik.
- Stabil működés mellett nagyon egyszerű az adatok méretezése.
- Adattárolásra (kevesebb hely) vannak oszlopos megoldások.
- Nagyon gyors párhuzamos feladatok végrehajtása, ha rendelkezésre állnak az erőforrások.
Cons.
- Ez Hadoop, és nehéz használni. Ha nem vagyunk készek egy kész megoldást a felhőben elfogadni (és nem vagyunk készek a költségek szempontjából), akkor a teljes stack-et össze kell szerelni és támogatni kell az adminisztrátorok kezével, és nagyon nem akarjuk ez.
- Az adatok összesítve vannak .
azonban:
A sebesség a számítási szerverek számának skálázásával érhető el. Leegyszerűsítve, ha egy nagy cég vagyunk, analitikával foglalkozunk, és a vállalkozás számára kritikus az információk minél gyorsabb összesítése (akár nagy mennyiségű számítási erőforrás igénybevétele árán is), akkor ez a mi választásunk. De nem álltunk készen arra, hogy megsokszorozzuk a hardverflottát a feladatok felgyorsítása érdekében.
Druida/Pinot
Sokkal többről van szó konkrétan a TSDB-ről, de ismét a Hadoop veremről.
Van .
Néhány szóban: a Druid/Pinot jobban néz ki, mint a Clickhouse olyan esetekben, amikor:
- Az adatok heterogén természetűek (esetünkben csak a szervermetrikák idősorait rögzítjük, és valójában ez egy tábla. De lehetnek más esetek is: berendezések idősorai, gazdasági idősorok stb. saját szerkezete, amelyeket összesíteni és feldolgozni kell).
- Ráadásul sok ilyen adat van.
- Megjelennek és eltűnnek az idősoros táblák és adatok (azaz bizonyos adathalmazok érkeztek, elemezték és törölték).
- Nincs egyértelmű kritérium, amely alapján az adatok particionálhatók.
Ellenkező esetekben a ClickHouse jobban teljesít, és ez a mi esetünk.
Kattintson a Ház gombra
- SQL-szerű
- Könnyen kezelhető.
- Az emberek azt mondják, hogy működik.
Bekerül a tesztelésre.
InfluxDB
A ClickHouse külföldi alternatívája. A mínuszok közül: A magas rendelkezésre állás csak a kereskedelmi verzióban van jelen, de össze kell hasonlítani.
Bekerül a tesztelésre.
Cassandra
Egyrészt tudjuk, hogy metrikus idősorok tárolására használják olyan megfigyelő rendszerek, mint pl. vagy OkMeter. Vannak azonban konkrétumok.
A Cassandra nem hagyományos értelemben vett oszlopos adatbázis. Inkább sornézetnek tűnik, de minden sor eltérő számú oszlopot tartalmazhat, ami megkönnyíti az oszlopos nézet megszervezését. Ebben az értelemben egyértelmű, hogy 2 milliárd oszlopos korlát mellett lehetőség van egyes adatok oszlopokban (és ugyanazon idősorokban) tárolására. Például a MySQL-ben 4096 oszlop van korlátozva, és könnyű hibába botlani az 1117-es kóddal, ha ugyanezt próbálja megtenni.
A Cassandra motor nagy mennyiségű adat tárolására fókuszál elosztott rendszerben master nélkül, a fentebb említett Cassandra CAP tétel pedig inkább az AP-ről, vagyis az adatok elérhetőségéről és a particionálással szembeni ellenállásról szól. Így ez az eszköz nagyszerű lehet, ha csak írni kell ebbe az adatbázisba, és ritkán olvasni belőle. És itt logikus, hogy Cassandrát „hideg” tárolóként használjuk. Vagyis hosszú távú, megbízható helyként nagy mennyiségű történelmi adat tárolására, amelyekre ritkán van szükség, de szükség esetén visszakereshetők. Ennek ellenére a teljesség kedvéért mi is teszteljük. De ahogy korábban is mondtam, nincs vágy a kiválasztott adatbázis-megoldás kódjának aktív átírására, ezért kissé korlátozottan teszteljük - anélkül, hogy az adatbázis-struktúrát a Cassandra sajátosságaihoz igazítanánk.
Prométheusz
Nos, kíváncsiságból úgy döntöttünk, hogy teszteljük a Prometheus tároló teljesítményét – csak azért, hogy megértsük, gyorsabbak vagy lassabbak vagyunk-e a jelenlegi megoldásoknál, és mennyivel.
Vizsgálati módszertan és eredmények
Tehát 5 adatbázist teszteltünk a következő 6 konfigurációban: ClickHouse (1 csomópont), ClickHouse (elosztott táblázat 3 csomóponthoz), InfluxDB, Mysql 8, Cassandra (3 csomópont) és Prometheus. A tesztterv a következő:
- előzményadatok feltöltése egy hétre (840 millió érték naponta; 208 ezer mérőszám);
- rögzítési terhelést generálunk (6 terhelési módot vettünk figyelembe, lásd alább);
- A rögzítéssel párhuzamosan időszakonként kijelöléseket végzünk, emulálva a diagramokkal dolgozó felhasználó kéréseit. Hogy ne bonyolítsuk túl a dolgokat, egy hétre 10 mérőszámhoz (pontosan ennyi van a CPU-grafikonon) válogattunk ki adatokat.
A betöltést a megfigyelő ügynökünk viselkedésének emulálásával végezzük, amely 15 másodpercenként küld értékeket minden metrikának. Ugyanakkor érdekeltek minket a következők:
- azon metrikák teljes száma, amelyekbe az adatokat írják;
- intervallum az értékek egy metrikához való küldéséhez;
- csomó méret.
A tétel méretéről. Mivel nem ajánlott szinte minden kísérleti adatbázisunkat egyszeri beillesztéssel betölteni, szükségünk lesz egy közvetítőre, amely összegyűjti a bejövő metrikákat és csoportokba csoportosítja, és kötegelt beszúrásként írja be az adatbázisba.
Továbbá, hogy jobban megértsük, hogyan kell értelmezni a kapott adatokat, képzeljük el, hogy nem csak egy csomó mérőszámot küldünk, hanem a mérőszámok szerverekbe vannak rendezve – szerverenként 125 mérőszám. Itt a szerver egyszerűen egy virtuális entitás – csak azért, hogy megértsük, hogy például 10000 80 mérőszám körülbelül XNUMX szervernek felel meg.
És mindezt figyelembe véve itt van a 6 adatbázis írási betöltési módunk:
Itt két pont van. Először is, Cassandra esetében ezek a tételméretek túl nagynak bizonyultak, ott 50 vagy 100 értéket használtunk. Másodszor pedig, mivel a Prometheus szigorúan húzó üzemmódban működik, pl. maga megy, és adatokat gyűjt a metrika forrásokból (és még a pushgateway, a név ellenére sem változtat alapvetően a helyzeten), a megfelelő betöltéseket statikus konfigurációk kombinációjával valósították meg.
A teszt eredményei a következők:
Amit érdemes megjegyezni: fantasztikusan gyors minták a Prometheustól, rettenetesen lassú minták a Cassandrától, elfogadhatatlanul lassú minták az InfluxDB-től; Felvételi sebességet tekintve mindenkit megnyert a ClickHouse, a Prometheus pedig nem vesz részt a versenyen, mert magában készít betéteket és nem mérünk semmit.
Ennek eredményeképpen,: A ClickHouse és az InfluxDB mutatta magát a legjobbnak, de az Influxból klasztert csak az Enterprise verzió alapján lehet építeni, ami pénzbe kerül, a ClickHouse viszont semmibe és Oroszországban készül. Logikus, hogy az USA-ban valószínűleg az inInfluxDB, nálunk pedig a ClickHouse mellett döntenek.
Forrás: will.com