Tutaangalia jinsi Zabbix inavyofanya kazi na hifadhidata ya TimescaleDB kama sehemu ya nyuma. Tutakuonyesha jinsi ya kuanza kutoka mwanzo na jinsi ya kuhama kutoka PostgreSQL. Pia tutatoa majaribio ya utendakazi linganishi ya usanidi huo mbili.
HighLoad++ Siberia 2019. Tomsk Hall. Juni 24, 16:00. Hizi na . Kongamano lijalo la HighLoad++ litafanyika tarehe 6 na 7 Aprili 2020 huko St. Petersburg. Maelezo na tikiti .
Andrey Gushchin (baadaye - AG): - Mimi ni mhandisi wa usaidizi wa kiufundi wa ZABBIX (hapa anajulikana kama "Zabbix"), mkufunzi. Nimekuwa nikifanya kazi katika usaidizi wa kiufundi kwa zaidi ya miaka 6 na nimekuwa na uzoefu wa moja kwa moja na utendakazi. Leo nitazungumza kuhusu utendaji ambao TimescaleDB inaweza kutoa ikilinganishwa na PostgreSQL 10 ya kawaida. Pia, sehemu fulani ya utangulizi kuhusu jinsi inavyofanya kazi kwa ujumla.
Changamoto kuu za tija: kutoka kwa ukusanyaji wa data hadi kusafisha data
Kwa kuanzia, kuna changamoto fulani za utendaji ambazo kila mfumo wa ufuatiliaji unakabiliana nazo. Changamoto ya kwanza ya tija ni kukusanya na kuchakata data haraka.
Mfumo mzuri wa ufuatiliaji unapaswa kupokea data zote kwa haraka, kwa wakati, kuzichakata kulingana na misemo ya vichochezi, yaani, kuichakata kulingana na vigezo fulani (hii ni tofauti katika mifumo tofauti) na kuihifadhi kwenye hifadhidata ili kutumia data hii kwenye baadaye.
Changamoto ya pili ya utendakazi ni uhifadhi wa historia. Hifadhi katika hifadhidata mara nyingi na upate ufikiaji wa haraka na rahisi wa vipimo hivi ambavyo vilikusanywa kwa muda. Jambo muhimu zaidi ni kwamba data hii ni rahisi kupata, itumie katika ripoti, grafu, vichochezi, katika baadhi ya maadili ya kizingiti, kwa tahadhari, nk.
Changamoto ya tatu ya utendakazi ni kusafisha historia, yaani, unapofika mahali ambapo huhitaji kuhifadhi vipimo vyovyote vya kina ambavyo vimekusanywa kwa miaka 5 (hata miezi au miezi miwili). Baadhi ya nodi za mtandao zilifutwa, au baadhi ya seva pangishi hazihitajiki tena kwa sababu tayari zimepitwa na wakati na hazikusanywi tena. Yote hii inahitaji kusafishwa ili hifadhidata yako isikua kubwa sana. Kwa ujumla, kusafisha historia mara nyingi ni mtihani mzito kwa uhifadhi - mara nyingi huwa na athari kubwa kwenye utendakazi.
Jinsi ya kutatua matatizo ya caching?
Sasa nitazungumza haswa kuhusu Zabbix. Katika Zabbix, simu za kwanza na za pili zinatatuliwa kwa kutumia caching.
Ukusanyaji na usindikaji wa data - Tunatumia RAM kuhifadhi data hii yote. Data hizi sasa zitajadiliwa kwa undani zaidi.
Pia kwa upande wa hifadhidata kuna kache kwa chaguo kuu - kwa grafu na vitu vingine.
Inaakibisha upande wa seva ya Zabbix yenyewe: tuna ConfigurationCache, ValueCache, HistoryCache, TrendsCache. Ni nini?
ConfigurationCache ni akiba kuu ambayo tunahifadhi metriki, seva pangishi, vipengee vya data, vichochezi; kila kitu unachohitaji ili kuchakata, kukusanya data, kutoka kwa wapangishi wa kukusanya, na mara ngapi. Yote hii imehifadhiwa kwenye ConfigurationCache ili usiende kwenye hifadhidata na kuunda maswali yasiyo ya lazima. Baada ya seva kuanza, tunasasisha cache hii (kuunda) na kusasisha mara kwa mara (kulingana na mipangilio ya usanidi).
Inahifadhi kwenye Zabbix. Mkusanyiko wa data
Hapa mchoro ni mkubwa sana:
Wakuu katika mpango ni watoza hawa:
Hizi ni michakato ya mkutano wenyewe, "wapiga kura" mbalimbali ambao wanajibika kwa aina tofauti za makusanyiko. Wanakusanya data kupitia icmp, ipmi, na itifaki mbalimbali na kuzihamisha zote kwenye usindikaji wa awali.
Inachakata Akiba ya Historia
Pia, ikiwa tumekokotoa vipengele vya data (wale wanaoifahamu Zabbix wanajua), yaani, vipengele vya data vilivyokokotwa, tunavichukua moja kwa moja kutoka kwa ValueCache. Nitakuambia jinsi inavyojazwa baadaye. Wakusanyaji hawa wote hutumia ConfigurationCache kupokea kazi zao na kisha kuzipitisha kwenye usindikaji wa awali.
Uchakataji wa awali pia hutumia ConfigurationCache kupata hatua za uchakataji na kuchakata data hii kwa njia mbalimbali. Kuanzia toleo la 4.2, tumeihamisha hadi kwa seva mbadala. Hii ni rahisi sana, kwa sababu kujitayarisha yenyewe ni operesheni ngumu sana. Na ikiwa una Zabbix kubwa sana, yenye idadi kubwa ya vipengele vya data na mzunguko wa juu wa mkusanyiko, basi hii hurahisisha kazi sana.
Ipasavyo, baada ya kuchakata data hii kwa njia fulani kwa kutumia uchakataji wa awali, tunaihifadhi katikaHistoryCache ili kuichakata zaidi. Hii inahitimisha ukusanyaji wa data. Tunaendelea na mchakato kuu.
Kazi ya kusawazisha historia
Mchakato kuu katika Zabbix (kwani ni usanifu wa monolithic) ni Usawazishaji wa Historia. Huu ndio mchakato kuu ambao unashughulika haswa na usindikaji wa atomiki wa kila kipengele cha data, ambayo ni, kila thamani:
- thamani inakuja (inachukua kutoka kwa HistoryCache);
- huangalia katika Kilandanishi cha Usanidi: ikiwa kuna vichochezi vyovyote vya kukokotoa - huzihesabu;
ikiwa kuna - huunda matukio, huunda kuongezeka ili kuunda tahadhari, ikiwa ni lazima kulingana na usanidi; - rekodi vichochezi kwa usindikaji unaofuata, mkusanyiko; ukijumlisha zaidi ya saa iliyopita na kadhalika, thamani hii inakumbukwa na ValueCache ili usiende kwenye jedwali la historia; Kwa hivyo, ValueCache imejazwa na data muhimu ambayo ni muhimu kuhesabu vichochezi, vipengele vilivyohesabiwa, nk;
- kisha Kisawazishaji cha Historia huandika data zote kwenye hifadhidata;
- hifadhidata inawaandika kwa diski - hapa ndipo mchakato wa usindikaji unaisha.
Hifadhidata. Kuhifadhi akiba
Kwa upande wa hifadhidata, unapotaka kutazama grafu au ripoti fulani kwenye matukio, kuna kache mbalimbali. Lakini katika ripoti hii sitazungumza juu yao.
Kwa MySQL kuna Innodb_buffer_pool, na rundo la kache tofauti ambazo zinaweza pia kusanidiwa.
Lakini hizi ndio kuu:
- pamoja_bafa;
- saizi_ya_kache_ifaayo;
- bwawa_iliyoshirikiwa.
Kwa hifadhidata zote, nilisema kwamba kuna kache fulani ambazo hukuruhusu kuhifadhi kwenye RAM data ambayo inahitajika mara nyingi kwa maswali. Wana teknolojia zao wenyewe kwa hili.
Kuhusu Utendaji wa Hifadhidata
Ipasavyo, kuna mazingira ya ushindani, ambayo ni, seva ya Zabbix inakusanya data na kuirekodi. Inapoanzishwa upya, pia inasoma kutoka kwa historia ili kujaza ValueCache na kadhalika. Hapa unaweza kuwa na hati na ripoti zinazotumia API ya Zabbix, ambayo imeundwa kwenye kiolesura cha wavuti. Zabbix API huingia kwenye hifadhidata na kupokea data muhimu ili kupata grafu, ripoti, au aina fulani ya orodha ya matukio, matatizo ya hivi karibuni.
Pia suluhisho la taswira maarufu sana ni Grafana, ambayo watumiaji wetu hutumia. Inaweza kuingia moja kwa moja kupitia API ya Zabbix na kupitia hifadhidata. Pia huunda ushindani fulani wa kupata data: urekebishaji bora zaidi wa hifadhidata unahitajika ili kuzingatia utoaji wa haraka wa matokeo na majaribio.
Inafuta historia. Zabbix ana Mlinzi wa Nyumba
Simu ya tatu ambayo inatumika katika Zabbix ni kufuta historia kwa kutumia Mlinzi wa Nyumba. Mlinzi wa nyumba hufuata mipangilio yote, yaani, vipengele vyetu vya data vinaonyesha muda wa kuhifadhi (kwa siku), muda gani wa kuhifadhi mitindo, na mienendo ya mabadiliko.
Sikuzungumza kuhusu TrendCache, ambayo tunahesabu kwa kuruka: data hufika, tunaijumlisha kwa saa moja (zaidi hizi ni nambari za saa iliyopita), kiasi ni wastani/chini na tunairekodi mara moja kwa saa. jedwali la mienendo ya mabadiliko ("Mwelekeo") . "Mlinzi wa nyumba" huanza na kufuta data kutoka kwa hifadhidata kwa kutumia chaguzi za kawaida, ambazo hazifanyi kazi kila wakati.
Jinsi ya kuelewa kuwa haifai? Unaweza kuona picha ifuatayo kwenye grafu za utendaji wa michakato ya ndani:
Kisawazishaji chako cha Historia kina shughuli nyingi kila wakati (grafu nyekundu). Na mchoro "nyekundu" unaoendelea juu. Huyu ni "Mlinzi wa Nyumba" anayeanza na kungoja hifadhidata kufuta safu mlalo zote ambazo imebainisha.
Hebu tuchukue Kitambulisho cha Kipengee: unahitaji kufuta elfu 5 za mwisho; bila shaka, kwa faharisi. Lakini kwa kawaida hifadhidata ni kubwa kabisa - hifadhidata bado inaisoma kutoka kwa diski na kuiweka kwenye kashe, na hii ni operesheni ghali sana kwa hifadhidata. Kulingana na ukubwa wake, hii inaweza kusababisha matatizo fulani ya utendaji.
Unaweza kulemaza Mlinzi wa Nyumba kwa njia rahisi - tuna kiolesura cha wavuti kinachojulikana. Mipangilio katika Utawala wa jumla (mipangilio ya "Mtunza Nyumba") tunazima uhifadhi wa ndani kwa historia ya ndani na mitindo. Ipasavyo, Mlinzi wa Nyumba hadhibiti tena hii:
Unaweza kufanya nini baadaye? Uliizima, grafu zako zimesawazishwa ... Ni matatizo gani zaidi yanaweza kutokea katika kesi hii? Ni nini kinachoweza kusaidia?
Kugawanya (kugawa)
Kawaida hii imeundwa kwa njia tofauti kwenye kila hifadhidata ya uhusiano ambayo nimeorodhesha. MySQL ina teknolojia yake mwenyewe. Lakini kwa ujumla zinafanana sana linapokuja suala la PostgreSQL 10 na MySQL. Bila shaka, kuna tofauti nyingi za ndani katika jinsi yote yanatekelezwa na jinsi yote yanavyoathiri utendakazi. Lakini kwa ujumla, uundaji wa kizigeu kipya mara nyingi pia husababisha shida fulani.
Kulingana na usanidi wako (unaunda data ngapi kwa siku moja), kawaida huweka kiwango cha chini - hii ni siku 1 / kundi, na kwa "mwenendo", mienendo ya mabadiliko - mwezi 1 / kundi jipya. Hii inaweza kubadilika ikiwa una usanidi mkubwa sana.
Wacha tuseme mara moja juu ya saizi ya usanidi: hadi maadili mapya elfu 5 kwa sekunde (kinachojulikana kama nvps) - hii itazingatiwa "usanidi" mdogo. Wastani - kutoka kwa maadili elfu 5 hadi 25 kwa sekunde. Yote yaliyo hapo juu tayari ni usakinishaji mkubwa na mkubwa sana ambao unahitaji usanidi wa uangalifu wa hifadhidata.
Kwenye usakinishaji mkubwa sana, siku 1 inaweza isiwe bora. Binafsi nimeona sehemu kwenye MySQL ya gigabytes 40 kwa siku (na kunaweza kuwa na zaidi). Hii ni kiasi kikubwa sana cha data, ambayo inaweza kusababisha matatizo fulani. Inahitaji kupunguzwa.
Kwa nini unahitaji kugawanya?
Kile Ugawaji hutoa, nadhani kila mtu anajua, ni ugawaji wa meza. Mara nyingi hizi ni faili tofauti kwenye diski na maombi ya span. Huchagua kizigeu kimoja vyema zaidi ikiwa ni sehemu ya ugawaji wa kawaida.
Kwa Zabbix, haswa, hutumiwa na anuwai, kwa anuwai, ambayo ni, tunatumia muhuri wa wakati (nambari ya kawaida, wakati tangu mwanzo wa enzi). Unabainisha mwanzo wa siku/mwisho wa siku, na hii ndiyo kizigeu. Ipasavyo, ikiwa unaomba data ambayo ina umri wa siku mbili, kila kitu hutolewa kutoka kwa hifadhidata haraka, kwa sababu unahitaji tu kupakia faili moja kwenye kashe na kuirudisha (badala ya meza kubwa).
Hifadhidata nyingi pia huharakisha kuingiza (kuingiza kwenye jedwali moja la mtoto). Ninazungumza kidhahiri kwa sasa, lakini hii pia inawezekana. Kugawanya mara nyingi husaidia.
Elasticsearch kwa NoSQL
Hivi majuzi, mnamo 3.4, tulitekeleza suluhisho la NoSQL. Aliongeza uwezo wa kuandika katika Elasticsearch. Unaweza kuandika aina fulani: unachagua - ama kuandika nambari au ishara fulani; tuna maandishi ya kamba, unaweza kuandika kumbukumbu kwa Elasticsearch... Ipasavyo, kiolesura cha wavuti pia kitafikia Elasticsearch. Hii inafanya kazi nzuri katika hali zingine, lakini kwa sasa inaweza kutumika.
TimescaleDB. Hypertables
Kwa 4.4.2 tulizingatia jambo moja kama TimescaleDB. Ni nini? Hiki ni kiendelezi cha PostgreSQL, yaani, ina kiolesura asili cha PostgreSQL. Zaidi, kiendelezi hiki hukuruhusu kufanya kazi kwa ufanisi zaidi na data ya safu za saa na kuwa na ugawaji wa kiotomatiki. Inaonekanaje:
Hii ni hypertable - kuna dhana kama hiyo katika Timescale. Hii ni hypertable ambayo unaunda, na ina vipande. Chunks ni partitions, hizi ni meza za watoto, ikiwa sijakosea. Ni kweli ufanisi.
TimescaleDB na PostgreSQL
Kama watengenezaji wa TimescaleDB wanavyohakikishia, wanatumia algoriti sahihi zaidi kuchakata hoja, hususani vichocheo, ambavyo huwaruhusu kuwa na utendakazi takriban mara kwa mara pamoja na ongezeko la ukubwa wa seti ya data. Hiyo ni, baada ya safu milioni 200 za Postgres, ile ya kawaida huanza kudorora sana na kupoteza utendakazi kihalisi hadi sifuri, huku Timescale hukuruhusu kuchomeka kwa ufanisi iwezekanavyo kwa kiasi chochote cha data.
Jinsi ya kufunga TimescaleDB? Ni rahisi!
Iko katika nyaraka, imeelezwa - unaweza kuiweka kutoka kwa vifurushi kwa yoyote ... Inategemea vifurushi rasmi vya Postgres. Inaweza kukusanywa kwa mikono. Ilifanyika kwamba nililazimika kukusanya kwa hifadhidata.
Kwenye Zabbix tunawasha Kiendelezi kwa urahisi. Nadhani wale waliotumia Kiendelezi katika Postgres... Unawasha Kiendelezi kwa urahisi, uunde kwa hifadhidata ya Zabbix unayotumia.
Na hatua ya mwisho ...
TimescaleDB. Uhamiaji wa meza za historia
Unahitaji kuunda hypertable. Kuna kazi maalum kwa hii - Unda hypertable. Ndani yake, parameter ya kwanza ni meza ambayo inahitajika katika hifadhidata hii (ambayo unahitaji kuunda hypertable).
Sehemu ya kuunda, na chunk_time_interval (hii ni muda wa vipande (vipande vinavyohitaji kutumika). 86 ni siku moja.
Migrate_data kigezo: Ikiwa utaingiza kwa kweli, basi hii itahamisha data yote ya sasa hadi vipande vilivyoundwa awali.
Nimetumia migrate_data mwenyewe - inachukua muda wa kutosha, kulingana na ukubwa wa hifadhidata yako. Nilikuwa na zaidi ya terabyte - ilichukua zaidi ya saa moja kuunda. Katika baadhi ya matukio, wakati wa majaribio, nilifuta data ya kihistoria ya maandishi (history_text) na kamba (history_str) ili nisizihamishe - hazikuwa za kuvutia kwangu.
Na tunafanya sasisho la mwisho katika db_extention yetu: tunasakinisha timecaledb ili hifadhidata na, haswa, Zabbix yetu ielewe kuwa kuna db_extention. Anaiwasha na kutumia sintaksia sahihi na hoja kwenye hifadhidata, kwa kutumia "vipengele" ambavyo ni muhimu kwa TimescaleDB.
Usanidi wa seva
Nilitumia seva mbili. Seva ya kwanza ni mashine ndogo ya kawaida, wasindikaji 20, gigabytes 16 za RAM. Nilisanidi Postgres 10.8 juu yake:
Mfumo wa uendeshaji ulikuwa Debian, mfumo wa faili ulikuwa xfs. Nilifanya mipangilio ndogo ya kutumia hifadhidata hii, ukiondoa kile Zabbix yenyewe itatumia. Kwenye mashine hiyo hiyo kulikuwa na seva ya Zabbix, PostgreSQL na mawakala wa kupakia.
Nimetumia mawakala 50 amilifu wanaotumia LoadableModule kutoa matokeo tofauti haraka. Ndio ambao walitengeneza kamba, nambari, na kadhalika. Nilijaza hifadhidata na data nyingi. Hapo awali, usanidi ulikuwa na vipengee elfu 5 vya data kwa kila seva pangishi, na takriban kila kipengele cha data kilikuwa na kichochezi - ili hii iwe usanidi halisi. Wakati mwingine hata unahitaji zaidi ya kichochezi kimoja kutumia.
Nilidhibiti muda wa kusasisha na upakiaji wenyewe kwa sio tu kutumia mawakala 50 (kuongeza zaidi), lakini pia kutumia vipengee vya data vinavyobadilika na kupunguza muda wa kusasisha hadi sekunde 4.
Mtihani wa utendaji. PostgreSQL: NVP elfu 36
Uzinduzi wa kwanza, usanidi wa kwanza niliokuwa nao ulikuwa kwenye PostreSQL 10 safi kwenye vifaa hivi (thamani elfu 35 kwa sekunde). Kwa ujumla, kama unaweza kuona kwenye skrini, kuingiza data huchukua sehemu za sekunde - kila kitu ni nzuri na haraka, anatoa SSD (200 gigabytes). Jambo pekee ni kwamba GB 20 inajaza haraka sana.
Kutakuwa na grafu nyingi sana katika siku zijazo. Hii ni dashibodi ya kawaida ya utendaji ya seva ya Zabbix.
Grafu ya kwanza ni idadi ya maadili kwa sekunde (bluu, juu kushoto), maadili elfu 35 katika kesi hii. Hii (kituo cha juu) ni upakiaji wa michakato ya ujenzi, na hii (juu kulia) ni upakiaji wa michakato ya ndani: wasawazishaji wa historia na mtunza nyumba, ambayo hapa (kituo cha chini) imekuwa ikifanya kazi kwa muda mrefu.
Grafu hii (kituo cha chini) inaonyesha matumizi ya ValueCache - ni vichochezi vingapi vya ValueCache (thamani elfu kadhaa kwa sekunde). Grafu nyingine muhimu ni ya nne (chini kushoto), ambayo inaonyesha matumizi ya HistoryCache, ambayo nilizungumzia, ambayo ni buffer kabla ya kuingiza kwenye hifadhidata.
Mtihani wa utendaji. PostgreSQL: NVP elfu 50
Ifuatayo, niliongeza mzigo hadi maadili elfu 50 kwa sekunde kwenye vifaa sawa. Wakati wa kupakiwa na Mlinzi wa Nyumba, maadili elfu 10 yalirekodiwa katika sekunde 2-3 na hesabu. Ni nini, kwa kweli, kinachoonyeshwa kwenye skrini ifuatayo:
"Mlinzi wa nyumba" tayari anaanza kuingilia kati na kazi, lakini kwa ujumla, mzigo kwenye watekaji wa historia-sinker bado uko kwenye kiwango cha 60% (grafu ya tatu, kulia juu). HistoriaCache tayari inaanza kujaza kikamilifu wakati Mlinzi wa Nyumba anaendesha (chini kushoto). Ilikuwa karibu nusu ya gigabyte, 20% imejaa.
Mtihani wa utendaji. PostgreSQL: NVP elfu 80
Kisha niliiongeza hadi maadili elfu 80 kwa sekunde:
Ilikuwa takriban vitu elfu 400 vya data, vichocheo elfu 280. Kuingiza, kama unaweza kuona, kwa suala la mzigo wa sinki za historia (kulikuwa na 30 kati yao) tayari ilikuwa juu sana. Kisha nikaongeza vigezo mbalimbali: kuzama kwa historia, kache ... Kwenye vifaa hivi, mzigo kwenye sinkers za historia ulianza kuongezeka hadi kiwango cha juu, karibu "kwenye rafu" - ipasavyo, HistoryCache iliingia kwenye mzigo mkubwa sana:
Wakati huu wote nilifuatilia vigezo vyote vya mfumo (jinsi processor inatumiwa, RAM) na kugundua kuwa utumiaji wa diski ulikuwa wa juu - nilipata uwezo wa juu wa diski hii kwenye vifaa hivi, kwenye mashine hii ya kawaida. "Postgres" ilianza kutupa data kwa bidii kwa nguvu kama hiyo, na diski haikuwa na wakati wa kuandika, kusoma ...
Nilichukua seva nyingine ambayo tayari ilikuwa na wasindikaji 48 na gigabytes 128 za RAM:
Pia "niliiweka" - niliweka usawazishaji wa Historia (vipande 60) na nikapata utendaji unaokubalika. Kwa kweli, sisi sio "kwenye rafu," lakini hii labda ni kikomo cha tija, ambapo tayari ni muhimu kufanya kitu kuhusu hilo.
Mtihani wa utendaji. TimesscaleDB: 80 elfu NVPs
Kazi yangu kuu ilikuwa kutumia TimescaleDB. Kila grafu inaonyesha dip:
Hitilafu hizi ni uhamishaji wa data haswa. Baada ya hayo, kwenye seva ya Zabbix, wasifu wa upakiaji wa sinki za historia, kama unaweza kuona, ulibadilika sana. Inakuruhusu kuingiza data karibu mara 3 kwa kasi zaidi na kutumia HistoryCache kidogo - ipasavyo, data itawasilishwa kwa wakati. Tena, maadili elfu 80 kwa sekunde ni kiwango cha juu kabisa (kwa kweli, sio kwa Yandex). Kwa ujumla hii ni usanidi mkubwa, na seva moja.
Mtihani wa utendaji wa PostgreSQL: NVP elfu 120
Ifuatayo, niliongeza thamani ya idadi ya vitu vya data hadi nusu milioni na nikapokea thamani iliyohesabiwa ya elfu 125 kwa sekunde:
Na nilipata grafu hizi:
Kimsingi, hii ni usanidi wa kufanya kazi, inaweza kufanya kazi kwa muda mrefu sana. Lakini kwa kuwa nilikuwa na diski ya terabyte 1,5 tu, niliitumia kwa siku kadhaa. Jambo muhimu zaidi ni kwamba wakati huo huo sehemu mpya ziliundwa kwenye TimescaleDB, na hii haikuonekana kabisa kwa utendaji, ambayo haiwezi kusema kuhusu MySQL.
Kwa kawaida, partitions huundwa usiku, kwa sababu hii kwa ujumla inazuia kuingizwa na kufanya kazi na meza na inaweza kusababisha uharibifu wa huduma. Katika kesi hii sio hivyo! Kazi kuu ilikuwa kujaribu uwezo wa TimescaleDB. Matokeo yake yalikuwa takwimu ifuatayo: maadili elfu 120 kwa sekunde.
Pia kuna mifano katika jamii:
Mtu huyo pia aliwasha TimescaleDB na mzigo kwenye kutumia io.weight ulishuka kwenye kichakataji; na matumizi ya vipengele vya mchakato wa ndani pia yamepungua kutokana na kujumuishwa kwa TimescaleDB. Kwa kuongezea, hizi ni diski za pancake za kawaida, ambayo ni, mashine ya kawaida kwenye diski za kawaida (sio SSD)!
Kwa usanidi mdogo ambao ni mdogo na utendaji wa diski, TimescaleDB, kwa maoni yangu, ni suluhisho nzuri sana. Itakuruhusu kuendelea kufanya kazi kabla ya kuhamia maunzi ya haraka kwa hifadhidata.
Ninakualika wote kwenye hafla zetu: Mkutano huko Moscow, Mkutano huko Riga. Tumia chaneli zetu - Telegraph, jukwaa, IRC. Ikiwa una maswali yoyote, njoo kwenye dawati yetu, tunaweza kuzungumza juu ya kila kitu.
Maswali ya Hadhira
Swali kutoka kwa hadhira (hapa - A): - Ikiwa TimescaleDB ni rahisi sana kusanidi, na inatoa utendakazi zaidi, basi labda hii inapaswa kutumika kama mbinu bora ya kusanidi Zabbix na Postgres? Na kuna vikwazo na hasara za suluhisho hili, au baada ya yote, ikiwa nimeamua kufanya Zabbix kwa ajili yangu mwenyewe, naweza kuchukua Postgres kwa urahisi, kufunga Timescale huko mara moja, kuitumia na sifikiri juu ya matatizo yoyote?
AG: - Ndio, ningesema kwamba hili ni pendekezo zuri: tumia Postgres mara moja na kiendelezi cha TimescaleDB. Kama nilivyosema tayari, hakiki nyingi nzuri, licha ya ukweli kwamba "kipengele" hiki ni cha majaribio. Lakini kwa kweli vipimo vinaonyesha kuwa hii ni suluhisho nzuri (na TimescaleDB) na nadhani itaibuka! Tunafuatilia jinsi kiendelezi hiki kinavyokua na tutafanya mabadiliko inapohitajika.
Hata wakati wa maendeleo, tulitegemea moja ya "sifa" zao zinazojulikana: iliwezekana kufanya kazi na chunks tofauti kidogo. Lakini basi walikata katika toleo lililofuata, na tulilazimika kuacha kutegemea nambari hii. Ningependekeza kutumia suluhisho hili kwenye usanidi nyingi. Ikiwa unatumia MySQL ... Kwa usanidi wa wastani, suluhisho lolote hufanya kazi vizuri.
J: - Kwenye grafu za mwisho kutoka kwa jumuiya, kulikuwa na grafu na "Mlinzi wa Nyumba":
Aliendelea kufanya kazi. Mlinzi wa Nyumba anafanya nini na TimescaleDB?
AG: - Sasa siwezi kusema kwa uhakika - nitaangalia msimbo na kukuambia kwa undani zaidi. Hutumia maswali ya TimescaleDB sio kufuta vipande, lakini kwa njia fulani kujumlisha. Bado siko tayari kujibu swali hili la kiufundi. Tutajua zaidi kwenye stendi leo au kesho.
J: - Nina swali kama hilo - kuhusu utendaji wa operesheni ya kufuta katika Timescale.
Jibu (jibu kutoka kwa hadhira): β Unapofuta data kwenye jedwali, ukiifanya kupitia kufuta, basi unahitaji kupitia jedwali hilo - futa, safisha, weka alama kila kitu kwa utupu ujao. Katika Timescale, kwa kuwa una vipande, unaweza kuacha. Kwa kusema, unaambia faili iliyo kwenye data kubwa: "Futa!"
Timescale inaelewa tu kuwa chunk kama hiyo haipo tena. Na kwa kuwa imeunganishwa kwenye mpangilio wa hoja, hutumia ndoano kupata hali yako katika kuchagua au shughuli zingine na mara moja inaelewa kuwa sehemu hii haipo tena - "Sitaenda huko tena!" (data haipatikani). Ni hayo tu! Hiyo ni, skanning ya meza inabadilishwa na kufuta faili ya binary, kwa hiyo ni haraka.
J: - Tayari tumegusa mada ya yasiyo ya SQL. Kwa kadiri ninavyoelewa, Zabbix haitaji kabisa kurekebisha data, na hii yote ni kitu kama logi. Je, inawezekana kutumia hifadhidata maalum ambazo haziwezi kubadilisha data zao, lakini wakati huo huo kuokoa, kujilimbikiza, na kusambaza kwa kasi zaidi - Clickhouse, kwa mfano, kitu cha Kafka-kama? .. Kafka pia ni logi! Je, inawezekana kwa namna fulani kuwaunganisha?
AG: - Upakuaji unaweza kufanywa. Tuna "kipengele" fulani tangu toleo la 3.4: unaweza kuandika faili zote za kihistoria, matukio, kila kitu kingine kwa faili; na kisha utume kwa hifadhidata nyingine yoyote kwa kutumia kidhibiti fulani. Kwa kweli, watu wengi hufanya kazi tena na kuandika moja kwa moja kwenye hifadhidata. Juu ya kuruka, sinkers historia kuandika haya yote katika files, mzunguko files hizi, na kadhalika, na unaweza kuhamisha hii kwa Clickhouse. Siwezi kusema juu ya mipango, lakini labda msaada zaidi kwa suluhisho za NoSQL (kama vile Clickhouse) utaendelea.
J: - Kwa ujumla, zinageuka kuwa unaweza kujiondoa kabisa postgres?
AG: - Kwa kweli, sehemu ngumu zaidi katika Zabbix ni majedwali ya kihistoria, ambayo husababisha shida na matukio mengi. Katika kesi hii, ikiwa hutahifadhi matukio kwa muda mrefu na kuhifadhi historia na mwenendo katika hifadhi nyingine ya haraka, basi kwa ujumla, nadhani, hakutakuwa na matatizo.
J: - Je, unaweza kukadiria ni kwa kasi gani kila kitu kitafanya kazi ikiwa utabadilisha kwa Clickhouse, kwa mfano?
AG: - Sijaijaribu. Nadhani angalau nambari zinazofanana zinaweza kupatikana kwa urahisi, kwa kuwa Clickhouse ina kiolesura chake, lakini siwezi kusema kwa uhakika. Ni bora kupima. Yote inategemea usanidi: una majeshi ngapi, na kadhalika. Kuingiza ni jambo moja, lakini pia unahitaji kurejesha data hii - Grafana au kitu kingine.
J: - Kwa hivyo tunazungumza juu ya mapigano sawa, na sio juu ya faida kubwa ya hifadhidata hizi za haraka?
AG: - Nadhani tunapounganisha, kutakuwa na vipimo sahihi zaidi.
J: - RRD nzuri ya zamani ilienda wapi? Ni nini kilikufanya ubadilishe kwa hifadhidata za SQL? Hapo awali, vipimo vyote vilikusanywa kwenye RRD.
AG: - Zabbix alikuwa na RRD, labda katika toleo la zamani sana. Kumekuwa na hifadhidata za SQL kila wakati - mbinu ya kawaida. Mbinu ya kawaida ni MySQL, PostgreSQL (zimekuwepo kwa muda mrefu sana). Karibu hatukuwahi kutumia kiolesura cha kawaida kwa hifadhidata za SQL na RRD.
Baadhi ya matangazo π
Asante kwa kukaa nasi. Je, unapenda makala zetu? Je, ungependa kuona maudhui ya kuvutia zaidi? Tuunge mkono kwa kuweka agizo au kupendekeza kwa marafiki, , analogi ya kipekee ya seva za kiwango cha kuingia, ambayo ilivumbuliwa na sisi kwa ajili yako: (inapatikana kwa RAID1 na RAID10, hadi cores 24 na hadi 40GB DDR4).
Dell R730xd 2x nafuu katika kituo cha data cha Equinix Tier IV huko Amsterdam? Hapa tu nchini Uholanzi! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - kutoka $99! Soma kuhusu
Chanzo: mapenzi.com