VictoriaMetrics හි ප්‍රශස්තකරණයට යන්න. ඇලෙක්සැන්ඩර් වල්යාල්කින්

Alexander Valyalkin විසින් "VictoriaMetrics හි ප්‍රශස්තකරණයන්" විසින් 2019 අග භාගයේ වාර්තාවේ පිටපත කියවීමට මම ඔබට යෝජනා කරමි.

වික්ටෝරියා මෙට්රික්ස් - කාල ශ්‍රේණියක ස්වරූපයෙන් දත්ත ගබඩා කිරීම සහ සැකසීම සඳහා වේගවත් හා පරිමාණය කළ හැකි DBMS (වාර්තා මඟින් මෙම කාලයට අනුරූප වන කාලය සහ අගයන් සමූහයක් සාදයි, උදාහරණයක් ලෙස, සංවේදකවල තත්ත්වය පිළිබඳ වරින් වර ඡන්ද විමසීමෙන් හෝ එකතු කිරීමෙන් ලබා ගනී. ප්රමිතික).

මෙම වාර්තාවේ වීඩියෝවට සබැඳියක් මෙන්න - https://youtu.be/MZ5P21j_HLE

විනිවිදක

ඔබ ගැන අපට කියන්න. මම ඇලෙක්සැන්ඩර් වල්යාල්කින්. මෙතන මගේ GitHub ගිණුම. මම Go සහ කාර්ය සාධන ප්‍රශස්තකරණය ගැන දැඩි උනන්දුවක් දක්වමි. මම ප්‍රයෝජනවත් සහ එතරම් ප්‍රයෝජනවත් නොවන පුස්තකාල රාශියක් ලිව්වෙමි. ඔවුන් එක්කෝ පටන් ගනී fast, හෝ සමඟ quick උපසර්ගය.

මම දැනට VictoriaMetrics එකේ වැඩ කරනවා. එය කුමක්ද සහ මම එහි කරන්නේ කුමක්ද? මම මේ ඉදිරිපත් කිරීමේදී මේ ගැන කතා කරන්නම්.

වාර්තාවේ දළ සටහන මෙසේය.

• මුලින්ම මම කියන්නම් VictoriaMetrics කියන්නේ මොකක්ද කියලා.
• ඊට පස්සේ මම කියන්නම් කාල මාලාව මොකක්ද කියලා.
• ඊට පස්සේ මම කියන්නම් කොහොමද කාල ශ්‍රේණියේ දත්ත සමුදායක් ක්‍රියා කරන්නේ කියලා.
• ඊළඟට, මම ඔබට දත්ත සමුදා ගෘහ නිර්මාණ ශිල්පය ගැන කියන්නම්: එය සමන්විත වන්නේ කුමක්ද?
• ඉන්පසු අපි VictoriaMetrics සතුව ඇති ප්‍රශස්තකරණයන් වෙත යමු. මෙය ප්‍රතිලෝම දර්ශකය සඳහා ප්‍රශස්තකරණයක් වන අතර Go හි bitset ක්‍රියාත්මක කිරීම සඳහා ප්‍රශස්තකරණයකි.

වික්ටෝරියා මෙට්‍රික්ස් යනු කුමක්දැයි ප්‍රේක්ෂකයින් කවුරුන් හෝ දන්නවාද? අපොයි, ගොඩක් අය දැනටමත් දන්නවා. ඒක හොඳ ආරංචියක්. නොදන්න අයට මේක time series database එකක්. එය ClickHouse ක්‍රියාත්මක කිරීමේ සමහර විස්තර මත ClickHouse ගෘහ නිර්මාණ ශිල්පය මත පදනම් වේ. උදාහරණයක් ලෙස, MergeTree, පවතින සියලුම ප්‍රොසෙසර් කෝර් මත සමාන්තර ගණනය කිරීම සහ ප්‍රොසෙසර හැඹිලියේ තබා ඇති දත්ත කොටස් මත ක්‍රියා කිරීමෙන් කාර්ය සාධන ප්‍රශස්තකරණය.

VictoriaMetrics අනෙකුත් කාල ශ්‍රේණි දත්ත සමුදායන්ට වඩා හොඳ දත්ත සම්පීඩනයක් සපයයි.

එය සිරස් අතට පරිමාණය කරයි - එනම්, ඔබට එක් පරිගණකයකට තවත් ප්‍රොසෙසර්, වැඩි RAM එකතු කළ හැකිය. VictoriaMetrics මෙම පවතින සම්පත් සාර්ථකව භාවිතා කරන අතර රේඛීය ඵලදායිතාව වැඩිදියුණු කරනු ඇත.

VictoriaMetrics ද තිරස් අතට පරිමාණය කරයි - එනම්, ඔබට VictoriaMetrics පොකුරට අමතර නෝඩ් එකතු කළ හැකි අතර, එහි කාර්ය සාධනය රේඛීයව පාහේ වැඩි වනු ඇත.

ඔබ අනුමාන කළ පරිදි, VictoriaMetrics යනු වේගවත් දත්ත සමුදායකි, මන්ද මට අනෙක් ඒවා ලිවීමට නොහැක. එය Go හි ලියා ඇත, එබැවින් මම මෙම රැස්වීමේදී ඒ ගැන කතා කරමි.

කාල මාලාවක් යනු කුමක්දැයි දන්නේ කවුද? ඔහුත් ගොඩක් අය දන්නවා. කාල ශ්‍රේණියක් යනු යුගල මාලාවකි (timestamp, значение), මෙම යුගල කාලය අනුව වර්ග කර ඇත. අගය පාවෙන ලක්ෂ්‍ය අංකයකි - float64.

සෑම කාල ශ්‍රේණියක්ම යතුරකින් අනන්‍ය ලෙස හඳුනා ගැනේ. මෙම යතුර සමන්විත වන්නේ කුමක් ද? එය හිස් නොවන යතුරු-අගය යුගල කට්ටලයකින් සමන්විත වේ.

මෙන්න කාල මාලාවක උදාහරණයක්. මෙම මාලාවේ යතුර වන්නේ යුගල ලැයිස්තුවකි: __name__="cpu_usage" මෙට්රික් එකේ නම, instance="my-server" - මෙම මෙට්රික් එකතු කරන පරිගණකය මෙයයි, datacenter="us-east" - මෙම පරිගණකය පිහිටා ඇති දත්ත මධ්යස්ථානය මෙයයි.

අපි ප්‍රධාන අගය යුගල තුනකින් සමන්විත වේලා ශ්‍රේණි නාමයකින් අවසන් කළෙමු. මෙම යතුර යුගල ලැයිස්තුවකට අනුරූප වේ (timestamp, value). t1, t3, t3, ..., tN - මේවා වේලා මුද්දර, 10, 20, 12, ..., 15 - අනුරූප අගයන්. දී ඇති ශ්‍රේණියක් සඳහා දෙන ලද වේලාවක cpu-භාවිතය මෙයයි.

කාල ශ්‍රේණි භාවිතා කළ හැක්කේ කොතැනින්ද? කාට හරි අදහසක් තියෙනවද?

• DevOps වලදී, ඔබට CPU, RAM, ජාලය, rps, දෝෂ ගණන, ආදිය මැනිය හැක.
• IoT - අපට උෂ්ණත්වය, පීඩනය, භූ ඛණ්ඩාංක සහ වෙනත් යමක් මැනිය හැකිය.
• මූල්‍ය - අපට සියලු වර්ගවල කොටස් සහ මුදල් සඳහා මිල ගණන් නිරීක්ෂණය කළ හැකිය.
• මීට අමතරව, කර්මාන්තශාලාවල නිෂ්පාදන ක්‍රියාවලීන් අධීක්ෂණය කිරීමේදී කාල ශ්‍රේණි භාවිතා කළ හැකිය. රොබෝවරුන් සඳහා සුළං ටර්බයින නිරීක්ෂණය කිරීමට VictoriaMetrics භාවිතා කරන පරිශීලකයින් අප සතුව ඇත.
• විවිධ උපාංගවල සංවේදක වලින් තොරතුරු රැස් කිරීම සඳහා කාල ශ්‍රේණි ද ප්‍රයෝජනවත් වේ. උදාහරණයක් ලෙස, එන්ජිමක් සඳහා; ටයර් පීඩනය මැනීම සඳහා; වේගය, දුර මැනීම සඳහා; පෙට්‍රල් පරිභෝජනය මැනීම සඳහා යනාදිය.
• ගුවන් යානා නිරීක්ෂණය කිරීමට කාල ශ්‍රේණි ද භාවිතා කළ හැක. සෑම ගුවන් යානයකම කළු පෙට්ටියක් ඇති අතර එය ගුවන් යානයේ සෞඛ්‍යයේ විවිධ පරාමිතීන් සඳහා කාල ශ්‍රේණි එකතු කරයි. අභ්‍යවකාශ කර්මාන්තයේ ද කාල ශ්‍රේණි භාවිතා වේ.
• සෞඛ්‍යය යනු රුධිර පීඩනය, ස්පන්දනය යනාදියයි.

මට අමතක වූ තවත් යෙදුම් තිබිය හැකිය, නමුත් නවීන ලෝකයේ කාල ශ්‍රේණි ක්‍රියාකාරීව භාවිතා වන බව ඔබ තේරුම් ගනී යැයි මම බලාපොරොත්තු වෙමි. තවද ඔවුන්ගේ භාවිතයේ පරිමාව සෑම වසරකම වර්ධනය වේ.

ඔබට කාල ශ්‍රේණි දත්ත සමුදායක් අවශ්‍ය වන්නේ ඇයි? කාල ශ්‍රේණි ගබඩා කිරීමට ඔබට සාමාන්‍ය සම්බන්ධතා දත්ත සමුදායක් භාවිතා කළ නොහැක්කේ ඇයි?

