ClickHouse + Graphite: තැටි ඉඩ පරිභෝජනය සැලකිය යුතු ලෙස අඩු කරන්නේ කෙසේද

සුභ පැතුම්, හබ්ර්.

කවුරුහරි පද්ධතිය සූරාකෑවොත් ග්රැෆයිට්-වෙබ් සහ ගබඩා කාර්ය සාධන ගැටලුවකට මුහුණ පෑමට සිදු විය විහඟි (IO, තැටි ඉඩ පරිභෝජනය), එවිට ClickHouse ආදේශකයක් ලෙස විකාශනය වීමේ අවස්ථාව එකකට නැඹුරු විය යුතුය. මෙම ප්‍රකාශය මගින් ගම්‍ය වන්නේ තුන්වන පාර්ශ්ව ක්‍රියාත්මක කිරීමක් දැනටමත් ඩීමන් ලැබෙන ප්‍රමිතික ලෙස භාවිතා කර ඇති බවයි, උදාහරණයක් ලෙස කාබන් ලේඛකයා හෝ go-carbon.

ClickHouse විස්තර කර ඇති ගැටළු හොඳින් විසඳයි. උදාහරණයක් ලෙස, විස්පර් වෙතින් 2TiB දත්ත මාරු කිරීමෙන් පසුව, ඒවා 300GiB වලට ගැලපේ. මම සංසන්දනය ගැන විස්තරාත්මකව වාසය නොකරමි; මෙම මාතෘකාව පිළිබඳ ලිපි ඕනෑ තරම් තිබේ. මීට අමතරව, මෑතක් වන තුරුම, අපගේ ClickHouse ගබඩාව සමඟ සෑම දෙයක්ම පරිපූර්ණ නොවීය.

පරිභෝජනය කරන අවකාශය සමඟ ගැටළු

මුලින්ම බැලූ බැල්මට සෑම දෙයක්ම හොඳින් ක්රියා කළ යුතුය. අනුගමනය ලියකියවිලි, ප්‍රමිතික ගබඩා යෝජනා ක්‍රමය සඳහා වින්‍යාසයක් සාදන්න (තවත් retention), ඉන්පසු ග්‍රැෆයිට්-වෙබ් සඳහා තෝරාගත් පසුතලයේ නිර්දේශය අනුව වගුවක් සාදන්න: කාබන්-ක්ලික්හවුස්+ග්රැෆයිට්-ක්ලික්හවුස් හෝ ග්රැෆවුස්, කුමන තොගය භාවිතා කරන්නේද යන්න මත පදනම්ව. හා... කාල බෝම්බය පත්තු වෙනවා.

කුමන එකක්ද යන්න තේරුම් ගැනීම සඳහා, * පවුලේ එන්ජින් වගු වල ඇතුළු කිරීම් ක්‍රියා කරන ආකාරය සහ දත්තවල වැඩිදුර ජීවන මාර්ගය ඔබ දැනගත යුතුය.MergeTree ClickHouse (ප්‍රස්ථාර උපුටා ගන්නා ලදී презентации ඇලෙක්සි සැටලෙපින්):

• ඇතුල් කළා блок දත්ත. අපගේ නඩුවේදී, එය පැමිණියේ මෙට්රික්ස් ය.
  
• එවැනි සෑම බ්ලොක් එකක්ම තැටියට ලිවීමට පෙර යතුර අනුව වර්ග කර ඇත. ORDER BYවගුව නිර්මාණය කිරීමේදී නිශ්චිතව දක්වා ඇත.
• වර්ග කිරීමෙන් පසු, кусок (part) දත්ත තැටියට ලියා ඇත.
  
• සේවාදායකයා එවැනි කෑලි බොහොමයක් නොමැති වන පරිදි පසුබිමේ නිරීක්ෂණය කරයි, සහ පසුබිම දියත් කරයි слияния (merge, මින් ඉදිරියට ඒකාබද්ධ කරන්න).
  
  
• දත්ත සක්‍රියව ගලා ඒම නැවැත්වූ විගස සේවාදායකය ස්වයංක්‍රීයව ඒකාබද්ධ වීම ක්‍රියාත්මක වීම නවත්වයි партицию (partition), නමුත් ඔබට විධානය සමඟ ක්‍රියාවලිය අතින් ආරම්භ කළ හැක OPTIMIZE.
• කොටසේ ඉතිරිව ඇත්තේ එක් කැබැල්ලක් පමණක් නම්, ඔබට සුපුරුදු විධානය භාවිතයෙන් ඒකාබද්ධ කිරීම ක්‍රියාත්මක කිරීමට නොහැකි වනු ඇත; ඔබ භාවිතා කළ යුතුය OPTIMIZE ... FINAL

ඉතින්, පළමු දර්ශක පැමිණේ. තවද ඔවුන් යම් ඉඩක් ලබා ගනී. පසුකාලීන සිදුවීම් බොහෝ සාධක මත පදනම්ව තරමක් වෙනස් විය හැක:

• කොටස් කිරීමේ යතුර ඉතා කුඩා (දිනකට) හෝ ඉතා විශාල (මාස කිහිපයක්) විය හැකිය.
• රඳවා ගැනීමේ වින්‍යාසය සක්‍රිය කොටස තුළ (මිතික සටහන් කර ඇති) සැලකිය යුතු දත්ත එකතු කිරීමේ සීමාවන් කිහිපයකට ගැලපේ.
• දත්ත විශාල ප්‍රමාණයක් තිබේ නම්, පසුබිම් ඒකාබද්ධ කිරීම හේතුවෙන් දැනටමත් විශාල විය හැකි (ඔබ ප්‍රශස්ත නොවන කොටස් කිරීමේ යතුරක් තෝරා ගන්නේ නම්) මුල්ම කොටස් නැවුම් කුඩා කැබලි සමඟ ඒකාබද්ධ නොවේ.

