کلک ہاؤس + گریفائٹ: ڈسک کی جگہ کی کھپت کو نمایاں طور پر کم کرنے کا طریقہ

سلام، ابر.

اگر کوئی نظام کا استحصال کرتا ہے۔ گریفائٹ ویب اور اسٹوریج کی کارکردگی کے مسئلے کا سامنا کرنا پڑا کسبی (IO، ڈسک کی جگہ استعمال ہوئی)، پھر اس موقع پر کہ ClickHouse کو متبادل کے طور پر کاسٹ کیا گیا تھا۔ اس بیان سے یہ ظاہر ہوتا ہے کہ فریق ثالث کا نفاذ پہلے سے ہی ڈیمون وصول کرنے والے میٹرکس کے طور پر استعمال ہوتا ہے، مثال کے طور پر کاربن رائٹر یا گو کاربن.

کلک ہاؤس بیان کردہ مسائل کو اچھی طرح حل کرتا ہے۔ مثال کے طور پر، وسپر سے 2TiB ڈیٹا منتقل کرنے کے بعد، وہ 300GiB میں فٹ ہو جاتے ہیں۔ میں موازنہ پر تفصیل سے غور نہیں کروں گا؛ اس موضوع پر کافی مضامین موجود ہیں۔ اس کے علاوہ، کچھ عرصہ پہلے تک، ہمارے کلک ہاؤس اسٹوریج کے ساتھ ہر چیز کامل نہیں تھی۔

استعمال شدہ جگہ کے ساتھ مسائل

پہلی نظر میں، سب کچھ اچھی طرح سے کام کرنا چاہئے. درج ذیل دستاویزات، میٹرکس اسٹوریج اسکیم کے لئے ایک تشکیل بنائیں (مزید retention)، پھر گریفائٹ ویب کے لیے منتخب کردہ بیک اینڈ کی سفارش کے مطابق ایک ٹیبل بنائیں: کاربن کلک ہاؤس+گریفائٹ کلک ہاؤس یا graphouseاس پر منحصر ہے کہ کون سا اسٹیک استعمال کیا جاتا ہے۔ اور... ٹائم بم چلا جاتا ہے۔

یہ سمجھنے کے لیے کہ کون سا ہے، آپ کو یہ جاننے کی ضرورت ہے کہ داخلے کیسے کام کرتے ہیں اور *خاندان کے انجنوں کے جدولوں میں ڈیٹا کا مزید لائف پاتھمرج ٹری کلک ہاؤس (چارٹس سے لیا گیا ہے۔ پیشکشیں Alexey Zatelepin):

• داخل کیا گیا۔ блок ڈیٹا ہمارے معاملے میں، یہ میٹرکس تھا جو آیا.
  
• اس طرح کے ہر بلاک کو ڈسک پر لکھے جانے سے پہلے کلید کے مطابق ترتیب دیا جاتا ہے۔ ORDER BYجدول بناتے وقت بیان کیا جاتا ہے۔
• چھانٹنے کے بعد، кусок (part) ڈیٹا ڈسک پر لکھا جاتا ہے۔
  
• سرور پس منظر میں نگرانی کرتا ہے تاکہ اس طرح کے بہت سے ٹکڑے نہ ہوں، اور پس منظر کو لانچ کرتا ہے۔ слияния (merge، اس کے بعد انضمام)۔
  
  
• جیسے ہی ڈیٹا فعال طور پر میں بہنا بند ہو جاتا ہے سرور اپنے طور پر انضمام کو چلانا بند کر دیتا ہے۔ партицию (partition)، لیکن آپ کمانڈ کے ساتھ دستی طور پر عمل شروع کر سکتے ہیں۔ OPTIMIZE.
• اگر پارٹیشن میں صرف ایک ٹکڑا بچا ہے، تو آپ عام کمانڈ کا استعمال کرتے ہوئے انضمام کو چلانے کے قابل نہیں ہوں گے؛ آپ کو استعمال کرنا ضروری ہے OPTIMIZE ... FINAL

تو، پہلے میٹرکس آتے ہیں۔ اور وہ کچھ جگہ لیتے ہیں۔ بعد کے واقعات بہت سے عوامل کی بنیاد پر کچھ مختلف ہو سکتے ہیں:

• تقسیم کرنے والی کلید یا تو بہت چھوٹی (ایک دن) یا بہت بڑی (کئی مہینے) ہوسکتی ہے۔
• برقرار رکھنے کی ترتیب فعال پارٹیشن (جہاں میٹرکس کو ریکارڈ کیا جاتا ہے) کے اندر کئی اہم ڈیٹا جمع کرنے کی حدوں کو فٹ کر سکتا ہے، یا شاید نہیں۔
• اگر بہت زیادہ ڈیٹا ہے، تو ابتدائی حصے، جو کہ پس منظر کے انضمام کی وجہ سے پہلے سے ہی بہت زیادہ ہو سکتے ہیں (اگر آپ غیر بہترین پارٹیشننگ کلید کا انتخاب کرتے ہیں)، خود کو تازہ چھوٹے ٹکڑوں کے ساتھ ضم نہیں کریں گے۔

