Giunsa namon gisulayan ang daghang mga database sa serye sa oras

Sa milabay nga pipila ka mga tuig, ang mga database sa time-series mitalikod gikan sa usa ka talagsaon nga butang (labi ka espesyal nga gigamit sa bisan sa bukas nga mga sistema sa pag-monitor (ug gihigot sa piho nga mga solusyon) o sa mga proyekto sa Big Data) ngadto sa usa ka "produkto sa konsumedor". Sa teritoryo sa Russian Federation, espesyal nga pasalamat kinahanglan ihatag sa Yandex ug ClickHouse alang niini. Hangtud niini nga punto, kung kinahanglan nimo nga tipigan ang daghang data sa serye sa oras, kinahanglan nimo nga mahibal-an ang kinahanglan nga magtukod usa ka makalilisang nga stack sa Hadoop ug ipadayon kini, o makigsulti sa mga protocol nga indibidwal alang sa matag sistema.

Morag sa 2019 ang usa ka artikulo kung diin ang TSDB angayan nga gamiton adunay usa ra ka sentence: "gamita lang ang ClickHouse." Apan ... adunay mga nuances.

Sa tinuud, ang ClickHouse aktibo nga nag-uswag, ang base sa tiggamit nagkadako, ug ang suporta aktibo kaayo, apan nahimo ba kita nga mga bihag sa kalampusan sa publiko sa ClickHouse, nga naglandong sa uban, tingali mas epektibo/masaligan nga mga solusyon?

Sa sinugdanan sa miaging tuig, nagsugod kami sa pagtrabaho pag-usab sa among kaugalingon nga sistema sa pag-monitor, diin ang pangutana mitungha sa pagpili sa usa ka angay nga database alang sa pagtipig sa datos. Gusto nakong hisgutan ang kasaysayan niini nga pagpili dinhi.

Pagbuot sa problema

Una sa tanan, usa ka kinahanglanon nga pasiuna. Ngano nga kinahanglan namon ang among kaugalingon nga sistema sa pag-monitor ug giunsa kini gidisenyo?

Nagsugod kami sa paghatag og mga serbisyo sa suporta sa 2008, ug sa 2010 nahimong tin-aw nga nahimong lisud ang pagtipon sa datos mahitungod sa mga proseso nga nahitabo sa imprastraktura sa kliyente nga adunay mga solusyon nga naglungtad niadtong panahona (naghisgot kami, ang Dios pasayloa ako, Cacti, Zabbix ug ang mitumaw nga Graphite).

Ang among panguna nga kinahanglanon mao ang:

• suporta (niana nga panahon - dosena, ug sa umaabot - gatusan) sa mga kliyente sulod sa usa ka sistema ug sa samang higayon ang presensya sa usa ka sentralisadong sistema sa pagdumala sa alerto;
• pagka-flexible sa pagdumala sa sistema sa alerto (pagdugang sa mga alerto tali sa mga opisyal sa katungdanan, pag-iskedyul, base sa kahibalo);
• ang abilidad sa lawom nga detalye sa mga graph (Zabbix niadtong panahona naghubad sa mga graph sa porma sa mga hulagway);
• long-term storage sa usa ka dako nga kantidad sa data (usa ka tuig o labaw pa) ug ang abilidad sa dali nga pagkuha niini.

Niini nga artikulo interesado kami sa katapusang punto.

Naghisgot bahin sa pagtipig, ang mga kinahanglanon mao ang mga musunud:

• ang sistema kinahanglan nga molihok dayon;
• tilinguhaon nga ang sistema adunay SQL interface;
• ang sistema kinahanglan nga lig-on ug adunay usa ka aktibo nga base sa tiggamit ug suporta (sa dihang nag-atubang kami sa panginahanglan sa pagsuporta sa mga sistema sama sa MemcacheDB, nga wala na maugmad, o ang gi-apod-apod nga storage sa MooseFS, ang bug tracker niini gitipigan sa Chinese: gisubli namo kini nga istorya alang sa among proyekto nga dili gusto);
• pagsunod sa CAP theorem: Consitency (gikinahanglan) - ang data kinahanglan nga up-to-date, dili nato gusto nga ang sistema sa pagdumala sa alerto dili makadawat og bag-ong datos ug moluwa sa mga alerto mahitungod sa dili pag-abot sa datos alang sa tanan nga mga proyekto; Partition Tolerance (gikinahanglan) - dili namo gusto nga makakuha og Split Brain system; Availability (dili kritikal, kung adunay usa ka aktibo nga replika) - mahimo natong ibalhin sa backup nga sistema ang atong kaugalingon kung adunay usa ka aksidente, gamit ang code.