සාම්ප්‍රදායික දත්ත සමුදායන් තුළ ගබඩා කිරීමට සහ සැකසීමට අපහසු වන, කාල ශ්‍රේණිවල සාමාන්‍යයෙන් විශාල තොරතුරු ප්‍රමාණයක් අඩංගු වන බැවිනි. එබැවින්, කාල ශ්රේණි සඳහා විශේෂිත දත්ත සමුදායන් දර්ශනය විය. මෙම පදනම් ඵලදායී ලෙස ලකුණු ගබඩා කරයි (timestamp, value) දී ඇති යතුර සමඟ. ඔවුන් ගබඩා කර ඇති දත්ත යතුර මගින්, තනි යතුරු අගය යුගලයකින් හෝ බහුවිධ යතුරු අගය යුගල මගින් හෝ regexp මගින් කියවීම සඳහා API සපයයි. උදාහරණයක් ලෙස, ඔබට ඇමරිකාවේ දත්ත මධ්‍යස්ථානයක ඔබගේ සියලුම සේවාවන්හි CPU භාරය සොයා ගැනීමට අවශ්‍ය වේ, එවිට ඔබට මෙම ව්‍යාජ විමසුම භාවිතා කිරීමට අවශ්‍ය වේ.

සාමාන්‍යයෙන් කාල ශ්‍රේණි දත්ත සමුදායන් විශේෂිත විමසුම් භාෂා සපයන්නේ කාල ශ්‍රේණි SQL ඉතා හොඳින් නොගැලපෙන බැවිනි. SQL සඳහා සහය දක්වන දත්ත සමුදායන් ඇතත් එය එතරම් සුදුසු නොවේ. වැනි භාෂා විමසන්න PromQL, InfluxQL, ගලන, Q. කවුරුහරි අඩුම තරමින් මෙම භාෂාවෙන් එකක්වත් අසා ඇතැයි මම බලාපොරොත්තු වෙමි. PromQL ගැන ගොඩක් අය අහලා ඇති. මෙය Prometheus විමසුම් භාෂාවයි.

උදාහරණයක් ලෙස VictoriaMetrics භාවිතා කරමින් නවීන කාල ශ්‍රේණියේ දත්ත සමුදා ගෘහ නිර්මාණ ශිල්පය පෙනෙන්නේ මෙයයි.

එය කොටස් දෙකකින් සමන්විත වේ. මෙය ප්‍රතිලෝම දර්ශකය සහ කාල ශ්‍රේණි අගයන් සඳහා ගබඩා කිරීමකි. මෙම ගබඩාවන් වෙන් කර ඇත.

දත්ත සමුදායට නව වාර්තාවක් පැමිණි විට, දී ඇති කට්ටලයක් සඳහා කාල ශ්‍රේණි හඳුනාගැනීම සඳහා අපි ප්‍රථමයෙන් ප්‍රතිලෝම දර්ශකය වෙත පිවිසෙමු. label=value දී ඇති මෙට්රික් සඳහා. අපි මෙම හැඳුනුම්කාරකය සොයාගෙන දත්ත ගබඩාවේ අගය සුරකින්න.

TSDB වෙතින් දත්ත ලබා ගැනීමට ඉල්ලීමක් පැමිණි විට, අපි මුලින්ම ප්‍රතිලෝම දර්ශකය වෙත යන්නෙමු. අපි සියල්ල ලබා ගනිමු timeseries_ids මෙම කට්ටලයට ගැලපෙන වාර්තා label=value. ඉන්පසුව අපි අවශ්‍ය සියලුම දත්ත දත්ත ගබඩාවෙන් සුචිගත කර ලබා ගනිමු timeseries_ids.

කාල ශ්‍රේණි දත්ත සමුදායක් පැමිණෙන තෝරාගත් විමසුමක් සකසන ආකාරය පිළිබඳ උදාහරණයක් බලමු.

• පළමුවෙන්ම ඇය සියල්ල ලබා ගනී timeseries_ids ලබා දී ඇති යුගල අඩංගු ප්‍රතිලෝම දර්ශකයකින් label=value, හෝ දී ඇති නිත්‍ය ප්‍රකාශනයක් තෘප්තිමත් කරන්න.
• එවිට එය සොයාගත් ඒවා සඳහා දී ඇති කාල පරතරයකින් දත්ත ගබඩාවෙන් සියලුම දත්ත ලක්ෂ්‍ය ලබා ගනී timeseries_ids.
• මෙයින් පසු, පරිශීලකයාගේ ඉල්ලීම අනුව දත්ත සමුදාය මෙම දත්ත ලක්ෂ්‍ය මත යම් ගණනය කිරීම් සිදු කරයි. ඊට පසු, එය පිළිතුර නැවත ලබා දෙයි.

මෙම ඉදිරිපත් කිරීමේදී මම ඔබට පළමු කොටස ගැන කියන්නම්. මෙය සෙවීමකි timeseries_ids ප්රතිලෝම දර්ශකය මගින්. දෙවෙනි කොටස ගැනත් තුන්වෙනි කොටස ගැනත් පස්සේ බලාගන්න පුළුවන් වික්ටෝරියා මෙට්‍රික්ස් මූලාශ්‍ර, නැත්නම් මම වෙනත් වාර්තා සකස් කරන තුරු ඉන්න :)

අපි ප්රතිලෝම දර්ශකය වෙත යමු. බොහෝ දෙනෙක් මෙය සරල යැයි සිතිය හැකිය. ප්‍රතිලෝම දර්ශකයක් යනු කුමක්ද සහ එය ක්‍රියා කරන්නේ කෙසේද යන්න දන්නේ කවුද? ඔහ්, දැන් එතරම් මිනිසුන් නැත. එය කුමක්දැයි තේරුම් ගැනීමට උත්සාහ කරමු.

ඇත්තටම එය සරලයි. එය හුදෙක් අගයකට යතුරක් සිතියම් ගත කරන ශබ්දකෝෂයකි. යතුරක් යනු කුමක්ද? මෙම යුවළ label=valueකොහෙද label и value - මේවා රේඛා. සහ අගයන් කට්ටලයක් වේ timeseries_ids, ලබා දී ඇති යුගලය ඇතුළත් වේ label=value.

ප්රතිලෝම දර්ශකය ඔබට ඉක්මනින් සියල්ල සොයා ගැනීමට ඉඩ සලසයි timeseries_ids, ලබා දී ඇති label=value.

එය ඔබට ඉක්මනින් සොයා ගැනීමට ද ඉඩ සලසයි timeseries_ids යුගල කිහිපයක් සඳහා කාල මාලාව label=value, හෝ ජෝඩු සඳහා label=regexp. මෙය සිදු වන්නේ කෙසේද? කට්ටලයේ ඡේදනය සොයා ගැනීමෙන් timeseries_ids එක් එක් යුගල සඳහා label=value.

ප්රතිලෝම දර්ශකයේ විවිධ ක්රියාත්මක කිරීම් දෙස බලමු. සරලම බොළඳ ක්රියාත්මක කිරීම සමඟ ආරම්භ කරමු. ඇය මේ වගේ.

උත්සවය getMetricIDs නූල් ලැයිස්තුවක් ලැබේ. සෑම පේළියකම අඩංගු වේ label=value. මෙම කාර්යය ලැයිස්තුවක් ආපසු ලබා දෙයි metricIDs.

එය ක්රියා කරන්නේ කෙසේද? මෙහිදී අපට ගෝලීය විචල්‍යයක් ලෙස හැඳින්වේ invertedIndex. මෙය සාමාන්‍ය ශබ්දකෝෂයකි (map), එමඟින් තන්තුව ඉන්ට් පෙති වලට සිතියම් ගත කරයි. රේඛාවේ අඩංගු වේ label=value.

කාර්යය ක්රියාත්මක කිරීම: ලබා ගන්න metricIDs පළමු සඳහා label=value, එවිට අපි අනෙක් සියල්ල හරහා යන්නෙමු label=value, අපිට ඒක ලැබෙනවා metricIDs ඔවුන් සදහා. සහ කාර්යය අමතන්න intersectInts, එය පහත සාකච්ඡා කරනු ඇත. තවද මෙම ශ්‍රිතය මෙම ලැයිස්තු වල ඡේදනය නැවත ලබා දෙයි.

ඔබට පෙනෙන පරිදි, ප්රතිලෝම දර්ශකයක් ක්රියාත්මක කිරීම ඉතා සංකීර්ණ නොවේ. නමුත් මෙය බොළඳ ක්‍රියාත්මක කිරීමකි. එහි ඇති අවාසි මොනවාද? Naive ක්රියාත්මක කිරීමේ ප්රධාන අවාසිය නම් එවැනි ප්රතිලෝම දර්ශකයක් RAM හි ගබඩා කර ඇත. යෙදුම නැවත ආරම්භ කිරීමෙන් පසු අපට මෙම දර්ශකය අහිමි වේ. මෙම දර්ශකය තැටියට සුරැකීමක් නොමැත. එවැනි ප්‍රතිලෝම දර්ශකයක් දත්ත සමුදායක් සඳහා සුදුසු නොවනු ඇත.

දෙවන අඩුපාඩුව ද මතකය හා සම්බන්ධ වේ. ප්‍රතිලෝම දර්ශකය RAM එකට ගැලපේ. එය RAM ප්‍රමාණය ඉක්මවා ගියහොත්, පැහැදිලිවම අපට ලැබෙනු ඇත - මතක දෝෂයෙන් ඉවත් වේ. සහ වැඩසටහන ක්රියා නොකරනු ඇත.

වැනි සූදානම් කළ විසඳුම් භාවිතයෙන් මෙම ගැටළුව විසඳා ගත හැකිය මට්ටම ඩීබී, හෝ රොක්ස්ඩීබී.

කෙටියෙන් කිවහොත්, අපට ඉක්මනින් මෙහෙයුම් තුනක් කිරීමට ඉඩ සලසන දත්ත ගබඩාවක් අවශ්‍ය වේ.

• පළමු මෙහෙයුම පටිගත කිරීමයි ключ-значение මෙම දත්ත සමුදායට. ඇය මෙය ඉතා ඉක්මනින් කරයි, කොහෙද ключ-значение අත්තනෝමතික නූල් වේ.
• දෙවන මෙහෙයුම යනු ලබා දී ඇති යතුරක් භාවිතයෙන් අගයක් සඳහා ඉක්මන් සෙවුමකි.
• තුන්වන මෙහෙයුම යනු ලබා දී ඇති උපසර්ගයක් මගින් සියලු අගයන් සඳහා ඉක්මන් සෙවුමකි.

