ClickHouse + Graphite: ڪيئن خاص طور تي ڊسڪ اسپيس واپرائڻ کي گھٽائڻ

سلام ، سلام.

جيڪڏهن ڪو نظام جو استحصال ڪري ٿو graphite-web ۽ هڪ اسٽوريج ڪارڪردگي جو مسئلو آهي ڀڻ ڀڻ ڪرڻ (IO، ڊسڪ اسپيس استعمال ڪيو ويو)، پوء اهو موقعو ته ڪلڪ هاؤس کي متبادل طور اڇلايو ويو هو هڪ ڏانهن وڃڻ گهرجي. هن بيان جو مطلب آهي ته هڪ ٽئين پارٽي عمل درآمد اڳ ۾ ئي استعمال ڪيو ويو آهي ڊيمون وصول ڪندڙ ميٽرڪس، مثال طور ڪاربان يا ڪاربان.

ڪلڪ هائوس بيان ڪيل مسئلن کي چڱي طرح حل ڪري ٿو. مثال طور، ويسپر مان ڊيٽا جي 2TiB منتقل ڪرڻ کان پوء، اهي 300GiB ۾ فٽ ٿين ٿا. مان تفصيل سان مقابلو نه ڪندس؛ هن موضوع تي ڪافي مضمون آهن. ان کان علاوه، تازو تائين، اسان جي ڪلڪ هائوس اسٽوريج سان هر شي مڪمل نه هئي.

استعمال ٿيل جڳهه سان مسئلا

پهرين نظر ۾، هر شيء کي چڱي طرح ڪم ڪرڻ گهرجي. پٺيان دستاويز، ميٽرڪ اسٽوريج اسڪيم لاءِ هڪ ترتيب ٺاهيو (وڌيڪ retention)، پوءِ graphite-web لاءِ منتخب ٿيل پس منظر جي سفارش مطابق ٽيبل ٺاھيو: ڪاربان-ڪلڪ هائوس+graphite-clickhouse يا گراف هائوس، ان تي منحصر آهي ته اسٽيڪ استعمال ڪيو ويندو آهي. ۽ ... ٽائيم بم بند ٿي ويندو آهي.

سمجھڻ لاءِ ته ڪھڙو ھڪڙو، توھان کي ڄاڻڻ جي ضرورت آھي ته ڪيئن داخل ڪرڻ ڪم ڪندو آھي ۽ ڊيٽا جي وڌيڪ زندگي جو رستو * خاندان جي انجڻ جي جدولن ۾مرج ٽري ڪلڪ هائوس (چارٽ تان ورتل презентации Alexey Zatelepin):

• داخل ٿيل блок ڊيٽا. اسان جي صورت ۾، اها ميٽرڪ هئي جيڪا پهچي وئي.
  
• هر اهڙي بلاڪ کي ڊسڪ تي لکڻ کان اڳ ڪيئي مطابق ترتيب ڏنو ويو آهي. ORDER BYٽيبل ٺاهڻ وقت بيان ڪيو ويو آهي.
• ترتيب ڏيڻ کان پوء، кусок (part) ڊيٽا ڊسڪ تي لکيل آهي.
  
• سرور پس منظر ۾ مانيٽر ڪري ٿو ته جيئن اهڙا ڪيترائي ٽڪرا نه هجن، ۽ پس منظر کي لانچ ڪري ٿو слияния (merge، ان کان پوء ضم).
  
  
• جيئن ئي ڊيٽا فعال طور تي ۾ وهڻ بند ٿي وڃي ته سرور پنهنجو پاڻ تي ضم ٿيڻ کي روڪي ٿو партицию (partition)، پر توھان عمل کي دستي طور ڪمانڊ سان شروع ڪري سگھو ٿا OPTIMIZE.
• جيڪڏهن ورهاڱي ۾ صرف هڪ ٽڪرو رهجي ويو آهي، ته پوء توهان عام حڪم استعمال ڪندي ضم کي هلائڻ جي قابل نه هوندا؛ توهان کي استعمال ڪرڻ گهرجي OPTIMIZE ... FINAL

تنهن ڪري، پهريون ميٽرڪس اچي ٿو. ۽ اهي ڪجهه جاء وٺن ٿا. ايندڙ واقعا ڪجھ مختلف ٿي سگھن ٿا ڪيترن ئي عنصر جي بنياد تي:

• ورهاڱي واري ڪيڏي يا ته ٿي سگهي ٿي تمام ننڍو (هڪ ڏينهن) يا تمام وڏو (ڪيترائي مهينا).
• برقرار رکڻ واري ترتيب فعال ورهاڱي جي اندر ڪيترن ئي اهم ڊيٽا گڏ ڪرڻ واري حدن کي پورو ڪري سگھي ٿي (جتي ميٽرڪ رڪارڊ ٿيل آهن)، يا شايد نه.
• جيڪڏهن ڊيٽا جو تمام گهڻو آهي، ته پوءِ سڀ کان اڳ وارا ٽڪرا، جيڪي پس منظر ۾ ضم ٿيڻ جي ڪري اڳ ۾ ئي وڏا هوندا (جيڪڏهن توهان هڪ غير بهتر ورهاڱي واري ڪيئي چونڊيندا آهيو)، پاڻ کي تازو ننڍن حصن سان ضم نه ڪندا.

