கிளிக்ஹவுஸ் + கிராஃபைட்: வட்டு இட நுகர்வு கணிசமாகக் குறைப்பது எப்படி

வாழ்த்துக்கள், ஹாப்ர்.

அமைப்பை யாராவது சுரண்டினால் கிராஃபைட்-வலை மற்றும் சேமிப்பக செயல்திறன் சிக்கலை எதிர்கொண்டது இரகசியம் பேசு (IO, டிஸ்க் ஸ்பேஸ் நுகரப்பட்டது), பின்னர் கிளிக்ஹவுஸ் மாற்றாக அனுப்பப்படும் வாய்ப்பு ஒன்று இருக்க வேண்டும். இந்த அறிக்கையானது மூன்றாம் தரப்பு செயலாக்கம் ஏற்கனவே ஒரு டீமான் பெறும் அளவீடுகளாகப் பயன்படுத்தப்படுகிறது என்பதைக் குறிக்கிறது, உதாரணமாக கார்பன் எழுத்தாளர் அல்லது செல்ல-கார்பன்.

கிளிக்ஹவுஸ் விவரிக்கப்பட்ட சிக்கல்களை நன்கு தீர்க்கிறது. எடுத்துக்காட்டாக, விஸ்பரிலிருந்து 2TiB தரவை மாற்றிய பிறகு, அவை 300GiB க்கு பொருந்துகின்றன. நான் விரிவாக இந்த தலைப்பில் நிறைய கட்டுரைகள் உள்ளன; கூடுதலாக, சமீப காலம் வரை, எங்கள் ClickHouse சேமிப்பகத்தில் எல்லாம் சரியாக இல்லை.

நுகரப்படும் இடத்தில் சிக்கல்கள்

முதல் பார்வையில், எல்லாம் நன்றாக வேலை செய்ய வேண்டும். தொடர்ந்து ஆவணங்கள், அளவீடுகள் சேமிப்பு திட்டத்திற்கான ஒரு கட்டமைப்பை உருவாக்கவும் (மேலும் retention), பின்னர் கிராஃபைட்-வலைக்கு தேர்ந்தெடுக்கப்பட்ட பின்தளத்தின் பரிந்துரையின்படி ஒரு அட்டவணையை உருவாக்கவும்: கார்பன்-கிளிக்ஹவுஸ்+கிராஃபைட்-கிளிக்ஹவுஸ் அல்லது கிராஃபௌஸ், எந்த அடுக்கு பயன்படுத்தப்படுகிறது என்பதைப் பொறுத்து. மேலும்... டைம் பாம் வெடிக்கிறது.

எது என்பதைப் புரிந்து கொள்ள, * குடும்பத்தின் என்ஜின்களின் அட்டவணையில் செருகல்கள் எவ்வாறு செயல்படுகின்றன மற்றும் தரவின் மேலும் வாழ்க்கைப் பாதையை நீங்கள் அறிந்து கொள்ள வேண்டும்.MergeTree கிளிக்ஹவுஸ் (விளக்கப்படங்கள் எடுக்கப்பட்டது விளக்கக்காட்சிகள் அலெக்ஸி ஜாடெலெபின்):

• செருகப்பட்டது блок தகவல்கள். எங்கள் விஷயத்தில், வந்த அளவீடுகள் தான்.
  
• அத்தகைய ஒவ்வொரு தொகுதியும் வட்டில் எழுதப்படுவதற்கு முன் விசையின் படி வரிசைப்படுத்தப்படுகிறது. ORDER BYஅட்டவணையை உருவாக்கும் போது குறிப்பிடப்பட்டது.
• வரிசைப்படுத்திய பின், кусок (part) தரவு வட்டில் எழுதப்பட்டது.
  
• சேவையகம் பின்னணியில் கண்காணிக்கிறது, இதனால் பல துண்டுகள் இல்லை, மேலும் பின்னணியைத் துவக்குகிறது слияния (merge, இனி ஒன்றிணைக்க).
  
  
• தரவு செயலில் செல்வதை நிறுத்தியவுடன், சேவையகம் இயங்குவதை நிறுத்துகிறது партицию (partition), ஆனால் நீங்கள் கட்டளையுடன் செயல்முறையை கைமுறையாக தொடங்கலாம் OPTIMIZE.
• பகிர்வில் ஒரே ஒரு துண்டு இருந்தால், நீங்கள் பயன்படுத்த வேண்டிய வழக்கமான கட்டளையைப் பயன்படுத்தி ஒன்றிணைப்பை இயக்க முடியாது OPTIMIZE ... FINAL

எனவே, முதல் அளவீடுகள் வருகின்றன. மேலும் அவர்கள் சிறிது இடத்தை எடுத்துக்கொள்கிறார்கள். பல காரணிகளைப் பொறுத்து அடுத்தடுத்த நிகழ்வுகள் ஓரளவு மாறுபடலாம்:

• பகிர்வு விசை மிகச் சிறியதாக (ஒரு நாள்) அல்லது மிகப் பெரியதாக (பல மாதங்கள்) இருக்கலாம்.
• தக்கவைப்பு கட்டமைப்பு செயலில் உள்ள பகிர்வுக்குள் (அளவீடுகள் பதிவுசெய்யப்பட்ட இடத்தில்) பல குறிப்பிடத்தக்க தரவு திரட்டல் வரம்புகளுக்கு பொருந்தலாம் அல்லது இல்லை.
• நிறைய தரவு இருந்தால், பின்புல இணைப்பின் காரணமாக ஏற்கனவே பெரியதாக இருக்கும் ஆரம்ப துகள்கள் (உகந்ததாக இல்லாத பகிர்வு விசையைத் தேர்வுசெய்தால்), புதிய சிறிய துண்டுகளுடன் தங்களை ஒன்றிணைக்காது.

மேலும் அது எப்போதும் ஒரே மாதிரியாக முடிவடைகிறது. கிளிக்ஹவுஸில் அளவீடுகளால் ஆக்கிரமிக்கப்பட்ட இடம் பின்வரும் சந்தர்ப்பங்களில் மட்டுமே அதிகரிக்கும்:

• விண்ணப்பிக்க வேண்டாம் OPTIMIZE ... FINAL கைமுறையாக அல்லது
• அனைத்து பகிர்வுகளிலும் தரவைச் செருக வேண்டாம், இதனால் விரைவில் அல்லது பின்னர் பின்னணி இணைப்பு தொடங்கும்

இரண்டாவது முறை செயல்படுத்த எளிதானது, எனவே இது தவறானது மற்றும் முதலில் முயற்சி செய்யப்பட்டது.
நான் மிகவும் எளிமையான பைதான் ஸ்கிரிப்டை எழுதினேன், அது கடந்த 4 ஆண்டுகளாக ஒவ்வொரு நாளும் போலி அளவீடுகளை அனுப்பியது மற்றும் ஒவ்வொரு மணி நேரமும் கிரான் ஓடியது.
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. செயலில் உள்ள பதிவுகளுடன் பகிர்வுகளைத் தொட வேண்டிய அவசியமில்லை என்ற உண்மையையும் இறுதி செயலாக்கம் கணக்கில் எடுத்துக்கொள்கிறது.

இந்த திட்டம் சரியாக என்ன செய்கிறது கிராஃபைட்-சிஎச்-உகப்பாக்கி. Yandex.Market இன் முன்னாள் சகாக்கள் அதை உற்பத்தியில் முயற்சித்தனர், வேலையின் முடிவை கீழே காணலாம்.

நீங்கள் கிளிக்ஹவுஸ் மூலம் ஒரு சர்வரில் நிரலை இயக்கினால், அது டீமான் பயன்முறையில் செயல்படத் தொடங்கும். ஒரு மணி நேரத்திற்கு ஒருமுறை கோரிக்கை செயல்படுத்தப்படும், மூன்று நாட்களுக்கு மேல் பழைய புதிய பகிர்வுகள் தோன்றியுள்ளனவா என்பதைச் சரிபார்த்து, அதை மேம்படுத்தலாம்.

எங்கள் உடனடித் திட்டங்கள் குறைந்தபட்சம் டெப் பேக்கேஜ்களை வழங்குவது, முடிந்தால் ஆர்பிஎம்.

அதற்கு பதிலாக, ஒரு முடிவுக்கும்

கடந்த 9+ மாதங்களில் நான் எனது நிறுவனத்தில் இருந்தேன் InnoGames கிளிக்ஹவுஸ் மற்றும் கிராஃபைட்-வலை சந்திப்பில் நிறைய நேரம் டிங்கரிங் செய்தார். இது ஒரு நல்ல அனுபவமாக இருந்தது, இதன் விளைவாக விஸ்பரிலிருந்து கிளிக்ஹவுஸுக்கு மெட்ரிக்ஸ் சேமிப்பகமாக விரைவாக மாறியது. இந்தக் கட்டுரை இந்த அடுக்கின் பல்வேறு பகுதிகளில் என்னென்ன மேம்பாடுகளைச் செய்துள்ளோம், எதிர்காலத்தில் என்ன செய்யப் போகிறோம் என்பதைப் பற்றிய ஒரு தொடரின் ஆரம்பம் என்று நம்புகிறேன்.

கோரிக்கையை உருவாக்க பல லிட்டர் பீர் மற்றும் நிர்வாக நாட்கள் செலவிடப்பட்டன v0டெவில், அதற்காக அவருக்கு எனது நன்றியைத் தெரிவித்துக் கொள்கிறேன். மேலும் இந்த கட்டுரையை மதிப்பாய்வு செய்வதற்கும்.

கிதுப்பில் திட்டப் பக்கம்

ஆதாரம்: www.habr.com