LevelDB සහ RocksDB - මෙම දත්ත සමුදායන් ගූගල් සහ ෆේස්බුක් විසින් සංවර්ධනය කරන ලදී. මුලින්ම LevelDB ආවා. පස්සේ Facebook එකේ කට්ටිය LevelDB අරගෙන ඒක දියුණු කරන්න පටන් ගත්තා, RocksDB හැදුවා. දැන් RocksDB සහ MySQL වෙත මාරු කර ඇති ඒවා ඇතුළුව සියලුම අභ්‍යන්තර දත්ත සමුදායන් Facebook තුළ RocksDB මත ක්‍රියා කරයි. ඔවුන් ඔහුව නම් කළා MyRocks.

LevelDB භාවිතයෙන් ප්‍රතිලෝම දර්ශකයක් ක්‍රියාත්මක කළ හැක. එය කරන්නේ කෙසේද? අපි යතුරක් ලෙස සුරකිමු label=value. අගය යනු යුගලය පවතින කාල ශ්‍රේණියේ හඳුනාගැනීමයි label=value.

දී ඇති යුගලයක් සමඟ අපට බොහෝ කාල ශ්‍රේණි තිබේ නම් label=value, එවිට මෙම දත්ත සමුදායේ එකම යතුර සහ වෙනස් පේළි රාශියක් ඇත timeseries_ids. සියල්ලන්ගේ ලැයිස්තුවක් ලබා ගැනීමට timeseries_ids, මෙයින් ආරම්භ වන label=prefix, අපි මෙම දත්ත සමුදාය ප්‍රශස්ත කර ඇති පරාසයක ස්කෑන් කිරීමක් කරන්නෙමු. එනම්, අපි ආරම්භ වන සියලුම රේඛා තෝරා ගනිමු label=prefix සහ අවශ්ය ලබා ගන්න timeseries_ids.

මෙන්න එය Go හි පෙනෙන ආකාරය පිළිබඳ නියැදි ක්‍රියාත්මක කිරීමකි. අපට ප්‍රතිලෝම දර්ශකයක් ඇත. මෙය LevelDB වේ.

කාර්යය බොළඳ ක්රියාත්මක කිරීම සඳහා සමාන වේ. එය බොළඳ ක්‍රියාත්මක කිරීම පාහේ පේළියෙන් පේළිය පුනරාවර්තනය කරයි. එකම කාරණය හැරෙනවා වෙනුවට map අපි ප්‍රතිලෝම දර්ශකයට පිවිසෙමු. අපි පළමු සඳහා සියලු අගයන් ලබා ගනිමු label=value. එවිට අපි ඉතිරි සියලුම යුගල හරහා යන්නෙමු label=value සහ ඔවුන් සඳහා අනුරූප මෙට්‍රික්අයිඩී කට්ටල ලබා ගන්න. එවිට අපි ඡේදනය සොයා ගනිමු.

සෑම දෙයක්ම හොඳ බව පෙනේ, නමුත් මෙම විසඳුමේ අඩුපාඩු තිබේ. VictoriaMetrics මුලදී LevelDB මත පදනම් වූ ප්‍රතිලෝම දර්ශකයක් ක්‍රියාත්මක කළේය. නමුත් අවසානයේ මට එය අත්හැරීමට සිදු විය.

ඇයි? LevelDB බොළඳ ක්‍රියාත්මක කිරීමට වඩා මන්දගාමී නිසා. බොළඳ ක්‍රියාත්මක කිරීමේදී, ලබා දී ඇති යතුරක් ලබා දී, අපි වහාම සම්පූර්ණ පෙත්තම ලබා ගනිමු metricIDs. මෙය ඉතා වේගවත් මෙහෙයුමකි - සම්පූර්ණ පෙත්ත භාවිතයට සූදානම්.

LevelDB හි, සෑම අවස්ථාවකම ශ්‍රිතයක් කැඳවනු ලැබේ GetValues ඔබ ආරම්භ වන සියලුම රේඛා හරහා යා යුතුය label=value. සහ එක් එක් පේළිය සඳහා වටිනාකම ලබා ගන්න timeseries_ids. එවැනි අයගෙන් timeseries_ids මේවායින් පෙත්තක් එකතු කරන්න timeseries_ids. නිසැකවම, මෙය යතුර මගින් සාමාන්‍ය සිතියමකට ප්‍රවේශ වීමට වඩා මන්දගාමී වේ.

දෙවන අඩුපාඩුව නම් LevelDB C වලින් ලියා තිබීමයි. Go වෙතින් C ශ්‍රිතයන් ඇමතීම ඉතා වේගවත් නොවේ. එය නැනෝ තත්පර සිය ගණනක් ගතවේ. මෙය ඉතා වේගවත් නොවේ, මන්ද යත්, නැනෝ තත්පර 1-5ක් ගත වන go හි ලියා ඇති සාමාන්‍ය ක්‍රියාකාරී ඇමතුමකට සාපේක්ෂව, කාර්ය සාධනයේ වෙනස දස ගුණයකි. VictoriaMetrics සඳහා මෙය මාරාන්තික දෝෂයක් විය :)

එබැවින් මම ප්රතිලෝම දර්ශකය මගේම ක්රියාත්මක කිරීම ලිවීය. තවද ඔහු ඇයට කතා කළේය ඒකාබද්ධ කිරීම.

Mergeset MergeTree දත්ත ව්‍යුහය මත පදනම් වේ. මෙම දත්ත ව්‍යුහය ClickHouse වෙතින් ලබාගෙන ඇත. පැහැදිලිවම, වේගවත් සෙවීම සඳහා ඒකාබද්ධ කිරීම ප්‍රශස්ත කළ යුතුය timeseries_ids ලබා දී ඇති යතුර අනුව. Mergeset සම්පූර්ණයෙන්ම Go වලින් ලියා ඇත. බලන්න පුළුවන් GitHub මත VictoriaMetrics මූලාශ්‍ර. ඒකාබද්ධ කිරීම ක්‍රියාත්මක කිරීම ෆෝල්ඩරයේ ඇත /lib/mergeset. ඔබට එහි සිදුවන්නේ කුමක්දැයි සොයා ගැනීමට උත්සාහ කළ හැකිය.

ඒකාබද්ධ API LevelDB සහ RocksDB ට බෙහෙවින් සමාන ය. එනම්, එය ඔබට ඉක්මනින් එහි නව වාර්තා සුරැකීමට සහ ලබා දී ඇති උපසර්ගයකින් වාර්තා ඉක්මනින් තෝරා ගැනීමට ඉඩ සලසයි.

mergeset එකේ අවාසි ගැන අපි පසුව කතා කරමු. ප්‍රතිලෝම දර්ශකයක් ක්‍රියාත්මක කිරීමේදී නිෂ්පාදනයේදී වික්ටෝරියා මෙට්‍රික්ස් සමඟ ඇති වූ ගැටළු මොනවාදැයි දැන් අපි කතා කරමු.

ඔවුන් මතු වූයේ ඇයි?

පළමු හේතුව වන්නේ අධික කැටි ගැසීම් අනුපාතයයි. රුසියානු භාෂාවට පරිවර්තනය කර ඇති මෙය කාල ශ්රේණියේ නිතර වෙනස් වීමකි. කාල ශ්‍රේණියක් අවසන් වී නව ශ්‍රේණියක් ආරම්භ වන විට හෝ බොහෝ නව කාල ශ්‍රේණි ආරම්භ වන්නේ මෙයයි. තවද මෙය බොහෝ විට සිදු වේ.

දෙවන හේතුව වන්නේ කාල ශ්‍රේණි විශාල සංඛ්‍යාවක් තිබීමයි. ආරම්භයේ දී, අධීක්ෂණය ජනප්රිය වෙමින් පවතින විට, කාල ශ්රේණි සංඛ්යාව කුඩා විය. උදාහරණයක් ලෙස, එක් එක් පරිගණකය සඳහා ඔබ CPU, මතකය, ජාලය සහ තැටි පැටවීම නිරීක්ෂණය කළ යුතුය. පරිගණකයකට 4 කාල මාලාවක්. ඔබ සතුව පරිගණක 100ක් සහ කාල ශ්‍රේණි 400ක් ඇතැයි සිතමු. මෙය ඉතා ස්වල්පයකි.

කාලයාගේ ඇවෑමෙන්, මිනිසුන්ට වඩාත් කැටිති තොරතුරු මැනිය හැකි බව සොයා ගත්හ. උදාහරණයක් ලෙස, සම්පූර්ණ ප්‍රොසෙසරයේ බර නොව, එක් එක් ප්‍රොසෙසර හරය වෙන වෙනම මනින්න. ඔබ සතුව ප්‍රොසෙසර මධ්‍ය 40 ක් තිබේ නම්, ප්‍රොසෙසර භාරය මැනීමට ඔබට 40 ගුණයක කාල ශ්‍රේණියක් ඇත.

නමුත් එය පමණක් නොවේ. එක් එක් ප්‍රොසෙසර හරය නිෂ්ක්‍රීයව පවතින විට idle වැනි අවස්ථා කිහිපයක් තිබිය හැක. තවද පරිශීලක අවකාශයේ වැඩ කරන්න, කර්නල් අවකාශයේ සහ වෙනත් ප්‍රාන්තවල වැඩ කරන්න. තවද එවැනි සෑම තත්වයක්ම වෙනම කාල ශ්‍රේණියක් ලෙසද මැනිය හැක. මෙය අතිරේකව පේළි ගණන 7-8 ගුණයකින් වැඩි කරයි.

එක් මෙට්‍රික් එකකින් අපට එක් පරිගණකයකට මෙට්‍රික් 40 x 8 = 320 ලැබුණි. 100 න් ගුණ කරන්න, අපට 32 වෙනුවට 000 ලැබේ.

ඊට පස්සේ Kubernetes ආවා. Kubernetes විවිධ සේවාවන් සඳහා සත්කාරකත්වය දිය හැකි නිසා එය වඩාත් නරක අතට හැරුණි. Kubernetes හි සෑම සේවාවක්ම බොහෝ කරල් වලින් සමන්විත වේ. තවද මේ සියල්ල නිරීක්ෂණය කළ යුතුය. ඊට අමතරව, ඔබගේ සේවාවන්හි නව අනුවාදවල නිරන්තර යෙදවීමක් අප සතුව ඇත. සෑම නව අනුවාදයක් සඳහාම, නව කාල මාලාවක් සෑදිය යුතුය. එහි ප්‍රතිඵලයක් වශයෙන්, කාල ශ්‍රේණි සංඛ්‍යාව ඝාතීය ලෙස වර්ධනය වන අතර, අධි-කාර්ඩිනලිටි ලෙස හඳුන්වන කාල ශ්‍රේණි විශාල සංඛ්‍යාවක ගැටලුවට අප මුහුණ දී සිටී. අනෙකුත් කාල ශ්‍රේණි දත්ත සමුදායන් හා සසඳන විට VictoriaMetrics එය සමඟ සාර්ථකව කටයුතු කරයි.

