අපි Zabbix TimescaleDB දත්ත සමුදාය පසුබිම ලෙස ක්රියා කරන ආකාරය දෙස බලමු. අපි ඔබට මුල සිට ආරම්භ කරන්නේ කෙසේද සහ PostgreSQL වෙතින් සංක්‍රමණය කරන්නේ කෙසේදැයි පෙන්වන්නෙමු. අපි වින්යාස දෙකේ සංසන්දනාත්මක කාර්ය සාධන පරීක්ෂණ ද ලබා දෙන්නෙමු.
HighLoad++ සයිබීරියාව 2019. Tomsk ශාලාව. ජූනි 24, 16:00. මේවා සහ . මීළඟ HighLoad++ සම්මන්ත්‍රණය 6 අප්‍රේල් 7 සහ 2020 යන දිනවල ශාන්ත පීටර්ස්බර්ග්හිදී පැවැත්වේ. විස්තර සහ ටිකට්පත් .
Andrey Gushchin (මෙතැන් සිට - AG): - මම ZABBIX තාක්ෂණික සහාය ඉංජිනේරුවෙක් (මෙතැන් සිට "Zabbix" ලෙස හැඳින්වේ), පුහුණුකරුවෙක්. මම වසර 6 කට වැඩි කාලයක් තාක්ෂණික සහායක සේවය කර ඇති අතර කාර්ය සාධනය පිළිබඳ සෘජු අත්දැකීම් ඇත. සාමාන්ය PostgreSQL 10 සමඟ සසඳන විට TimescaleDB හට ලබා දිය හැකි කාර්ය සාධනය ගැන අද මම කතා කරමි. එසේම, එය පොදුවේ ක්රියා කරන ආකාරය පිළිබඳව හඳුන්වාදීමේ කොටසක්.
ඉහළම ඵලදායිතා අභියෝග: දත්ත එකතු කිරීමේ සිට දත්ත පිරිසිදු කිරීම දක්වා
ආරම්භ කිරීම සඳහා, සෑම අධීක්ෂණ පද්ධතියක්ම මුහුණ දෙන ඇතැම් කාර්ය සාධන අභියෝග තිබේ. පළමු ඵලදායිතා අභියෝගය වන්නේ දත්ත ඉක්මනින් රැස් කිරීම සහ සැකසීමයි.
හොඳ අධීක්ෂණ පද්ධතියක් ඉක්මනින්, නියමිත වේලාවට සියලු දත්ත ලබා ගත යුතුය, එය ප්‍රේරක ප්‍රකාශන අනුව ක්රියා කළ යුතුය, එනම්, එය යම් නිර්ණායක අනුව (මෙය විවිධ පද්ධතිවල වෙනස් වේ) සහ මෙම දත්ත භාවිතා කිරීම සඳහා දත්ත සමුදායක සුරැකිය යුතුය. අනාගතය.
දෙවන කාර්ය සාධන අභියෝගය වන්නේ ඉතිහාස ගබඩාවයි. බොහෝ විට දත්ත සමුදායක ගබඩා කර කාලයක් පුරා එකතු කරන ලද මෙම ප්‍රමිතික වෙත ඉක්මන් සහ පහසු ප්‍රවේශයක් ලබා ගන්න. වැදගත්ම දෙය නම් මෙම දත්ත ලබා ගැනීමට පහසු වන අතර එය වාර්තා, ප්‍රස්ථාර, ප්‍රේරක, සමහර එළිපත්ත අගයන්, ඇඟවීම් සඳහා යනාදිය භාවිතා කරයි.
තුන්වන කාර්ය සාධන අභියෝගය වන්නේ ඉතිහාසය නිෂ්කාශනය කිරීමයි, එනම්, ඔබ වසර 5ක් (මාස හෝ මාස දෙකක පවා) එකතු කර ඇති කිසිදු සවිස්තරාත්මක ප්‍රමිතික ගබඩා කිරීමට අවශ්ය නොවන ස්ථානයට පැමිණි විට. සමහර ජාල නෝඩ් මකා දමා ඇත, නැතහොත් සමහර ධාරක, ඒවා දැනටමත් යල් පැන ගිය සහ තවදුරටත් එකතු නොකරන නිසා ප්‍රමිතික තවදුරටත් අවශ්ය නොවේ. ඔබගේ දත්ත සමුදාය ඉතා විශාල නොවන පරිදි මේ සියල්ල පිරිසිදු කළ යුතුය. පොදුවේ ගත් කල, ඉතිහාසය ඉවත් කිරීම බොහෝ විට ගබඩා කිරීම සඳහා බරපතල පරීක්ෂණයකි - එය බොහෝ විට කාර්ය සාධනය කෙරෙහි ඉතා දැඩි බලපෑමක් ඇති කරයි.
හැඹිලි ගැටළු විසඳන්නේ කෙසේද?
මම දැන් Zabbix ගැන විශේෂයෙන් කතා කරන්නම්. Zabbix හි, පළමු සහ දෙවන ඇමතුම් හැඹිලිය භාවිතයෙන් විසඳනු ලැබේ.
දත්ත එකතු කිරීම සහ සැකසීම - මෙම සියලු දත්ත ගබඩා කිරීමට අපි RAM භාවිතා කරමු. මෙම දත්ත දැන් වඩාත් විස්තරාත්මකව සාකච්ඡා කරනු ඇත.
දත්ත සමුදාය පැත්තේ ප්රධාන තේරීම් සඳහා - ප්‍රස්ථාර සහ වෙනත් දේවල් සඳහා යම් හැඹිලි ඇත.
Zabbix සේවාදායකයේම පැත්තේ හැඹිලිගත කිරීම: අපට ConfigurationCache, ValueCache, HistoryCache, TrendsCache ඇත. එය කුමක්ද?
ConfigurationCache යනු අපි ප්‍රමිතික, ධාරක, දත්ත අයිතම, ප්‍රේරක ගබඩා කරන ප්රධාන හැඹිලියයි; ඔබට පෙර සැකසුම් සැකසීමට අවශ්ය සියල්ල, දත්ත රැස් කිරීම, කුමන ධාරක එකතු කළ යුතුද, කුමන සංඛ්‍යාතයකින්ද යන්න. දත්ත ගබඩාවට ගොස් අනවශ්‍ය විමසුම් ඇති නොවන පරිදි මේ සියල්ල ConfigurationCache හි ගබඩා කර ඇත. සේවාදායකය ආරම්භ වූ පසු, අපි මෙම හැඹිලිය යාවත්කාලීන කරන්නෙමු (එය සාදන්න) සහ එය වරින් වර යාවත්කාලීන කරන්න (වින්යාස සැකසුම් මත පදනම්ව).
Zabbix හි හැඹිලිගත කිරීම. දත්ත එකතුව
මෙන්න රූප සටහන තරමක් විශාලයි:
යෝජනා ක්රමයේ ප්රධාන ඒවා වන්නේ මෙම එකතු කරන්නන් ය:
මේවා එකලස් කිරීමේ ක්‍රියාවලීන්ම වේ, විවිධ වර්ගයේ එකලස් කිරීම් සඳහා වගකිව යුතු විවිධ “ඡන්ද කරුවන්”. ඔවුන් icmp, ipmi, සහ විවිධ ප්‍රොටෝකෝල හරහා දත්ත රැස් කර ඒ සියල්ල පෙර සැකසුම් වෙත මාරු කරයි.
පූර්ව සැකසුම් ඉතිහාස හැඹිලිය
ඒවගේම, අපි ගණනය කර ඇති දත්ත මූලද්‍රව්‍ය (Zabbix ගැන හුරුපුරුදු අය දන්නවා), එනම් ගණනය කළ, එකතු කිරීමේ දත්ත මූලද්‍රව්‍ය තිබේ නම්, අපි ඒවා කෙලින්ම ValueCache වෙතින් ලබා ගනිමු. පුරවන හැටි පස්සෙ කියන්නම්. මෙම සියලුම එකතුකරන්නන් ඔවුන්ගේ රැකියා ලබා ගැනීමට ConfigurationCache භාවිතා කරන අතර පසුව ඒවා පෙර සැකසුම් වෙත යොමු කරයි.
පෙර සැකසුම් පියවරයන් ලබා ගැනීමට සහ විවිධ ආකාරවලින් මෙම දත්ත සැකසීමට වින්යාස කේත භාවිතා කරයි. 4.2 අනුවාදයෙන් පටන් ගෙන, අපි එය ප්‍රොක්සි එකකට ගෙන ගොස් ඇත. මෙය ඉතා පහසු ය, මන්ද පෙර සැකසීම තරමක් අපහසු මෙහෙයුමකි. තවද ඔබට දත්ත මූලද්‍රව්‍ය විශාල සංඛ්‍යාවක් සහ ඉහළ එකතු කිරීමේ සංඛ්‍යාතයක් සහිත ඉතා විශාල Zabbix තිබේ නම්, මෙය කාර්යය බෙහෙවින් සරල කරයි.
ඒ අනුව, අපි මෙම දත්ත යම් ආකාරයකින් පෙර සැකසුම් භාවිතයෙන් සැකසූ පසු, එය තවදුරටත් සැකසීම සඳහා අපි එය HistoryCache හි සුරකිමු. මෙය දත්ත එකතු කිරීම අවසන් කරයි. අපි ප්රධාන ක්රියාවලිය වෙත යන්නෙමු.
ඉතිහාසය සමමුහුර්ත කරන්නාගේ කාර්යය
Zabbix හි ප්රධාන ක්රියාවලිය (එය මොනොලිතික් ගෘහ නිර්මාණ ශිල්පයක් බැවින්) ඉතිහාසය සමමුහුර්තකරණය වේ. එක් එක් දත්ත මූලද්‍රව්‍යයේ පරමාණුක සැකසුම් සමඟ විශේෂයෙන් කටයුතු කරන ප්රධාන ක්රියාවලිය මෙයයි, එනම් එක් එක් අගය:
- අගය පැමිණේ (එය එය HistoryCache වෙතින් ලබා ගනී);
- වින්යාස සමමුහුර්තකරණයේ චෙක්පත්: ගණනය කිරීම සඳහා කිසියම් ප්‍රේරක තිබේද - ඒවා ගණනය කරයි;
තිබේ නම් - වින්‍යාසය අනුව අවශ්ය නම්, අනතුරු ඇඟවීමක් නිර්මාණය කිරීම සඳහා සිදුවීම් නිර්මාණය කරයි, උත්සන්න කරයි; - පසුව සැකසීම, එකතු කිරීම සඳහා වාර්තා අවුලුවාලීම; ඔබ අවසන් පැය සහ යනාදිය එකතු කළහොත්, ඉතිහාස වගුවට නොයන ලෙස මෙම අගය ValueCache විසින් මතක තබා ගනී; මේ අනුව, ප්‍රේරක, ගණනය කළ මූලද්‍රව්‍ය ආදිය ගණනය කිරීමට අවශ්ය අවශ්ය දත්ත වලින් ValueCache පිරී ඇත.
- එවිට ඉතිහාස සමමුහුර්තකය සියලු දත්ත දත්ත ගබඩාවට ලියයි;
- දත්ත සමුදාය ඒවා තැටියට ලියයි - සැකසුම් ක්රියාවලිය අවසන් වන්නේ මෙහිදීය.
දත්ත සමුදාය. හැඹිලිගත කිරීම
දත්ත සමුදාය පැත්තෙන්, ඔබට සිදුවීම් පිළිබඳ ප්‍රස්තාර හෝ සමහර වාර්තා බැලීමට අවශ්ය වූ විට, විවිධ හැඹිලි ඇත. නමුත් මේ වාර්තාවේ මම ඒවා ගැන කතා කරන්නේ නැහැ.
MySQL සඳහා Innodb_buffer_pool ඇත, සහ වින්යාස කළ හැකි විවිධ හැඹිලි සමූහයක් ද ඇත.
නමුත් මේවා ප්රධාන ඒවා වේ:
- හවුල්_බෆර්;
- ඵලදායී_හැඹිලි_ප්‍රමාණය;
- හවුල්_සංචිතය.
සියලුම දත්ත සමුදායන් සඳහා, විමසුම් සඳහා බොහෝ විට අවශ්ය දත්ත RAM හි ගබඩා කිරීමට ඔබට ඉඩ සලසන ඇතැම් හැඹිලි ඇති බව මම කීවෙමි. මේ සඳහා ඔවුන්ට ඔවුන්ගේම තාක්ෂණයන් ඇත.
දත්ත සමුදායේ කාර්ය සාධනය ගැන
ඒ අනුව, තරඟකාරී පරිසරයක් ඇත, එනම් Zabbix සේවාදායකය දත්ත රැස් කර එය වාර්තා කරයි. නැවත ආරම්භ කරන විට, එය ValueCache පිරවීම සඳහා ඉතිහාසයෙන් ද කියවයි. මෙහිදී ඔබට වෙබ් අතුරු මුහුණතක් මත ගොඩනගා ඇති Zabbix API භාවිතා කරන ස්ක්‍රිප්ට් සහ වාර්තා ලබා ගත හැක. Zabbix API දත්ත සමුදායට ඇතුළු වන අතර ප්‍රස්තාර, වාර්තා හෝ යම් ආකාරයක සිදුවීම් ලැයිස්තුවක්, මෑත කාලීන ගැටළු ලබා ගැනීමට අවශ්ය දත්ත ලබා ගනී.
අපගේ පරිශීලකයින් භාවිතා කරන ග්‍රැෆානා ද ඉතා ජනප්‍රිය දෘශ්‍යකරණ විසඳුමකි. Zabbix API හරහා සහ දත්ත සමුදාය හරහා සෘජුවම ලොග් වීමට හැකියාව ඇත. එය දත්ත ලබා ගැනීම සඳහා යම් තරඟයක් ද නිර්මාණය කරයි: ප්‍රතිඵල සහ පරීක්ෂණ වේගවත් බෙදා හැරීමට අනුකූල වීමට දත්ත සමුදායේ සියුම්, වඩා හොඳ සුසර කිරීමක් අවශ්ය වේ.
ඉතිහාසය හිස් කිරීම. Zabbix හි ගෘහ සේවිකාවක් සිටී
Zabbix හි භාවිතා වන තුන්වන ඇමතුම ගෘහ පාලකය භාවිතයෙන් ඉතිහාසය ඉවත් කිරීමයි. ගෘහ සේවිකාව සියලු සැකසුම් අනුගමනය කරයි, එනම්, අපගේ දත්ත මූලද්‍රව්‍ය මඟින් කොපමණ කාලයක් ගබඩා කළ යුතුද (දිනවලින්), ප්රවණතා ගබඩා කළ යුතු කාලය සහ වෙනස්වීම්වල ගතිකත්වය දක්වයි.
අපි පියාසර කරන විට ගණනය කරන TrendCache ගැන මම කතා කළේ නැත: දත්ත පැමිණේ, අපි එය පැයක් සඳහා එකතු කරමු (බොහෝ විට මේවා අවසාන පැය සඳහා සංඛ්‍යා වේ), ප්‍රමාණය සාමාන්ය/අවම වන අතර අපි එය පැයකට වරක් සටහන් කරමු වෙනස්කම් වල ගතිකත්වය පිළිබඳ වගුව ("ප්රවණතා") . "ගෘහපාලකයා" සෑම විටම ඵලදායී නොවන නිතිපතා තේරීම් භාවිතයෙන් දත්ත සමුදායෙන් දත්ත ආරම්භ කර මකා දමයි.
එය අකාර්යක්ෂම බව තේරුම් ගන්නේ කෙසේද? අභ්‍යන්තර ක්‍රියාවලිවල කාර්ය සාධන ප්‍රස්ථාරවල ඔබට පහත පින්තූරය දැකිය හැකිය:
ඔබගේ ඉතිහාස සමමුහුර්තකය නිරන්තරයෙන් කාර්යබහුලයි (රතු ප්‍රස්තාරය). සහ ඉහළට යන "රතු" ප්රස්ථාරය. මෙය "ගෘහපාලකයෙක්" වන අතර එය දත්ත සමුදාය විසින් නියම කර ඇති සියලුම පේළි මකා දැමීමට බලා සිටියි.
අපි අයිතම හැඳුනුම්පතක් ගනිමු: ඔබට අවසන් 5 දහස මකා දැමිය යුතුය; ඇත්ත වශයෙන්ම, දර්ශක මගින්. නමුත් සාමාන්යයෙන් දත්ත කට්ටලය තරමක් විශාලයි - දත්ත සමුදාය තවමත් එය තැටියෙන් කියවා එය හැඹිලියට තබයි, මෙය දත්ත සමුදාය සඳහා ඉතා මිල අධික මෙහෙයුමකි. එහි විශාලත්වය අනුව, මෙය ඇතැම් කාර්ය සාධන ගැටළු වලට හේතු විය හැක.
ඔබට සරල ආකාරයකින් Housekeeper අක්‍රිය කළ හැකිය - අපට හුරුපුරුදු වෙබ් අතුරු මුහුණතක් ඇත. පරිපාලන සාමාන්‍යයේ සිටුවම් ("ගෘහපාලකයා" සඳහා වූ සැකසුම්) අපි අභ්‍යන්තර ඉතිහාසය සහ ප්රවණතා සඳහා අභ්‍යන්තර ගෘහ පාලනය අක්‍රිය කරමු. ඒ අනුව, ගෘහ පාලකයා තවදුරටත් මෙය පාලනය නොකරයි:
ඔබට ඊළඟට කුමක් කළ හැකිද? ඔබ එය ක්රියා විරහිත කර ඇත, ඔබගේ ප්‍රස්ථාර සමතලා වී ඇත... මෙම නඩුවේදී මතු විය හැකි තවත් ගැටළු මොනවාද? උපකාර කළ හැක්කේ කුමක්ද?
කොටස් කිරීම (කොටස් කිරීම)
සාමාන්යයෙන් මෙය මා ලැයිස්තුගත කර ඇති එක් එක් සම්බන්ධතා දත්ත සමුදාය මත වෙනස් ආකාරයකින් වින්යාස කර ඇත. MySQL සතුව තමන්ගේම තාක්ෂණයක් ඇත. නමුත් PostgreSQL 10 සහ MySQL සම්බන්ධයෙන් ගත් කල, සමස්තයක් වශයෙන් ඒවා බොහෝ දුරට සමාන වේ. ඇත්ත වශයෙන්ම, ඒ සියල්ල ක්රියාත්මක කරන ආකාරය සහ ඒ සියල්ල කාර්ය සාධනයට බලපාන ආකාරය පිළිබඳ අභ්‍යන්තර වෙනස්කම් රාශියක් ඇත. නමුත් පොදුවේ ගත් කල, නව කොටසක් නිර්මාණය කිරීම බොහෝ විට යම් යම් ගැටළු වලට තුඩු දෙයි.
ඔබගේ සැකසුම මත පදනම්ව (ඔබ එක් දිනක් තුළ කොපමණ දත්ත නිර්මාණය කරයිද), ඔවුන් සාමාන්යයෙන් අවමය සකසයි - මෙය දින 1 / කණ්ඩායම, සහ "ප්රවණතා" සඳහා, වෙනස්වීම් වල ගතිකත්වය - මාස 1 / නව කණ්ඩායම. ඔබට ඉතා විශාල සැකසුමක් තිබේ නම් මෙය වෙනස් විය හැක.
සැකසුමේ ප්‍රමාණය ගැන අපි වහාම කියමු: තත්පරයකට නව අගයන් 5 දහසක් දක්වා (ඊනියා nvps) - මෙය කුඩා “සැකසීමක්” ලෙස සලකනු ලැබේ. සාමාන්‍යය - තත්පරයකට අගයන් 5 සිට 25 දහසක් දක්වා. ඉහත ඇති සියල්ල දැනටමත් විශාල සහ ඉතා විශාල ස්ථාපනයන් වන අතර දත්ත සමුදායේ ඉතා ප්රවේශමෙන් වින්යාස කිරීම අවශ්ය වේ.
ඉතා විශාල ස්ථාපනයන්හිදී, දින 1 ප්රශස්ත නොවිය හැක. මම පුද්ගලිකව MySQL හි දිනකට ගිගාබයිට් 40 ක කොටස් දැක ඇත්තෙමි (සහ තවත් තිබිය හැක). මෙය ඉතා විශාල දත්ත ප්‍රමාණයක් වන අතර, සමහර ගැටලු ඇති විය හැක. ඒක අඩු කරන්න ඕන.
ඔබට කොටස් කිරීම අවශ්ය වන්නේ ඇයි?
කොටස් කිරීම සපයන්නේ, මම හිතන්නේ හැමෝම දන්නවා, වගු කොටස් කිරීම. බොහෝ විට මේවා තැටියේ සහ span ඉල්ලීම්වල වෙනම ගොනු වේ. එය සාමාන්ය කොටස් කිරීමේ කොටසක් නම් එය වඩාත් ප්රශස්ත ලෙස එක් කොටසක් තෝරා ගනී.
Zabbix සඳහා, විශේෂයෙන්ම, එය පරාසය අනුව, පරාසය අනුව, එනම්, අපි කාල මුද්රාවක් භාවිතා කරයි (සාමාන්ය අංකයක්, යුගයේ ආරම්භයේ සිට කාලය). ඔබ දවසේ ආරම්භය/දවසේ අවසානය සඳහන් කරයි, මෙය කොටසයි. ඒ අනුව, ඔබ දින දෙකක් පැරණි දත්ත ඉල්ලන්නේ නම්, දත්ත සමුදායෙන් සියල්ල වේගයෙන් ලබා ගනී, මන්ද ඔබට අවශ්ය වන්නේ එක් ගොනුවක් පමණක් හැඹිලියට පටවා එය ආපසු ලබා දීමයි (විශාල වගුවකට වඩා).
බොහෝ දත්ත සමුදායන් ඇතුළත් කිරීම වේගවත් කරයි (එක් ළමා වගුවකට ඇතුළු කිරීම). මම දැනට කතා කරන්නේ වියුක්තව, නමුත් මෙය ද හැකි ය. කොටස් කිරීම බොහෝ විට උපකාරී වේ.
NoSQL සඳහා ඉලාස්ටික් සෙවුම්
මෑතකදී, 3.4 හි, අපි NoSQL විසඳුමක් ක්රියාත්මක කළා. Elasticsearch හි ලිවීමේ හැකියාව එක් කරන ලදී. ඔබට ඇතැම් වර්ග ලිවිය හැකිය: ඔබ තෝරාගන්න - අංක ලියන්න හෝ සමහර සංඥා; අපට string text ඇත, ඔබට Elasticsearch වෙත ලඝු-සටහන් ලිවිය හැක... ඒ අනුව, වෙබ් අතුරු මුහුණත Elasticsearch වෙතද ප්‍රවේශ වනු ඇත. මෙය සමහර අවස්ථාවලදී විශිෂ්ට ලෙස ක්රියා කරයි, නමුත් මේ මොහොතේ එය භාවිතා කළ හැකිය.
කාල පරාසයDB. හයිපර්ටබල්
4.4.2 සඳහා අපි TimescaleDB වැනි එක දෙයකට අවධානය යොමු කළෙමු. එය කුමක්ද? මෙය PostgreSQL සඳහා දිගුවකි, එනම් එයට ස්වදේශීය PostgreSQL අතුරු මුහුණතක් ඇත. තවද, මෙම දිගුව ඔබට කාලානුරූප දත්ත සමඟ වඩාත් කාර්යක්ෂමව වැඩ කිරීමට සහ ස්වයංක්‍රීය කොටස් කිරීමට ඉඩ සලසයි. එය පෙනෙන්නේ කෙසේද:
මෙය අධි වගුවකි - Timescale හි එවැනි සංකල්පයක් තිබේ. මෙය ඔබ විසින් නිර්මාණය කරන ලද අධි වගුවක් වන අතර එහි කුට්ටි අඩංගු වේ. කුට්ටි යනු කොටස් වේ, මේවා ළමා වගු වේ, මම වරදවා වටහා නොගත්තොත්. එය ඇත්තෙන්ම ඵලදායී වේ.
TimescaleDB සහ PostgreSQL
TimescaleDB නිෂ්පාදකයින් සහතික කරන පරිදි, ඔවුන් විමසුම් සැකසීම සඳහා වඩාත් නිවැරදි ඇල්ගොරිතමයක් භාවිතා කරයි, විශේෂයෙන් ඇතුළත් කිරීම්, එමඟින් දත්ත කට්ටල ඇතුළු කිරීමේ ප්‍රමාණය වැඩි වීමත් සමඟ ආසන්න වශයෙන් නියත කාර්ය සාධනයක් ලබා ගැනීමට ඔවුන්ට ඉඩ සලසයි. එනම්, පෝස්ට්ග්‍රෙස් පේළි මිලියන 200 කට පසු, සාමාන්ය එක බොහෝ සෙයින් පහත වැටීමට පටන් ගන්නා අතර කාර්ය සාධනය වචනාර්ථයෙන් ශුන්‍යයට අහිමි වන අතර, ටයිම්ස්කේල් ඔබට ඕනෑම දත්ත ප්‍රමාණයක් සමඟ හැකිතාක් කාර්යක්ෂමව ඇතුළත් කිරීම් ඇතුළත් කිරීමට ඉඩ සලසයි.
TimescaleDB ස්ථාපනය කරන්නේ කෙසේද? ඒක සරලයි!
එය ලේඛනගතව ඇත, එය විස්තර කර ඇත - ඔබට ඕනෑම පැකේජයකින් එය ස්ථාපනය කළ හැකිය ... එය නිල Postgres පැකේජ මත රඳා පවතී. අතින් සම්පාදනය කළ හැක. දත්ත සමුදාය සඳහා මට සම්පාදනය කිරීමට සිදු විය.
Zabbix හි අපි හුදෙක් දිගුව සක්‍රිය කරමු. මම හිතන්නේ Postgres වල Extention පාවිච්චි කරපු අය... ඔයා සරලවම Extention ඇක්ටිවේට් කරලා, ඔයා පාවිච්චි කරන Zabbix දත්ත සමුදාය සඳහා එය නිර්මාණය කරන්න.
සහ අවසාන පියවර ...
කාල පරාසයDB. ඉතිහාස වගු සංක්‍රමණය
ඔබ අධි වගුවක් සෑදිය යුතුය. මේ සඳහා විශේෂ කාර්යයක් ඇත - hypertable සාදන්න. එහි, පළමු පරාමිතිය වන්නේ මෙම දත්ත සමුදායේ අවශ්ය වන වගුවයි (ඒ සඳහා ඔබට අධි වගුවක් සෑදිය යුතුය).
නිර්මාණය කළ යුතු ක්ෂේත්‍රය, සහ chunk_time_interval (මෙය කුට්ටිවල (භාවිතා කළ යුතු කොටස්) පරතරයයි. 86 යනු එක් දිනකි.
Migrate_data පරාමිතිය: ඔබ සත්‍ය වෙත ඇතුළු කළහොත්, මෙය දැනට පවතින සියලුම දත්ත පෙර-සාදන ලද කුට්ටි වෙත සංක්‍රමණය කරයි.
මම migrate_data භාවිතා කර ඇත - ඔබේ දත්ත සමුදාය කොතරම් විශාලද යන්න මත පදනම්ව එයට සාධාරණ කාලයක් ගතවේ. මට ටෙරාබයිට් එකකට වඩා තිබුණා - එය නිර්මාණය කිරීමට පැයකට වඩා ගත විය. සමහර අවස්ථාවලදී, පරීක්ෂා කිරීමේදී, මම ඒවා මාරු නොකිරීමට පෙළ (history_text) සහ string (history_str) සඳහා ඓතිහාසික දත්ත මකා දැමුවෙමි - ඒවා මට ඇත්තෙන්ම සිත්ගන්නා සුළු නොවීය.
තවද අපි අපගේ db_extention හි අවසාන යාවත්කාලීනය සිදු කරමු: දත්ත සමුදාය සහ විශේෂයෙන්ම අපගේ Zabbix හට db_extention ඇති බව අවබෝධ වන පරිදි අපි timescaledb ස්ථාපනය කරමු. ඔහු එය සක්‍රිය කර, TimescaleDB සඳහා අවශ්ය එම "විශේෂාංග" භාවිතා කරමින් දත්ත සමුදායට නිවැරදි වාක්‍ය ඛණ්ඩය සහ විමසුම් භාවිතා කරයි.
සේවාදායක වින්‍යාසය
මම සර්වර් දෙකක් පාවිච්චි කළා. පළමු සේවාදායකය තරමක් කුඩා අතථ්‍ය යන්ත්‍රයක්, ප්‍රොසෙසර 20 ක්, ගිගාබයිට් 16 ක RAM වේ. මම එය මත Postgres 10.8 වින්යාස කළෙමි:
මෙහෙයුම් පද්ධතිය Debian විය, ගොනු පද්ධතිය xfs විය. මෙම විශේෂිත දත්ත සමුදාය භාවිතා කිරීමට මම අවම සැකසුම් සකස් කළෙමි, Zabbix විසින්ම භාවිතා කරන දේ අඩු කළෙමි. එම යන්ත්‍රයේම Zabbix සේවාදායකයක්, PostgreSQL සහ load agents විය.
මම ඉක්මනින් වෙනස් ප්‍රතිඵල උත්පාදනය කිරීමට LoadableModule භාවිතා කරන ක්‍රියාකාරී නියෝජිතයන් 50ක් භාවිතා කර ඇත. ඔවුන් තමයි නූල්, ඉලක්කම් ආදිය ජනනය කළේ. මම database එක ගොඩක් data වලින් පිරෙව්වා. මුලදී, වින්‍යාසයෙහි එක් ධාරකයකට දත්ත මූලද්‍රව්‍ය 5 දහසක් අඩංගු වූ අතර, දළ වශයෙන් සෑම දත්ත මූලද්‍රව්‍යයක්ම ප්‍රේරකයක් අඩංගු විය - මෙය සැබෑ සැකසුම සඳහා. සමහර විට ඔබට භාවිතා කිරීමට ප්‍රේරක එකකට වඩා අවශ්ය වේ.
මම නියෝජිතයන් 50 ක් (තවත් එකතු කිරීම) පමණක් නොව ගතික දත්ත මූලද්‍රව්‍ය භාවිතා කර යාවත්කාලීන කාල පරතරය තත්පර 4 දක්වා අඩු කිරීමෙන් යාවත්කාලීන කාල සීමාව සහ පැටවීම නියාමනය කළෙමි.
කාර්ය සාධනය ටෙස්ට්. PostgreSQL: NVP 36 දහසක්
පළමු දියත් කිරීම, මා සතුව තිබූ පළමු සැකසුම මෙම දෘඩාංගයේ පිරිසිදු PostreSQL 10 මත විය (තත්පරයට අගයන් 35 දහසක්). සාමාන්යයෙන්, ඔබට තිරය මත දැකිය හැකි පරිදි, දත්ත ඇතුල් කිරීම තත්පරයක කොටස් ගනී - සෑම දෙයක්ම හොඳ සහ වේගවත්, SSD ධාවකයන් (ගිගාබයිට් 200). එකම දේ තමයි 20 GB සෑහෙන්න ඉක්මනට පිරෙන එක.
අනාගතයේදී එවැනි ප්‍රස්ථාර විශාල ප්‍රමාණයක් ඇත. මෙය සම්මත Zabbix සේවාදායක කාර්ය සාධන උපකරණ පුවරුවකි.
පළමු ප්රස්ථාරය යනු තත්පරයකට අගයන් ගණන (නිල්, ඉහළ වම්), මෙම නඩුවේ අගයන් 35 කි. මෙය (ඉහළ මැද) ගොඩනැගීමේ ක්‍රියාවලීන් පැටවීම වන අතර මෙය (ඉහළ දකුණේ) අභ්‍යන්තර ක්‍රියාවලීන් පැටවීම වේ: ඉතිහාස සමමුහුර්ත කරන්නන් සහ ගෘහ පාලකයා, මෙහි (පහළ මැද) සෑහෙන කාලයක් තිස්සේ ක්රියාත්මක වේ.
මෙම ප්රස්ථාරය (පහළ මැද) ValueCache භාවිතය පෙන්වයි - ප්‍රේරක සඳහා ValueCache පහර කීයක් (තත්පරයට අගයන් දහස් ගණනක්). තවත් වැදගත් ප්‍රස්ථාරයක් වන්නේ දත්ත සමුදායට ඇතුළු කිරීමට පෙර බෆරයක් වන මා කතා කළ HistoryCache භාවිතය පෙන්වන හතරවෙනි එක (පහළ වමේ) වේ.
කාර්ය සාධනය ටෙස්ට්. PostgreSQL: NVP 50 දහසක්
ඊළඟට, මම එකම දෘඩාංගයේ බර තත්පරයට අගයන් 50 දක්වා වැඩි කළෙමි. ගෘහ සේවිකාව විසින් පටවන විට, ගණනය කිරීම් සමඟ තත්පර 10-2 කින් අගයන් 3 ක් සටහන් විය. ඇත්ත වශයෙන්ම, පහත තිර පිටුවේ දැක්වෙන්නේ කුමක්ද:
"ගෘහපාලකයා" දැනටමත් කාර්යයට බාධා කිරීමට පටන් ගෙන ඇත, නමුත් සාමාන්යයෙන්, ඉතිහාසය-සින්කර් උගුල් මත පැටවීම තවමත් 60% මට්ටමේ (තෙවන ප්රස්ථාරය, ඉහළ දකුණේ) මට්ටමේ පවතී. Housekeeper (පහළ වමේ) ධාවනය වන අතරතුර HistoryCache දැනටමත් සක්‍රියව පිරවීමට පටන් ගනී. එය ගිගාබයිට් භාගයක් පමණ විය, 20% පිරී ඇත.
කාර්ය සාධනය ටෙස්ට්. PostgreSQL: NVP 80 දහසක්
ඉන්පසු මම එය තත්පරයට අගයන් 80 දක්වා වැඩි කළෙමි:
එය ආසන්න වශයෙන් දත්ත මූලද්‍රව්‍ය 400 ක්, ප්‍රේරක 280 දහසක් විය. ඔබට පෙනෙන පරිදි, ඉතිහාස සින්කර් බර අනුව ඇතුළු කිරීම (ඒවායින් 30 ක් තිබුණි) දැනටමත් තරමක් ඉහළ ය. ඉන්පසු මම විවිධ පරාමිතීන් වැඩි කළෙමි: ඉතිහාස සින්කර්, හැඹිලිය ... මෙම දෘඩාංග මත, ඉතිහාස සින්කර් මත බර උපරිම ලෙස වැඩි වීමට පටන් ගත්තේය, පාහේ “රාක්කයේ” - ඒ අනුව, HistoryCache ඉතා ඉහළ බරකට ගියේය:
මේ කාලය පුරාම මම සියලුම පද්ධති පරාමිතීන් (ප්‍රොසෙසරය භාවිතා කරන ආකාරය, RAM) නිරීක්ෂණය කළ අතර තැටි භාවිතය උපරිම බව සොයා ගත්තා - මෙම දෘඩාංගයේ, මෙම අථත්‍ය යන්ත්‍රයේ මෙම තැටියේ උපරිම ධාරිතාව මම ලබා ගත්තෙමි. "Postgres" එතරම් තීව්‍රතාවයකින් දත්ත තරමක් ක්‍රියාශීලීව බැහැර කිරීමට පටන් ගත් අතර තැටියට තවදුරටත් ලිවීමට, කියවීමට කාලය නොතිබුණි ...
මම දැනටමත් ප්‍රොසෙසර 48 ක් සහ ගිගාබයිට් 128 ක RAM ඇති වෙනත් සේවාදායකයක් ගත්තා:
මම එය “සුසර” කළෙමි - ඉතිහාස සමමුහුර්තකරණය (කෑලි 60) ස්ථාපනය කර පිළිගත හැකි කාර්ය සාධනයක් ලබා ගත්තෙමි. ඇත්ත වශයෙන්ම, අපි "රාක්කයේ" නැත, නමුත් මෙය බොහෝ විට ඵලදායිතාවයේ සීමාව වේ, එය දැනටමත් ඒ ගැන යමක් කිරීමට අවශ්ය වේ.
කාර්ය සාධනය ටෙස්ට්. TimescaleDB: NVPs 80ක්
මගේ ප්රධාන කාර්යය වූයේ TimescaleDB භාවිතා කිරීමයි. සෑම ප්‍රස්ථාරයක්ම පහත වැටීමක් පෙන්වයි:
මෙම අසාර්ථකත්වයන් හරියටම දත්ත සංක්‍රමණය වේ. ඊට පසු, Zabbix සේවාදායකයේ, ඉතිහාස සින්කර් වල පැටවීමේ පැතිකඩ, ඔබට පෙනෙන පරිදි, බොහෝ වෙනස් විය. එය ඔබට 3 ගුණයක් වේගයෙන් දත්ත ඇතුළත් කිරීමට සහ අඩු HistoryCache භාවිතා කිරීමට ඉඩ සලසයි - ඒ අනුව, ඔබට නියමිත වේලාවට දත්ත ලබා දෙනු ඇත. නැවතත්, තත්පරයකට අගයන් 80 දහසක් තරමක් ඉහළ අනුපාතයකි (ඇත්ත වශයෙන්ම, Yandex සඳහා නොවේ). සමස්තයක් ලෙස මෙය එක් සේවාදායකයක් සහිත තරමක් විශාල සැකසුමකි.
PostgreSQL කාර්ය සාධන පරීක්ෂණය: NVP 120 දහසක්
ඊළඟට, මම දත්ත මූලද්‍රව්‍ය ගණනේ අගය මිලියන භාගයක් දක්වා වැඩි කළ අතර තත්පරයකට ගණනය කළ අගය 125 දහසක් ලැබුණි:
මට මේ ප්‍රස්ථාර ලැබුණා:
ප්‍රතිපත්තිමය වශයෙන්, මෙය වැඩ කරන සැකසුමකි, එය සෑහෙන කාලයක් වැඩ කළ හැකිය. නමුත් මා සතුව තිබුණේ ටෙරාබයිට් 1,5 ක තැටියක් පමණක් බැවින් මම එය දින දෙකකින් භාවිතා කළෙමි. වැදගත්ම දෙය නම්, ඒ සමඟම TimescaleDB හි නව කොටස් නිර්මාණය කර ඇති අතර, මෙය MySQL ගැන පැවසිය නොහැකි කාර්ය සාධනය සඳහා සම්පූර්ණයෙන්ම අවධානයට ලක් නොවීය.
සාමාන්යයෙන්, කොටස් රාත්‍රියේදී සාදනු ලැබේ, මන්ද මෙය සාමාන්යයෙන් ඇතුළු කිරීම සහ වගු සමඟ වැඩ කිරීම අවහිර කරන අතර සේවාව පිරිහීමට හේතු විය හැක. මෙම නඩුවේ මෙය එසේ නොවේ! ප්රධාන කාර්යය වූයේ TimescaleDB හි හැකියාවන් පරීක්ෂා කිරීමයි. ප්‍රති result ලය පහත රූපය විය: තත්පරයකට අගයන් 120 දහසක්.
සමාජයේ උදාහරණ ද තිබේ:
පුද්ගලයා TimescaleDB ද ක්රියාත්මක කළ අතර io.weight භාවිතා කිරීමේ බර ප්‍රොසෙසරය මත පහත වැටුණි; සහ TimescaleDB ඇතුළත් කිරීම නිසා අභ්‍යන්තර ක්‍රියාවලි මූලද්‍රව්‍ය භාවිතය ද අඩු වී ඇත. එපමණක් නොව, මේවා සාමාන්ය පෑන්කේක් තැටි, එනම් සාමාන්ය තැටිවල සාමාන්ය අථත්‍ය යන්ත්‍රයක් (එස්එස්ඩී නොවේ)!
තැටි කාර්ය සාධනය මගින් සීමා කර ඇති සමහර කුඩා සැකසුම් සඳහා, TimescaleDB, මගේ මතය අනුව, ඉතා හොඳ විසඳුමක් වේ. දත්ත සමුදාය සඳහා වේගවත් දෘඪාංග වෙත සංක්‍රමණය වීමට පෙර දිගටම වැඩ කිරීමට එය ඔබට ඉඩ සලසයි.
අපගේ සිදුවීම් සඳහා මම ඔබ සැමට ආරාධනා කරමි: මොස්කව්හි සමුළුව, රීගාහි සමුළුව. අපගේ නාලිකා භාවිතා කරන්න - ටෙලිග්‍රාම්, සංසදය, IRC. ඔබට කිසියම් ප්‍රශ්නයක් ඇත්නම්, අපගේ මේසයට එන්න, අපට සියල්ල ගැන කතා කළ හැකිය.
ප්‍රේක්ෂක ප්‍රශ්න
ප්‍රේක්ෂකයින්ගෙන් ප්‍රශ්නය (මෙතැන් සිට - A): - TimescaleDB වින්යාස කිරීම එතරම් පහසු නම් සහ එය එවැනි කාර්ය සාධනයක් වැඩි දියුණුවක් ලබා දෙන්නේ නම්, සමහර විට මෙය Postgres සමඟ Zabbix වින්යාස කිරීම සඳහා හොඳම භාවිතයක් ලෙස භාවිතා කළ යුතුද? තවද මෙම විසඳුමේ කිසියම් අන්තරායන් සහ අවාසි තිබේද, නැතහොත් සියල්ලට පසු, මම මා වෙනුවෙන් Zabbix සෑදීමට තීරණය කළේ නම්, මට පහසුවෙන් Postgres රැගෙන යා හැකි අතර, වහාම එහි Timescale ස්ථාපනය කළ හැකිද, එය භාවිතා කර කිසිදු ගැටළුවක් ගැන නොසිතිය හැකිද?
AG: - ඔව්, මෙය හොඳ නිර්දේශයක් බව මම කියමි: TimescaleDB දිගුව සමඟ වහාම Postgres භාවිතා කරන්න. මම දැනටමත් පවසා ඇති පරිදි, මෙම "විශේෂාංගය" පර්යේෂණාත්මක බව තිබියදීත්, බොහෝ හොඳ සමාලෝචන. නමුත් ඇත්ත වශයෙන්ම පරීක්ෂණ පෙන්නුම් කරන්නේ මෙය විශිෂ්ට විසඳුමක් (TimescaleDB සමඟ) වන අතර එය පරිණාමය වනු ඇතැයි මම සිතමි! මෙම දිගුව වර්ධනය වන ආකාරය අපි නිරීක්ෂණය කරමින් සිටින අතර අවශ්ය පරිදි වෙනස්කම් සිදු කරනු ඇත.
සංවර්ධනය අතරතුර පවා, අපි ඔවුන්ගේ සුප්රසිද්ධ "විශේෂාංග" එකක් මත විශ්වාසය තැබුවෙමු: එය ටිකක් වෙනස් ලෙස කුට්ටි සමඟ වැඩ කිරීමට හැකි විය. නමුත් පසුව ඔවුන් එය ඊළඟ නිකුතුවේදී කපා දැමූ අතර, අපට මෙම කේතය මත විශ්වාසය තැබීම නතර කිරීමට සිදු විය. බොහෝ සැකසුම් වලදී මෙම විසඳුම භාවිතා කිරීමට මම නිර්දේශ කරමි. ඔබ MySQL භාවිතා කරන්නේ නම්... සාමාන්ය සැකසුම් සඳහා, ඕනෑම විසඳුමක් හොඳින් ක්රියා කරයි.
පිළිතුර: - ප්‍රජාවේ අවසාන ප්‍රස්ථාරවල, “ගෘහපාලකයා” සමඟ ප්‍රස්ථාරයක් තිබුණි:
ඔහු දිගටම වැඩ කළේය. TimescaleDB සමඟ ගෘහ පාලකයා කරන්නේ කුමක්ද?
AG: - දැන් මට නිශ්චිතවම කිව නොහැක - මම කේතය දෙස බලා ඔබට වඩාත් විස්තරාත්මකව කියන්නම්. එය TimescaleDB විමසුම් භාවිතා කරන්නේ කුට්ටි මකා දැමීමට නොව, කෙසේ හෝ ඒවා එකතු කිරීමටයි. මෙම තාක්ෂණික ප්‍රශ්නයට පිළිතුරු දීමට මම තවම සූදානම් නැත. අපි අද හෝ හෙට ස්ටෑන්ඩ් එකේ වැඩි විස්තර සොයා බලමු.
පිළිතුර: - මට සමාන ප්‍රශ්නයක් තිබේ - Timescale හි මකාදැමීමේ මෙහෙයුමේ ක්‍රියාකාරිත්වය ගැන.
A (ප්‍රේක්ෂකයින්ගෙන් පිළිතුර): - ඔබ වගුවකින් දත්ත මකා දැමූ විට, ඔබ එය මකා දැමීම හරහා කරන්නේ නම්, එවිට ඔබට මේසය හරහා යා යුතුය - අනාගත රික්තය සඳහා සියල්ල මකන්න, පිරිසිදු කරන්න, සලකුණු කරන්න. Timescale හි, ඔබට කුට්ටි ඇති බැවින්, ඔබට පහත දැමිය හැක. දළ වශයෙන් කිවහොත්, ඔබ විශාල දත්තවල ඇති ගොනුවට සරලව කියන්න: "මකන්න!"
එවැනි කුට්ටියක් තවදුරටත් නොපවතින බව Timescale සරලව තේරුම් ගනී. එය විමසුම් සැලසුම්කරුට ඒකාබද්ධ කර ඇති බැවින්, එය තෝරාගත් හෝ වෙනත් මෙහෙයුම් වලදී ඔබේ කොන්දේසි අල්ලා ගැනීමට කොකු භාවිතා කරන අතර මෙම කොටස තවදුරටත් නොපවතින බව වහාම තේරුම් ගනී - "මම තවදුරටත් එහි නොයමි!" (දත්ත නොමැත). එච්චරයි! එනම්, වගු ස්කෑන් කිරීම ද්විමය ගොනු මකාදැමීම මගින් ප්රතිස්ථාපනය වේ, එබැවින් එය වේගවත් වේ.
පිළිතුර: - අපි දැනටමත් SQL නොවන මාතෘකාව මත ස්පර්ශ කර ඇත. මට වැටහෙන පරිදි, Zabbix හට දත්ත වෙනස් කිරීමට අවශ්ය නොවන අතර මේ සියල්ල ලොගයක් වැනි දෙයකි. ඔවුන්ගේ දත්ත වෙනස් කළ නොහැකි විශේෂිත දත්ත සමුදායන් භාවිතා කළ හැකිද, නමුත් ඒ සමඟම වඩා වේගයෙන් සුරැකීම, රැස් කිරීම සහ බෙදා හැරීම - Clickhouse, උදාහරණයක් ලෙස, Kafka වැනි දෙයක්?.. Kafka ද ලොගයකි! ඒවා කෙසේ හෝ ඒකාබද්ධ කළ හැකිද?
AG: - බෑම සිදු කළ හැක. 3.4 අනුවාදයේ සිට අපට නිශ්චිත "විශේෂාංගයක්" ඇත: ඔබට සියලුම ඓතිහාසික ගොනු, සිදුවීම්, අනෙකුත් සියල්ල ගොනු වෙත ලිවිය හැකිය; පසුව එය කිසියම් හසුරුවන්නක් භාවිතයෙන් වෙනත් ඕනෑම දත්ත සමුදායකට යවන්න. ඇත්ත වශයෙන්ම, බොහෝ අය නැවත සකස් කර කෙලින්ම දත්ත ගබඩාවට ලියන්න. පියාසර කරන විට, ඉතිහාස සින්කර් මේ සියල්ල ලිපිගොනු වලට ලියා, මෙම ගොනු කරකවන්න, සහ යනාදිය, ඔබට මෙය ක්ලික්හවුස් වෙත මාරු කළ හැකිය. මට සැලසුම් ගැන කිව නොහැක, නමුත් සමහර විට NoSQL විසඳුම් සඳහා තවදුරටත් සහාය (Clickhouse වැනි) දිගටම පවතිනු ඇත.
පිළිතුර: - පොදුවේ ගත් කල, ඔබට postgres සම්පූර්ණයෙන්ම ඉවත් කළ හැකි බව පෙනේ?
AG: - ඇත්ත වශයෙන්ම, Zabbix හි වඩාත්ම දුෂ්කර කොටස වන්නේ වඩාත්ම ගැටළු සහ සිදුවීම් නිර්මාණය කරන ඓතිහාසික වගු ය. මෙම අවස්ථාවෙහිදී, ඔබ සිදුවීම් දිගු කාලයක් ගබඩා නොකරන්නේ නම් සහ වෙනත් වේගවත් ගබඩාවක ප්රවණතා සමඟ ඉතිහාසය ගබඩා කරන්නේ නම්, පොදුවේ ගත් කල, මම හිතන්නේ කිසිදු ගැටළුවක් ඇති නොවනු ඇත.
පිළිතුර: - උදාහරණයක් ලෙස ඔබ Clickhouse වෙත මාරු වුවහොත් සියල්ල කෙතරම් වේගයෙන් ක්රියාත්මක වේදැයි ඔබට තක්සේරු කළ හැකිද?
AG: - මම එය පරීක්ෂා කර නැත. ක්ලික්හවුස් සතුව තමන්ගේම අතුරු මුහුණතක් ඇති බැවින් අවම වශයෙන් එකම සංඛ්‍යා ඉතා සරලව සාක්ෂාත් කරගත හැකි යැයි මම සිතමි, නමුත් මට නිසැකවම පැවසිය නොහැක. පරීක්ෂා කිරීම වඩා හොඳය. එය සියල්ල වින්‍යාසය මත රඳා පවතී: ඔබට කොපමණ ධාරක තිබේද, සහ යනාදිය. ඇතුළත් කිරීම එක් දෙයක්, නමුත් ඔබට මෙම දත්ත නැවත ලබා ගත යුතුය - Grafana හෝ වෙනත් දෙයක්.
පිළිතුර: - ඉතින් අපි කතා කරන්නේ සමාන සටනක් ගැන මිස මෙම වේගවත් දත්ත සමුදායේ විශාල වාසිය ගැන නොවේද?
AG: - මම හිතන්නේ අපි ඒකාබද්ධ වූ විට, වඩාත් නිවැරදි පරීක්ෂණ සිදුවනු ඇත.
පිළිතුර: - හොඳ පැරණි RRD කොහෙද ගියේ? ඔබ SQL දත්ත සමුදායන් වෙත මාරු වීමට හේතු වූයේ කුමක්ද? මුලදී, සියලුම මිනුම් RRD මත එකතු කරන ලදී.
AG: - Zabbix සතුව RRD තිබුණා, සමහර විට ඉතා පැරණි අනුවාදයක. සෑම විටම SQL දත්ත සමුදායන් ඇත - සම්භාව්‍ය ප්‍රවේශයකි. සම්භාව්‍ය ප්‍රවේශය MySQL, PostgreSQL (ඒවා ඉතා දිගු කාලයක් පැවතුනි). අපි කවදාවත් SQL සහ RRD දත්ත සමුදායන් සඳහා පොදු අතුරු මුහුණතක් භාවිතා කර නැත.
සමහර දැන්වීම් 🙂
අප සමඟ රැඳී සිටීම ගැන ඔබට ස්තුතියි. ඔබ අපේ ලිපි වලට කැමතිද? වඩාත් රසවත් අන්තර්ගතය බැලීමට අවශ්‍යද? ඇණවුමක් කිරීමෙන් හෝ මිතුරන්ට නිර්දේශ කිරීමෙන් අපට සහාය වන්න, , ඔබ වෙනුවෙන් අප විසින් නිර්මාණය කරන ලද ප්‍රවේශ මට්ටමේ සේවාදායකයන්ගේ අද්විතීය ප්‍රතිසමයක්: (RAID1 සහ RAID10, cores 24 දක්වා සහ 40GB DDR4 දක්වා ඇත).
Dell R730xd ඇම්ස්ටර්ඩෑම් හි Equinix Tier IV දත්ත මධ්‍යස්ථානයේ 2 ගුණයක් ලාභදායීද? මෙතන විතරයි නෙදර්ලන්තයේ! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $99 සිට! ගැන කියවන්න
මූලාශ්රය: www.habr.com