Kuidas me testisime mitmeid ajareadade andmebaase

Viimastel aastatel on ajareaktsioonide andmebaasid muutunud haruldasest nähtusest (spetsialiseeritud peamiselt kas avatud seire-süsteemides või Big Data projektides) „rahvatooteks“. Venemaal on selle eest erilised tänud Jaandekse ja ClickHouse’i suunas. Enne seda, kui teil oli vajalik salvestada suur hulk ajareaktsioonide andmeid, pidi olema kas valmis üles tõstma monstratiivse Hadoopi virna ja seda haldama või suhtlema teie süsteemile individuaalsete protokollidega.

Võib tunduda, et 2019. aastal koosneks artikkel sellest, millist TSDB-d kasutada, ainult ühest lausest: „lihtsalt kasutage ClickHouse’i“. Kuid... on nüansse.

Tõepoolest, ClickHouse areneb kiiresti, kasutajaskond kasvab ja toetus on aktiivne, kuid kas me pole saanud ClickHouse’i avaliku edusöödu vangideks, mis on varju visanud teised, võib-olla tõhusamad/usaldusväärsemad lahendused?

Eelmisel aastal alustasime oma seire-süsteemi ümberdisainimist, mille käigus tõusis küsimus sobiva andmebaasi valimise üle. Soovin jagada siin selle valiku ajalugu.

Ülesande seadmine

Kõigepealt — vajalik eelkommendi. Miks me vajame omamoodi seire-süsteemi ja kuidas see toimis?

Alustasime tugiteenuste osutamist 2008. aastal, ja 2010. aastaks sai selgeks, et klientide infrastruktuuridest saadud andmete kogumine olemasolevate lahendustega (me räägime, palun, Cacti’st, Zabbixist ja tekkivast Graphitest) muutus keeruliseks.

Meie peamised nõuded olid:

• toetamine (sel hetkel — kümnete, tulevikus — sadade) klientide raamistikus ja samas keskline teavitamissüsteem;
• paindlikkus teavitamissüsteemi haldamisel (teavituste eskaleerimine vahetult vastutajate vahel, ajakava arvestamine, teadmusbaas);
• võimalus detailseks graafikute detailimiseks (Zabbix joonistas sel hetkel graafikuid piltidena);
• pikaajaline suurte andmehulkade säilitamine (aasta või rohkem) ja nende kiire leidmine.

Käesolevas artiklis huvitab meid viimane punkt.

Rääkides salvestusest, olid nõuded järgmised:

• süsteem peab kiiresti töötama;
• soovitav on, et süsteemil oleks SQL-liides;
• süsteem peab olema stabiilne ning tal olema aktiivne kasutajabaas ja tugi (oleme kunagi pidanud toetama selliseid süsteeme nagu MemcacheDB, mida enam ei arendatud, või jaotatud salvestust MooseFS, mille bug tracker oli hiina keeles: me ei tahtnud oma projektiga seda ajalugu korrata);
• CAP-teoreemi järgimine: Consistency (vajalik) — andmed peavad olema ajakohased, me ei soovi, et teavitushaldussüsteem ei saaks uusi andmeid ja annaks häireid, et andmeid ei ole jõudnud kõigisse projektidesse; Partition Tolerance (vajalik) — me ei soovi saada Split Brain süsteemi; Availability (ei ole kriitiline, kui olemas on aktiivne koopia) — saame ise lülituda varusüsteemile, kui juhtub avarii, koodiga.

Ometi, kummalisel kombel, oli sel hetkel meie jaoks ideaalne lahendus MySQL. Meie andmestruktuur oli äärmiselt lihtne: serveri id, arvesti id, timestamp ja väärtus; kiire kuumade andmete valik tagati suure buffer pool'i suuruse, ajalooliste andmete valik — SSD.

Nii saavutasime värskete kahe nädala andmete valiku, sekundi detailsusega 200 ms enne andmete täielikku joonistamist, ja elasime selles süsteemis üsna kaua.

Vahepeal möödus aeg ja andmete hulk kasvas. 2016. aastaks ulatus andmehulk kümnete terabaitideni, mis renditud SSD-salvestuste puhul oli märkimisväärne kulu.

Selleks ajaks oli suurenenud kolonnandmebaaside levik, mille üle hakkasime aktiivselt mõtlema: kolonnandmebaasides hoitakse andmeid, nagu võime aru saada, kolonnide kaupa, ja kui vaadata meie andmeid, on lihtne näha suurt hulka dublette, mida võiks kolonnandmebaasi kasutamisel tihendamisega kokku suruda.

Siiski töötas ettevõtte jaoks võtmesüsteem stabiilselt edasi ja ei olnud soovi katsetada millegi teisega üleminekut.

