ClickHouse + Graphite៖ របៀបកាត់បន្ថយការប្រើប្រាស់ទំហំថាសយ៉ាងសំខាន់

ជំរាបសួរ, habr ។

ប្រសិនបើនរណាម្នាក់កេងប្រវ័ញ្ចប្រព័ន្ធ graphite-web និងជួបប្រទះបញ្ហាដំណើរការផ្ទុក ខ្សឹប (IO, ទំហំថាសប្រើប្រាស់) បន្ទាប់មកឱកាសដែល ClickHouse ត្រូវបានបោះជាការជំនួសគួរតែមានទំនោរទៅមួយ។ សេចក្តីថ្លែងការណ៍នេះបង្កប់ន័យថាការអនុវត្តភាគីទីបីត្រូវបានប្រើប្រាស់រួចជាស្រេចជាម៉ែត្រការទទួលដេមិន អ្នកនិពន្ធកាបូន ឬ កាបូនិក.

ClickHouse ដោះស្រាយបញ្ហាដែលបានពិពណ៌នាបានយ៉ាងល្អ។ ឧទាហរណ៍ បន្ទាប់ពីផ្ទេរទិន្នន័យ 2TiB ពីខ្សឹប ពួកវាសមនឹង 300GiB។ ខ្ញុំនឹងមិនរស់នៅលើការប្រៀបធៀបលម្អិតទេ មានអត្ថបទជាច្រើនលើប្រធានបទនេះ។ លើសពីនេះទៀត រហូតមកដល់ពេលថ្មីៗនេះ មិនមែនអ្វីៗទាំងអស់សុទ្ធតែល្អឥតខ្ចោះជាមួយនឹងកន្លែងផ្ទុក ClickHouse របស់យើងនោះទេ។

បញ្ហាជាមួយកន្លែងប្រើប្រាស់

នៅ glance ដំបូងអ្វីគ្រប់យ៉ាងគួរតែដំណើរការល្អ។ កំពុងតាម ឯកសារបង្កើត​ការ​កំណត់​សម្រាប់​គម្រោង​ការ​ផ្ទុក​ម៉ែត្រ (បន្ថែម​ទៀត។ retention) បន្ទាប់មកបង្កើតតារាងមួយតាមការណែនាំរបស់ backend ដែលបានជ្រើសរើសសម្រាប់ graphite-web៖ carbon-clickhouse+graphite-clickhouse ឬ ក្រាហ្វិចអាស្រ័យលើជង់មួយណាដែលត្រូវប្រើ។ ហើយ ... គ្រាប់បែកពេលវេលាបានរលត់។

ដើម្បីយល់ពីមួយណា អ្នកត្រូវដឹងពីរបៀបដែលការបញ្ចូលដំណើរការ និងផ្លូវជីវិតបន្ថែមទៀតនៃទិន្នន័យនៅក្នុងតារាងម៉ាស៊ីននៃគ្រួសារ *មែកធាង ClickHouse (តារាងយកពី បទបង្ហាញ Alexey Zatelpin)៖

• បញ្ចូល блок ទិន្នន័យ។ ក្នុងករណីរបស់យើងវាគឺជារង្វាស់ដែលបានមកដល់។
  
• ប្លុកបែបនេះនីមួយៗត្រូវបានតម្រៀបតាមគន្លឹះមុនពេលត្រូវបានសរសេរទៅថាស។ ORDER BYបញ្ជាក់នៅពេលបង្កើតតារាង។
• បន្ទាប់ពីការតម្រៀប, кусок (part) ទិន្នន័យត្រូវបានសរសេរទៅឌីស។
  
• ម៉ាស៊ីនមេត្រួតពិនិត្យក្នុងផ្ទៃខាងក្រោយ ដូច្នេះមិនមានបំណែកបែបនេះច្រើនទេ ហើយបើកដំណើរការផ្ទៃខាងក្រោយ слияния (mergeបន្តបន្ទាប់បញ្ចូលគ្នា)។
  
  
• ម៉ាស៊ីនមេឈប់ដំណើរការ បញ្ចូលចូលគ្នាដោយខ្លួនឯង ដរាបណាទិន្នន័យឈប់ហូរចូលយ៉ាងសកម្ម партицию (partition) ប៉ុន្តែអ្នកអាចចាប់ផ្តើមដំណើរការដោយដៃដោយប្រើពាក្យបញ្ជា OPTIMIZE.
• ប្រសិន​បើ​នៅ​សល់​តែ​មួយ​ដុំ​នៅ​ក្នុង​ភាគថាស​នោះ អ្នក​នឹង​មិន​អាច​ដំណើរការ​ការ​បញ្ចូល​គ្នា​ដោយ​ប្រើ​ពាក្យ​បញ្ជា​ធម្មតា​ទេ​ OPTIMIZE ... FINAL

ដូច្នេះម៉ែត្រទីមួយមកដល់។ ហើយពួកគេយកកន្លែងខ្លះ។ ព្រឹត្តិការណ៍បន្ទាប់អាចប្រែប្រួលខ្លះអាស្រ័យលើកត្តាជាច្រើន៖

• គ្រាប់ចុចបែងចែកអាចតូចណាស់ (មួយថ្ងៃ) ឬធំណាស់ (ច្រើនខែ)។
• ការកំណត់រចនាសម្ព័ន្ធការរក្សាទុកអាចសមនឹងកម្រិតនៃការប្រមូលផ្តុំទិន្នន័យសំខាន់ៗមួយចំនួននៅក្នុងភាគថាសសកម្ម (ដែលម៉ែត្រត្រូវបានកត់ត្រា) ឬប្រហែលជាមិនមែនទេ។
• ប្រសិនបើមានទិន្នន័យច្រើន នោះកំណាត់ដំបូងបំផុតដែលដោយសារតែការបញ្ចូលគ្នានៃផ្ទៃខាងក្រោយអាចមានទំហំធំរួចទៅហើយ (ប្រសិនបើអ្នកជ្រើសរើសសោការបែងចែកដែលមិនសមស្របបំផុត) នឹងមិនបញ្ចូលគ្នាជាមួយកំណាត់តូចៗថ្មីៗនោះទេ។