ඉහළ චංචල අනුපාතය දෙස සමීපව බලමු. නිෂ්පාදනයේ ඉහළ කම්පන අනුපාතයකට හේතුව කුමක්ද? ලේබල් සහ ටැග් වල සමහර අර්ථයන් නිරන්තරයෙන් වෙනස් වන බැවිනි.

උදාහරණයක් ලෙස, සංකල්පය ඇති Kubernetes ගන්න deployment, එනම් ඔබගේ යෙදුමේ නව අනුවාදයක් නිකුත් කරන විට. කිසියම් හේතුවක් නිසා, Kubernetes සංවර්ධකයින් ලේබලයට යෙදවීමේ හැඳුනුම්පත එක් කිරීමට තීරණය කළහ.

මෙය හේතු වූයේ කුමක් ද? එපමණක් නොව, සෑම නව යෙදවීමක් සමඟම, සියලුම පැරණි කාල ශ්‍රේණිවලට බාධා ඇති වන අතර, ඒවා වෙනුවට නව කාල ශ්‍රේණි නව ලේබල් අගයකින් ආරම්භ වේ deployment_id. එවැනි පේළි සිය දහස් ගණනක් සහ මිලියන ගණනක් තිබිය හැකිය.

මේ සියල්ලේ වැදගත්ම දෙය නම් මුළු කාල ශ්‍රේණි ගණන වර්ධනය වන නමුත් දැනට ක්‍රියාත්මක වන සහ දත්ත ලබා ගන්නා කාල ශ්‍රේණි සංඛ්‍යාව නියතව පැවතීමයි. මෙම තත්වය අධි චූෂණ අනුපාතය ලෙස හැඳින්වේ.

ඉහළ චංචල අනුපාතයේ ප්‍රධාන ගැටළුව වන්නේ නියමිත කාල පරාසයක් තුළ දී ඇති ලේබල් කට්ටලයක් සඳහා සියලු කාල ශ්‍රේණි සඳහා නිරන්තර සෙවුම් වේගයක් සහතික කිරීමයි. සාමාන්‍යයෙන් මෙය අවසාන පැය හෝ අවසාන දිනය සඳහා කාල පරතරය වේ.

මෙම ගැටලුව විසඳන්නේ කෙසේද? මෙන්න පළමු විකල්පය. මෙය කාලයාගේ ඇවෑමෙන් ස්වාධීන කොටස් වලට ප්රතිලෝම දර්ශකය බෙදීමයි. එනම්, යම් කාල පරතරයක් ගෙවී යයි, අපි වත්මන් ප්රතිලෝම දර්ශකය සමඟ වැඩ කිරීම අවසන් කරමු. සහ නව ප්රතිලෝම දර්ශකයක් සාදන්න. තවත් කාල පරතරයක් ගෙවී යන විට, අපි තවත් එකක් සහ තවත් එකක් නිර්මාණය කරමු.

තවද මෙම ප්‍රතිලෝම දර්ශක වලින් නියැදීමේදී, දී ඇති පරතරය තුළට වැටෙන ප්‍රතිලෝම දර්ශක සමූහයක් අපට හමු වේ. තවද, ඒ අනුව, අපි එතැන් සිට කාල ශ්‍රේණියේ හැඳුනුම්පත තෝරා ගනිමු.

මෙමගින් සම්පත් ඉතිරි වන්නේ ලබා දී ඇති පරතරය තුළට නොවැටෙන කොටස් දෙස බැලීමට අපට අවශ්‍ය නොවන බැවිනි. එනම්, සාමාන්‍යයෙන්, අපි අවසාන පැය සඳහා දත්ත තෝරා ගන්නේ නම්, පෙර කාල පරතරයන් සඳහා අපි විමසුම් මඟ හරිමු.

මෙම ගැටළුව විසඳීමට තවත් විකල්පයක් තිබේ. මෙය එක් එක් දිනය සඳහා එදින සිදු වූ කාල ශ්‍රේණිවල ids ලැයිස්තුවක් වෙන වෙනම ගබඩා කර තැබීමයි.

කලින් විසඳුමට වඩා මෙම විසඳුමේ වාසිය නම් කාලයත් සමඟ අතුරුදහන් නොවන කාල ශ්‍රේණියේ තොරතුරු අපි අනුපිටපත් නොකිරීමයි. ඒවා නිරන්තරයෙන් පවතින අතර වෙනස් නොවේ.

අවාසිය නම් එවැනි විසඳුමක් ක්රියාත්මක කිරීම වඩා දුෂ්කර වන අතර දෝෂහරණය කිරීමට වඩා අපහසු වේ. VictoriaMetrics මෙම විසඳුම තෝරා ගත්තේය. එය ඓතිහාසිකව සිදුවූයේ එලෙසය. මෙම විසඳුම ද පෙර එකට සාපේක්ෂව හොඳින් ක්රියා කරයි. මක්නිසාද යත් වෙනස් නොවන, එනම් කාලයත් සමඟ අතුරුදහන් නොවන කාල ශ්‍රේණි සඳහා එක් එක් කොටසෙහි දත්ත අනුපිටපත් කිරීම අවශ්‍ය වන බැවින් මෙම විසඳුම ක්‍රියාත්මක නොකළ බැවිනි. VictoriaMetrics මූලික වශයෙන් තැටි අවකාශය පරිභෝජනය සඳහා ප්‍රශස්ත කරන ලද අතර, පෙර ක්‍රියාත්මක කිරීම තැටි අවකාශය පරිභෝජනය වඩාත් නරක අතට හැරිණි. නමුත් මෙම ක්රියාත්මක කිරීම තැටි අවකාශය පරිභෝජනය අවම කිරීම සඳහා වඩාත් සුදුසු වේ, එබැවින් එය තෝරා ගන්නා ලදී.

මට ඇය සමඟ සටන් කිරීමට සිදු විය. අරගලය වූයේ මෙම ක්‍රියාත්මක කිරීමේදී ඔබ තවමත් විශාල සංඛ්‍යාවක් තෝරා ගැනීමට අවශ්‍ය වීමයි timeseries_ids ප්‍රතිලෝම දර්ශක කාලය කොටස් කරන විට වඩා දත්ත සඳහා.

අපි කොහොමද මේ ගැටලුව විසඳුවේ? අපි එය මුල් ආකාරයෙන් විසඳා ගත්තෙමු - එක් හඳුනාගැනීමක් වෙනුවට එක් එක් ප්‍රතිලෝම දර්ශක ප්‍රවේශය තුළ කාල ශ්‍රේණි හඳුනාගැනීම් කිහිපයක් ගබඩා කිරීමෙන්. එනම්, අපට යතුරක් තිබේ label=value, සෑම කාල ශ්‍රේණියකම සිදු වේ. දැන් අපි කිහිපයක් ඉතිරි කරමු timeseries_ids එක් ප්රවේශයක් තුළ.

මෙන්න උදාහරණයක්. මීට පෙර අපට N ඇතුළත් කිරීම් තිබුණි, නමුත් දැන් අපට එක් ප්‍රවේශයක් ඇත, එහි උපසර්ගය අනෙක් සියල්ලටම සමාන වේ. පෙර ප්‍රවේශය සඳහා, අගයෙහි සියලුම කාල ශ්‍රේණි id අඩංගු වේ.

මෙමඟින් එවැනි ප්‍රතිලෝම දර්ශකයක ස්කෑන් වේගය 10 ගුණයක් දක්වා වැඩි කිරීමට හැකි විය. තවද එය හැඹිලිය සඳහා මතක පරිභෝජනය අඩු කිරීමට අපට ඉඩ සලසයි, මන්ද දැන් අපි නූල් ගබඩා කර ඇත label=value N වරක් එකට හැඹිලියේ එක් වරක් පමණි. කුබර්නෙට්ස් එහි තල්ලු කිරීමට කැමති ඔබේ ටැග් සහ ලේබලවල දිගු රේඛා ගබඩා කරන්නේ නම් මෙම රේඛාව විශාල විය හැකිය.

ප්රතිලෝම දර්ශකයක් මත සෙවීම වේගවත් කිරීම සඳහා තවත් විකල්පයක් වන්නේ ෂර්ඩින් කිරීමයි. එකක් වෙනුවට ප්‍රතිලෝම දර්ශක කිහිපයක් නිර්මාණය කිරීම සහ යතුර මගින් ඒවා අතර දත්ත බෙදා ගැනීම. මේක සෙට් එකක් key=value වාෂ්ප. එනම්, අපට ප්‍රොසෙසර කිහිපයකින් සමාන්තරව විමසිය හැකි ස්වාධීන ප්‍රතිලෝම දර්ශක කිහිපයක් අපට ලැබේ. පෙර ක්‍රියාත්මක කිරීම් තනි-ප්‍රොසෙසර ප්‍රකාරයේදී පමණක් ක්‍රියා කිරීමට අවසර දී ඇත, එනම්, එක් හරයක පමණක් දත්ත ස්කෑන් කිරීම. ClickHouse කිරීමට කැමති පරිදි, මෙම විසඳුම එකවර හර කිහිපයක දත්ත ස්කෑන් කිරීමට ඔබට ඉඩ සලසයි. අපි ක්‍රියාත්මක කිරීමට සැලසුම් කරන්නේ මෙයයි.

දැන් අපි අපේ බැටළුවන් වෙත ආපසු යමු - ඡේදනය කිරීමේ කාර්යයට timeseries_ids. විය හැකි ක්‍රියාත්මක කිරීම් මොනවාදැයි අපි සලකා බලමු. මෙම කාර්යය ඔබට සොයා ගැනීමට ඉඩ සලසයි timeseries_ids දී ඇති කට්ටලයක් සඳහා label=value.

පළමු විකල්පය බොළඳ ක්රියාත්මක කිරීමකි. කූඩු ලූප දෙකක්. මෙහිදී අපට Function input එක ලැබේ intersectInts පෙති දෙකක් - a и b. නිමැවුමේදී, එය මෙම පෙතිවල ඡේදනය අප වෙත ආපසු යා යුතුය.

