ClickHouse + Graphite- disk space သုံးစွဲမှုကို သိသိသာသာ လျှော့ချနည်း

မင်္ဂလာပါ

တစ်စုံတစ်ယောက်က စနစ်ကို အသုံးချရင် ဖိုက်တာဝက်ဘ် သိုလှောင်မှု စွမ်းဆောင်ရည် ပြဿနာနှင့် ကြုံတွေ့ခဲ့ရသည်။ တီးတိုးစကားပွော (IO၊ disk space သုံးစွဲသည်)၊ ထို့နောက် ClickHouse ကို အစားထိုးမှုအဖြစ် ကာစ်လုပ်ရန် အခွင့်အလမ်းတစ်ခု ဖြစ်သင့်သည်။ ဤထုတ်ပြန်ချက်သည် ဥပမာအားဖြင့် ပြင်ပအဖွဲ့အစည်း အကောင်အထည်ဖော်မှုအား daemon လက်ခံမက်ထရစ်များအဖြစ် အသုံးပြုထားပြီးဖြစ်ကြောင်း ဆိုလိုသည်။ ကာဗွန်ရေးသူ သို့မဟုတ် သွား-ကာဗွန်.

ClickHouse သည် ဖော်ပြထားသော ပြဿနာများကို ကောင်းမွန်စွာ ဖြေရှင်းပေးသည်။ ဥပမာအားဖြင့်၊ အသံတိုးတိုးမှဒေတာ 2TiB ကိုလွှဲပြောင်းပြီးနောက်၊ ၎င်းတို့သည် 300GiB သို့ အံဝင်ခွင်ကျဖြစ်သည်။ အသေးစိတ်နှိုင်းယှဥ်မှုတွင် ငါမနေလိုပါ၊ ဤအကြောင်းအရာနှင့် ပတ်သက်၍ ဆောင်းပါးများစွာရှိပါသည်။ ထို့အပြင်၊ မကြာသေးမီအထိ၊ ကျွန်ုပ်တို့၏ ClickHouse သိုလှောင်မှုတွင် အရာအားလုံးသည် ပြီးပြည့်စုံခြင်းမရှိသေးပါ။

လောင်တဲ့နေရာနဲ့ ပြဿနာတွေ

အစပိုင်းမှာတော့ အရာအားလုံးက ကောင်းကောင်းအလုပ်လုပ်သင့်တယ်။ လိုက်နေသည်။ စာရွက်စာတမ်းမက်ထရစ်များသိုလှောင်မှုအစီအစဉ်အတွက် config တစ်ခုဖန်တီးပါ (နောက်ထပ် retention) ထို့နောက် ဂရပ်ဖိုက်-ဝဘ်အတွက် ရွေးချယ်ထားသော နောက်ကွယ်မှ အကြံပြုချက်အတိုင်း ဇယားတစ်ခုကို ဖန်တီးပါ- ကာဗွန်-ကလစ်ရုံ+ဖိုက်တာ ကလစ် သို့မဟုတ် ဂရပ်ဖစ်မည်သည့် stack ကိုအသုံးပြုသည်ပေါ် မူတည်. ပြီးတော့... ချိန်ကိုက်ဗုံးက ပြတ်သွားတယ်။

မည်သည့်အရာကို နားလည်ရန်၊ * မိသားစု၏ အင်ဂျင်ဇယားများတွင် ထည့်သွင်းမှုများ မည်သို့လုပ်ဆောင်ပုံနှင့် ဒေတာ၏ နောက်ထပ်ဘဝလမ်းကြောင်းကို သိရှိရန် လိုအပ်ပါသည်။MergeTree ClickHouse (ဇယားကွက်များ တင်ဆက်မှု Alexey Zatelepin):

• ထည့်သွင်းခဲ့သည်။ блок ဒေတာ။ ကျွန်ုပ်တို့၏အခြေအနေတွင်၊ ၎င်းသည်ရောက်ရှိလာသောတိုင်းတာမှုများဖြစ်သည်။
  
• ထိုကဲ့သို့သော ဘလောက်တစ်ခုစီကို disk သို့မရေးမီ သော့အလိုက်စီထားသည်။ ORDER BYဇယားကိုဖန်တီးသောအခါသတ်မှတ်ထားသည်။
• စီပြီးနောက်၊ кусок (part) data တွေကို disk မှာရေးထားတယ်။
  
