Paano Namin Sinubukan ang Maramihang Mga Database ng Serye ng Oras

Sa nakalipas na ilang taon, ang mga database ng time-series ay naging isang "produkto ng consumer" mula sa isang kakaibang bagay (napakadalubhasa sa mga bukas na sistema ng pagsubaybay (at nakatali sa mga partikular na solusyon) o sa mga proyekto ng Big Data). Sa teritoryo ng Russian Federation, ang espesyal na pasasalamat ay dapat ibigay sa Yandex at ClickHouse. Hanggang sa puntong ito, kung kailangan mong mag-imbak ng isang malaking halaga ng data ng serye ng oras, kailangan mong tanggapin ang pangangailangan na bumuo ng isang napakalaking Hadoop stack at mapanatili ito, o makipag-usap sa mga protocol na indibidwal para sa bawat system.

Maaaring mukhang sa 2019 ang isang artikulo tungkol sa kung saan ang TSDB ay sulit na gamitin ay bubuo lamang ng isang pangungusap: "gamitin lang ang ClickHouse." Ngunit... may mga nuances.

Sa katunayan, ang ClickHouse ay aktibong umuunlad, ang user base ay lumalaki, at ang suporta ay napakaaktibo, ngunit tayo ba ay naging mga hostage sa pampublikong tagumpay ng ClickHouse, na natabunan ang iba, marahil ay mas epektibo/maaasahang solusyon?

Sa simula ng nakaraang taon, sinimulan naming muling gawin ang aming sariling sistema ng pagsubaybay, kung saan lumitaw ang tanong sa pagpili ng angkop na database para sa pag-iimbak ng data. Gusto kong pag-usapan ang kasaysayan ng pagpiling ito dito.

Pahayag ng problema

Una sa lahat, isang kinakailangang paunang salita. Bakit kailangan natin ng sarili nating monitoring system at paano ito idinisenyo?

Nagsimula kaming magbigay ng mga serbisyo ng suporta noong 2008, at noong 2010 naging malinaw na naging mahirap ang pagsasama-sama ng data tungkol sa mga prosesong nagaganap sa imprastraktura ng kliyente kasama ang mga solusyon na umiiral noong panahong iyon (pinag-uusapan natin, patawarin ako ng Diyos, Cacti, Zabbix at ang umuusbong na Graphite).

Ang aming pangunahing mga kinakailangan ay:

• suporta (sa oras na iyon - dose-dosenang, at sa hinaharap - daan-daang) ng mga kliyente sa loob ng isang sistema at sa parehong oras ang pagkakaroon ng isang sentralisadong sistema ng pamamahala ng alerto;
• kakayahang umangkop sa pamamahala ng sistema ng alerto (pagtaas ng mga alerto sa pagitan ng mga opisyal ng tungkulin, pag-iiskedyul, base ng kaalaman);
• ang kakayahang malalim na magdetalye ng mga graph (ang Zabbix noong panahong iyon ay nag-render ng mga graph sa anyo ng mga larawan);
• pangmatagalang imbakan ng isang malaking halaga ng data (isang taon o higit pa) at ang kakayahang mabilis na makuha ito.

Sa artikulong ito interesado kami sa huling punto.

Sa pagsasalita tungkol sa imbakan, ang mga kinakailangan ay ang mga sumusunod:

• ang sistema ay dapat gumana nang mabilis;
• ito ay kanais-nais na ang sistema ay may isang SQL interface;
• ang system ay dapat na stable at may aktibong user base at suporta (sa sandaling kami ay nahaharap sa pangangailangang suportahan ang mga system tulad ng MemcacheDB, na hindi na binuo, o ang MooseFS distributed storage, ang bug tracker nito ay pinanatili sa Chinese: inuulit namin ang kuwentong ito para sa aming proyekto ay hindi gusto);
• pagsunod sa theorem ng CAP: Consitency (kinakailangan) - ang data ay dapat na napapanahon, hindi namin nais na ang sistema ng pamamahala ng alerto ay hindi makatanggap ng bagong data at naglalabas ng mga alerto tungkol sa hindi pagdating ng data para sa lahat ng mga proyekto; Partition Tolerance (kinakailangan) - hindi namin gustong makakuha ng Split Brain system; Availability (hindi kritikal, kung mayroong aktibong replica) - maaari tayong lumipat sa backup system mismo kung sakaling magkaroon ng aksidente, gamit ang code.