බොළඳ ක්රියාත්මක කිරීමක් මේ ආකාරයෙන් පෙනේ. අපි පෙත්තෙන් සියලුම අගයන් පුනරාවර්තනය කරමු a, මෙම ලූපය තුළ අපි පෙත්තෙහි සියලුම අගයන් හරහා යන්නෙමු b. ඒ වගේම අපි ඒවා සංසන්දනය කරනවා. ඒවා ගැලපෙන්නේ නම්, අපි ඡේදනයක් සොයාගෙන ඇත. සහ එය සුරකින්න result.

අවාසි මොනවාද? චතුරස්රාකාර සංකීර්ණත්වය එහි ප්රධාන පසුබෑමයි. උදාහරණයක් ලෙස, ඔබේ මානයන් පෙති නම් a и b වරකට මිලියනයක්, එවිට මෙම කාර්යය කිසිදා ඔබට පිළිතුරක් ලබා නොදෙනු ඇත. මන්ද එය නවීන පරිගණක සඳහා පවා බොහෝ දේ වන ට්‍රිලියනයක් පුනරාවර්තනය කිරීමට අවශ්‍ය වනු ඇත.

දෙවන ක්රියාත්මක කිරීම සිතියම මත පදනම් වේ. අපි සිතියමක් සාදන්නෙමු. අපි පෙත්තේ සිට සියලුම අගයන් මෙම සිතියමට දමමු a. ඊට පස්සේ අපි වෙනම ලූපයක් තුළ පෙත්තක් හරහා යනවා b. තවද මෙම අගය ස්ලයිස් වලින් දැයි අපි පරීක්ෂා කරමු b සිතියමේ. එය පවතී නම්, එය ප්රතිඵලයට එකතු කරන්න.

ප්රතිලාභ මොනවාද? වාසිය වන්නේ රේඛීය සංකීර්ණත්වය පමණක් තිබීමයි. එනම්, විශාල පෙති සඳහා ශ්‍රිතය වඩා වේගයෙන් ක්‍රියාත්මක වේ. මිලියන ප්‍රමාණයේ පෙත්තක් සඳහා, මෙම ශ්‍රිතය පෙර ශ්‍රිතයේ ට්‍රිලියන පුනරාවර්තනයන්ට ප්‍රතිවිරුද්ධව, මිලියන 2ක පුනරාවර්තන වලින් ක්‍රියාත්මක වේ.

අවාසිය නම් මෙම සිතියම නිර්මාණය කිරීමට මෙම කාර්යයට වැඩි මතකයක් අවශ්‍ය වීමයි.

දෙවන අවාසිය නම් හැෂිං සඳහා විශාල උඩිස් ය. මෙම අඩුපාඩුව ඉතා පැහැදිලි නැත. අපට එය ද එතරම් පැහැදිලි නොවීය, එබැවින් මුලින් වික්ටෝරියා මෙට්‍රික්ස් හි ඡේදනය ක්‍රියාත්මක කිරීම සිතියමක් හරහා විය. නමුත් පසුව පැතිකඩ කිරීම පෙන්නුම් කළේ ප්‍රධාන ප්‍රොසෙසර කාලය සිතියමට ලිවීමට සහ මෙම සිතියමේ අගයක් තිබේදැයි පරීක්ෂා කිරීමට වැය වන බවයි.

මෙම ස්ථානවල CPU කාලය නාස්ති වන්නේ ඇයි? මක්නිසාද යත් Go මෙම රේඛා මත හැෂිං මෙහෙයුමක් සිදු කරයි. එනම්, එය HashMap හි දී ඇති දර්ශකයකට ප්‍රවේශ වීම සඳහා යතුරේ හැෂ් ගණනය කරයි. හැෂ් ගණනය කිරීමේ මෙහෙයුම නැනෝ තත්පර දස ගණනකින් අවසන් වේ. මෙය VictoriaMetrics සඳහා මන්දගාමී වේ.

මෙම නඩුව සඳහා විශේෂයෙන් ප්‍රශස්තිකරණය කරන ලද බිට්සෙට් එකක් ක්‍රියාත්මක කිරීමට මම තීරණය කළෙමි. පෙති දෙකක ඡේදනය දැන් පෙනෙන්නේ මෙයයි. මෙන්න අපි බිට්සෙට් එකක් හදනවා. අපි එයට පළමු පෙත්තෙන් මූලද්රව්ය එකතු කරමු. ඉන්පසුව අපි දෙවන පෙත්තෙහි මෙම මූලද්රව්යවල පැවැත්ම පරීක්ෂා කරමු. තවද ඒවා ප්රතිඵලයට එකතු කරන්න. එනම්, එය පෙර උදාහරණයෙන් පාහේ වෙනස් නොවේ. මෙහි ඇති එකම දෙය නම් අපි අභිරුචි කාර්යයන් සමඟ සිතියම වෙත ප්‍රවේශය ප්‍රතිස්ථාපනය කළෙමු add и has.

මුලින්ම බැලූ බැල්මට පෙනෙන්නේ, මීට පෙර එහි සම්මත සිතියමක් භාවිතා කර ඇත්නම්, පසුව වෙනත් කාර්යයන් නම් කර ඇත්නම්, මෙය මන්දගාමීව ක්‍රියා කළ යුතු බව පෙනේ, නමුත් පැතිකඩ මඟින් පෙන්නුම් කරන්නේ මෙය VictoriaMetrics සම්බන්ධයෙන් සම්මත සිතියමට වඩා 10 ගුණයක් වේගයෙන් ක්‍රියා කරන බවයි.

ඊට අමතරව, සිතියම ක්‍රියාත්මක කිරීමට සාපේක්ෂව එය ඉතා අඩු මතකයක් භාවිතා කරයි. මොකද අපි මෙතන බයිට් අටක අගයන් වෙනුවට බිටු ගබඩා කරනවා.

මෙම ක්‍රියාවට නැංවීමේ අවාසිය නම් එය එතරම් පැහැදිලි නොවන, සුළුපටු නොවන බවයි.

බොහෝ අය නොදකින තවත් අඩුපාඩුවක් වන්නේ මෙම ක්‍රියාත්මක කිරීම සමහර අවස්ථාවලදී හොඳින් ක්‍රියා නොකිරීමයි. එනම්, වික්ටෝරියා මෙට්‍රික්ස් කාල ශ්‍රේණියේ ID වල ඡේදනය වීමේ මෙම අවස්ථාව සඳහා එය විශේෂිත අවස්ථාවක් සඳහා ප්‍රශස්ත කර ඇත. එය සියලු අවස්ථා සඳහා සුදුසු බව මින් අදහස් නොවේ. එය වැරදි ලෙස භාවිතා කළහොත්, අපට ලැබෙන්නේ කාර්ය සාධන වැඩිවීමක් නොව, මතකයේ දෝෂයක් සහ කාර්ය සාධනය මන්දගාමී වීමකි.

මෙම ව්යුහය ක්රියාත්මක කිරීම සලකා බලමු. ඔබට බැලීමට අවශ්‍ය නම්, එය VictoriaMetrics මූලාශ්‍රවල, ෆෝල්ඩරයේ පිහිටා ඇත lib/uint64set. එය VictoriaMetrics නඩුව සඳහා විශේෂයෙන් ප්‍රශස්ත කර ඇත timeseries_id යනු 64-bit අගයකි, එහිදී පළමු බිටු 32 මූලික වශයෙන් නියත වන අතර අවසාන බිටු 32 පමණක් වෙනස් වේ.

මෙම දත්ත ව්‍යුහය තැටියේ ගබඩා කර නැත, එය ක්‍රියාත්මක වන්නේ මතකයේ පමණි.

මෙන්න එහි API. එය ඉතා සංකීර්ණ නොවේ. API විශේෂයෙන් VictoriaMetrics භාවිතා කිරීම සඳහා නිශ්චිත උදාහරණයක් ලෙස සකස් කර ඇත. එනම්, මෙහි අනවශ්ය කාර්යයන් නොමැත. VictoriaMetrics විසින් පැහැදිලිව භාවිතා කරන කාර්යයන් මෙන්න.

කාර්යයන් ඇත add, නව අගයන් එකතු කරන. කාර්යයක් ඇත has, නව අගයන් සඳහා පරීක්ෂා කරයි. සහ කාර්යයක් ඇත del, අගයන් ඉවත් කරන. උපකාරක කාර්යයක් ඇත len, කට්ටලයේ ප්රමාණය ආපසු ලබා දෙයි. කාර්යය clone ක්ලෝන ගොඩක්. සහ කාර්යය appendto මෙම කට්ටලය පෙත්තක් බවට පරිවර්තනය කරයි timeseries_ids.

මෙම දත්ත ව්යුහය ක්රියාත්මක කිරීම පෙනෙන්නේ මෙයයි. කට්ටලයට මූලද්රව්ය දෙකක් ඇත:

• ItemsCount කට්ටලයක ඇති මූලද්‍රව්‍ය ගණන ඉක්මනින් ආපසු ලබා දීමට උපකාරක ක්ෂේත්‍රයකි. මෙම සහායක ක්ෂේත්‍රය නොමැතිව එය කළ හැකි වනු ඇත, නමුත් එය මෙහි එකතු කිරීමට සිදු වූයේ VictoriaMetrics බොහෝ විට එහි ඇල්ගොරිතමවල බිට්සෙට් දිග විමසන බැවිනි.

• දෙවන ක්ෂේත්රය වේ buckets. මෙය ව්යුහයෙන් පෙත්තකි bucket32. සෑම ව්යුහයක්ම ගබඩා කරයි hi ක්ෂේත්රය. මේවා ඉහළ බිටු 32 වේ. සහ පෙති දෙකක් - b16his и buckets සිට bucket16 ව්යුහයන්.

16-bit ව්‍යුහයේ දෙවන කොටසේ ඉහළම බිටු 64 මෙහි ගබඩා කර ඇත. තවද මෙහි එක් එක් බයිටයේ පහළ බිටු 16 සඳහා බිට්සෙට් ගබඩා කර ඇත.