2017. aastal toimunud Percona Live konverentsil San José's teatas esmakordselt endast Clickhouse'i arendajad. Esmapilgul näis süsteem tootmisvalmis olevat (noh, Yandex.Metrika — see on karm tootmine), tugi oli kiire ja lihtne ning mis kõige tähtsam, haldamine oli lihtne. Alates 2018. aastast alustasime ülemineku protsessi. Kuid toona oli palju 'küpseid' ja ajaga proovitud TSDB-süsteeme ning otsustasime eraldada märkimisväärse aja alternatiivide võrdlemiseks, et veenduda, et meie nõuetega vastavaid alternatiive Clickhouse'ile ei ole.

Lisaks juba mainitud nõuetele andmete hoidmiseks ilmusid uued:

• uus süsteem peab tagama vähemalt sama jõudluse nagu MySQL, samade riistvararessursside juures;
• uue süsteemi andmehoidla maht peab olema oluliselt väiksem;
• Andmebaas peab endiselt olema lihtne hallata;
• soovisime, et rakendust oleks minimaalne muuta andmebaasi vahetusel.

Milliseid süsteeme hakkasime vaatama

Apache Hive/Apache Impala
Küps ja laialdaselt testitud Hadoopi tehnoloogiast. Tegelikult on see SQL-liides, mis on üles ehitatud andmete hoidmisele oma formaatides HDFS-is.

Plussid.

• Stabiilses töökorralduses on andmete skaleerimine väga lihtne.
• On olemas veergude lahendused andmete hoidmiseks (vähem ruumi).
• Paralleelsete ülesannete täitmine on ressursside olemasolul väga kiire.

Miinused.

• See on Hadoop ja selle kasutamine on keeruline. Kui me ei ole valmis kasutama valmislahendust pilves (ja me ei ole hinna tõttu valmis), on kogu tehnoloogiaadministraatorite kätesse kokku koguda ja hallata ning seda ei oleks me väga soovinud.
• Andmed koondatakse tõeliselt kiiresti.

Siiski:

Kiirus saavutatakse arvutusserverite arvu skaleerimisega. Teisisõnu, kui me oleme suur ettevõte, tegeleme analüütikaga ja äri jaoks on kriitiliselt oluline maksimumkiirusel teavet koondada (isegi kui see tähendab suurt hulka arvutusressursse), võib see olla meie valik. Kuid me ei olnud valmis oluliselt suurendama riistvara parki ülesannete täitmise kiiruse nimel.

Druid/Pinot

Oleme juba palju lähemal konkreetselt TSDB-le, kuid jälle - Hadoopi tehnoloogia.

Jah suurepärane artikkel, mis võrdleb Druid'i ja Pinot'i plusse ja miinuseid ClickHouse'iga .

Kokkuvõttes: Druid/Pinot näivad Clickhouse'ist paremad olukordades, kui:

• Teie andmed on heterogeensed (meie puhul salvestame ainult serveri mõõdikute ajaseeriaid ning see on sisuliselt üks tabel. Ent võivad olla ka teised juhtumid: seadmete ajaseeriad, majanduslikud ajaseeriad jne — igaühel oma struktuur, mida tuleb kokku koguda ja töödelda).
• Samuti on neid andmeid väga palju.
• Tabelid ja ajaseeriad tulevad ja kaovad (see tähendab, et mingisugune andmekogum saabub, seda analüüsitakse ja seejärel kustutatakse).
• Pole selget kriteeriumi, mille alusel andmeid partitsioneerida.

Vastupidistes juhtudel töötab ClickHouse paremini, see kehtib meie kohta.

ClickHouse

• SQL-sarnane.
• Lihtne hallata.
• Inimesed ütlevad, et see toimib.

Jõuab testimise lühinimekirja.

InfluxDB

Välismaine alternatiiv ClickHouse'ile. Puudusteks on: kõrge saadavus on olemas ainult kommertsversioonis, kuid tuleks võrrelda.

Jõuab testimise lühinimekirja.

Cassandra

Ühest küljest teame, et seda kasutatakse mõõtmisajaseeriate salvestamiseks sellistes monitooringusüsteemides nagu näiteks, SignalFX või OkMeter. Siiski on siin omad eripärad.

Cassandra ei ole kolonnibaas andmebaas traditsioonilises mõttes. See näeb pigem välja nagu rea-aga igas reas võib olla erinev arv veerge, millega on lihtne korraldada kolonnide esitamist. Sel moel on mõistetav, et 2 miljardi veeru piiri korral on võimalik salvestada andmeid just veergude kaupa (näiteks samu ajaseeriesid). Näiteks MySQL-is on piirmääraks 4096 veergu ja seal võivad kergesti esineda vead koodiga 1117, kui proovitakse teha sama.