තවද එය සෑම විටම එකම ලෙස අවසන් වේ. ClickHouse හි මෙට්‍රික්ස් විසින් අල්ලාගෙන සිටින ඉඩ වැඩි වන්නේ නම්:

• අයදුම් නොකරන්න OPTIMIZE ... FINAL අතින් හෝ
• සියලුම කොටස් වලට අඛණ්ඩ පදනමක් මත දත්ත ඇතුල් නොකරන්න, එවිට ඉක්මනින් හෝ පසුව පසුබිම් ඒකාබද්ධ කිරීමක් ආරම්භ වනු ඇත

දෙවන ක්‍රමය ක්‍රියාත්මක කිරීමට පහසුම ක්‍රමය බව පෙනේ, එබැවින් එය වැරදියි සහ පළමුව උත්සාහ කරන ලදී.
මම පසුගිය වසර 4 තුළ සෑම දිනකම ව්‍යාජ ප්‍රමිතික යවන සහ සෑම පැයකටම ක්‍රෝන් ධාවනය කරන තරමක් සරල python පිටපතක් ලිව්වෙමි.
ClickHouse DBMS හි සම්පූර්ණ කාර්යය පදනම් වී ඇත්තේ මෙම පද්ධතිය ඉක්මනින් හෝ පසුව සියලු පසුබිම් වැඩ කරනු ඇති බව මත වන නමුත්, එය කවදාදැයි නොදනී, පැරණි දැවැන්ත කෑලි නව කුඩා ඒවා සමඟ ඒකාබද්ධ වීමට පටන් ගන්නා තෙක් බලා සිටීමට මට නොහැකි විය. . බලහත්කාර ප්‍රශස්තිකරණය ස්වයංක්‍රීය කිරීමට ක්‍රමයක් සෙවීමට අපට අවශ්‍ය බව පැහැදිලි විය.

ClickHouse පද්ධති වගු වල තොරතුරු

අපි මේසයේ ව්යුහය දෙස බලමු පද්ධතිය.කොටස්. මෙය ClickHouse සේවාදායකයේ ඇති සියලුම වගු වල එක් එක් කොටස පිළිබඳ සවිස්තරාත්මක තොරතුරු වේ. වෙනත් දේ අතර, පහත තීරු අඩංගු වේ:

• db නම (database);
• වගු නම (table);
• නම සහ කොටස් හැඳුනුම්පත (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 වගු කොටස් එක් එක් ආපසු ලබා දෙයි. කළ යුතු එකම දෙය ඉල්ලීමක් සමඟ ඒවා සියල්ලම හරහා යාමයි OPTIMIZE ... FINAL. අවසාන ක්රියාත්මක කිරීම ක්රියාකාරී පටිගත කිරීම සමඟ කොටස් ස්පර්ශ කිරීමට අවශ්ය නොවන බව ද සැලකිල්ලට ගනී.

මෙම ව්යාපෘතිය හරියටම කරන්නේ මෙයයි graphite-ch-optimizer. Yandex.Market හි හිටපු සගයන් එය නිෂ්පාදනයේදී උත්සාහ කළ අතර, කාර්යයේ ප්රතිඵලය පහතින් දැක ගත හැකිය.

ඔබ ක්ලික්හවුස් සමඟ සේවාදායකයක් මත වැඩසටහන ක්‍රියාත්මක කරන්නේ නම්, එය හුදෙක් ඩීමන් ප්‍රකාරයේදී ක්‍රියා කිරීමට පටන් ගනී. පැයකට වරක් විමසුමක් ක්‍රියාත්මක කරනු ලැබේ, ප්‍රශස්ත කළ හැකි දින තුනකට වඩා පැරණි නව කොටස් දර්ශණය වී ඇත්දැයි පරීක්ෂා කරයි.

අපගේ ක්ෂණික සැලසුම් වන්නේ අවම වශයෙන් deb පැකේජ සැපයීම සහ හැකි නම් rpm ය.

ඒ වෙනුවට අවසාන කාල පරිච්ඡේදය

පසුගිය මාස 9+ තුළ මම මගේ සමාගම තුළ සිටිමි ඉනෝගේම්ස් ClickHouse සහ graphite-web යන මංසන්ධියේ ටින්කර් කරමින් බොහෝ කාලයක් ගත කළේය. එය හොඳ අත්දැකීමක් වූ අතර, ප්‍රමිතික ගබඩාවක් ලෙස විස්පර් සිට ClickHouse වෙත ඉක්මන් සංක්‍රමණයක් ඇති විය. මෙම ලිපි මාලාවේ විවිධ කොටස් සඳහා අප විසින් සිදු කර ඇති වැඩිදියුණු කිරීම් සහ අනාගතයේදී කුමක් සිදු කරනු ඇත්ද යන්න පිළිබඳ ලිපි මාලාවක ආරම්භයේ යමක් මෙම ලිපිය වනු ඇතැයි මම බලාපොරොත්තු වෙමි.

බියර් ලීටර් කිහිපයක් සහ පරිපාලක දින ඉල්ලීම සංවර්ධනය කිරීම සඳහා වැය කරන ලදී v0devil, ඒ සඳහා මම ඔහුට මගේ කෘතඥතාව පළ කිරීමට කැමැත්තෙමි. තවද මෙම ලිපිය සමාලෝචනය කිරීම සඳහා.

github හි ව්‍යාපෘති පිටුව

මූලාශ්රය: www.habr.com