Miaka mitatu iliyopita Viktor Tarnavsky na Alexey Milovidov kutoka Yandex kwenye hatua HighLoad ++ , jinsi ClickHouse ilivyo nzuri, na jinsi haipunguzi. Na kwenye hatua inayofuata kulikuwa Alexander Zaitsev Ρ kuhusu kuhamia Bonyeza Nyumba kutoka kwa DBMS nyingine ya uchanganuzi na kwa hitimisho kwamba Bonyeza Nyumba, bila shaka, nzuri, lakini si rahisi sana. Wakati katika 2016 kampuni LifeStreet, ambapo Alexander alifanya kazi wakati huo, alikuwa akibadilisha mfumo wa uchanganuzi wa petabyte nyingi kuwa Bonyeza Nyumba, ilikuwa "barabara ya matofali ya manjano" yenye kuvutia iliyojaa hatari zisizojulikana - Bonyeza Nyumba wakati huo ilionekana kama uwanja wa kuchimba madini.
Miaka mitatu baadaye Bonyeza Nyumba ikawa bora zaidi - wakati huu Alexander alianzisha kampuni ya Altinity, ambayo sio tu inasaidia watu kuhamia Bonyeza Nyumba kadhaa ya miradi, lakini pia inaboresha bidhaa yenyewe pamoja na wenzake kutoka Yandex. Sasa Bonyeza Nyumba bado sio matembezi ya kutojali, lakini sio tena uwanja wa kuchimba madini.
Alexander amekuwa akifanya kazi na mifumo iliyosambazwa tangu 2003, akiendeleza miradi mikubwa MySQL, Oracle ΠΈ Vertika. Juu ya mwisho HighLoad ++ 2019 Alexander, mmoja wa waanzilishi wa kutumia Bonyeza Nyumba, aliiambia DBMS hii ni nini sasa. Tutajifunza kuhusu sifa kuu Bonyeza Nyumba: jinsi inatofautiana na mifumo mingine na katika hali gani ni bora zaidi kuitumia. Kwa kutumia mifano, tutaangalia mazoea ya hivi karibuni na yaliyojaribiwa na mradi kwa mifumo ya ujenzi kulingana na Bonyeza Nyumba.
Retrospective: nini kilitokea miaka 3 iliyopita
Miaka mitatu iliyopita tulihamisha kampuni LifeStreet juu ya Bonyeza Nyumba kutoka kwa hifadhidata nyingine ya uchanganuzi, na uhamishaji wa uchanganuzi wa mtandao wa matangazo ulionekana kama hii:
- Juni 2016. Katika Chanzo wazi alionekana Bonyeza Nyumba na mradi wetu ulianza;
- Agosti. Uthibitisho wa Dhana: mtandao mkubwa wa matangazo, miundombinu na terabytes 200-300 za data;
- Oktoba. Data ya kwanza ya uzalishaji;
- Desemba. Mzigo kamili wa bidhaa ni matukio bilioni 10-50 kwa siku.
- Juni 2017. Uhamisho wa watumiaji kwa mafanikio Bonyeza Nyumba, 2,5 petabytes za data kwenye kundi la seva 60.
Wakati wa mchakato wa uhamiaji, kulikuwa na uelewa unaokua kwamba Bonyeza Nyumba ni mfumo mzuri ambao unapendeza kufanya kazi nao, lakini hii ni mradi wa ndani wa Yandex. Kwa hiyo, kuna nuances: Yandex itashughulika kwanza na wateja wake wa ndani na kisha tu kwa jumuiya na mahitaji ya watumiaji wa nje, na ClickHouse basi haikufikia kiwango cha biashara katika maeneo mengi ya kazi. Ndio maana tulianzisha Altinity mnamo Machi 2017 kutengeneza Bonyeza Nyumba hata haraka na rahisi zaidi sio tu kwa Yandex, bali pia kwa watumiaji wengine. Na sasa sisi:
- Tunatoa mafunzo na kusaidia kuunda suluhisho kulingana na Bonyeza Nyumba ili wateja wasipate shida, na ili suluhisho hatimaye lifanye kazi;
- Tunatoa usaidizi wa 24/7 Bonyeza Nyumba- mitambo;
- Tunatengeneza miradi yetu wenyewe ya mfumo ikolojia;
- Tunajitolea kikamilifu Bonyeza Nyumba, kujibu maombi kutoka kwa watumiaji ambao wanataka kuona vipengele fulani.
Na kwa kweli, tunasaidia kuhamia Bonyeza Nyumba Ρ MySQL, Vertika, Oracle, Greenplum, Kuondoka na mifumo mingine. Tumehusika katika hatua mbalimbali, na zote zimefanikiwa.
Kwa nini uhamie Bonyeza Nyumba
Haipunguzi kasi! Hii ndiyo sababu kuu. Bonyeza Nyumba - hifadhidata ya haraka sana kwa hali tofauti:
Nukuu za nasibu kutoka kwa watu ambao wamekuwa wakifanya kazi na watu kwa muda mrefu Bonyeza Nyumba.
Scalability. Kwenye hifadhidata nyingine unaweza kufikia utendaji mzuri kwenye kipande kimoja cha vifaa, lakini Bonyeza Nyumba unaweza kuongeza sio tu kwa wima, lakini pia kwa usawa, kwa kuongeza seva. Kila kitu haifanyi kazi vizuri kama tungependa, lakini inafanya kazi. Unaweza kupanua mfumo kadiri biashara yako inavyokua. Ni muhimu kwamba hatuzuiliwi na suluhisho sasa na daima kuna uwezekano wa maendeleo.
Kubebeka. Hakuna kushikamana na jambo moja. Kwa mfano, na Redshift ya Amazon Ni vigumu kuhamia mahali fulani. A Bonyeza Nyumba unaweza kuiweka kwenye kompyuta yako ndogo, seva, kuipeleka kwenye wingu, nenda kwa Mabernet - hakuna vikwazo kwa uendeshaji wa miundombinu. Hii ni rahisi kwa kila mtu, na hii ni faida kubwa ambayo hifadhidata zingine nyingi zinazofanana haziwezi kujivunia.
Utulivu. Bonyeza Nyumba haina kuacha katika jambo moja, kwa mfano, Yandex.Metrica, lakini yanaendelea na hutumiwa katika zaidi na zaidi miradi tofauti na viwanda. Inaweza kupanuliwa kwa kuongeza uwezo mpya wa kutatua matatizo mapya. Kwa mfano, inaaminika kuwa kuhifadhi kumbukumbu kwenye hifadhidata ni tabia mbaya, kwa hivyo walikuja nayo Elasticsearch. Lakini shukrani kwa kubadilika Bonyeza Nyumba, unaweza pia kuhifadhi kumbukumbu ndani yake, na mara nyingi hii ni bora zaidi kuliko ndani Elasticsearch - ndani Bonyeza Nyumba hii inahitaji chuma mara 10 chini.
Bure Open Source. Sio lazima ulipe chochote. Hakuna haja ya kujadili ruhusa ya kusakinisha mfumo kwenye kompyuta yako ndogo au seva. Hakuna ada zilizofichwa. Wakati huo huo, hakuna teknolojia nyingine ya hifadhidata ya Open Source inayoweza kushindana nayo kwa kasi Bonyeza Nyumba. MySQL, MariaDB, Greenplum - wote ni polepole zaidi.
Jumuiya, endesha na furaha. Katika Bonyeza Nyumba jumuiya bora: mikutano, gumzo na Alexey Milovidov, ambaye anatutoza sote kwa nishati na matumaini yake.
Kuhamia kwa ClickHouse
Kuenda kwa Bonyeza Nyumba kwa sababu fulani, unahitaji vitu vitatu tu:
- Kuelewa mapungufu Bonyeza Nyumba na kile ambacho hakifai.
- Chukua faida teknolojia na nguvu zake kuu.
- Jaribio. Hata kuelewa jinsi inavyofanya kazi Bonyeza Nyumba, si mara zote inawezekana kutabiri wakati itakuwa kasi, wakati itakuwa polepole, wakati itakuwa bora, na wakati itakuwa mbaya zaidi. Kwa hivyo jaribu.
Tatizo la kusonga
Kuna moja tu "lakini": ikiwa utahamia Bonyeza Nyumba kutoka kwa kitu kingine, basi kwa kawaida kitu kitaenda vibaya. Tumezoea baadhi ya desturi na mambo ambayo yanafanya kazi katika hifadhidata yetu tunayopenda. Kwa mfano, mtu yeyote anayefanya kazi naye SQHifadhidata za L huzingatia seti ifuatayo ya utendakazi kuwa ya lazima:
- shughuli;
- vikwazo;
- uthabiti;
- fahirisi;
- SASISHA/FUTA;
- NULLs;
- milliseconds;
- otomatiki aina casts;
- viungo vingi;
- partitions za kiholela;
- zana za usimamizi wa nguzo.
Kuajiri ni lazima, lakini miaka mitatu iliyopita Bonyeza Nyumba Hakuna mojawapo ya vipengele hivi vilivyopatikana! Sasa chini ya nusu ya kile ambacho hakijatekelezwa kinasalia: shughuli, vikwazo, Uthabiti, milliseconds na utumaji wa aina.
Na jambo kuu ni kwamba ndani Bonyeza Nyumba baadhi ya mazoea na mbinu za kawaida hazifanyi kazi au hazifanyi kazi tofauti na tulivyozoea. Kila kitu kinachoonekana ndani Bonyeza Nyumba, inalingana na "Njia ya ClickHouse", yaani. vitendaji vinatofautiana na hifadhidata zingine. Kwa mfano:
- Fahirisi hazijachaguliwa, lakini zimerukwa.
- SASISHA/FUTA si synchronous, lakini asynchronous.
- Kuna viungio vingi, lakini hakuna mpangaji wa hoja. Jinsi zinavyotekelezwa kwa ujumla sio wazi sana kwa watu kutoka ulimwengu wa hifadhidata.
Maandishi ya ClickHouse
Mnamo 1960, mtaalam wa hesabu wa Amerika wa asili ya Hungary Wigner EP aliandika makala"Ufanisi usio na maana wa hisabati katika sayansi ya asiliβ (βUfanisi Usioeleweka wa Hisabati katika Sayansi ya Asiliβ) kwamba ulimwengu unaotuzunguka unafafanuliwa vyema kwa sababu fulani na sheria za hisabati. Hisabati ni sayansi ya kufikirika, na sheria za kimaumbile zilizoonyeshwa kwa njia ya hisabati sio ndogo, na Wigner EP alisisitiza kuwa hii ni ajabu sana.
Kwa mtazamo wangu, Bonyeza Nyumba - ajabu sawa. Ili kufafanua Wigner, tunaweza kusema hivi: ufanisi usiofikiriwa ni wa kushangaza Bonyeza Nyumba katika aina mbalimbali za matumizi ya uchambuzi!
Kwa mfano, hebu tuchukue Ghala la Data la Wakati Halisi, ambayo data inapakiwa karibu kila wakati. Tunataka kupokea maombi kutoka kwayo kwa kuchelewa kwa mara ya pili. Tafadhali - tumia Bonyeza Nyumba, kwa sababu hii ndio hali ambayo iliundwa. Bonyeza Nyumba hivi ndivyo inavyotumika sio tu kwenye wavuti, lakini pia katika uchambuzi wa uuzaji na kifedha, AdTech, na vile vile katika Utambuzi wa udanganyifun. KATIKA Ghala la Data la Wakati Halisi mpango changamano wa muundo kama vile "nyota" au "snowflake" hutumiwa, meza nyingi na JOIN (wakati mwingine nyingi), na data kawaida huhifadhiwa na kubadilishwa katika baadhi ya mifumo.
Wacha tuchukue hali nyingine - Msururu wa Wakati: ufuatiliaji wa vifaa, mitandao, takwimu za matumizi, Mtandao wa vitu. Hapa tunakutana na matukio rahisi yaliyopangwa kwa wakati. Bonyeza Nyumba haikutengenezwa awali kwa hili, lakini imejionyesha kufanya kazi vizuri, ndiyo sababu makampuni makubwa hutumia Bonyeza Nyumba kama ghala la ufuatiliaji wa taarifa. Ili kuchunguza ikiwa inafaa Bonyeza Nyumba kwa mfululizo wa saa, tuliweka alama kulingana na mbinu na matokeo InfluxDB ΠΈ TimescaleDB - maalumu mfululizo wa wakati hifadhidata. Hiyo Bonyeza Nyumba, hata bila utoshelezaji wa kazi kama hizo, hushinda kwenye uwanja wa kigeni:
Π mfululizo wa wakati Kawaida meza nyembamba hutumiwa - nguzo kadhaa ndogo. Data nyingi zinaweza kutoka kwa ufuatiliajiβmamilioni ya rekodi kwa sekundeβna kwa kawaida huja kwa mlipuko mdogo (halisi wakati utiririshaji). Kwa hiyo, script tofauti ya uingizaji inahitajika, na maswali yenyewe yana maalum yao.
Management Log. Kukusanya kumbukumbu kwenye hifadhidata kawaida ni mbaya, lakini Bonyeza Nyumba hii inaweza kufanyika kwa baadhi ya maoni kama ilivyoelezwa hapo juu. Makampuni mengi hutumia Bonyeza Nyumba haswa kwa kusudi hili. Katika kesi hii, tunatumia meza pana ya gorofa ambapo tunahifadhi magogo yote (kwa mfano, kwa fomu JSON), au kata vipande vipande. Data kawaida hupakiwa katika makundi makubwa (faili), na tunatafuta kwa uga fulani.
Kwa kila moja ya kazi hizi, hifadhidata maalum hutumiwa kawaida. Bonyeza Nyumba mtu anaweza kufanya yote na vizuri sana kwamba inawashinda. Hebu sasa tuangalie kwa karibu mfululizo wa wakati hali, na jinsi ya "kupika" kwa usahihi Bonyeza Nyumba kwa scenario hii.
Mfululizo wa Wakati
Hivi sasa hii ndio hali kuu ambayo Bonyeza Nyumba kuchukuliwa suluhisho la kawaida. Mfululizo wa wakati ni seti ya matukio yaliyopangwa kwa wakati, yanayowakilisha mabadiliko katika mchakato fulani baada ya muda. Kwa mfano, hii inaweza kuwa kiwango cha moyo kwa siku au idadi ya michakato katika mfumo. Kila kitu ambacho hutoa kupe wakati na vipimo fulani ni mfululizo wa wakati:
Wengi wa aina hizi za matukio hutoka kwa ufuatiliaji. Hii inaweza kuwa sio ufuatiliaji wa wavuti tu, bali pia vifaa halisi: magari, mifumo ya viwandani, IOT, viwanda au teksi zisizo na mtu, katika shina ambayo Yandex tayari inaweka Bonyeza Nyumba- seva.
Kwa mfano, kuna makampuni ambayo hukusanya data kutoka kwa meli. Kila sekunde chache, vitambuzi kwenye meli ya kontena hutuma mamia ya vipimo tofauti. Wahandisi huzisoma, hujenga mifano na kujaribu kuelewa jinsi chombo kinatumika kwa ufanisi, kwa sababu meli ya chombo haipaswi kuwa bila kazi kwa sekunde moja. Wakati wowote wa kupumzika ni kupoteza pesa, kwa hiyo ni muhimu kutabiri njia ili kuacha ni ndogo.
Siku hizi kuna ukuaji wa hifadhidata maalumu zinazopima mfululizo wa wakati. Kwenye tovuti Injini za DB Hifadhidata tofauti zimeorodheshwa kwa njia fulani, na unaweza kuzitazama kwa aina:
Aina ya kukua kwa kasi ni mfululizo wa wakatis. Hifadhidata za grafu pia zinakua, lakini mfululizo wa wakatizimekuwa zikikua kwa kasi zaidi katika miaka michache iliyopita. Wawakilishi wa kawaida wa familia hii ya hifadhidata ni InfluxDB, Prometheus, KDB, TimescaleDB (imejengwa juu PostgreSQL), ufumbuzi kutoka Amazon. Bonyeza Nyumba inaweza kutumika hapa pia, na inatumika. Ngoja nikupe mifano michache hadharani.
Mmoja wa waanzilishi ni kampuni Wingu (CDN- mtoaji). Wanafuatilia zao CDN kupitia Bonyeza Nyumba (DNS-maombi, HTTP-maswali) na mzigo mkubwa - matukio milioni 6 kwa sekunde. Kila kitu kinapita Kafka, huenda kwa Bonyeza Nyumba, ambayo inatoa fursa ya kuona dashibodi za matukio katika mfumo kwa wakati halisi.
Comcast - mmoja wa viongozi katika mawasiliano ya simu nchini Marekani: mtandao, televisheni ya digital, simu. Waliunda mfumo sawa wa kudhibiti CDN ndani Open Source ya mradi huo Udhibiti wa Trafiki wa Apache kufanya kazi na data yako kubwa. Bonyeza Nyumba hutumika kama kigezo cha uchanganuzi.
percona kujengwa ndani Bonyeza Nyumba ndani yako PMMkuhifadhi ufuatiliaji wa aina mbalimbali MySQL.
Mahitaji Maalum
Hifadhidata za mfululizo wa wakati zina mahitaji yao maalum.
- Uingizaji wa haraka kutoka kwa mawakala wengi. Tunapaswa kuingiza data kutoka kwa mitiririko mingi haraka sana. Bonyeza Nyumba Inafanya hivyo vizuri kwa sababu viingilio vyake vyote havizuii. Yoyote Kuingiza ni faili mpya kwenye diski, na viingizi vidogo vinaweza kubaki kwa njia moja au nyingine. KATIKA Bonyeza Nyumba Ni bora kuingiza data katika makundi makubwa badala ya mstari mmoja kwa wakati mmoja.
- Mpango rahisi. Katika mfululizo wa wakati kwa kawaida hatujui muundo wa data kabisa. Inawezekana kujenga mfumo wa ufuatiliaji wa programu maalum, lakini basi ni vigumu kuitumia kwa programu nyingine. Hii inahitaji mpango rahisi zaidi. Bonyeza Nyumba, hukuruhusu kufanya hivi, ingawa ni msingi ulioandikwa kwa nguvu.
- Uhifadhi bora na kusahau data. Kawaida ndani mfululizo wa wakati kiasi kikubwa cha data, hivyo ni lazima ihifadhiwe kwa ufanisi iwezekanavyo. Kwa mfano, saa InfluxDB compression nzuri ni sifa yake kuu. Lakini mbali na kuhifadhi, unahitaji pia kuwa na uwezo wa "kusahau" data ya zamani na kufanya aina fulani sampuli za chini - kuhesabu otomatiki kwa jumla.
- Maswali ya haraka kwenye data iliyojumlishwa. Wakati mwingine ni ya kuvutia kuangalia dakika 5 za mwisho kwa usahihi wa milliseconds, lakini kwa dakika ya data ya kila mwezi au granularity ya pili inaweza kuhitajika - takwimu za jumla zinatosha. Msaada wa aina hii ni muhimu, vinginevyo ombi la miezi 3 litachukua muda mrefu sana kukamilisha hata ndani Bonyeza Nyumba.
- Maombi kama "hatua ya mwisho, kama yaΒ». Hizi ni za kawaida kwa mfululizo wa wakati maswali: angalia kipimo cha mwisho au hali ya mfumo kwa wakati fulani t. Haya sio maswali ya kupendeza sana kwa hifadhidata, lakini unahitaji pia kuweza kuyatekeleza.
- Mfululizo wa wakati wa "Gluing".. Mfululizo wa wakati ni mfululizo wa wakati. Ikiwa kuna safu mbili za wakati, mara nyingi zinahitaji kuunganishwa na kuunganishwa. Sio rahisi kufanya hivyo kwenye hifadhidata zote, haswa na safu za wakati zisizo sawa: hapa kuna vidokezo vya wakati, kuna zingine. Unaweza kuzingatia wastani, lakini ghafla bado kutakuwa na shimo huko, kwa hiyo haijulikani.
Wacha tuone jinsi mahitaji haya yanatimizwa ndani Bonyeza Nyumba.
Mpango
Π Bonyeza Nyumba mpango kwa mfululizo wa wakati inaweza kufanywa kwa njia tofauti, kulingana na kiwango cha kawaida cha data. Inawezekana kuunda mfumo kwenye data ya kawaida wakati tunajua vipimo vyote mapema. Kwa mfano, nilifanya hivi Wingu pamoja na ufuatiliaji CDN ni mfumo ulioboreshwa vizuri. Unaweza kujenga mfumo wa jumla zaidi unaofuatilia miundombinu yote na huduma mbalimbali. Katika kesi ya data isiyo ya kawaida, hatujui mapema kile tunachofuatilia - na hii labda ndiyo kesi ya kawaida.
Data ya kawaida. Safu. Mpango huo ni rahisi - safu na aina zinazohitajika:
CREATE TABLE cpu (
created_date Date DEFAULT today(),
created_at DateTime DEFAULT now(),
time String,
tags_id UInt32, /* join to dim_tag */
usage_user Float64,
usage_system Float64,
usage_idle Float64,
usage_nice Float64,
usage_iowait Float64,
usage_irq Float64,
usage_softirq Float64,
usage_steal Float64,
usage_guest Float64,
usage_guest_nice Float64
) ENGINE = MergeTree(created_date, (tags_id, created_at), 8192);Hii ni jedwali la kawaida ambalo hufuatilia aina fulani ya shughuli za upakiaji wa mfumo (user, mfumo, wavivu, nzuri) Rahisi na rahisi, lakini sio kubadilika. Ikiwa tunataka mpango rahisi zaidi, basi tunaweza kutumia safu.
Data isiyo ya kawaida. Safu:
CREATE TABLE cpu_alc (
created_date Date,
created_at DateTime,
time String,
tags_id UInt32,
metrics Nested(
name LowCardinality(String),
value Float64
)
) ENGINE = MergeTree(created_date, (tags_id, created_at), 8192);
SELECT max(metrics.value[indexOf(metrics.name,'usage_user')]) FROM ...
Muundo Nested ni safu mbili: metrics.jina ΠΈ thamani.metrics. Hapa unaweza kuhifadhi data ya ufuatiliaji kiholela kama safu ya majina na safu ya vipimo kwa kila tukio. Kwa uboreshaji zaidi, badala ya muundo mmoja kama huo, unaweza kutengeneza kadhaa. Kwa mfano, moja kwa kuelea-thamani, mwingine - kwa int-maana kwa sababu int Ninataka kuhifadhi kwa ufanisi zaidi.
Lakini muundo kama huo ni ngumu zaidi kufikia. Utalazimika kutumia ujenzi maalum, ukitumia kazi maalum kutoa maadili ya kwanza ya faharisi na kisha safu:
SELECT max(metrics.value[indexOf(metrics.name,'usage_user')]) FROM ...Lakini bado inafanya kazi haraka sana. Njia nyingine ya kuhifadhi data isiyo ya kawaida ni kwa safu.
Data isiyo ya kawaida. Kamba. Kwa njia hii ya jadi, bila safu, majina na maadili huhifadhiwa wakati huo huo. Ikiwa vipimo 5 vinatoka kwa kifaa kimoja mara moja, safu mlalo 000 zinatolewa kwenye hifadhidata:
CREATE TABLE cpu_rlc (
created_date Date,
created_at DateTime,
time String,
tags_id UInt32,
metric_name LowCardinality(String),
metric_value Float64
) ENGINE = MergeTree(created_date, (metric_name, tags_id, created_at), 8192);
SELECT
maxIf(metric_value, metric_name = 'usage_user'),
...
FROM cpu_r
WHERE metric_name IN ('usage_user', ...)
Bonyeza Nyumba inakabiliana na hii - ina upanuzi maalum Bonyeza Nyumba SQL. Kwa mfano maxKama - chaguo maalum la kukokotoa linalokokotoa kiwango cha juu zaidi kwa kipimo wakati hali fulani inatimizwa. Unaweza kuandika misemo kama hii katika ombi moja na kuhesabu mara moja thamani ya vipimo kadhaa.
Wacha tulinganishe njia tatu:
Hapa nimeongeza "Ukubwa wa Data ya Disk" kwa seti fulani ya data ya majaribio. Kwa upande wa safu wima, tuna ukubwa mdogo zaidi wa data: ukandamizaji wa juu, kasi ya juu ya hoja, lakini tunalipa kwa kurekodi kila kitu mara moja.
Katika kesi ya safu, kila kitu ni mbaya zaidi. Data bado imebanwa vyema na muundo usio wa kawaida unaweza kuhifadhiwa. Lakini Bonyeza Nyumba - database ya columnar, na tunapoanza kuhifadhi kila kitu kwa safu, inageuka kuwa safu moja, na tunalipa kwa kubadilika kwa ufanisi. Kwa operesheni yoyote, utalazimika kusoma safu nzima kwenye kumbukumbu, kisha pata kipengee kinachohitajika ndani yake - na ikiwa safu inakua, basi kasi inaharibika.
Katika moja ya kampuni zinazotumia njia hii (kwa mfano, ), safu hukatwa vipande vipande vya vipengele 128. Data kutoka kwa metrics elfu kadhaa yenye kiasi cha TB 200 ya data / siku haihifadhiwa katika safu moja, lakini katika safu 10 au 30 na mantiki maalum ya kuhifadhi.
Njia rahisi zaidi ni kwa kamba. Lakini data haijabanwa vibaya, saizi ya jedwali ni kubwa, na hata wakati maswali yanategemea metriki kadhaa, ClickHouse haifanyi kazi ipasavyo.
Mpango wa mseto
Hebu tufikiri kwamba tumechagua mzunguko wa safu. Lakini ikiwa tunajua kwamba dashibodi zetu nyingi zinaonyesha tu vipimo vya watumiaji na mfumo, tunaweza pia kubadilisha vipimo hivi kuwa safu wima kutoka safu katika kiwango cha jedwali kwa njia hii:
CREATE TABLE cpu_alc (
created_date Date,
created_at DateTime,
time String,
tags_id UInt32,
metrics Nested(
name LowCardinality(String),
value Float64
),
usage_user Float64
MATERIALIZED metrics.value[indexOf(metrics.name,'usage_user')],
usage_system Float64
MATERIALIZED metrics.value[indexOf(metrics.name,'usage_system')]
) ENGINE = MergeTree(created_date, (tags_id, created_at), 8192);
Wakati wa kuingiza Bonyeza Nyumba itazihesabu kiotomatiki. Kwa njia hii unaweza kuchanganya biashara na raha: mpango huo ni rahisi na wa jumla, lakini tulitoa nguzo zinazotumiwa mara kwa mara. Kumbuka kwamba hii haikuhitaji kubadilisha kuingiza na ETLambayo inaendelea kuingiza safu kwenye meza. Tulifanya tu ALTER TABLE, aliongeza spika kadhaa na tukapata mpango mseto na wa haraka zaidi ambao unaweza kuanza kutumia mara moja.
Codecs na compression
Kwa mfululizo wa wakati Ni muhimu jinsi unavyopakia data vizuri kwa sababu kiasi cha taarifa kinaweza kuwa kikubwa sana. KATIKA Bonyeza Nyumba Kuna seti ya zana za kufikia athari ya ukandamizaji wa 1:10, 1:20, na wakati mwingine zaidi. Hii ina maana kwamba 1 TB ya data isiyofunguliwa kwenye diski inachukua 50-100 GB. Saizi ndogo ni nzuri, data inaweza kusomwa na kuchakatwa haraka.
Ili kufikia kiwango cha juu cha compression, Bonyeza Nyumba inasaidia kodeki zifuatazo:
Jedwali la mfano:
CREATE TABLE benchmark.cpu_codecs_lz4 (
created_date Date DEFAULT today(),
created_at DateTime DEFAULT now() Codec(DoubleDelta, LZ4),
tags_id UInt32,
usage_user Float64 Codec(Gorilla, LZ4),
usage_system Float64 Codec(Gorilla, LZ4),
usage_idle Float64 Codec(Gorilla, LZ4),
usage_nice Float64 Codec(Gorilla, LZ4),
usage_iowait Float64 Codec(Gorilla, LZ4),
usage_irq Float64 Codec(Gorilla, LZ4),
usage_softirq Float64 Codec(Gorilla, LZ4),
usage_steal Float64 Codec(Gorilla, LZ4),
usage_guest Float64 Codec(Gorilla, LZ4),
usage_guest_nice Float64 Codec(Gorilla, LZ4),
additional_tags String DEFAULT ''
)
ENGINE = MergeTree(created_date, (tags_id, created_at), 8192);Hapa tunafafanua codec DoubleDelta katika kesi moja, katika pili - Gorilla, na hakika tutaongeza zaidi LZ4 mgandamizo. Kama matokeo, saizi ya data kwenye diski imepunguzwa sana:
Hii inaonyesha ni kiasi gani data hiyo hiyo inachukua, lakini kwa kutumia kodeki na mbano tofauti:
- katika faili ya GZIP kwenye diski;
- katika ClickHouse bila codecs, lakini kwa compression ZSTD;
- katika ClickHouse na codecs na compression LZ4 na ZSTD.
Inaweza kuonekana kuwa jedwali zilizo na kodeki huchukua nafasi ndogo sana.
Saizi mambo
Sio muhimu sana aina sahihi ya data:
Katika mifano yote hapo juu nilitumia Kuelea64. Lakini ikiwa tulichagua Kuelea32, basi hiyo itakuwa bora zaidi. Hii ilionyeshwa vizuri na wavulana kutoka Perkona kwenye nakala iliyounganishwa hapo juu. Ni muhimu kutumia aina ya kompakt inayofaa zaidi kwa kazi: hata kidogo kwa saizi ya diski kuliko kasi ya swala. Bonyeza Nyumba nyeti sana kwa hili.
Ikiwa unaweza kutumia int32 badala ya int64, kisha utarajie ongezeko la karibu mara mbili katika utendaji. Data inachukua kumbukumbu kidogo, na "hesabu" zote hufanya kazi kwa kasi zaidi. Bonyeza Nyumba kwa ndani ni mfumo uliochapwa kwa ukali sana; hufanya matumizi ya juu ya uwezekano wote ambao mifumo ya kisasa hutoa.
Mkusanyiko na Maoni ya Nyenzo
Ujumlisho na mionekano ya uhalisia hukuruhusu kuunda mijumuisho ya hafla tofauti:
Kwa mfano, unaweza kuwa na data ya chanzo isiyojumlishwa, na unaweza kuambatisha mitazamo mbalimbali kwao kwa kujumlisha kiotomatiki kupitia injini maalum. SummingMergeTree (SMT). SMT ni muundo maalum wa ujumlishaji wa data ambao hukokotoa hesabu kiotomatiki. Data ghafi imeingizwa kwenye hifadhidata, inakusanywa kiotomatiki, na dashibodi zinaweza kutumika mara moja juu yake.
TTL - "sahau" data ya zamani
Jinsi ya "kusahau" data ambayo haihitajiki tena? Bonyeza Nyumba anajua jinsi ya kufanya hivi. Wakati wa kuunda meza, unaweza kutaja TTL misemo: kwa mfano, kwamba tunahifadhi data ndogo kwa siku moja, data ya kila siku kwa siku 30, na kamwe tusiguse data ya kila wiki au ya kila mwezi:
CREATE TABLE aggr_by_minute
β¦
TTL time + interval 1 day
CREATE TABLE aggr_by_day
β¦
TTL time + interval 30 day
CREATE TABLE aggr_by_week
β¦
/* no TTL */
Ngazi nyingi - kugawanya data kwenye diski
Kuchukua wazo hili zaidi, data inaweza kuhifadhiwa ndani Bonyeza Nyumba katika maeneo mbalimbali. Tuseme tunataka kuhifadhi data motomoto kwa wiki iliyopita kwenye mtandao wa karibu sana SSD, na tunaweka data zaidi ya kihistoria mahali pengine. KATIKA Bonyeza Nyumba hii sasa inawezekana:
Unaweza kusanidi sera ya uhifadhi (sera ya uhifadhi) Hivyo Bonyeza Nyumba itahamisha data kiotomatiki inapofikia hali fulani hadi hifadhi nyingine.
Lakini sio hivyo tu. Katika ngazi ya meza maalum, unaweza kufafanua sheria kwa wakati hasa data inapoingia kwenye hifadhi ya baridi. Kwa mfano, data huhifadhiwa kwenye diski ya haraka sana kwa siku 7, na kila kitu ambacho ni cha zamani kinahamishiwa kwa polepole. Hii ni nzuri kwa sababu hukuruhusu kuweka mfumo katika utendaji wa juu, wakati unadhibiti gharama na usipoteze pesa kwenye data baridi:
CREATE TABLE
...
TTL date + INTERVAL 7 DAY TO VOLUME 'cold_volume',
date + INTERVAL 180 DAY DELETE
Fursa za kipekee Bonyeza Nyumba
Katika karibu kila kitu Bonyeza Nyumba Kuna "vivutio" kama hivyo, lakini vinarekebishwa na kutengwa - kitu ambacho hakiko kwenye hifadhidata zingine. Kwa mfano, hapa kuna baadhi ya vipengele vya kipekee Bonyeza Nyumba:
- Safu. Katika Bonyeza Nyumba msaada mzuri sana kwa safu, pamoja na uwezo wa kufanya mahesabu magumu juu yao.
- Kukusanya Miundo ya Data. Hii ni moja ya "sifa za muuaji" Bonyeza Nyumba. Licha ya ukweli kwamba wavulana kutoka Yandex wanasema kwamba hatutaki kujumlisha data, kila kitu kimejumuishwa. Bonyeza Nyumba, kwa sababu ni haraka na rahisi.
- Maoni ya Nyenzo. Pamoja na ujumlishaji wa miundo ya data, mitazamo iliyobadilishwa hukuruhusu kufanya urahisi halisi wakati mkusanyiko.
- ClickHouse SQL. Hiki ni kiendelezi cha lugha SQL na vipengee vingine vya ziada na vya kipekee ambavyo vinapatikana tu ndani Bonyeza Nyumba. Hapo awali, ilikuwa kama upanuzi kwa upande mmoja, na hasara kwa upande mwingine. Sasa karibu hasara zote ikilinganishwa na SQL 92 tuliiondoa, sasa ni nyongeza tu.
- Lambda- maneno. Je, bado ziko kwenye hifadhidata yoyote?
- ML-ungwa mkono. Hii inapatikana katika hifadhidata tofauti, zingine ni bora, zingine ni mbaya zaidi.
- chanzo wazi. Tunaweza kupanua Bonyeza Nyumba pamoja. Sasa ndani Bonyeza Nyumba wachangiaji wapatao 500, na idadi hii inakua kila mara.
Maswali gumu
Π Bonyeza Nyumba kuna njia nyingi tofauti za kufanya kitu kimoja. Kwa mfano, unaweza kurudisha thamani ya mwisho kutoka kwa jedwali kwa njia tatu tofauti za CPU (pia kuna ya nne, lakini ni ya kigeni zaidi).
Ya kwanza inaonyesha jinsi inavyofaa kufanya ndani Bonyeza Nyumba maswali unapotaka kuangalia hiyo tuple zilizomo katika subquery. Hili ni jambo ambalo mimi binafsi nilikosa katika hifadhidata zingine. Ikiwa ninataka kulinganisha kitu na subquery, basi katika hifadhidata zingine tu scalar inaweza kulinganishwa nayo, lakini kwa safu kadhaa ninahitaji kuandika. JOIN. Katika Bonyeza Nyumba unaweza kutumia tuple:
SELECT *
FROM cpu
WHERE (tags_id, created_at) IN
(SELECT tags_id, max(created_at)
FROM cpu
GROUP BY tags_id)Njia ya pili hufanya vivyo hivyo lakini hutumia kazi ya jumla argMax:
SELECT
argMax(usage_user), created_at),
argMax(usage_system), created_at),
...
FROM cpu Π Bonyeza Nyumba kuna kazi kadhaa za jumla, na ikiwa unatumia viunganishi, basi kulingana na sheria za combinatorics utapata karibu elfu yao. ArgMax - moja ya kazi zinazohesabu thamani ya juu: ombi hurejesha thamani mtumiaji_mtumiaji, ambapo thamani ya juu inafikiwa imeundwa_saa:
SELECT now() as created_at,
cpu.*
FROM (SELECT DISTINCT tags_id from cpu) base
ASOF LEFT JOIN cpu USING (tags_id, created_at)
ASOF JIUNGE - safu za "gluing" na nyakati tofauti. Hiki ni kipengele cha kipekee cha hifadhidata ambacho kinapatikana tu ndani kdb+. Ikiwa kuna safu mbili za wakati na nyakati tofauti, ASOF JIUNGE hukuruhusu kusonga na kuziunganisha katika ombi moja. Kwa kila thamani katika mfululizo wa wakati mmoja, thamani ya karibu zaidi katika nyingine inapatikana, na inarejeshwa kwenye mstari huo huo:
Kazi za Uchambuzi
Katika kiwango SQL-2003 unaweza kuandika kama hii:
SELECT origin,
timestamp,
timestamp -LAG(timestamp, 1) OVER (PARTITION BY origin ORDER BY timestamp) AS duration,
timestamp -MIN(timestamp) OVER (PARTITION BY origin ORDER BY timestamp) AS startseq_duration,
ROW_NUMBER() OVER (PARTITION BY origin ORDER BY timestamp) AS sequence,
COUNT() OVER (PARTITION BY origin ORDER BY timestamp) AS nb
FROM mytable
ORDER BY origin, timestamp;
Π Bonyeza Nyumba Hauwezi kufanya hivyo - haiauni kiwango SQL-2003 na pengine kamwe kufanya hivyo. Badala yake, katika Bonyeza Nyumba Ni kawaida kuandika kama hii:
Niliahidi lambdas - hizi hapa!
Hii ni analog ya swala la uchanganuzi katika kiwango SQL-2003: anahesabu tofauti kati ya hizo mbili muhuri wa muda, muda, nambari ya kawaida - kila kitu ambacho kwa kawaida tunazingatia kazi za uchambuzi. KATIKA Bonyeza Nyumba Tunazihesabu kwa njia ya safu: kwanza tunaangusha data kwenye safu, baada ya hapo tunafanya kila kitu tunachotaka kwenye safu, na kisha tunapanua tena. Sio rahisi sana, inahitaji upendo wa programu ya kazi kwa kiwango cha chini, lakini ni rahisi sana.
Sifa maalum
Zaidi ya hayo, katika Bonyeza Nyumba kazi nyingi maalumu. Kwa mfano, jinsi ya kuamua ni vikao ngapi vinavyofanyika wakati huo huo? Kazi ya kawaida ya ufuatiliaji ni kuamua mzigo wa juu na ombi moja. KATIKA Bonyeza Nyumba Kuna kazi maalum kwa kusudi hili:
Kwa ujumla, ClickHouse ina kazi maalum kwa madhumuni mengi:
- kukimbia Tofauti, kukimbiaKusanya, jirani;
- sumMap (ufunguo, thamani);
- timeSeriesGroupSum(uid, muhuri wa muda, thamani);
- timeSeriesGroupRateSum(uid, muhuri wa muda, thamani);
- skewPop, skewSamp, kurtPop, kurtSamp;
- NA KUJAZA / NA TIES;
- simpleLinearRegression, stochasticLinearRegression.
Hii sio orodha kamili ya kazi, kuna 500-600 kwa jumla. Kidokezo: kazi zote ndani Bonyeza Nyumba iko kwenye jedwali la mfumo (sio zote zimeandikwa, lakini zote zinavutia):
select * from system.functions order by nameBonyeza Nyumba huhifadhi habari nyingi kuhusu yenyewe, ikiwa ni pamoja na meza za kumbukumbu, query_log, logi ya kufuatilia, logi ya shughuli na vizuizi vya data (sehemu_logi), logi ya metriki, na logi ya mfumo, ambayo kawaida huandika kwa diski. Vipimo vya kumbukumbu ni mfululizo wa wakati Π² Bonyeza Nyumba kweli Bonyeza Nyumba: Hifadhidata yenyewe inaweza kuchukua jukumu mfululizo wa wakati hifadhidata, kwa hivyo "kula" yenyewe.
Hili pia ni jambo la kipekee - kwani tunafanya kazi nzuri mfululizo wa wakati, kwa nini hatuwezi kuhifadhi kila kitu tunachohitaji ndani yetu wenyewe? Hatuhitaji Prometheus, tunaweka kila kitu kwetu. Imeunganishwa grafana na tunajifuatilia wenyewe. Hata hivyo, kama Bonyeza Nyumba huanguka, hatutaona kwa nini, kwa hivyo kwa kawaida hawafanyi hivyo.
Nguzo kubwa au ndogo nyingi Bonyeza Nyumba
Ni nini bora - nguzo moja kubwa au ClickHouse nyingi ndogo? Mbinu ya jadi ya DWH ni nguzo kubwa ambayo mizunguko imetengwa kwa kila programu. Tulikuja kwa msimamizi wa hifadhidata - tupe mchoro, na walitupa moja:
Π Bonyeza Nyumba unaweza kufanya hivyo tofauti. Unaweza kufanya kila programu iwe yako mwenyewe Bonyeza Nyumba:
Hatuhitaji tena ile kubwa ya kutisha DWH na watawala wasiokubalika. Tunaweza kuipa kila programu kivyake Bonyeza Nyumba, na msanidi anaweza kuifanya mwenyewe, kwani Bonyeza Nyumba rahisi sana kufunga na hauhitaji utawala mgumu:
Lakini ikiwa tunayo mengi Bonyeza Nyumba, na unahitaji kusakinisha mara nyingi, basi unataka kugeuza mchakato huu kiotomatiki. Kwa hili tunaweza, kwa mfano, kutumia Mabernet ΠΈ clickhouse-endeshaji. KATIKA Kubernetes ClickHouse unaweza kuiweka "on-click": Ninaweza kubofya kitufe, endesha faili ya maelezo na hifadhidata iko tayari. Ninaweza kuunda mchoro mara moja, nianze kupakia vipimo hapo, na baada ya dakika 5 nina dashibodi tayari. grafana. Ni rahisi sana!
matokeo?
Hivyo, Bonyeza Nyumba -Hii:
- Haraka. Kila mtu anajua hili.
- Tu. Utata kidogo, lakini ninaamini kuwa ni ngumu katika mafunzo, rahisi katika mapigano. Ikiwa unaelewa jinsi Bonyeza Nyumba inafanya kazi, basi kila kitu ni rahisi sana.
- Ulimwenguni. Inafaa kwa hali tofauti: DWH, Msururu wa Muda, Hifadhi ya Kumbukumbu. Lakini sivyo OLTP hifadhidata, kwa hivyo usijaribu kuingiza kifupi na kusoma hapo.
- Jambo la kushangaza. Labda yule anayefanya kazi naye Bonyeza Nyumba, alipata wakati mwingi wa kupendeza kwa maana nzuri na mbaya. Kwa mfano, toleo jipya lilitoka, kila kitu kiliacha kufanya kazi. Au wakati ulijitahidi na kazi kwa siku mbili, lakini baada ya kuuliza swali kwenye mazungumzo ya Telegraph, kazi hiyo ilitatuliwa kwa dakika mbili. Au kama kwenye mkutano kwenye ripoti ya Lesha Milovidov, picha ya skrini kutoka Bonyeza Nyumba kuvunja matangazo HighLoad ++. Kitu cha aina hii hutokea wakati wote na hufanya maisha yetu kuwa magumu. Bonyeza Nyumba mkali na ya kuvutia!
Unaweza kutazama wasilisho .
Mkutano uliosubiriwa kwa muda mrefu wa watengenezaji wa mifumo ya mzigo mkubwa katika itafanyika mnamo Novemba 9 na 10 huko Skolkovo. Hatimaye, huu utakuwa mkutano wa nje ya mtandao (ingawa kukiwa na tahadhari zote), kwa kuwa nishati ya HighLoad++ haiwezi kusakinishwa mtandaoni.
Kwa mkutano huo, tunapata na kukuonyesha kesi kuhusu uwezo wa juu wa teknolojia: HighLoad ++ ilikuwa, iko na itakuwa mahali pekee ambapo unaweza kujifunza jinsi Facebook, Yandex, VKontakte, Google na Amazon zinavyofanya kazi kwa siku mbili.
Baada ya kufanya mikutano yetu bila usumbufu tangu 2007, mwaka huu tutakutana kwa mara ya 14. Wakati huu, mkutano umekua mara 10; mwaka jana, hafla kuu ya tasnia ilileta pamoja washiriki 3339, wasemaji 165, ripoti na mikutano, na nyimbo 16 zilikuwa zikiendeshwa kwa wakati mmoja.
Mwaka jana kulikuwa na mabasi 20, lita 5280 za chai na kahawa, lita 1650 za vinywaji vya matunda na chupa 10200 za maji. Na kilo nyingine 2640 za chakula, sahani 16 na vikombe 000. Kwa njia, na pesa zilizotolewa kutoka kwa karatasi iliyosindika, tulipanda miche 25 ya mwaloni :)Unaweza kununua tikiti , pata habari kuhusu mkutano huo - , na kuzungumza kwenye mitandao yote ya kijamii: , , ΠΈ .
Chanzo: mapenzi.com