Cassandra mootor on suunatud suurte andmehulkade salvestamisele jaotatud süsteemis ilma peamasterita, ning eelnevalt mainitud CAP-teoorias kaldub Cassandra rohkem AP-ile, st andmete kättesaadavusele ja partitsioonide jagunemise taluvusele. Seetõttu sobib see tööriist suurepäraselt, kui on vaja ainult kirjutada sellesse andmebaasi ja harva lugeda. Siin on loogiline kasutada Cassandrat kui „külma“ salvestust. See tähendab, et tegemist on pikaajalise usaldusväärse kohaga suurte ajalooliste andmehulkade säilitamiseks, mis on harva vajalikud, kuid kui vaja, saab neid kätte. Siiski, täielikkuse huvides testime seda ka. Kuid nagu ma varem ütlesin, ei ole soovi aktiivselt koodi valitud andmebaasi lahenduse järgi ümber kirjutada, seega testime seda veidi piiratud viisil — ilma andmebaasi struktuuri kohandamiseta Cassandra spetsiifilistele omadustele.

Prometheus

No ja juba huvi pärast otsustasime testida Prometheuse salvestusvõimekust — lihtsalt selleks, et mõista, kas oleme kiiremad või aeglasemad kui meie praegused lahendused ja kui palju.

Testimise metoodika ja tulemused

Nii, testisime 5 andmebaasi järgmistes 6 konfiguratsioonis: ClickHouse (1 sõlm), ClickHouse (jaotatud tabel 3 sõlmega), InfluxDB, Mysql 8, Cassandra (3 sõlme) ja Prometheus. Testimise plaan on järgmine:

1. laadime nädalase ajaloolise andmesisalduse (840 miljonit väärtust päevas; 208 tuhat mõõdikut);
2. genereerime kirjutuskoormust (vaatasime 6 koormuse režiimi, vt allpool);
3. samuti teeme perioodiliselt valimisi kirjutamise ajal, simuleerides kasutaja päringute tegemist, kes töötab diagrammidega. Liialt keeruliseks minemata valisime andmed 10 mõõdiku kohta (just nii palju neid CPU diagrammil on) nädalaks.

Koormame, simuleerides meie monitooringu agendi käitumist, kes saadab iga mõõdiku väärtused iga 15 sekundi tagant. Sellega seoses on meil huvi varieerida:

• mõõdikutega, kuhu andmeid kirjutatakse;
• väärtuste edastamise intervalli ühte mõõdikut;
• partii suurust.

Partii suurusest. Kuna peaaegu kõik meie katseandmebaasid ei soovita koormata üksikute sissekannetega, on meil vaja relaat, mis kogub saabuvad mõõdikud ja grupeerib need mingisuguste järgi ning kirjutab need andmebaasi partii sissekandega.

Samuti, et paremini mõista, kuidas hiljem saadud andmeid tõlgendada, kujutame ette, et me ei saada lihtsalt kuhja mõõdikuid, vaid mõõdikud on korraldatud serverite kaupa — 125 mõõdikut serveri kohta. Siin on server lihtsalt virtuaalne entiteet — lihtsalt selleks, et mõista, et näiteks 10000 mõõdikut vastavad umbes 80 serverile.

Nii et silmas pidades meie kuut kirjutamisrežiimi koormust:

Siin on kaks aspekti. Esiteks, Cassandra jaoks olid sellised partiide suurused liiga suured, seal kasutasime väärtusi 50 või 100. Teiseks, kuna Prometheus töötab rangelt pull-režiimis, st see läheb ise ja võtab andmeid mõõdikute allikatest (isegi pushgateway, vaatamata oma nimele, ei muuda olukorda), siis vastavad koormused olid realiseeritud statiilsete konfiguratsioonide kombinatsiooniga.

Testimise tulemused on järgmised:

Mida tasub märkida: fantastiliselt kiired päringud Prometheuses, häbiväärselt aeglased päringud Cassandra's, vastuvõetamatult aeglased päringud InfluxDB-s; kirjutamise kiiruselt võitis ClickHouse, ning Prometheus ei osale konkursil, sest see teeb sisestused ise enda sees ja me ei mõõda midagi.

Kokkuvõttes: said parimaid tulemusi ClickHouse ja InfluxDB, kuid Influxi klastrit saab ehitada ainult Enterprise-versiooni põhjal, mis maksab raha, samas kui ClickHouse ei maksa midagi ja on valmistatud Venemaal. Loogiliselt, et USA-s eelistatakse tõenäoliselt InfluxDB-d, meie aga ClickHouse'i.

Allikas: habr.com