Viimaste aastate jooksul on aegridade andmebaasid muutunud veidrast asjast (kõrgelt spetsialiseerunud, mida kasutatakse avatud seiresüsteemides (ja seotud konkreetsete lahendustega) või suurandmete projektides) "tarbekaubaks". Vene Föderatsiooni territooriumil tuleb selle eest eriliselt tänada Yandexi ja ClickHouse'i. Kuni selle hetkeni, kui teil oli vaja salvestada suurel hulgal aegridade andmeid, tuli teil kas leppida vajadusega luua koletu Hadoopi virn ja seda hooldada või suhelda iga süsteemi jaoks eraldi protokollidega.
Võib tunduda, et aastal 2019 koosneb artikkel, mille kohta TSDB-d tasub kasutada, ainult ühest lausest: "kasuta lihtsalt ClickHouse'i". Aga... on nüansse.
Tõepoolest, ClickHouse areneb aktiivselt, kasutajaskond kasvab ja toetus on väga aktiivne, kuid kas oleme saanud ClickHouse'i avaliku edu pantvangideks, mis on varjutanud teised, võib-olla tõhusamad/usaldusväärsemad lahendused?
Eelmise aasta alguses alustasime enda seiresüsteemi ümbertöötamist, mille käigus tekkis küsimus andmete salvestamiseks sobiva andmebaasi valikust. Tahan siinkohal rääkida selle valiku ajaloost.
Probleemi avaldus
Kõigepealt vajalik eessõna. Milleks meil üldse oma seiresüsteemi vaja on ja kuidas see loodud on?
Alustasime tugiteenuste osutamisega 2008. aastal ning 2010. aastaks sai selgeks, et tol hetkel eksisteerinud lahendustega (jutt on jumal andke andeks, Cacti, Zabbix) muutus keeruliseks andmete koondamine kliendi infrastruktuuris toimuvate protsesside kohta. ja tekkiv grafiit).
Meie peamised nõuded olid:
- toetada (sel ajal - kümneid ja tulevikus - sadu) kliente ühes süsteemis ja samal ajal tsentraliseeritud hoiatushaldussüsteemi olemasolu;
- häiresüsteemi haldamise paindlikkus (hoiatuste eskaleerimine valveametnike vahel, ajakava, teadmistebaas);
- graafikute sügava detailistamise oskus (Zabbix renderdas sel ajal graafikuid piltidena);
- suure andmehulga pikaajaline säilitamine (aasta või rohkem) ja võimalus need kiiresti kätte saada.
Selles artiklis oleme huvitatud viimasest punktist.
Ladustusest rääkides olid nõuded järgmised:
- süsteem peab töötama kiiresti;
- on soovitav, et süsteemil oleks SQL-liides;
- süsteem peab olema stabiilne ning sellel peab olema aktiivne kasutajabaas ja tugi (kui olime silmitsi vajadusega toetada selliseid süsteeme nagu MemcacheDB, mida enam ei arendatud, või MooseFS-i hajutatud salvestusruum, mille veajälgija oli hiina keeles: kordame seda lugu meie projekti jaoks ei tahtnud);
- vastavus ÜPP teoreemile: Kooskõla (nõutav) - andmed peavad olema ajakohased, me ei soovi, et häirehaldussüsteem ei saaks uusi andmeid ja sülitaks välja hoiatusi kõigi projektide andmete mittesaabumise kohta; Partition Tolerance (nõutav) - me ei taha saada Split Brain süsteemi; Kättesaadavus (mitte kriitiline, kui on aktiivne replika) - saame ise lülituda avarii korral varusüsteemile, kasutades koodi.
Kummalisel kombel osutus tollal MySQL meie jaoks ideaalseks lahenduseks. Meie andmestruktuur oli äärmiselt lihtne: serveri ID, loenduri ID, ajatempel ja väärtus; kuumade andmete kiire proovivõtmise tagas suur puhverkogum ning ajalooliste andmete diskreetimise tagas SSD.
Nii saavutasime valiku värskeid kahe nädala andmeid, mille üksikasjad ulatusid sekundini 200 ms enne andmete täielikku renderdamist, ja elasime selles süsteemis üsna kaua.
Vahepeal läks aeg ja andmete hulk kasvas. 2016. aastaks ulatusid andmemahud kümnete terabaitideni, mis oli renditud SSD-mäluruumi kontekstis märkimisväärne kulu.
Selleks ajaks olid veerupõhised andmebaasid aktiivselt levinud, millele hakkasime aktiivselt mõtlema: veergude andmebaasides salvestatakse andmed, nagu aru saate, veergudes ja kui vaadata meie andmeid, on lihtne näha suurt duplikaatide arv, mis võiks veergude andmebaasi kasutamisel tihendada selle tihendamisega.
Ettevõtte võtmesüsteem töötas aga stabiilselt ja ma ei tahtnud katsetada millegi muuga üleminekuga.
2017. aastal San Joses toimunud Percona Live konverentsil andsid Clickhouse’i arendajad endast ilmselt esimest korda teada. Esmapilgul oli süsteem tootmisvalmis (noh, Yandex.Metrica on karm tootmissüsteem), tugi oli kiire ja lihtne ning mis kõige tähtsam, toimimine oli lihtne. Alates 2018. aastast oleme alustanud üleminekuprotsessi. Kuid selleks ajaks oli „täiskasvanutele“ mõeldud ja ajatestitud TSDB süsteeme palju ning otsustasime pühendada palju aega ja võrrelda alternatiive, et veenduda, et Clickhouse'ile pole meie vajadustele vastavaid alternatiivseid lahendusi.
Lisaks juba määratletud ladustamisnõuetele on ilmunud uued:
- uus süsteem peaks sama hulga riistvara puhul pakkuma vähemalt sama jõudlust kui MySQL;
- uue süsteemi salvestusruum peaks võtma oluliselt vähem ruumi;
- DBMS-i peab siiski olema lihtne hallata;
- Tahtsin DBMS-i muutmisel rakendust minimaalselt muuta.
Milliseid süsteeme me kaaluma hakkasime?
Apache Hive / Apache Impala
Vana, lahingutes testitud Hadoopi virn. Põhimõtteliselt on see SQL-i liides, mis on üles ehitatud HDFS-i algvormingutes andmete salvestamisele.
Plussid
- Stabiilse töö korral on andmete skaleerimine väga lihtne.
- Andmete salvestamiseks on veerulahendused (vähem ruumi).
- Paralleelsete ülesannete väga kiire täitmine, kui ressursse on saadaval.
Miinused
- See on Hadoop ja seda on raske kasutada. Kui me ei ole valmis pilves valmislahendust võtma (ja me pole valmis ka kulude osas), tuleb kogu pinu kokku panna ja administraatorite kätega toetada ja me tõesti ei taha see.
- Andmed on koondatud .
Kuid:
Kiirus saavutatakse arvutiserverite arvu skaleerimisega. Lihtsamalt öeldes, kui oleme suurettevõte, tegeleme analüütikaga ja ettevõtte jaoks on ülioluline koondada teave võimalikult kiiresti (isegi suure hulga arvutusressursside kasutamise hinnaga), võib see olla meie valik. Kuid me ei olnud valmis ülesannete kiirendamiseks riistvaraparki mitmekordistama.
Druiid/Pinot
TSDB kohta on palju rohkem, kuid jällegi Hadoopi pinu.
On .
Mõne sõnaga: Druid/Pinot näevad paremad välja kui Clickhouse juhtudel, kui:
- Teie andmed on heterogeensed (meie puhul salvestame ainult serverimõõdikute aegridu ja tegelikult on see üks tabel. Kuid võib olla ka teisi juhtumeid: seadmete aegread, majanduslikud aegread jne - igaüks neist oma struktuur, mida tuleb koondada ja töödelda).
- Pealegi on neid andmeid palju.
- Ilmuvad ja kaovad aegridadega tabelid ja andmed (st mingi andmekogum saabus, analüüsiti ja kustutati).
- Puudub selge kriteerium, mille alusel andmeid saab jaotada.
Vastupidisel juhul toimib ClickHouse paremini ja see on meie juhtum.
Klõpsake nuppu Maja
- SQL-i sarnane
- Lihtne hallata.
- Inimesed ütlevad, et see töötab.
Otsitakse testimiseks.
InfluxDB
Välismaa alternatiiv ClickHouse'ile. Miinustest: kõrge saadavus on olemas ainult kommertsversioonis, kuid seda tuleb võrrelda.
Otsitakse testimiseks.
Cassandra
Ühest küljest teame, et seda kasutavad meetermõõdustiku aegridade salvestamiseks sellised seiresüsteemid nagu näiteks või OkMeter. Siiski on spetsiifikat.
Cassandra ei ole traditsioonilises mõttes veeruline andmebaas. See näeb välja rohkem nagu reavaade, kuid igal real võib olla erinev arv veerge, mis muudab veeruvaate korraldamise lihtsaks. Selles mõttes on selge, et limiidiga 2 miljardit veergu on võimalik salvestada osa andmeid veergudesse (ja samasse aegrida). Näiteks MySQL-is on piirang 4096 veergu ja koodiga 1117 on lihtne viga komistada, kui proovite sama teha.
Cassandra mootor on keskendunud suurte andmemahtude salvestamisele hajussüsteemis ilma masterita ning ülalmainitud Cassandra CAP teoreem puudutab rohkem AP-d ehk andmete kättesaadavust ja vastupidavust partitsioonidele. Seega võib see tööriist olla suurepärane, kui teil on vaja ainult sellesse andmebaasi kirjutada ja sellest harva lugeda. Ja siin on loogiline kasutada Cassandrat "külma" hoidlana. See tähendab, et see on pikaajaline ja usaldusväärne koht suurte ajalooliste andmete salvestamiseks, mida harva vajatakse, kuid mida saab vajadusel hankida. Sellegipoolest testime seda täielikkuse huvides. Kuid nagu ma varem ütlesin, ei ole soovi valitud andmebaasilahenduse koodi aktiivselt ümber kirjutada, seega testime seda mõnevõrra piiratult - ilma andmebaasi struktuuri Cassandra spetsiifikaga kohandamata.
Prometheus
Noh, uudishimust otsustasime testida Prometheuse salvestusruumi jõudlust – lihtsalt selleks, et mõista, kas oleme praegustest lahendustest kiiremad või aeglasemad ja kui palju.
Testimise metoodika ja tulemused
Niisiis testisime 5 andmebaasi järgmises 6 konfiguratsioonis: ClickHouse (1 sõlm), ClickHouse (jaotatud tabel 3 sõlme jaoks), InfluxDB, Mysql 8, Cassandra (3 sõlme) ja Prometheus. Katseplaan on järgmine:
- laadige üles ajaloolised andmed nädala kohta (840 miljonit väärtust päevas; 208 tuhat mõõdikut);
- genereerime salvestuskoormuse (vaatati 6 laadimisrežiimi, vt allpool);
- Paralleelselt salvestamisega teeme perioodiliselt valikuid, emuleerides diagrammidega töötava kasutaja taotlusi. Et asju mitte liiga keeruliseks ajada, valisime nädalaks 10 mõõdiku (täpselt nii palju neid on protsessori graafikul) jaoks andmed.
Laadime, emuleerides meie jälgimisagendi käitumist, mis saadab igale mõõdikule väärtused iga 15 sekundi järel. Samal ajal oleme huvitatud erinevatest:
- mõõdikute koguarv, millesse andmed kirjutatakse;
- intervall väärtuste saatmiseks ühele mõõdikule;
- partii suurus.
Partii suuruse kohta. Kuna peaaegu kõiki meie eksperimentaalseid andmebaase ei soovitata laadida üksikute sisestustega, vajame releed, mis kogub sissetulevad mõõdikud ja rühmitab need rühmadesse ning kirjutab need andmebaasi partii sisestusena.
Samuti, et paremini mõista, kuidas saadud andmeid tõlgendada, kujutame ette, et me ei saada lihtsalt hunnikut mõõdikuid, vaid mõõdikud on korraldatud serveritesse – 125 mõõdikut serveri kohta. Siin on server lihtsalt virtuaalne üksus – selleks, et mõista, et näiteks 10000 80 mõõdikut vastavad umbes XNUMX serverile.
Ja siin, võttes seda kõike arvesse, on meie 6 andmebaasi kirjutamise laadimisrežiimi:
Siin on kaks punkti. Esiteks, Cassandra jaoks osutusid need partii suurused liiga suureks, kasutasime seal väärtusi 50 või 100. Ja teiseks, kuna Prometheus töötab rangelt tõmberežiimis, st. see ise läheb ja kogub andmeid mõõdikute allikatest (ja isegi pushgateway, vaatamata nimele, ei muuda olukorda põhimõtteliselt), vastavad koormused realiseeriti staatiliste konfiguratsioonide kombinatsiooni abil.
Testi tulemused on järgmised:
Mida tasub tähele panna: fantastiliselt kiired sämplid Prometheusest, kohutavalt aeglased sämplid Cassandrast, lubamatult aeglased sämplid InfluxDB-st; Salvestuskiiruselt võitis ClickHouse kõik ja Prometheus konkursil ei osale, sest teeb ise inserte ja meie ei mõõda midagi.
Selle tulemusena: ClickHouse ja InfluxDB näitasid end parimatest, kuid Influxi klastrit saab ehitada ainult Enterprise versiooni põhjal, mis maksab raha, ClickHouse aga ei maksa midagi ja on valmistatud Venemaal. Loogiline, et USA-s on valik ilmselt inInfluxDB kasuks ja meil ClickHouse'i kasuks.
Allikas: www.habr.com