• ထိုသို့သောအပိုင်းများစွာမပါဝင်စေရန် ဆာဗာသည် နောက်ခံတွင်စောင့်ကြည့်ပြီး နောက်ခံကိုဖွင့်သည်။ слияния (mergeနောက်မှ ပေါင်းစည်းပါ။)
  
  
• ဒေတာများ တက်ကြွစွာ စီးဆင်းမှု ရပ်တန့်သွားသည်နှင့် တပြိုင်နက် ဆာဗာသည် သူ့ဘာသာသူ ပေါင်းစည်းခြင်း ရပ်တန့်သွားပါသည်။ партицию (partition) သို့သော် သင်သည် command ဖြင့် လုပ်ငန်းစဉ်ကို ကိုယ်တိုင်စတင်နိုင်သည်။ OPTIMIZE.
• partition တွင် အပိုင်းတစ်ပိုင်းသာကျန်ပါက၊ ပုံမှန် command ကို အသုံးပြု၍ ပေါင်းစည်းခြင်းကို သင်အသုံးပြုရမည် မဟုတ်ပါ။ OPTIMIZE ... FINAL

ဒီတော့ ပထမဆုံး တိုင်းတာမှုတွေ ရောက်လာတယ်။ ပြီးတော့ သူတို့က နေရာယူတယ်။ အကြောင်းရင်းများစွာပေါ်မူတည်ပြီး နောက်ဆက်တွဲဖြစ်ရပ်များသည် အနည်းငယ်ကွဲပြားနိုင်သည်-

• အပိုင်းခွဲခြင်းသော့သည် အလွန်သေးငယ်သော (တစ်နေ့) သို့မဟုတ် အလွန်ကြီး (လပေါင်းများစွာ) ဖြစ်နိုင်သည်။
• ထိန်းသိမ်းမှုပုံစံသည် တက်ကြွသောအကန့် (မက်ထရစ်များကို မှတ်တမ်းတင်ထားသည့်) အတွင်း သိသာထင်ရှားသော ဒေတာစုစည်းမှု သတ်မှတ်ချက်များနှင့် ကိုက်ညီနိုင်သည် သို့မဟုတ် ဖြစ်နိုင်သည်။
• ဒေတာများစွာရှိပါက၊ နောက်ခံပေါင်းစပ်မှုကြောင့် ကြီးမားနေပြီဖြစ်သော (အသင့်တော်ဆုံးမဟုတ်သော အပိုင်းခွဲခြင်းကီးကို ရွေးချယ်ပါက) အစောဆုံးအပိုင်းများသည် ၎င်းတို့ကို သေးငယ်သောအပိုင်းများနှင့် ပေါင်းစပ်မည်မဟုတ်ပါ။

ပြီးတော့ အမြဲတမ်း အတူတူပါပဲ။ ClickHouse ရှိ မက်ထရစ်များဖြင့် သိမ်းပိုက်ထားသော နေရာသည် တိုးလာပါက-

• မသက်ဆိုင်ပါ။ OPTIMIZE ... FINAL ကိုယ်တိုင် သို့မဟုတ်
• ဆက်လက်လုပ်ဆောင်နေသည့် အပိုင်းများအားလုံးတွင် ဒေတာမထည့်ပါနှင့်၊ ထို့ကြောင့် မကြာမီ သို့မဟုတ် နောက်ပိုင်းတွင် နောက်ခံပေါင်းစည်းမှု စတင်နိုင်မည်ဖြစ်သည်။

ဒုတိယနည်းလမ်းသည် အကောင်အထည်ဖော်ရန် အလွယ်ကူဆုံးဖြစ်ပုံရပြီး ၎င်းသည် မှားယွင်းနေပြီး ဦးစွာကြိုးစားခဲ့သည်။
ကျွန်ုပ်သည် လွန်ခဲ့သော 4 နှစ်တာကာလအတွင်း နေ့စဉ်နေ့တိုင်းအတွက် dummy metrics များပေးပို့ပြီး နာရီတိုင်း cron လည်ပတ်စေသော အတော်လေးရိုးရှင်းသော python script ကိုရေးခဲ့သည်။
ClickHouse DBMS ၏ လည်ပတ်မှုတစ်ခုလုံးသည် ဤစနစ်သည် မကြာမီ သို့မဟုတ် နောက်ပိုင်းတွင် နောက်ခံအလုပ်အားလုံးကို လုပ်ဆောင်မည်ဟူသောအချက်အပေါ် အခြေခံထားသောကြောင့်၊ သို့သော် မည်သည့်အချိန်တွင် လုပ်ဆောင်မည်ကို မသိရသေးပါ၊ ကြီးမားသောအပိုင်းအစများနှင့် စတင်ပေါင်းစပ်မည့်အချိန်ကို ကျွန်ုပ် မစောင့်နိုင်ခဲ့ပါ။ အသစ်လေးတွေ။ အတင်းအကြပ် ပိုမိုကောင်းမွန်အောင်ပြုလုပ်ခြင်းများကို အလိုအလျောက်လုပ်ဆောင်ရန် နည်းလမ်းရှာဖွေရန် လိုအပ်ကြောင်း ထင်ရှားလာပါသည်။