Katingad-an, niadtong panahona ang MySQL nahimo nga sulundon nga solusyon alang kanamo. Ang among data structure kay simple ra kaayo: server id, counter id, timestamp ug value; Ang paspas nga sampling sa init nga datos gisiguro sa usa ka dako nga buffer pool, ug ang sampling sa makasaysayan nga datos gisiguro sa SSD.

Sa ingon, nakab-ot namon ang usa ka sample sa bag-ong duha ka semana nga datos, nga adunay detalye hangtod sa ikaduha nga 200 ms sa wala pa ang datos hingpit nga gihatag, ug nagpuyo sa kini nga sistema sa dugay nga panahon.

Sa kasamtangan, ang panahon milabay ug ang gidaghanon sa data mitubo. Pagka 2016, ang mga volume sa datos miabot sa napulo ka terabytes, nga usa ka hinungdanon nga gasto sa konteksto sa giabangan nga pagtipig sa SSD.

Niini nga panahon, ang mga database sa kolumnar nahimong aktibo nga kaylap, nga gisugdan namon nga aktibo nga gihunahuna: sa mga database sa kolumnar, ang datos gitipigan, ingon nga imong masabtan, sa mga kolum, ug kung imong tan-awon ang among datos, dali nga makita ang usa ka dako. gidaghanon sa mga duplicate nga mahimo, sa Kung mogamit ka usa ka columnar database, i-compress kini gamit ang compression.

Bisan pa, ang yawe nga sistema sa kompanya nagpadayon sa pagtrabaho nga lig-on, ug dili ko gusto nga mag-eksperimento sa pagbalhin sa laing butang.

Sa 2017, sa komperensya sa Percona Live sa San Jose, ang mga developer sa Clickhouse tingali nagpahibalo sa ilang kaugalingon sa unang higayon. Sa una nga pagtan-aw, ang sistema andam na sa produksiyon (maayo, ang Yandex.Metrica usa ka mapintas nga sistema sa produksiyon), paspas ug yano ang suporta, ug, labing hinungdanon, yano ang operasyon. Sukad sa 2018, gisugdan na namo ang proseso sa transisyon. Apan niadtong panahona, adunay daghan nga "hamtong" ug nasulayan sa panahon nga TSDB nga mga sistema, ug kami nakahukom sa paggahin ug igo nga panahon ug pagtandi sa mga alternatibo aron sa pagsiguro nga walay alternatibo nga mga solusyon sa Clickhouse, sumala sa among mga kinahanglanon.

Gawas pa sa gipiho na nga mga kinahanglanon sa pagtipig, ang mga bag-o nagpakita:

• ang bag-ong sistema kinahanglan maghatag labing menos parehas nga pasundayag sama sa MySQL sa parehas nga kantidad sa hardware;
• ang pagtipig sa bag-ong sistema kinahanglan nga adunay gamay nga espasyo;
• Ang DBMS kinahanglan nga sayon ​​pa sa pagdumala;
• Gusto nako nga usbon ang aplikasyon bisan gamay kung usbon ang DBMS.

Unsang mga sistema ang atong gisugdan sa paghunahuna?

Apache Hive/Apache Impala
Usa ka karaan, gisulayan sa gubat nga Hadoop stack. Sa tinuud, kini usa ka interface sa SQL nga gitukod sa ibabaw sa pagtipig sa datos sa lumad nga mga format sa HDFS.

Mga pro.

• Uban sa lig-on nga operasyon, kini mao ang kaayo sayon ​​sa scale data.
• Adunay mga solusyon sa kolum alang sa pagtipig sa datos (gamay nga espasyo).
• Paspas kaayo nga pagpatuman sa parallel nga mga buluhaton kung adunay mga kapanguhaan.

Cons

• Kini ang Hadoop ug lisud gamiton. Kung dili kami andam sa pagkuha sa usa ka andam nga solusyon sa panganod (ug dili kami andam sa mga termino sa gasto), ang tibuuk nga stack kinahanglan nga tipunon ug suportahan sa mga kamot sa mga administrador, ug dili gyud namon gusto. kini.
• Ang datos gitipon paspas kaayo.

Bisan pa:

Ang katulin makab-ot pinaagi sa pag-scale sa gidaghanon sa mga server sa kompyuter. Sa yano nga pagkasulti, kung kami usa ka dako nga kompanya, nag-apil sa pag-analisar, ug hinungdanon alang sa negosyo ang pagtipon sa kasayuran sa labing madali (bisan sa gasto sa paggamit sa daghang mga kapanguhaan sa pag-compute), mahimo’g kini ang among kapilian. Apan dili kami andam nga padaghanon ang armada sa hardware aron mapadali ang mga buluhaton.

Druid/Pinot

Adunay daghan pa bahin sa TSDB partikular, apan usab, ang Hadoop stack.

Adunay maayo nga artikulo nga nagtandi sa mga kaayohan ug kahusay sa Druid ug Pinot batok sa ClickHouse .

Sa pipila ka mga pulong: Ang Druid / Pinot mas maayo nga tan-awon kaysa Clickhouse sa mga kaso diin:

• Ikaw adunay usa ka heterogeneous nga kinaiya sa data (sa among kaso, kami nagrekord lamang sa timeseries sa server metrics, ug, sa pagkatinuod, kini mao ang usa ka lamesa. Apan mahimong adunay uban nga mga kaso: ekipo time series, ekonomikanhon nga panahon serye, ug uban pa - ang matag usa adunay kaugalingon nga estraktura, nga kinahanglan nga tigumon ug iproseso).
• Dugang pa, adunay daghan niini nga datos.
• Ang mga lamesa ug datos nga adunay mga serye sa oras makita ug mawala (nga mao, pipila ka hugpong sa mga datos nga miabot, gisusi ug gitangtang).
• Walay klaro nga sukdanan diin ang datos mahimong mabahin.

Sa kaatbang nga mga kaso, ang ClickHouse mas maayo, ug kini ang among kaso.

clickhouse

• Sama sa SQL
• Sayon sa pagdumala.
• Ang mga tawo nag-ingon nga kini molihok.

Nakuha sa shortlist para sa pagsulay.

InfluxDB

Usa ka langyaw nga alternatibo sa ClickHouse. Sa mga minus: Ang High Availability anaa lamang sa komersyal nga bersyon, apan kini kinahanglan nga itandi.

Nakuha sa shortlist para sa pagsulay.

Cassandra

Sa usa ka bahin, nahibal-an namon nga gigamit kini sa pagtipig sa mga metric timeseries sa ingon nga mga sistema sa pag-monitor sama sa, pananglitan, SignalFX o OkMeter. Bisan pa, adunay mga espesipiko.

Ang Cassandra dili usa ka columnar database sa tradisyonal nga diwa. Kini morag usa ka talan-awon sa laray, apan ang matag linya mahimong adunay lain-laing gidaghanon sa mga kolum, nga makapasayon ​​sa pag-organisar sa usa ka kolumnar nga panglantaw. Niini nga pagsabut, tin-aw nga sa limitasyon sa 2 bilyon nga mga kolum, posible nga tipigan ang pipila ka mga datos sa mga kolum (ug ang parehas nga serye sa oras). Pananglitan, sa MySQL adunay limitasyon sa 4096 nga mga kolum ug dali nga mapandol sa usa ka sayup nga adunay code 1117 kung sulayan nimo nga buhaton ang parehas.

Ang Cassandra engine naka-focus sa pagtipig sa daghang mga datos sa usa ka sistema nga gipang-apod-apod nga walay master, ug ang gihisgutan sa ibabaw nga Cassandra CAP theorem labaw pa mahitungod sa AP, nga mao, mahitungod sa pagkaanaa sa datos ug pagbatok sa partitioning. Busa, kini nga himan mahimong maayo kung kinahanglan nimo nga magsulat sa kini nga database ug panagsa ra magbasa gikan niini. Ug dinhi makatarunganon nga gamiton ang Cassandra ingon usa ka "bugnaw" nga pagtipig. Sa ato pa, isip usa ka dugay, kasaligan nga lugar aron tipigan ang daghang mga datos sa kasaysayan nga panagsa ra kinahanglan, apan mahimo’g makuha kung kinahanglan. Bisan pa niana, alang sa kaayohan sa pagkakompleto, ato usab kining sulayan. Apan, sama sa akong giingon sa sayo pa, wala’y tinguha nga aktibo nga isulat pag-usab ang code alang sa gipili nga solusyon sa database, mao nga sulayan namon kini nga medyo limitado - nga wala ipahiangay ang istruktura sa database sa mga detalye ni Cassandra.