Bucket64 අරාවකින් සමන්විත වේ uint64. මෙම නියතයන් භාවිතයෙන් දිග ගණනය කෙරේ. එකක bucket16 උපරිම ගබඩා කළ හැක 2^16=65536 ටිකක්. මේක 8න් බෙදුවොත් කිලෝබයිට් 8ක්. ආයෙත් 8න් බෙදුවොත් 1000යි uint64 අර්ථය. එනම් Bucket16 - මෙය අපගේ කිලෝබයිට් 8 ව්‍යුහයයි.

නව අගයක් එකතු කිරීම සඳහා මෙම ව්‍යුහයේ එක් ක්‍රමයක් ක්‍රියාත්මක කරන්නේ කෙසේදැයි බලමු.

ඒ සියල්ල ආරම්භ වන්නේ uint64 අර්ථයන්. අපි ඉහළ බිටු 32 ගණනය කරමු, අපි පහළ බිටු 32 ගණනය කරමු. අපි හැම දෙයක්ම හරහා යමු buckets. අපි එක් එක් බාල්දියේ ඉහළම බිටු 32 එකතු කරන අගය සමඟ සංසන්දනය කරමු. ඒවා ගැලපෙන්නේ නම්, අපි ශ්‍රිතය ලෙස හඳුන්වමු add ව්යුහය b32 තුළ buckets. එහි පහළ බිටු 32 එකතු කරන්න. සහ එය ආපසු ගියහොත් true, එතකොට මේ කියන්නේ අපි එතනට එහෙම අගයක් එකතු කරලා අපිට එහෙම අගයක් තිබුණේ නැහැ. එය නැවත පැමිණේ නම් false, එවිට එවැනි අර්ථයක් දැනටමත් පැවතුනි. එවිට අපි ව්යුහයේ මූලද්රව්ය සංඛ්යාව වැඩි කරමු.

ඔබට අවශ්‍ය එක අපි සොයා නොගත්තොත් bucket අවශ්‍ය hi-value සමඟ, අපි ශ්‍රිතය අමතන්නෙමු addAlloc, නව එකක් නිපදවනු ඇත bucket, එය බාල්දි ව්යුහයට එකතු කිරීම.

මෙය කාර්යය ක්රියාත්මක කිරීමයි b32.add. එය පෙර ක්රියාත්මක කිරීම හා සමාන වේ. අපි වඩාත්ම වැදගත් බිටු 16, අවම වශයෙන් සැලකිය යුතු බිටු 16 ගණනය කරමු.

එවිට අපි ඉහළ බිටු 16 හරහා යන්නෙමු. අපි ගැලපීම් සොයා ගනිමු. තවද ගැළපීමක් තිබේ නම්, අපි එකතු කිරීමේ ක්‍රමය ලෙස හඳුන්වමු, එය අපි ඊළඟ පිටුවේ සලකා බලමු bucket16.

මෙන්න පහත මට්ටම, එය හැකි තරම් ප්‍රශස්ත කළ යුතුය. සඳහා අපි ගණනය කරමු uint64 id අගය ස්ලයිස් බිට් සහ ද bitmask. මෙය ලබා දී ඇති 64-bit අගයක් සඳහා වන වෙස් මුහුණකි, එය මෙම බිට් එක තිබේදැයි පරීක්ෂා කිරීමට හෝ එය සැකසීමට භාවිතා කළ හැක. අපි මෙම බිට් එක සකසා එය සකසන්නේද යන්න සහ නැවත පැමිණීම පරීක්ෂා කරන්නෙමු. සාම්ප්‍රදායික සිතියම්වලට සාපේක්ෂව කාල ශ්‍රේණිවල ඡේදනය වන id වල ක්‍රියාකාරිත්වය 10 ගුණයකින් වේගවත් කිරීමට අපට ඉඩ සලසන අපගේ ක්‍රියාත්මක කිරීම මෙයයි.

මෙම ප්‍රශස්තකරණයට අමතරව, VictoriaMetrics සතුව තවත් බොහෝ ප්‍රශස්තකරණයන් ඇත. මෙම ප්‍රශස්තකරණයන්ගෙන් බොහොමයක් හේතුවක් සඳහා එකතු කර ඇත, නමුත් නිෂ්පාදනයේ කේතය පැතිකඩ කිරීමෙන් පසුව.

ප්‍රශස්තකරණයේ ප්‍රධාන රීතිය මෙයයි - මෙහි බාධාවක් ඇති වේ යැයි උපකල්පනය කරමින් ප්‍රශස්තිකරණය එක් නොකරන්න, මන්ද එහි බාධාවක් නොමැති බව පෙනී යා හැකි බැවිනි. ප්‍රශස්තකරණය සාමාන්‍යයෙන් කේතයේ ගුණාත්මක භාවය අඩු කරයි. එමනිසා, එය ප්‍රශස්ත කිරීම වටී පැතිකඩ කිරීමෙන් පසුව සහ වඩාත් සුදුසු නිෂ්පාදනයේදී, මෙය සැබෑ දත්ත වේ. යමෙකු කැමති නම්, ඔබට VictoriaMetrics මූලාශ්‍ර කේතය දෙස බලා එහි ඇති අනෙකුත් ප්‍රශස්තිකරණයන් ගවේෂණය කළ හැකිය.

මට bitset ගැන ප්‍රශ්නයක් තියෙනවා. C++ දෛශික බූල් ක්‍රියාවට නැංවීම, ප්‍රශස්ත බිටු කට්ටලයට බෙහෙවින් සමාන ය. ක්‍රියාත්මක කිරීම එතනින් ගත්තද?

නෑ එතනින් නෙවෙයි. මෙම බිට්සෙට් එක ක්‍රියාවට නංවන විට, වික්ටෝරියා මෙට්‍රික්ස් හි භාවිතා වන මෙම අයිඩී කාලමාලාවල ව්‍යුහය පිළිබඳ දැනුමෙන් මා මෙහෙයවන ලදී. තවද ඒවායේ ව්‍යුහය ඉහළ බිටු 32 මූලික වශයෙන් නියත වන පරිදි වේ. පහළ බිටු 32 වෙනස් වීමට යටත් වේ. බිට් එක අඩු වන තරමට එය බොහෝ විට වෙනස් විය හැකිය. එබැවින්, මෙම දත්ත ව්‍යුහය සඳහා මෙම ක්‍රියාත්මක කිරීම විශේෂයෙන් ප්‍රශස්ත කර ඇත. C++ ක්‍රියාත්මක කිරීම, මා දන්නා පරිදි, සාමාන්‍ය අවස්ථාව සඳහා ප්‍රශස්ත කර ඇත. ඔබ සාමාන්‍ය නඩුව සඳහා ප්‍රශස්ත කරන්නේ නම්, මෙයින් අදහස් කරන්නේ එය විශේෂිත නඩුවක් සඳහා වඩාත්ම ප්‍රශස්ත නොවන බවයි.

ඇලෙක්සි මිලොවිඩ්ගේ වාර්තාව නැරඹීමට ද මම ඔබට උපදෙස් දෙමි. මාසයකට පමණ පෙර, ඔහු විශේෂිත විශේෂීකරණයන් සඳහා ClickHouse හි ප්රශස්තකරණය ගැන කතා කළේය. ඔහු පවසන්නේ සාමාන්‍ය නඩුවේදී, C++ ක්‍රියාත්මක කිරීමක් හෝ වෙනත් ක්‍රියාත්මක කිරීමක් රෝහලක සාමාන්‍යයෙන් හොඳින් ක්‍රියාත්මක වන පරිදි සකස් කර ඇති බවයි. එය අපගේ වැනි දැනුම-විශේෂිත ක්‍රියාත්මක කිරීමකට වඩා නරක ලෙස ක්‍රියා කරයි, එහිදී ඉහළම බිටු 32 බොහෝ දුරට නියත බව අපි දනිමු.

මට දෙවන ප්‍රශ්නය ඇත. InfluxDB වෙතින් මූලික වෙනස කුමක්ද?

බොහෝ මූලික වෙනස්කම් තිබේ. කාර්ය සාධනය සහ මතක පරිභෝජනය සම්බන්ධයෙන් ගත් කල, පරීක්ෂණ වලදී InfluxDB අධි කාර්ඩිනලිටි කාල ශ්‍රේණි සඳහා 10 ගුණයකින් වැඩි මතක පරිභෝජනයක් පෙන්වයි, ඔබට ඒවායින් බොහොමයක් ඇති විට, උදාහරණයක් ලෙස මිලියන ගණනක්. උදාහරණයක් ලෙස, VictoriaMetrics සක්‍රීය පේළි මිලියනයකට 1 GB පරිභෝජනය කරන අතර InfluxDB 10 GB පරිභෝජනය කරයි. ඒ වගේම ඒක ලොකු වෙනසක්.

දෙවන මූලික වෙනස නම් InfluxDB හි අමුතු විමසුම් භාෂා ඇත - Flux සහ InfluxQL. හා සසඳන විට කාල ශ්‍රේණි සමඟ වැඩ කිරීම සඳහා ඒවා එතරම් පහසු නැත PromQL, VictoriaMetrics විසින් සහාය දක්වයි. PromQL යනු Prometheus වෙතින් විමසුම් භාෂාවකි.

තවත් එක් වෙනසක් නම්, InfluxDB හි තරමක් අමුතු දත්ත ආකෘතියක් ඇති අතර, එක් එක් පේළියට විවිධ ටැග් කට්ටලයක් සහිත ක්ෂේත්‍ර කිහිපයක් ගබඩා කළ හැකිය. මෙම රේඛා තවදුරටත් විවිධ වගු වලට බෙදා ඇත. මෙම අතිරේක සංකූලතා මෙම දත්ත සමුදාය සමඟ පසුකාලීන වැඩ සංකීර්ණ කරයි. සහයෝගය දැක්වීමට සහ තේරුම් ගැනීමට අපහසුය.

VictoriaMetrics හි සෑම දෙයක්ම වඩා සරල ය. එහිදී, සෑම කාල ශ්‍රේණියක්ම ප්‍රධාන අගයකි. අගය ලකුණු සමූහයකි - (timestamp, value), සහ යතුර කට්ටලයයි label=value. ක්ෂේත්ර සහ මිනුම් අතර වෙනසක් නොමැත. විවිධ පේළි අතර ගණනය කිරීම් තවමත් මා දන්නා පරිදි ක්‍රියාත්මක නොවන InfluxDB මෙන් නොව ඕනෑම දත්තයක් තෝරාගෙන පසුව ඒකාබද්ධ කිරීමට, එකතු කිරීමට, අඩු කිරීමට, ගුණ කිරීමට, බෙදීමට එය ඔබට ඉඩ සලසයි. ඒවා ක්‍රියාත්මක කලත් අමාරුයි, ගොඩක් code ලියන්න වෙනවා.