ហើយវាតែងតែបញ្ចប់ដូចគ្នា។ ចន្លោះដែលកាន់កាប់ដោយម៉ែត្រនៅក្នុង ClickHouse កើនឡើងតែប្រសិនបើ៖

• កុំអនុវត្ត OPTIMIZE ... FINAL ដោយដៃឬ
• កុំបញ្ចូលទិន្នន័យទៅក្នុងភាគថាសទាំងអស់នៅលើមូលដ្ឋានដែលកំពុងដំណើរការ ដូច្នេះមិនយូរមិនឆាប់ ការបញ្ចូលផ្ទៃខាងក្រោយនឹងចាប់ផ្តើម

វិធីសាស្រ្តទីពីរហាក់ដូចជាងាយស្រួលបំផុតក្នុងការអនុវត្ត ហើយដូច្នេះវាមិនត្រឹមត្រូវទេ ហើយត្រូវបានសាកល្បងមុន។
ខ្ញុំបានសរសេរស្គ្រីប python ដ៏សាមញ្ញមួយ ដែលផ្ញើរង្វាស់អត់ចេះសោះសម្រាប់រាល់ថ្ងៃក្នុងរយៈពេល 4 ឆ្នាំកន្លងមក ហើយបានរត់ cron រៀងរាល់ម៉ោង។
ដោយសារប្រតិបត្តិការទាំងមូលរបស់ ClickHouse DBMS គឺផ្អែកលើការពិតដែលថាប្រព័ន្ធនេះនឹងឆាប់ឬក្រោយមកធ្វើការងារផ្ទៃខាងក្រោយទាំងអស់ ប៉ុន្តែវាមិនដឹងថានៅពេលណានោះទេ ខ្ញុំមិនអាចរង់ចាំដល់ពេលដែលបំណែកដ៏ធំចាស់ចាប់ផ្តើមបញ្ចូលគ្នាជាមួយ តូចៗថ្មី។ វាច្បាស់ណាស់ថាយើងត្រូវស្វែងរកវិធីដើម្បីធ្វើឱ្យការបង្កើនប្រសិទ្ធភាពដោយបង្ខំដោយស្វ័យប្រវត្តិ។

ព័ត៌មាននៅក្នុងតារាងប្រព័ន្ធ ClickHouse

តោះមើលរចនាសម្ព័ន្ធតារាង system.parts. នេះគឺជាព័ត៌មានដ៏ទូលំទូលាយអំពីបំណែកនីមួយៗនៃតារាងទាំងអស់នៅលើម៉ាស៊ីនមេ 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 បានសាកល្បងវានៅក្នុងផលិតកម្មលទ្ធផលនៃការងារអាចមើលឃើញខាងក្រោម។

ប្រសិនបើអ្នកដំណើរការកម្មវិធីនៅលើម៉ាស៊ីនមេជាមួយ ClickHouse វានឹងចាប់ផ្តើមដំណើរការជាធម្មតានៅក្នុងរបៀបដេមិន។ ពេលមួយម៉ោងសំណើនឹងត្រូវបានប្រតិបត្តិ ដោយពិនិត្យមើលថាតើភាគថាសថ្មីដែលចាស់ជាងបីថ្ងៃបានបង្ហាញខ្លួនដែលអាចត្រូវបានធ្វើឱ្យប្រសើរ។

ផែនការភ្លាមៗរបស់យើងគឺផ្តល់កញ្ចប់ deb យ៉ាងហោចណាស់ ហើយប្រសិនបើអាចធ្វើទៅបានផងដែរ rpm ។

ជំនួសឱ្យការសន្និដ្ឋានមួយ

ក្នុងរយៈពេល 9+ ខែកន្លងមកនេះ ខ្ញុំបាននៅក្នុងក្រុមហ៊ុនរបស់ខ្ញុំ innogames បានចំណាយពេលវេលាជាច្រើនដើម្បីបន្តនៅចំនុចប្រសព្វនៃ ClickHouse និងក្រាហ្វិចគេហទំព័រ។ វាជាបទពិសោធន៍ដ៏ល្អ ដែលនាំឱ្យមានការផ្លាស់ប្ដូរយ៉ាងរហ័សពីការខ្សឹបប្រាប់ ClickHouse ជាកន្លែងផ្ទុកម៉ែត្រ។ ខ្ញុំសង្ឃឹមថាអត្ថបទនេះគឺជាផ្នែកមួយនៃការចាប់ផ្តើមនៃស៊េរីមួយអំពីអ្វីដែលការកែលម្អដែលយើងបានធ្វើចំពោះផ្នែកផ្សេងៗនៃជង់នេះ និងអ្វីដែលនឹងត្រូវធ្វើនៅពេលអនាគត។

ស្រាបៀរជាច្រើនលីត្រ និងថ្ងៃគ្រប់គ្រងត្រូវបានចំណាយលើការបង្កើតសំណើ រួមជាមួយនឹង v0 អារក្សដែលខ្ញុំចង់បង្ហាញពីការដឹងគុណរបស់ខ្ញុំចំពោះគាត់។ ហើយក៏សម្រាប់ការពិនិត្យមើលអត្ថបទនេះ។

ទំព័រគម្រោងនៅលើ github

ប្រភព: www.habr.com