Kakatwa, sa oras na iyon ang MySQL ay naging perpektong solusyon para sa amin. Napakasimple ng aming istruktura ng data: server id, counter id, timestamp at value; ang mabilis na pag-sample ng mainit na data ay siniguro ng isang malaking buffer pool, at ang pag-sample ng makasaysayang data ay siniguro ng SSD.

Kaya, nakamit namin ang isang sample ng bagong dalawang-linggong data, na may detalye hanggang sa pangalawang 200 ms bago ang data ay ganap na nai-render, at nabuhay sa system na ito sa loob ng mahabang panahon.

Samantala, lumipas ang oras at lumaki ang dami ng data. Pagsapit ng 2016, umabot sa sampu-sampung terabytes ang dami ng data, na isang malaking gastos sa konteksto ng inuupahang storage ng SSD.

Sa oras na ito, ang mga database ng columnar ay naging aktibong laganap, na sinimulan naming aktibong isipin: sa mga database ng columnar, ang data ay nakaimbak, tulad ng naiintindihan mo, sa mga haligi, at kung titingnan mo ang aming data, madaling makita ang isang malaking bilang ng mga duplicate na maaaring, sa Kung gumagamit ka ng columnar database, i-compress ito gamit ang compression.

Gayunpaman, ang pangunahing sistema ng kumpanya ay patuloy na gumagana nang matatag, at hindi ko nais na mag-eksperimento sa paglipat sa ibang bagay.

Noong 2017, sa Percona Live conference sa San Jose, malamang na inihayag ng mga developer ng Clickhouse ang kanilang sarili sa unang pagkakataon. Sa unang tingin, ang sistema ay handa sa produksyon (well, Yandex.Metrica ay isang malupit na sistema ng produksyon), mabilis at simple ang suporta, at, higit sa lahat, simple ang operasyon. Mula noong 2018, sinimulan na namin ang proseso ng paglipat. Ngunit noong panahong iyon, marami nang "pang-adulto" at nasubok sa oras na mga sistema ng TSDB, at nagpasya kaming maglaan ng malaking oras at paghambingin ang mga alternatibo upang matiyak na walang alternatibong solusyon sa Clickhouse, ayon sa aming mga kinakailangan.

Bilang karagdagan sa tinukoy nang mga kinakailangan sa imbakan, lumitaw ang mga bago:

• ang bagong sistema ay dapat magbigay ng hindi bababa sa parehong pagganap bilang MySQL sa parehong dami ng hardware;
• ang imbakan ng bagong sistema ay dapat tumagal ng makabuluhang mas kaunting espasyo;
• Ang DBMS ay dapat pa ring madaling pamahalaan;
• Nais kong baguhin ang application nang kaunti kapag binabago ang DBMS.

Anong mga sistema ang sinimulan nating isaalang-alang?

Apache Hive/Apache Impala
Isang luma, nasubok sa labanan na Hadoop stack. Sa pangkalahatan, ito ay isang SQL interface na binuo sa ibabaw ng pag-iimbak ng data sa mga katutubong format sa HDFS.

Mga kalamangan.

• Sa matatag na operasyon, napakadaling sukatin ang data.
• Mayroong mga solusyon sa hanay para sa pag-iimbak ng data (mas kaunting espasyo).
• Napakabilis na pagpapatupad ng mga parallel na gawain kapag ang mga mapagkukunan ay magagamit.

Cons

• Ito ay Hadoop, at mahirap gamitin. Kung hindi kami handa na kumuha ng isang handa na solusyon sa cloud (at hindi kami handa sa mga tuntunin ng gastos), ang buong stack ay kailangang tipunin at suportahan ng mga kamay ng mga admin, at talagang ayaw namin ito.
• Pinagsama-sama ang data mabilis talaga.

Gayunpaman:

Ang bilis ay nakakamit sa pamamagitan ng pag-scale ng bilang ng mga computing server. Sa madaling salita, kung kami ay isang malaking kumpanya, nakikibahagi sa analytics, at kritikal para sa negosyo na pagsama-samahin ang impormasyon sa lalong madaling panahon (kahit na sa halaga ng paggamit ng malaking halaga ng mga mapagkukunan sa pag-compute), maaaring ito ang aming pipiliin. Ngunit hindi kami handa na paramihin ang fleet ng hardware upang mapabilis ang mga gawain.

Druid/Pinot

Mayroong higit pa tungkol sa TSDB partikular, ngunit muli, ang Hadoop stack.

Mayroon mahusay na artikulong naghahambing ng mga kalamangan at kahinaan ng Druid at Pinot kumpara sa ClickHouse .

Sa ilang mga salita: Druid/Pinot mukhang mas mahusay kaysa sa Clickhouse sa mga kaso kung saan:

• Mayroon kang isang heterogenous na katangian ng data (sa aming kaso, nagtatala lang kami ng mga timeseries ng mga sukatan ng server, at, sa katunayan, ito ay isang talahanayan. Ngunit maaaring may iba pang mga kaso: equipment time series, economic time series, atbp. - bawat isa ay may sarili nitong istraktura, na kailangang pagsama-samahin at iproseso).
• Bukod dito, mayroong maraming data na ito.
• Lumilitaw at nawawala ang mga talahanayan at data na may serye ng oras (iyon ay, dumating ang ilang hanay ng data, nasuri at tinanggal).
• Walang malinaw na pamantayan kung saan maaaring hatiin ang data.

Sa kabaligtaran ng mga kaso, ang ClickHouse ay gumaganap nang mas mahusay, at ito ang aming kaso.

clickhouse

• Parang SQL
• Madaling pamahalaan.
• Sinasabi ng mga tao na ito ay gumagana.

Nai-shortlist para sa pagsubok.

InfluxDB

Isang dayuhang alternatibo sa ClickHouse. Sa mga minus: Ang Mataas na Availability ay naroroon lamang sa komersyal na bersyon, ngunit kailangan itong ihambing.

Nai-shortlist para sa pagsubok.

Cassandra

Sa isang banda, alam namin na ginagamit ito upang mag-imbak ng mga timeseries ng panukat ng mga naturang sistema ng pagsubaybay gaya ng, halimbawa, SignalFX o OkMeter. Gayunpaman, may mga tiyak.

Si Cassandra ay hindi isang columnar database sa tradisyonal na kahulugan. Mas mukhang isang row view, ngunit ang bawat linya ay maaaring magkaroon ng ibang bilang ng mga column, na nagpapadali sa pag-aayos ng columnar view. Sa ganitong diwa, malinaw na may limitasyong 2 bilyong column, posibleng mag-imbak ng ilang data sa mga column (at sa parehong serye ng oras). Halimbawa, sa MySQL mayroong limitasyon ng 4096 na mga haligi at madaling madapa sa isang error sa code 1117 kung susubukan mong gawin ang pareho.

Ang Cassandra engine ay nakatuon sa pag-iimbak ng malalaking halaga ng data sa isang distributed system na walang master, at ang nabanggit sa itaas na Cassandra CAP theorem ay higit pa tungkol sa AP, iyon ay, tungkol sa data availability at paglaban sa partitioning. Kaya, ang tool na ito ay maaaring maging mahusay kung kailangan mo lamang sumulat sa database na ito at bihirang magbasa mula dito. At narito, makatuwirang gamitin si Cassandra bilang isang "malamig" na imbakan. Iyon ay, bilang isang pangmatagalan, maaasahang lugar upang mag-imbak ng malalaking halaga ng makasaysayang data na bihirang kailanganin, ngunit maaaring makuha kung kinakailangan. Gayunpaman, para sa kapakanan ng pagiging kumpleto, susubukan din namin ito. Ngunit, tulad ng sinabi ko kanina, walang pagnanais na aktibong muling isulat ang code para sa napiling solusyon sa database, kaya susubukan namin ito nang medyo limitado - nang hindi iniangkop ang istraktura ng database sa mga detalye ng Cassandra.

Promiteyus

Kaya, dahil sa curiosity, nagpasya kaming subukan ang performance ng Prometheus storage - para lang maunawaan kung kami ay mas mabilis o mas mabagal kaysa sa mga kasalukuyang solusyon at kung magkano.