මට පැහැදිලි ප්‍රශ්නයක් තියෙනවා. ඔබ කතා කළ යම් ආකාරයක ගැටලුවක් ඇති බව මට නිවැරදිව වැටහුණාද, මෙම ප්‍රතිලෝම දර්ශකය මතකයට නොගැලපේ, එබැවින් එහි කොටස් කිරීම තිබේද?

පළමුව, මම සම්මත Go සිතියමක් මත ප්‍රතිලෝම දර්ශකයක් බොළඳ ක්‍රියාත්මක කිරීමක් පෙන්නුම් කළෙමි. මෙම ක්‍රියාත්මක කිරීම දත්ත සමුදායන් සඳහා සුදුසු නොවේ, මන්ද මෙම ප්‍රතිලෝම දර්ශකය තැටියට සුරැකෙන්නේ නැති අතර, දත්ත සමුදාය තැටියට සුරැකිය යුතු අතර එමඟින් මෙම දත්ත නැවත ආරම්භ කිරීමේදී පවතිනු ඇත. මෙම ක්‍රියාත්මක කිරීමේදී, ඔබ යෙදුම නැවත ආරම්භ කරන විට, ඔබේ ප්‍රතිලෝම දර්ශකය අතුරුදහන් වනු ඇත. තවද ඔබට එය සොයා ගැනීමට නොහැකි වීම නිසා ඔබට සියලු දත්ත වෙත ප්‍රවේශය අහිමි වනු ඇත.

ආයුබෝවන්! වාර්තාවට ස්තූතියි! මගේ නම පාවෙල්. මම වයිල්ඩ්බෙරි වලින්. මට ඔබගෙන් ප්‍රශ්න කිහිපයක් තිබේ. එක ප්‍රශ්නය. ඔබගේ යෙදුමේ ගෘහ නිර්මාණ ශිල්පය ගොඩනඟන විට ඔබ වෙනත් මූලධර්මයක් තෝරාගෙන කාලයත් සමඟ දත්ත කොටස් කර ඇත්නම්, සමහර විට ඔබට සෙවීමේදී දත්ත ඡේදනය කිරීමට හැකි වනු ඇතැයි ඔබ සිතනවාද, එක් කොටසක එකකට දත්ත අඩංගු වේ යන කාරණය මත පදනම්ව කාල සීමාව, එනම්, එක් කාල පරතරයකින් සහ ඔබේ කෑලි වෙනස් ලෙස විසිරී ඇති බව ගැන ඔබට කරදර විය යුතු නොවේද? ප්‍රශ්න අංක 2 - ඔබ බිට්සෙට් සහ අනෙකුත් සියල්ල සමඟ සමාන ඇල්ගොරිතමයක් ක්‍රියාත්මක කරන බැවින්, සමහර විට ඔබ ප්‍රොසෙසර උපදෙස් භාවිතා කිරීමට උත්සාහ කර තිබේද? සමහර විට ඔබ එවැනි ප්‍රශස්තිකරණයන් උත්සාහ කර තිබේද?

මම දෙවැන්නට වහාම පිළිතුරු දෙන්නෙමි. අපි තවම ඒ තත්ත්වයට ඇවිත් නැහැ. නමුත් අවශ්‍ය නම් අපි එතනට එනවා. සහ පළමු එක, ප්රශ්නය කුමක්ද?

ඔබ අවස්ථා දෙකක් සාකච්ඡා කළා. ඔවුන් පැවසුවේ වඩාත් සංකීර්ණ ක්‍රියාත්මක කිරීමක් සමඟ ඔවුන් දෙවැන්න තෝරා ගත් බවයි. තවද ඔවුන් පළමු එකට කැමති නැත, එහිදී දත්ත කාලය අනුව කොටස් කර ඇත.

ඔව්. පළමු අවස්ථාවේ දී, දර්ශකයේ මුළු පරිමාව විශාල වනු ඇත, මන්ද එක් එක් කොටස තුළ මෙම සියලු කොටස් හරහා අඛණ්ඩව පවතින එම කාල ශ්‍රේණි සඳහා අනුපිටපත් දත්ත ගබඩා කිරීමට අපට සිදුවනු ඇත. තවද ඔබේ කාල ශ්‍රේණියේ චූන් අනුපාතය කුඩා නම්, එනම් එකම ශ්‍රේණිය නිරන්තරයෙන් භාවිතා කරන්නේ නම්, පළමු අවස්ථාවෙහිදී දෙවන අවස්ථාවට සාපේක්ෂව අල්ලාගෙන ඇති තැටි ඉඩ ප්‍රමාණයෙන් අපට බොහෝ දේ අහිමි වනු ඇත.

ඉතින් - ඔව්, කාල බෙදීම හොඳ විකල්පයකි. Prometheus එය භාවිතා කරයි. නමුත් ප්‍රොමිතියස්ට තවත් අඩුපාඩුවක් තිබේ. මෙම දත්ත කොටස් ඒකාබද්ධ කරන විට, එය සියලුම ලේබල සහ කාල මාලා සඳහා මතක මෙටා තොරතුරු තබා ගැනීමට අවශ්‍ය වේ. එබැවින්, එය ඒකාබද්ධ කරන දත්ත කැබලි විශාල නම්, VictoriaMetrics මෙන් නොව, ඒකාබද්ධ කිරීමේදී මතක පරිභෝජනය බෙහෙවින් වැඩි වේ. ඒකාබද්ධ කිරීමේදී, VictoriaMetrics මතකය කිසිසේත් පරිභෝජනය නොකරයි; ඒකාබද්ධ කළ දත්ත කොටස්වල ප්‍රමාණය නොසලකා කිලෝබයිට් කිහිපයක් පමණක් පරිභෝජනය කරයි.

ඔබ භාවිතා කරන ඇල්ගොරිතම මතකය භාවිතා කරයි. එය අගයන් අඩංගු වේලා මාලා ටැග් සලකුණු කරයි. තවද මේ ආකාරයෙන් ඔබ එක් දත්ත අරාවක සහ තවත් එකක යුගලනය වී ඇත්දැයි පරීක්ෂා කරයි. ඡේදනය සිදු වූවාද නැද්ද යන්න ඔබට වැටහේ. සාමාන්‍යයෙන්, දත්ත සමුදායන් කර්සර සහ පුනරාවර්තක ක්‍රියාවට නංවන අතර ඒවායේ වත්මන් අන්තර්ගතය ගබඩා කර මෙම මෙහෙයුම්වල සරල සංකීර්ණත්වය හේතුවෙන් වර්ග කළ දත්ත හරහා ක්‍රියාත්මක වේ.

දත්ත ගමන් කිරීමට අපි කර්සර භාවිතා නොකරන්නේ ඇයි?

ඔව්.

අපි වර්ග කළ පේළි LevelDB හෝ mergeset තුළ ගබඩා කරමු. අපට කර්සරය ගෙන ගොස් මංසන්ධිය සොයාගත හැකිය. ඇයි අපි එය භාවිතා නොකරන්නේ? මන්ද එය මන්දගාමී වේ. මක්නිසාද යත් කර්සරය යන්නෙන් අදහස් කරන්නේ ඔබ එක් එක් පේළිය සඳහා ශ්‍රිතයක් ඇමතීමට අවශ්‍ය බවයි. කාර්යය ඇමතුමක් නැනෝ තත්පර 5 කි. ඔබට රේඛා 100 ක් තිබේ නම්, අපි තත්පර භාගයක් ශ්‍රිතය ඇමතීමට ගත කරන බව පෙනේ.

එහෙම දෙයක් තියෙනවා, ඔව්. සහ මගේ අවසාන ප්‍රශ්නය. ප්රශ්නය ටිකක් අමුතු දෙයක් විය හැක. දත්ත පැමිණෙන මොහොතේ අවශ්‍ය සියලුම එකතු කිරීම් කියවා අවශ්‍ය පෝරමයේ සුරැකීමට නොහැකි වන්නේ ඇයි? VictoriaMetrics, ClickHouse, වැනි සමහර පද්ධතිවල විශාල වෙළුම් ඉතිරි කර ඒවා සඳහා වැඩි කාලයක් ගත කරන්නේ ඇයි?

එය වඩාත් පැහැදිලි කිරීමට මම උදාහරණයක් දෙන්නම්. අපි කියමු පොඩි සෙල්ලම් ස්පීඩෝමීටරයක් ​​වැඩ කරන්නේ කොහොමද කියලා? එය ඔබ ගමන් කළ දුර සටහන් කරයි, සෑම විටම එය එක් අගයකට එකතු කරයි, සහ දෙවන - කාලය. සහ බෙදයි. සහ සාමාන්ය වේගයක් ලබා ගනී. ඔබට එකම දේ ගැන කළ හැකිය. පියාසර කරන විට අවශ්ය සියලු කරුණු එකතු කරන්න.

හරි, මට ප්‍රශ්නය තේරෙනවා. ඔබේ ආදර්ශයට එහි තැනක් තිබේ. ඔබට අවශ්‍ය එකතු කිරීම් මොනවාදැයි ඔබ දන්නේ නම්, මෙය හොඳම ක්‍රියාත්මක කිරීම වේ. නමුත් ගැටළුව වන්නේ මිනිසුන් මෙම ප්‍රමිතික, ක්ලික්හවුස් හි සමහර දත්ත සුරකින අතර අනාගතයේදී ඒවා එකතු කර පෙරහන් කරන්නේ කෙසේදැයි ඔවුන් තවමත් නොදැන සිටීමයි, එබැවින් ඔවුන්ට සියලුම අමු දත්ත සුරැකීමට සිදුවේ. නමුත් ඔබට සාමාන්‍යයෙන් යමක් ගණනය කළ යුතු බව ඔබ දන්නේ නම්, අමු අගයන් පොකුරක් එහි ගබඩා කිරීම වෙනුවට එය ගණනය නොකරන්නේ මන්ද? නමුත් මෙය ඔබට අවශ්ය දේ හරියටම දන්නේ නම් පමණි.

