Muutaman viime vuoden aikana aikasarjatietokannat ovat muuttuneet oudosta asiasta (erittäin erikoistuneesta, jota käytetään joko avoimissa seurantajärjestelmissä (ja tiettyihin ratkaisuihin sidottuna) tai Big Data -projekteissa) "kuluttajatuotteeksi". Venäjän federaation alueella erityiskiitokset on annettava Yandexille ja ClickHouselle. Tähän asti, jos jouduit tallentamaan suuren määrän aikasarjadataa, sinun täytyi joko tyytyä tarpeeseen rakentaa hirvittävä Hadoop-pino ja ylläpitää sitä tai kommunikoida kullekin järjestelmälle yksilöllisten protokollien kanssa.
Saattaa näyttää siltä, että vuonna 2019 artikkeli, josta TSDB:tä kannattaa käyttää, koostuu vain yhdestä lauseesta: "käytä vain ClickHousea". Mutta... on vivahteita.
Todellakin, ClickHouse kehittyy aktiivisesti, käyttäjäkunta kasvaa ja tuki on erittäin aktiivista, mutta olemmeko joutuneet ClickHousen julkisen menestyksen panttivangeiksi, joka on jättänyt varjoonsa muut, ehkä tehokkaammat/luotettavammat ratkaisut?
Viime vuoden alussa aloitimme oman seurantajärjestelmän uudistamisen, jonka aikana heräsi kysymys sopivan tietokannan valinnasta tiedon tallentamiseen. Haluan puhua tämän valinnan historiasta täällä.
Ongelma
Ensinnäkin välttämätön esipuhe. Mihin ylipäätään tarvitsemme oman valvontajärjestelmän ja miten se on suunniteltu?
Aloitimme tukipalvelujen tarjoamisen vuonna 2008 ja vuoteen 2010 mennessä kävi selväksi, että asiakasinfrastruktuurissa tapahtuvien prosessien datan yhdistäminen oli vaikeaa tuolloin olemassa olevilla ratkaisuilla (puhumme Jumala anteeksi, Cacti, Zabbix ja nouseva grafiitti).
Tärkeimmät vaatimuksemme olivat:
- tuki (tuohon aikaan - kymmeniä ja tulevaisuudessa - satoja) asiakkaita yhdessä järjestelmässä ja samalla keskitetyn hälytyshallintajärjestelmän läsnäolo;
- joustavuus hälytysjärjestelmän hallinnassa (hälytysten eskalointi päivystajien välillä, aikataulut, tietopohja);
- kyky yksityiskohtaisesti kaavioita (Zabbix tuolloin renderöi kaavioita kuvien muodossa);
- suuren tietomäärän pitkäaikainen tallennus (vuosi tai enemmän) ja mahdollisuus hakea se nopeasti.
Tässä artikkelissa olemme kiinnostuneita viimeisestä kohdasta.
Säilytyksestä puheen ollen vaatimukset olivat seuraavat:
- järjestelmän on toimittava nopeasti;
- on toivottavaa, että järjestelmässä on SQL-liitäntä;
- järjestelmän on oltava vakaa ja sillä on oltava aktiivinen käyttäjäkunta ja tuki (kun kohtasimme tarpeen tukea järjestelmiä, kuten MemcacheDB, jota ei enää kehitetty, tai MooseFS-hajautettu tallennustila, jonka virheseuranta pidettiin kiinaksi: toistamme tämän tarinan projektillemme ei halunnut);
- YMP-teoreeman noudattaminen: Johdonmukaisuus (pakollinen) - tietojen on oltava ajan tasalla, emme halua, että hälytystenhallintajärjestelmä ei saa uusia tietoja ja sylkeä hälytyksiä tietojen saapumatta jättämisestä kaikkien hankkeiden osalta; Ositustoleranssi (pakollinen) - emme halua saada Split Brain -järjestelmää; Saatavuus (ei kriittinen, jos on aktiivinen replika) - voimme itse vaihtaa varajärjestelmään onnettomuuden sattuessa koodin avulla.
Kummallista kyllä, tuolloin MySQL osoittautui meille ihanteelliseksi ratkaisuksi. Tietorakenteemme oli erittäin yksinkertainen: palvelimen tunnus, laskurin tunnus, aikaleima ja arvo; Kuumien tietojen nopea näytteenotto varmistettiin suurella puskurivaralla ja historiallisten tietojen näytteenotto SSD:llä.
Siten saimme otoksen tuoreista kahden viikon tiedoista, joiden yksityiskohdat olivat sekuntia 200 ms ennen tietojen täydellistä renderöintiä, ja elimme tässä järjestelmässä melko pitkään.
Samaan aikaan aikaa kului ja tiedon määrä kasvoi. Vuoteen 2016 mennessä datamäärät nousivat kymmeniin teratavuihin, mikä oli merkittävä kustannus vuokratun SSD-tallennustilan yhteydessä.
Tähän mennessä saraketietokannat olivat yleistyneet aktiivisesti, mitä aloimme aktiivisesti pohtimaan: saraketietokantoissa tiedot tallennetaan, kuten ymmärrät, sarakkeisiin, ja jos katsot tietojamme, on helppo nähdä suuri kaksoiskappaleiden määrä, joka voi pakata sen pakkaamalla käyttämällä saraketietokantaa.
Yrityksen avainjärjestelmä toimi kuitenkin edelleen vakaasti, enkä halunnut kokeilla vaihtamista johonkin muuhun.
Vuonna 2017 San Josessa järjestetyssä Percona Live -konferenssissa Clickhousen kehittäjät luultavasti ilmoittivat olevansa ensimmäistä kertaa. Ensi silmäyksellä järjestelmä oli tuotantovalmis (no, Yandex.Metrica on ankara tuotantojärjestelmä), tuki oli nopeaa ja yksinkertaista, ja mikä tärkeintä, käyttö oli helppoa. Vuodesta 2018 lähtien olemme aloittaneet siirtymäprosessin. Mutta siihen mennessä oli olemassa paljon "aikuisten" ja aikatestattuja TSDB-järjestelmiä, ja päätimme käyttää paljon aikaa ja vertailla vaihtoehtoja varmistaaksemme, ettei Clickhouselle ole vaihtoehtoisia ratkaisuja tarpeidemme mukaan.
Jo määritettyjen tallennusvaatimusten lisäksi on ilmestynyt uusia:
- uuden järjestelmän tulisi tarjota vähintään sama suorituskyky kuin MySQL samalla laitteistomäärällä;
- uuden järjestelmän varastoinnin tulisi viedä huomattavasti vähemmän tilaa;
- DBMS:n on silti oltava helposti hallittavissa;
- Halusin muuttaa sovellusta mahdollisimman vähän DBMS:ää vaihtaessani.
Mitä järjestelmiä aloimme harkita?
Apache Hive/Apache Impala
Vanha, taisteluissa testattu Hadoop-pino. Pohjimmiltaan se on SQL-käyttöliittymä, joka on rakennettu tietojen tallentamiseen alkuperäisissä muodoissa HDFS:ään.
Ammattilaisia.
- Vakaalla toiminnalla dataa on erittäin helppo skaalata.
- Tietojen tallentamiseen on olemassa sarakeratkaisuja (vähemmän tilaa).
- Erittäin nopea rinnakkaisten tehtävien suorittaminen, kun resursseja on saatavilla.
Miinukset.
- Se on Hadoop, ja sitä on vaikea käyttää. Jos emme ole valmiita ottamaan valmiita ratkaisuja pilveen (emmekä ole valmiita kustannusten suhteen), koko pino on koottava ja tuettava järjestelmänvalvojien käsissä, emmekä todellakaan halua Tämä.
- Tiedot kootaan yhteen .
kuitenkin:
Nopeus saavutetaan skaalaamalla laskentapalvelimien määrää. Yksinkertaisesti sanottuna, jos olemme suuri yritys, joka harjoittaa analytiikkaa ja yritykselle on tärkeää koota tiedot mahdollisimman nopeasti (jopa suuren laskentaresurssin käytön kustannuksella), tämä voi olla valintamme. Emme kuitenkaan olleet valmiita moninkertaistamaan laitteistokantaa tehtävien nopeuttamiseksi.
Druidi/Pinot
Erityisesti TSDB:stä on paljon enemmän, mutta jälleen kerran Hadoop-pino.
On .
Muutamalla sanalla: Druid/Pinot näyttävät paremmilta kuin Clickhouse tapauksissa, joissa:
- Tietosi on luonteeltaan heterogeenista (tapauksessamme tallennamme vain palvelinmittareiden aikasarjoja, ja itse asiassa tämä on yksi taulukko. Mutta voi olla muitakin tapauksia: laitteiden aikasarjat, taloudelliset aikasarjat jne. - jokaisessa on oma rakenne, joka on yhdistettävä ja käsiteltävä).
- Lisäksi näitä tietoja on paljon.
- Taulukot ja tiedot aikasarjoineen ilmestyvät ja katoavat (eli jokin tietojoukko saapui, analysoitiin ja poistettiin).
- Ei ole olemassa selkeää kriteeriä, jonka mukaan tiedot voidaan osioida.
Vastakkaisissa tapauksissa ClickHouse toimii paremmin, ja tämä on meidän tapaus.
Napsauta taloa
- SQL:n kaltainen
- Helppo hallita.
- Ihmiset sanovat, että se toimii.
Valitaan testattavaksi.
TuloDB
Ulkomainen vaihtoehto ClickHouselle. Miinuksista: Korkea saatavuus on vain kaupallisessa versiossa, mutta sitä on verrattava.
Valitaan testattavaksi.
Cassandra
Toisaalta tiedämme, että sitä käyttävät mittausaikasarjojen tallentamiseen sellaiset valvontajärjestelmät, kuten esim. tai OkMeter. On kuitenkin olemassa erityispiirteitä.
Cassandra ei ole saraketietokanta perinteisessä mielessä. Se näyttää enemmän rivinäkymältä, mutta jokaisella rivillä voi olla eri määrä sarakkeita, mikä helpottaa sarakenäkymän järjestämistä. Tässä mielessä on selvää, että 2 miljardin sarakkeen rajalla on mahdollista tallentaa joitakin tietoja sarakkeisiin (ja samoihin aikasarjoihin). Esimerkiksi MySQL:ssä on 4096 sarakkeen raja, ja on helppo törmätä virheeseen koodilla 1117, jos yrität tehdä samoin.
Cassandra-moottori on keskittynyt suurten tietomäärien tallentamiseen hajautettuun järjestelmään ilman isäntäkonetta, ja edellä mainittu Cassandra CAP -lause koskee enemmän AP:tä eli tiedon saatavuutta ja osioinnin vastustuskykyä. Tästä syystä tämä työkalu voi olla loistava, jos sinun tarvitsee vain kirjoittaa tähän tietokantaan ja harvoin lukea siitä. Ja tässä on loogista käyttää Cassandraa "kylmävarastona". Eli pitkän aikavälin luotettavana paikkana tallentaa suuria määriä historiallista tietoa, jota harvoin tarvitaan, mutta jotka voidaan tarvittaessa hakea. Täydellisyyden vuoksi testaamme kuitenkin myös sen. Mutta kuten aiemmin totesin, valitun tietokantaratkaisun koodia ei ole haluttu aktiivisesti kirjoittaa uudelleen, joten testaamme sitä jonkin verran rajoitetusti - mukauttamatta tietokantarakennetta Cassandran erityispiirteisiin.
Prometheus
No, uteliaisuudesta päätimme testata Prometheus-tallennustilan suorituskykyä - vain ymmärtääksemme, olemmeko nopeampia vai hitaampia kuin nykyiset ratkaisut ja kuinka paljon.
Testausmenetelmät ja tulokset
Testasimme siis 5 tietokantaa seuraavissa kuudessa kokoonpanossa: ClickHouse (6 solmu), ClickHouse (jaettu taulukko 1 solmulle), InfluxDB, Mysql 3, Cassandra (8 solmua) ja Prometheus. Testisuunnitelma on seuraava:
- lataa historiallisia tietoja viikolta (840 miljoonaa arvoa päivässä; 208 tuhatta mittaria);
- luomme tallennuskuorman (6 lataustilaa harkittiin, katso alla);
- Nauhoituksen rinnalla teemme ajoittain valintoja jäljitellen kaavioita käsittelevän käyttäjän pyyntöjä. Jotta asioita ei monimutkaistaisi liikaa, valitsimme tiedot 10 mittarille (täsmälleen kuinka monta niitä on CPU-kaaviossa) viikoksi.
Lataamme emuloimalla valvonta-agenttimme toimintaa, joka lähettää arvot jokaiselle mittarille 15 sekunnin välein. Samaan aikaan olemme kiinnostuneita muun muassa:
- niiden mittareiden kokonaismäärä, joihin data kirjoitetaan;
- intervalli arvojen lähettämiseksi yhteen metriikkaan;
- erän koko.
Tietoja erän koosta. Koska ei ole suositeltavaa ladata lähes kaikkia kokeellisia tietokantojamme yksittäisillä lisäyksillä, tarvitsemme releen, joka kerää saapuvat mittarit ja ryhmittelee ne ryhmiin ja kirjoittaa ne tietokantaan erälisäkkeenä.
Ymmärtääksemme paremmin, kuinka vastaanotettu data tulkitaan, kuvitellaan, että emme vain lähetä joukkoa mittareita, vaan mittarit on järjestetty palvelimiksi – 125 mittaria palvelinta kohden. Tässä palvelin on yksinkertaisesti virtuaalinen kokonaisuus - vain ymmärtääkseni, että esimerkiksi 10000 80 mittaria vastaa noin XNUMX palvelinta.
Ja tässä, ottaen kaikki tämä huomioon, on 6 tietokannan kirjoituslataustilaa:
Tässä on kaksi kohtaa. Ensinnäkin Cassandralle nämä eräkoot osoittautuivat liian suuriksi, siellä käytimme arvoja 50 tai 100. Ja toiseksi, koska Prometheus toimii tiukasti vetotilassa, ts. se itse menee ja kerää dataa metriikkalähteistä (eikä edes pushgateway nimestä huolimatta muuta tilannetta olennaisesti), vastaavat kuormat toteutettiin staattisten asetusten yhdistelmällä.
Testitulokset ovat seuraavat:
Mitä kannattaa huomioida: fantastisen nopeat näytteet Prometheuksesta, hirvittävän hitaat näytteet Cassandrasta, kohtuuttoman hitaat näytteet InfluxDB:stä; Tallennusnopeuden suhteen ClickHouse voitti kaikki, eikä Prometheus osallistu kilpailuun, koska se tekee itse lisäyksiä, emmekä mittaa mitään.
Tämän seurauksena: ClickHouse ja InfluxDB näyttivät olevansa parhaita, mutta Influxin klusteri voidaan rakentaa vain Enterprise-version pohjalta, joka maksaa, kun taas ClickHouse ei maksa mitään ja on valmistettu Venäjällä. On loogista, että USA:ssa valinta on luultavasti inInfluxDB:n ja meillä ClickHousen puolesta.
Lähde: will.com