Prometheus

Aw, tungod sa kakuryuso, nakahukom kami nga sulayan ang pasundayag sa pagtipig sa Prometheus - aron mahibal-an kung kami mas paspas o hinay kaysa sa karon nga mga solusyon ug kung pila.

Pamaagi sa pagsulay ug mga resulta

Busa, gisulayan namo ang 5 nga mga database sa mosunod nga 6 nga mga configuration: ClickHouse (1 node), ClickHouse (apod-apod nga lamesa alang sa 3 nodes), InfluxDB, Mysql 8, Cassandra (3 nodes) ug Prometheus. Ang plano sa pagsulay mao ang mosunod:

1. pag-upload sa makasaysayan nga datos sa usa ka semana (840 milyon nga kantidad matag adlaw; 208 ka libo nga sukatan);
2. makamugna kami og recording load (6 load modes ang gikonsiderar, tan-awa sa ubos);
3. Kaabag sa pagrekord, naghimo kami matag karon nga mga pagpili, nga gisundog ang mga hangyo sa usa ka tiggamit nga nagtrabaho sa mga tsart. Aron dili makomplikado pag-ayo ang mga butang, gipili namo ang datos alang sa 10 ka metrics (kana ang eksaktong gidaghanon sa CPU graph) sulod sa usa ka semana.

Nag-load kami pinaagi sa pagsundog sa pamatasan sa among ahente sa pag-monitor, nga nagpadala mga kantidad sa matag sukatan kausa matag 15 segundos. Sa samang higayon, kami interesado sa nagkalainlain:

• ang kinatibuk-ang gidaghanon sa mga sukdanan diin ang datos gisulat;
• agwat alang sa pagpadala mga kantidad sa usa ka sukatan;
• gidak-on sa batch.

Mahitungod sa gidak-on sa batch. Tungod kay dili girekomenda nga i-load ang halos tanan namong mga eksperimento nga database nga adunay usa ka pagsal-ot, kinahanglan namon ang usa ka relay nga nagkolekta sa umaabot nga mga sukatan ug gigrupo kini sa mga grupo ug isulat kini sa database ingon usa ka insert nga batch.

Usab, aron mas masabtan kung giunsa dayon paghubad ang nadawat nga datos, hunahunaon naton nga dili lang kami nagpadala usa ka hugpong sa mga sukatan, apan ang mga sukatan giorganisar sa mga server - 125 nga sukatan matag server. Dinhi ang server usa lamang ka virtual nga entidad - aron lang masabtan nga, pananglitan, ang 10000 nga mga sukatan katumbas sa mga 80 nga mga server.

Ug dinhi, nga gikonsiderar kining tanan, ang among 6 nga database write load modes:

Adunay duha ka punto dinhi. Una, alang kang Cassandra kini nga mga gidak-on sa batch nahimo’g dako kaayo, didto gigamit namon ang mga kantidad nga 50 o 100. Ug ikaduha, tungod kay ang Prometheus nagtrabaho nga hugot sa pull mode, i.e. kini mismo moadto ug mangolekta og mga datos gikan sa mga tinubdan sa metrics (ug bisan ang pushgateway, bisan pa sa ngalan, wala magbag-o sa sitwasyon), ang katugbang nga mga load gipatuman gamit ang kombinasyon sa static configs.

Ang mga resulta sa pagsulay mao ang mosunod:

Unsa ang angay matikdan: talagsaon nga paspas nga mga sample gikan sa Prometheus, hilabihan ka hinay nga mga sample gikan sa Cassandra, dili madawat nga hinay nga mga sample gikan sa InfluxDB; Sa termino sa katulin sa pagrekord, ang ClickHouse nakadaog sa tanan, ug ang Prometheus wala moapil sa kompetisyon, tungod kay kini naghimo sa mga pagsal-ot sa iyang kaugalingon ug wala kami nagsukod sa bisan unsa.

Ingon sa usa ka resulta,: Ang ClickHouse ug InfluxDB nagpakita sa ilang kaugalingon nga mao ang pinakamaayo, apan ang usa ka cluster gikan sa Influx mahimo lamang nga matukod base sa Enterprise nga bersyon, nga nagkantidad og salapi, samtang ang ClickHouse walay gasto ug gihimo sa Russia. Makataronganon nga sa USA ang pagpili lagmit pabor sa inInfluxDB, ug sa atong nasud kini pabor sa ClickHouse.

Source: www.habr.com