මාර්ගය වන විට, කාල ශ්‍රේණි ගබඩා කිරීම සඳහා දත්ත සමුදායන් සමස්ථ ගණන් කිරීමට සහාය වේ. උදාහරණයක් ලෙස, Prometheus සහාය දක්වයි පටිගත කිරීමේ නීති. එනම්, ඔබට අවශ්ය වන ඒකක මොනවාදැයි ඔබ දන්නේ නම් මෙය කළ හැකිය. VictoriaMetrics සතුව මෙය තවමත් නොමැත, නමුත් එය සාමාන්‍යයෙන් ප්‍රොමිතියස් විසින් පෙර කරනු ලබන අතර, මෙය නැවත කේතනය කිරීමේ රීති වල සිදු කළ හැක.

උදාහරණයක් ලෙස, මගේ පෙර රැකියාවේදී මට පසුගිය පැය තුළ ස්ලයිඩින් කවුළුවක සිදුවීම් ගණන ගණන් කිරීමට අවශ්‍ය විය. ගැටලුව වන්නේ මට Go හි අභිරුචි ක්‍රියාත්මක කිරීමක්, එනම් මෙම දේ ගණන් කිරීමේ සේවාවක් කිරීමට සිදු වීමයි. ගණනය කිරීමට අපහසු නිසා මෙම සේවාව අවසානයේ සුළුපටු නොවේ. ඔබට නිශ්චිත කාල පරතරයන්හිදී සමහර සමස්ථයන් ගණන් කිරීමට අවශ්‍ය නම් ක්‍රියාත්මක කිරීම සරල විය හැක. ඔබට ස්ලයිඩින් කවුළුවක සිදුවීම් ගණන් කිරීමට අවශ්‍ය නම්, එය පෙනෙන තරම් සරල නොවේ. මම හිතන්නේ මේක තවම ClickHouse වල හෝ timeeries databases වල ක්‍රියාත්මක කරලා නෑ, මොකද මේක ක්‍රියාත්මක කරන්න අමාරුයි.

සහ තවත් එක් ප්රශ්නයක්. අපි සාමාන්‍යකරණය ගැන කතා කරමින් සිටි අතර, මට මතක වූයේ වරක් කාබන් පසුබිමක් සහිත ග්‍රැෆයිට් වැනි දෙයක් තිබූ බවයි. පැරණි දත්ත තුනී කරන්නේ කෙසේදැයි ඔහු දැන සිටියේය, එනම් විනාඩියකට එක් ලක්ෂයක්, පැයකට එක් ලක්ෂයක්, ආදිය. ප්‍රතිපත්තිමය වශයෙන්, අපට අමු දත්ත අවශ්‍ය නම්, සාපේක්ෂව කථා කළහොත්, මාසයක් සහ අනෙක් සියල්ල කළ හැකි නම් මෙය ඉතා පහසු වේ. සිහින් විය යුතුය . නමුත් Prometheus සහ VictoriaMetrics මෙම ක්‍රියාකාරීත්වයට සහය නොදක්වයි. එයට සහය දැක්වීමට සැලසුම් කර තිබේද? එසේ නොවේ නම්, එසේ නොකරන්නේ මන්ද?

ප්‍රශ්නයට ස්තූතියි. අපගේ පරිශීලකයින් මෙම ප්‍රශ්නය වරින් වර අසයි. නියැදීම සඳහා සහය එක් කරන්නේ කවදාදැයි ඔවුන් අසයි. මෙහි ගැටළු කිහිපයක් තිබේ. පළමුව, සෑම පරිශීලකයෙක්ම තේරුම් ගනී downsampling වෙනස් දෙයක්: යමෙකුට ලබා දී ඇති අන්තරයකදී ඕනෑම අත්තනෝමතික ලක්ෂ්‍යයක් ලබා ගැනීමට අවශ්‍ය වේ, යමෙකුට උපරිම, අවම, සාමාන්‍ය අගයන් අවශ්‍ය වේ. බොහෝ පද්ධති ඔබේ දත්ත ගබඩාවට දත්ත ලියන්නේ නම්, ඔබට ඒ සියල්ල එකට එකතු කළ නොහැක. එක් එක් පද්ධතියට විවිධ සිහින් වීම අවශ්ය විය හැකිය. අනික මේක ක්‍රියාත්මක කරන්න අමාරුයි.

දෙවන කරුණ නම්, ClickHouse වැනි VictoriaMetrics, අමු දත්ත විශාල ප්‍රමාණයක් මත වැඩ කිරීම සඳහා ප්‍රශස්ත කර ඇත, එබැවින් ඔබට ඔබේ පද්ධතියේ හරයන් බොහොමයක් තිබේ නම් තත්පරයකට අඩු කාලයකදී රේඛා බිලියනයක් සවලක් තැබිය හැක. VictoriaMetrics හි කාල ශ්‍රේණි ලකුණු ස්කෑන් කිරීම - හරයකට තත්පරයට ලකුණු 50. තවද මෙම කාර්ය සාධනය පවතින හරයන් වෙත පරිමාණය කරයි. එනම්, ඔබට මධ්‍ය 000 ක් තිබේ නම්, උදාහරණයක් ලෙස, ඔබ තත්පරයකට ලකුණු බිලියනයක් පරිලෝකනය කරයි. VictoriaMetrics සහ ClickHouse හි මෙම ගුණාංගය පහත වැටීමේ අවශ්‍යතාවය අඩු කරයි.

තවත් විශේෂාංගයක් වන්නේ VictoriaMetrics මෙම දත්ත ඵලදායී ලෙස සම්පීඩනය කිරීමයි. නිෂ්පාදනයේ සාමාන්යයෙන් සම්පීඩනය ලක්ෂයකට බයිට් 0,4 සිට 0,8 දක්වා වේ. සෑම ලක්ෂ්‍යයක්ම වේලා මුද්‍රාව + අගයකි. තවද එය සාමාන්‍යයෙන් එක් බයිටයකට වඩා අඩු ප්‍රමාණයකට සම්පීඩිත වේ.

සර්ජි. මට ප්රශ්ණයක් තියෙනවා. අවම පටිගත කිරීමේ කාල ක්වොන්ටම් යනු කුමක්ද?

එක් මිලි තත්පරයක්. අපි මෑතකදී වෙනත් කාල ශ්‍රේණි දත්ත සමුදා සංවර්ධකයින් සමඟ සංවාදයක් පැවැත්වුවෙමු. ඔවුන්ගේ අවම කාල පරාසය තත්පර එකකි. සහ Graphite හි, උදාහරණයක් ලෙස, එය ද එක් තත්පරයකි. OpenTSDB හි එය තත්පරයක් ද වේ. InfluxDB නැනෝ තත්පර නිරවද්‍යතාවයක් ඇත. VictoriaMetrics හි එය මිලි තත්පර එකකි, මන්ද Prometheus හි එය මිලි තත්පරයකි. VictoriaMetrics මුලින් ප්‍රොමිතියස් සඳහා දුරස්ථ ගබඩාවක් ලෙස සංවර්ධනය කරන ලදී. නමුත් දැන් එය වෙනත් පද්ධති වලින් දත්ත සුරැකිය හැක.

මා කතා කළ පුද්ගලයා පවසන්නේ ඔවුන්ට තත්පරයේ සිට තත්පරය දක්වා නිරවද්‍යතාවයක් ඇති බවයි - එය ඔවුන්ට ප්‍රමාණවත් වන්නේ එය කාල ශ්‍රේණියේ දත්ත ගබඩාවේ ගබඩා වන දත්ත වර්ගය මත රඳා පවතින බැවිනි. මෙය DevOps දත්ත හෝ යටිතල පහසුකම් වලින් දත්ත නම්, ඔබ විනාඩියකට තත්පර 30 ක කාල පරතරයකින් එය රැස් කරන්නේ නම්, දෙවන නිරවද්‍යතාවය ප්‍රමාණවත් වේ, ඔබට අඩු කිසිවක් අවශ්‍ය නොවේ. තවද ඔබ මෙම දත්ත ඉහළ සංඛ්‍යාත වෙළඳ පද්ධති වලින් එකතු කරන්නේ නම්, ඔබට නැනෝ තත්පර නිරවද්‍යතාවයක් අවශ්‍ය වේ.

VictoriaMetrics හි මිලි තත්පර නිරවද්‍යතාවය DevOps නඩුව සඳහා ද සුදුසු වන අතර, වාර්තාවේ ආරම්භයේ මා සඳහන් කළ බොහෝ අවස්ථා සඳහා සුදුසු විය හැකිය. එය නොගැලපෙන එකම දෙය අධි සංඛ්‍යාත වෙළඳ පද්ධති වේ.

ඔයාට ස්තූතියි! සහ තවත් ප්රශ්නයක්. PromQL හි ගැළපුම යනු කුමක්ද?

සම්පූර්ණ පසුගාමී අනුකූලතාව. VictoriaMetrics PromQL සඳහා පූර්ණ සහය දක්වයි. ඊට අමතරව, එය PromQL හි අතිරේක උසස් ක්‍රියාකාරීත්වයක් එක් කරයි, එය හැඳින්වේ MetricsQL. මෙම විස්තීරණ ක්‍රියාකාරීත්වය පිළිබඳව YouTube හි කතාබහක් පවතී. මම ශාන්ත පීටර්ස්බර්ග් හි වසන්තයේ නිරීක්ෂණ රැස්වීමේදී කතා කළෙමි.

ටෙලිග්‍රාම් නාලිකාව වික්ටෝරියා මෙට්රික්ස්.

සමීක්ෂණයට සහභාගී විය හැක්කේ ලියාපදිංචි පරිශීලකයින්ට පමණි. පුරන්නකරුණාකර.

Prometheus සඳහා ඔබේ දිගුකාලීන ගබඩාව ලෙස VictoriaMetrics වෙත මාරු වීමෙන් ඔබව වළක්වන්නේ කුමක්ද? (අදහස් වල ලියන්න, මම එය මත විමසුමට එකතු කරමි))

• 71,4%මම Prometheus5 භාවිතා කරන්නේ නැහැ

• 28,6%VictoriaMetrics2 ගැන දැනගෙන හිටියේ නැහැ

පරිශීලකයින් 7 දෙනෙක් ඡන්දය දුන්හ. පරිශීලකයින් 12 දෙනෙක් ඡන්දය දීමෙන් වැළකී සිටියහ.

මූලාශ්රය: www.habr.com