ક્લિકહાઉસ + ગ્રેફાઇટ: ડિસ્ક સ્પેસ વપરાશને નોંધપાત્ર રીતે કેવી રીતે ઘટાડવો

શુભેચ્છાઓ.

જો કોઈ સિસ્ટમનું શોષણ કરે છે ગ્રેફાઇટ-વેબ અને સંગ્રહ પ્રદર્શન સમસ્યાનો સામનો કરવો પડ્યો બબડાટ (IO, ડિસ્ક સ્પેસનો વપરાશ), તો પછી ClickHouse ને રિપ્લેસમેન્ટ તરીકે કાસ્ટ કરવાની તક એક તરફ જતી હોવી જોઈએ. આ નિવેદન સૂચવે છે કે તૃતીય-પક્ષ અમલીકરણ પહેલાથી જ ડિમન મેળવતા મેટ્રિક્સ તરીકે ઉપયોગમાં લેવાય છે, ઉદાહરણ તરીકે કાર્બન લેખક અથવા ગો-કાર્બન.

ક્લિકહાઉસ વર્ણવેલ સમસ્યાઓને સારી રીતે હલ કરે છે. ઉદાહરણ તરીકે, વ્હીસ્પરમાંથી 2TiB ડેટા ટ્રાન્સફર કર્યા પછી, તેઓ 300GiB માં ફિટ થઈ જાય છે. હું વિગતવાર સરખામણી પર ધ્યાન આપીશ નહીં; આ વિષય પર પુષ્કળ લેખો છે. વધુમાં, તાજેતરમાં સુધી, અમારા ક્લિકહાઉસ સ્ટોરેજ સાથે બધું જ યોગ્ય ન હતું.

વપરાશની જગ્યા સાથે સમસ્યાઓ

પ્રથમ નજરમાં, બધું સારી રીતે કામ કરવું જોઈએ. અનુસરે છે દસ્તાવેજીકરણ, મેટ્રિક્સ સ્ટોરેજ સ્કીમ માટે રૂપરેખા બનાવો (આગળ retention), પછી ગ્રેફાઇટ-વેબ માટે પસંદ કરેલ બેકએન્ડની ભલામણ અનુસાર કોષ્ટક બનાવો: કાર્બન-ક્લિકહાઉસ+ગ્રેફાઇટ-ક્લિકહાઉસ અથવા ગ્રેપહાઉસ, કયા સ્ટેકનો ઉપયોગ થાય છે તેના આધારે. અને... ટાઈમ બોમ્બ ફાટી જાય છે.

કયું તે સમજવા માટે, તમારે જાણવાની જરૂર છે કે દાખલ કેવી રીતે કાર્ય કરે છે અને * કુટુંબના એન્જિનના કોષ્ટકોમાં ડેટાનો આગળનો જીવન માર્ગમર્જટ્રી ક્લિકહાઉસ (ચાર્ટમાંથી લેવામાં આવ્યા છે પ્રસ્તુતિઓ એલેક્સી ઝટેલેપિન):

• દાખલ કરેલ блок ડેટા અમારા કિસ્સામાં, તે મેટ્રિક્સ આવ્યા હતા.
  
• આવા દરેક બ્લોકને ડિસ્ક પર લખતા પહેલા કી અનુસાર સોર્ટ કરવામાં આવે છે. 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. અંતિમ અમલીકરણ એ હકીકતને પણ ધ્યાનમાં લે છે કે સક્રિય રેકોર્ડિંગ સાથે પાર્ટીશનોને સ્પર્શ કરવાની જરૂર નથી.

આ પ્રોજેક્ટ બરાબર શું કરે છે ગ્રેફાઇટ-સીએચ-ઓપ્ટિમાઇઝર. Yandex.Market ના ભૂતપૂર્વ સાથીદારોએ ઉત્પાદનમાં તેનો પ્રયાસ કર્યો, કાર્યનું પરિણામ નીચે જોઈ શકાય છે.

જો તમે ક્લિકહાઉસ સાથે સર્વર પર પ્રોગ્રામ ચલાવો છો, તો તે ફક્ત ડિમન મોડમાં કામ કરવાનું શરૂ કરશે. એક કલાકમાં એકવાર વિનંતિ ચલાવવામાં આવશે, તપાસ કરી રહ્યા છીએ કે શું ત્રણ દિવસ કરતાં જૂના નવા પાર્ટીશનો દેખાયા છે જે ઑપ્ટિમાઇઝ કરી શકાય છે.

અમારી તાત્કાલિક યોજનાઓ ઓછામાં ઓછા ડેબ પેકેજો પ્રદાન કરવાની છે, અને જો શક્ય હોય તો આરપીએમ પણ.

તેના બદલે એક નિષ્કર્ષ

છેલ્લા 9+ મહિનામાં હું મારી કંપનીમાં છું ઈનોગેમ્સ ક્લિકહાઉસ અને ગ્રેફાઇટ-વેબના આંતરછેદ પર ટિંકરિંગ કરવામાં ઘણો સમય પસાર કર્યો. તે એક સારો અનુભવ હતો, જેના પરિણામે મેટ્રિક્સ સ્ટોરેજ તરીકે વ્હીસ્પરથી ક્લિકહાઉસમાં ઝડપી સંક્રમણ થયું. હું આશા રાખું છું કે આ લેખ એ શ્રેણીની શરૂઆત છે કે અમે આ સ્ટેકના વિવિધ ભાગોમાં કયા સુધારા કર્યા છે અને ભવિષ્યમાં શું કરવામાં આવશે.

વિનંતિ વિકસાવવા માટે કેટલાક લિટર બીયર અને એડમિન દિવસો ખર્ચવામાં આવ્યા હતા v0devil, જેના માટે હું તેમનો આભાર વ્યક્ત કરવા માંગુ છું. અને આ લેખની સમીક્ષા માટે પણ.

ગીથબ પર પ્રોજેક્ટ પૃષ્ઠ

સોર્સ: www.habr.com