اور یہ ہمیشہ اسی طرح ختم ہوتا ہے۔ کلک ہاؤس میں میٹرکس کی جگہ صرف اس صورت میں بڑھتی ہے جب:

• لاگو نہ کریں OPTIMIZE ... FINAL دستی طور پر یا
• جاری بنیادوں پر تمام پارٹیشنز میں ڈیٹا داخل نہ کریں، تاکہ جلد یا بدیر بیک گراؤنڈ انضمام شروع ہو جائے

دوسرا طریقہ ایسا لگتا ہے کہ اس پر عمل درآمد کرنا سب سے آسان ہے اور اس لیے یہ غلط ہے اور اسے پہلے آزمایا گیا تھا۔
میں نے کافی آسان ازگر کا اسکرپٹ لکھا جو پچھلے 4 سالوں سے ہر دن کے لیے ڈمی میٹرکس بھیجتا تھا اور ہر گھنٹے میں کرون چلاتا تھا۔
چونکہ کلک ہاؤس ڈی بی ایم ایس کا پورا آپریشن اس حقیقت پر مبنی ہے کہ یہ سسٹم جلد یا بدیر تمام پس منظر کا کام کرے گا، لیکن یہ معلوم نہیں کہ کب، میں اس لمحے کا انتظار کرنے سے قاصر تھا جب پرانے بڑے ٹکڑے ایک دوسرے کے ساتھ ملنا شروع کر دیں گے۔ نئے چھوٹے. یہ واضح ہو گیا کہ ہمیں جبری اصلاح کو خود کار طریقے سے تلاش کرنے کی ضرورت ہے۔

کلک ہاؤس سسٹم ٹیبل میں معلومات

آئیے ٹیبل کی ساخت پر ایک نظر ڈالتے ہیں۔ نظام کے حصے. یہ کلک ہاؤس سرور پر تمام جدولوں کے ہر ٹکڑے کے بارے میں جامع معلومات ہے۔ دیگر چیزوں کے علاوہ درج ذیل کالموں پر مشتمل ہے:

• ڈی بی نام (database);
• میز کا نام (table);
• تقسیم کا نام اور ID (partition & partition_id);
• جب ٹکڑا بنایا گیا تھا (modification_time);
• ایک ٹکڑے میں کم از کم اور زیادہ سے زیادہ تاریخ (تقسیم دن کے حساب سے کی جاتی ہے) (min_date & max_date);

ایک میز بھی ہے۔ system.graphite_retentionsمندرجہ ذیل دلچسپ فیلڈز کے ساتھ:

• ڈی بی نام (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 کے سابق ساتھیوں نے اسے پیداوار میں آزمایا، کام کا نتیجہ ذیل میں دیکھا جا سکتا ہے۔

اگر آپ پروگرام کو کلک ہاؤس والے سرور پر چلاتے ہیں، تو یہ آسانی سے ڈیمون موڈ میں کام کرنا شروع کر دے گا۔ ایک گھنٹے میں ایک بار درخواست پر عمل درآمد کیا جائے گا، یہ جانچنا کہ آیا تین دن سے زیادہ پرانے نئے پارٹیشنز نمودار ہوئے ہیں جنہیں آپٹمائز کیا جا سکتا ہے۔

ہمارے فوری منصوبے کم از کم ڈیب پیکیج فراہم کرنے کے ہیں، اور اگر ممکن ہو تو آر پی ایم بھی۔

اس کے بجائے کسی نتیجے کے

پچھلے 9+ مہینوں میں میں اپنی کمپنی کے اندر رہا ہوں۔ اننو گیمس ClickHouse اور graphite-web کے چوراہے پر ٹنکرنگ میں کافی وقت گزارا۔ یہ ایک اچھا تجربہ تھا، جس کے نتیجے میں میٹرکس اسٹوریج کے طور پر وسوسے سے ClickHouse میں فوری منتقلی ہوئی۔ مجھے امید ہے کہ یہ مضمون اس سلسلے کا آغاز ہے کہ ہم نے اس اسٹیک کے مختلف حصوں میں کیا بہتری کی ہے، اور مستقبل میں کیا کیا جائے گا۔

درخواست تیار کرنے میں کئی لیٹر بیئر اور ایڈمن دن خرچ کیے گئے۔ v0devilجس کے لیے میں ان کا شکریہ ادا کرنا چاہتا ہوں۔ اور اس مضمون کا جائزہ لینے کے لیے بھی۔

گیتھب پر پروجیکٹ کا صفحہ

ماخذ: www.habr.com