Pamamaraan ng pagsubok at mga resulta

Kaya, sinubukan namin ang 5 database sa sumusunod na 6 na configuration: ClickHouse (1 node), ClickHouse (ibinahagi na talahanayan para sa 3 node), InfluxDB, Mysql 8, Cassandra (3 node) at Prometheus. Ang plano sa pagsubok ay ang mga sumusunod:

1. mag-upload ng makasaysayang data para sa isang linggo (840 milyong halaga bawat araw; 208 libong sukatan);
2. bumubuo kami ng recording load (6 na load mode ang isinaalang-alang, tingnan sa ibaba);
3. Kasabay ng pag-record, pana-panahon kaming gumagawa ng mga seleksyon, na tinutulad ang mga kahilingan ng isang user na nagtatrabaho sa mga chart. Upang hindi masyadong gawing kumplikado ang mga bagay, pumili kami ng data para sa 10 sukatan (iyon ay eksakto kung gaano karami ang nasa CPU graph) sa loob ng isang linggo.

Naglo-load kami sa pamamagitan ng pagtulad sa pag-uugali ng aming ahente sa pagsubaybay, na nagpapadala ng mga halaga sa bawat sukatan isang beses bawat 15 segundo. Kasabay nito, interesado kami sa pag-iiba-iba:

• ang kabuuang bilang ng mga sukatan kung saan nakasulat ang data;
• agwat para sa pagpapadala ng mga halaga sa isang sukatan;
• laki ng batch.

Tungkol sa laki ng batch. Dahil hindi inirerekomenda na i-load ang halos lahat ng aming pang-eksperimentong database na may iisang pagsingit, kakailanganin namin ng relay na kumukolekta ng mga papasok na sukatan at ipapangkat ang mga ito sa mga grupo at isusulat ang mga ito sa database bilang isang batch insert.

Gayundin, para mas maunawaan kung paano pagkatapos ay bigyang-kahulugan ang natanggap na data, isipin natin na hindi lang kami nagpapadala ng grupo ng mga sukatan, ngunit ang mga sukatan ay nakaayos sa mga server - 125 na sukatan bawat server. Narito ang server ay isang virtual na entity lamang - para lang maunawaan na, halimbawa, 10000 sukatan ang tumutugma sa humigit-kumulang 80 server.

At narito, isinasaalang-alang ang lahat ng ito, ang aming 6 na database write load mode:

Mayroong dalawang puntos dito. Una, para kay Cassandra ang mga laki ng batch na ito ay naging masyadong malaki, doon ginamit namin ang mga halaga ng 50 o 100. At pangalawa, dahil ang Prometheus ay gumagana nang mahigpit sa pull mode, i.e. ito mismo ay pumupunta at nangongolekta ng data mula sa mga pinagmumulan ng sukatan (at kahit na ang pushgateway, sa kabila ng pangalan, ay hindi pangunahing nagbabago sa sitwasyon), ang mga kaukulang pag-load ay ipinatupad gamit ang isang kumbinasyon ng mga static na config.

Ang mga resulta ng pagsusulit ay ang mga sumusunod:

Ano ang dapat tandaan: napakabilis na mga sample mula sa Prometheus, napakabagal na mga sample mula kay Cassandra, hindi katanggap-tanggap na mabagal na mga sample mula sa InfluxDB; Sa mga tuntunin ng bilis ng pag-record, ang ClickHouse ay nanalo sa lahat, at ang Prometheus ay hindi nakikilahok sa kumpetisyon, dahil gumagawa ito ng mga pagsingit mismo at hindi namin sinusukat ang anuman.

Bilang isang resulta,: Ang ClickHouse at InfluxDB ay gumanap ng pinakamahusay, ngunit ang isang cluster mula sa Influx ay maaari lamang itayo batay sa bersyon ng Enterprise, na nagkakahalaga ng pera, habang ang ClickHouse ay walang gastos at ginawa sa Russia. Ito ay lohikal na sa USA ang pagpipilian ay malamang na pabor sa inInfluxDB, at sa ating bansa ito ay pabor sa ClickHouse.

Pinagmulan: www.habr.com