ClickHouse စနစ်ဇယားများရှိ အချက်အလက်

ဇယားဖွဲ့စည်းပုံကိုကြည့်ရအောင် system.parts များ. ဤသည်မှာ ClickHouse ဆာဗာရှိ ဇယားအားလုံး၏ အပိုင်းတစ်ခုစီနှင့် ပတ်သက်သော ပြည့်စုံသော အချက်အလက်ဖြစ်သည်။ အခြားအရာများအနက်၊ အောက်ပါကော်လံများပါရှိသည်။

• db အမည် (database);
• ဇယားအမည် (table);
• partition အမည်နှင့် ID (partition & partition_id);
• အပိုင်းကို ဖန်တီးခဲ့တုန်းက (modification_time);
• အပိုင်းတစ်ခုတွင် အနည်းဆုံးနှင့် အများဆုံးရက်စွဲ (အပိုင်းခွဲခြင်းကို နေ့အလိုက်လုပ်ဆောင်သည်) (min_date & max_date);

စားပွဲလည်းရှိတယ်။ system.graphite_retentionsအောက်ပါစိတ်ဝင်စားဖွယ်နယ်ပယ်များနှင့်အတူ၊

• db အမည် (Tables.database);
• ဇယားအမည် (Tables.table);
• နောက်တစ်ခုပေါင်းစည်းခြင်းကို အသုံးပြုသင့်သောအခါ မက်ထရစ်အသက် (age);

ဒီတော့:

1. ကျွန်ုပ်တို့တွင် အပိုင်းဇယားတစ်ခုနှင့် ပေါင်းစပ်စည်းမျဉ်းများ ဇယားတစ်ခုရှိသည်။
2. ကျွန်ုပ်တို့သည် ၎င်းတို့၏ လမ်းဆုံများကို ပေါင်းစပ်ပြီး *GraphiteMergeTree ဇယားအားလုံးကို ရယူလိုက်ပါ။
3. ကျွန်ုပ်တို့သည် အပိုင်းပိုင်းအားလုံးကို ရှာဖွေနေပါသည်။
   • တစ်လုံးထက်ပိုသည်။
   • သို့မဟုတ် နောက်တစ်ခုပေါင်းစည်းမှုစည်းမျဉ်းကို ကျင့်သုံးရန် အချိန်ကျရောက်လာပြီဖြစ်သည်။ modification_time ဒီအချိန်ထက် အသက်ကြီးတယ်။

အကောင်အထည်ဖော်မှု

ဒီတောင်းဆိုချက်

SELECT
    concat(p.database, '.', p.table) AS table,
    p.partition_id AS partition_id,
    p.partition AS partition,
    -- Самое "старое" правило, которое может быть применено для
    -- партиции, но не в будущем, см (*)
    max(g.age) AS age,
    -- Количество кусков в партиции
    countDistinct(p.name) AS parts,
    -- За самую старшую метрику в партиции принимается 00:00:00 следующего дня
    toDateTime(max(p.max_date + 1)) AS max_time,
    -- Когда партиция должна быть оптимизированна
    max_time + age AS rollup_time,
    -- Когда самый старый кусок в партиции был обновлён
    min(p.modification_time) AS modified_at
FROM system.parts AS p
INNER JOIN
(
    -- Все правила для всех таблиц *GraphiteMergeTree
    SELECT
        Tables.database AS database,
        Tables.table AS table,
        age
    FROM system.graphite_retentions
    ARRAY JOIN Tables
    GROUP BY
        database,
        table,
        age
) AS g ON
    (p.table = g.table)
    AND (p.database = g.database)
WHERE
    -- Только активные куски
    p.active
    -- (*) И только строки, где правила аггрегации уже должны быть применены
    AND ((toDateTime(p.max_date + 1) + g.age) < now())
GROUP BY
    table,
    partition