۽ اهو هميشه ساڳيو ئي ختم ٿئي ٿو. ڪلڪ هاؤس ۾ ميٽرڪس تي قبضو ڪيل خلا صرف وڌي ٿو جيڪڏهن:

• لاڳو نه ڪريو OPTIMIZE ... FINAL دستي طور تي يا
• جاري بنيادن تي سڀني ورهاڱي ۾ ڊيٽا داخل نه ڪريو، تنهنڪري جلدي يا بعد ۾ هڪ پس منظر ضم ٿيڻ شروع ٿي ويندو.

ٻيو طريقو اهو لڳي ٿو ته عمل ڪرڻ لاء تمام آسان آهي ۽ ان ڪري، اهو غلط آهي ۽ پهرين ڪوشش ڪئي وئي.
مون هڪ بلڪل سادو پٿون اسڪرپٽ لکيو آهي جيڪو گذريل 4 سالن کان هر ڏينهن لاءِ ڊمي ميٽرڪ موڪليندو هو ۽ هر ڪلاڪ ۾ ڪرون هلندو هو.
جيئن ته ڪلڪ هائوس ڊي بي ايم ايس جو سڄو آپريشن ان حقيقت تي ٻڌل آهي ته هي سسٽم جلد يا بعد ۾ سڄو پس منظر ڪم ڪندو، پر اهو معلوم ناهي ته ڪڏهن، مان ان لمحي جو انتظار نه ڪري سگهيو آهيان جڏهن پراڻن وڏن ٽڪرن سان ضم ٿيڻ شروع ڪيو ويندو. نوان ننڍا. اهو واضح ٿي ويو ته اسان کي زبردستي اصلاحن کي خودڪار ڪرڻ جو طريقو ڳولڻ جي ضرورت آهي.

ClickHouse سسٽم جدولن ۾ معلومات

اچو ته ٽيبل جي جوڙجڪ تي هڪ نظر رکون سسٽم جا حصا. هي ڪلڪ هاؤس سرور تي سڀني جدولن جي هر ٽڪرا بابت جامع معلومات آهي. تي مشتمل آهي، ٻين شين جي وچ ۾، هيٺيان ڪالمن:

• ڊي بي نالو (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 جي اڳوڻي ساٿين ان جي پيداوار ۾ ڪوشش ڪئي، ڪم جو نتيجو هيٺ ڏسي سگھجي ٿو.

جيڪڏهن توهان پروگرام هلائيندا آهيو سرور تي ClickHouse سان، اهو صرف ڊيمون موڊ ۾ ڪم ڪرڻ شروع ڪندو. هڪ ڪلاڪ ۾ هڪ ڀيرو هڪ درخواست تي عمل ڪيو ويندو، چيڪ ڪيو ته ڇا ٽن ڏينهن کان پراڻن نوان ورهاڱي ظاهر ڪيا ويا آهن جيڪي بهتر ٿي سگهن ٿيون.

اسان جا فوري منصوبا آهن گهٽ ۾ گهٽ ڊيب پيڪيجز مهيا ڪرڻ، ۽ جيڪڏهن ممڪن هجي ته پڻ rpm.

سوچيم ته هڪ ٿڪل جي

گذريل 9+ مهينن دوران آئون پنهنجي ڪمپني جي اندر آهيان انو گيمز ClickHouse ۽ graphite-web جي چونڪ تي گهڻو وقت ٽِنڪر ڪرڻ ۾ گذاريو. اهو هڪ سٺو تجربو هو، جنهن جي نتيجي ۾ ويسپر کان ڪلڪ هاؤس کي ميٽرڪ اسٽوريج جي طور تي جلدي منتقلي. مون کي اميد آهي ته هي آرٽيڪل هڪ سيريز جي شروعات جي باري ۾ آهي ته اسان هن اسٽيڪ جي مختلف حصن ۾ ڪهڙيون بهتريون ڪيون آهن، ۽ مستقبل ۾ ڇا ڪيو ويندو.

بيئر جا ڪيترائي ليٽر ۽ منتظم ڏينهن خرچ ڪيا ويا درخواست کي ترقي ڪرڻ تي، گڏو گڏ v0devilجنهن لاءِ مان سندس شڪرگذاري ڪرڻ چاهيان ٿو. ۽ پڻ هن مضمون جو جائزو وٺڻ لاء.

github تي پروجيڪٽ جو صفحو

جو ذريعو: www.habr.com