HAVING
    -- Только партиции, которые младше момента оптимизации
    (modified_at < rollup_time)
    -- Или с несколькими кусками
    OR (parts > 1)
ORDER BY
    table ASC,
    partition ASC,
    age ASC

*GraphiteMergeTree table partitions တစ်ခုစီကို ပေါင်းစည်းခြင်းသည် disk space ကို လွတ်စေသင့်သည်။ တောင်းဆိုချက်တစ်ခုဖြင့် ၎င်းတို့အားလုံးကို ဖြတ်ကျော်ရန် တစ်ခုတည်းသာ ကျန်တော့သည်။ OPTIMIZE ... FINAL. နောက်ဆုံး အကောင်အထည်ဖော်မှုတွင် တက်ကြွစွာ မှတ်တမ်းတင်ခြင်းဖြင့် partitions များကို ထိရန်မလိုအပ်ဟူသောအချက်ကိုလည်း ထည့်သွင်းစဉ်းစားပါသည်။

ဒါက ပရောဂျက်လုပ်တာ အတိအကျပဲ။ graphite-ch-optimizer. Yandex.Market မှ လုပ်ဖော်ကိုင်ဖက်ဟောင်းများက ၎င်းကို ထုတ်လုပ်မှုတွင် စမ်းသပ်ခဲ့ပြီး အလုပ်၏ရလဒ်ကို အောက်တွင်ကြည့်ရှုနိုင်ပါသည်။

အကယ်၍ သင်သည် ClickHouse ဖြင့်ဆာဗာတစ်ခုပေါ်တွင်ပရိုဂရမ်ကို run ပါက၊ ၎င်းသည် daemon မုဒ်တွင်ရိုးရှင်းစွာစတင်အလုပ်လုပ်လိမ့်မည်။ တစ်နာရီ တစ်ကြိမ် မေးမြန်းမှုကို လုပ်ဆောင်မည်ဖြစ်ပြီး၊ သုံးရက်ထက် ဟောင်းသော အပိုင်းအသစ်များ ပေါ်ထွက်ခြင်း ရှိ၊ မရှိ စစ်ဆေးခြင်းဖြင့် ပိုမိုကောင်းမွန်အောင် ပြုလုပ်နိုင်သည်။

ကျွန်ုပ်တို့၏ချက်ချင်းအစီအစဥ်များသည် အနည်းဆုံး deb ပက်ကေ့ဂျ်များကို ပေးဆောင်ရန်ဖြစ်ပြီး ဖြစ်နိုင်ပါက rpm လည်းဖြစ်သည်။

အဲဒီအစားတစ်ဦးနိဂုံးပိုင်း၏

လွန်ခဲ့သည့် 9 လကျော်အတွင်း ကျွန်ုပ်သည် ကျွန်ုပ်၏ ကုမ္ပဏီတွင် ရှိနေပါသည်။ innogames ClickHouse နှင့် graphite-web တို့၏ဆုံရာတွင် အချိန်များစွာကုန်ဆုံးခဲ့သည်။ ဒါဟာ မက်ထရစ်သိုလှောင်မှုအဖြစ် တိတ်တိတ်ဆိတ်ဆိတ်ကနေ ClickHouse သို့ အမြန်ကူးပြောင်းမှုဖြစ်စေတဲ့ အတွေ့အကြုံကောင်းတစ်ခုပါ။ ဤဆောင်းပါးသည် ဤအစုအစည်း၏ အစိတ်အပိုင်းအမျိုးမျိုးအတွက် ကျွန်ုပ်တို့လုပ်ဆောင်ခဲ့သော တိုးတက်မှုများနှင့် အနာဂတ်တွင် လုပ်ဆောင်ရမည့်အရာများအကြောင်း စီးရီးတစ်ခု၏အစတစ်ခုဖြစ်သည်ဟု ကျွန်ုပ်မျှော်လင့်ပါသည်။

တောင်းဆိုမှုနှင့်အတူ ဘီယာလီတာများစွာနှင့် စီမံခန့်ခွဲသူနေ့ရက်များစွာကို သုံးစွဲခဲ့သည်။ v0devilသူ့ကို ကျေးဇူးတင်ကြောင်း ဖော်ပြလိုပါသည်။ ဤဆောင်းပါးကို ပြန်လည်သုံးသပ်ရန်အတွက်လည်း ဖြစ်ပါသည်။

github ရှိ ပရောဂျက်စာမျက်နှာ

source: www.habr.com