TL;DR: වසර හතරකට පෙර මම නව සේවාදායක අධීක්ෂණ මෙවලමක් සඳහා අදහසක් සමඟ ගූගල් හැර ගියෙමි. අදහස වූයේ සාමාන්‍යයෙන් හුදකලා කාර්යයන් එක් සේවාවකට ඒකාබද්ධ කිරීමයි එකතු කරනවා සහ ලොග් විශ්ලේෂණය, ප්‍රමිතික එකතුව, අනතුරු ඇඟවීම් සහ උපකරණ පුවරු. එක් මූලධර්මයක් නම් සේවාව සැබවින්ම විය යුතුය ඉක්මනින්, devops පහසු, අන්තර්ක්‍රියාකාරී, විනෝදජනක අත්දැකීමක් ලබා දීම. අයවැය තුළ රැඳී සිටින අතරතුර තත්පරයක භාගවලින් බහු-ගිගාබයිට් දත්ත කට්ටල සැකසීම මෙයට අවශ්‍ය වේ. පවතින ලොග් කළමනාකරණ මෙවලම් බොහෝ විට මන්දගාමී සහ අවුල් සහගත වේ, එබැවින් අපට හොඳ අභියෝගයකට මුහුණ දීමට සිදු විය: පරිශීලකයින්ට නව අත්දැකීමක් ලබා දීම සඳහා මෙවලමක් දක්ෂ ලෙස සැලසුම් කිරීම.

පැරණි පාසල් ක්‍රම, තිරිසන් බල ප්‍රවේශයක්, අනවශ්‍ය ස්ථර ඉවත් කිරීම සහ සංකීර්ණ දත්ත ව්‍යුහයන් මඟහරවා ගැනීමෙන් අපි Scalyr හි මෙම ගැටළුව විසඳූ ආකාරය මෙම ලිපියෙන් විස්තර කෙරේ. ඔබට මෙම පාඩම් ඔබේම ඉංජිනේරු ගැටළු සඳහා යෙදිය හැක.

පැරණි පාසල් බලය

ලොග් විශ්ලේෂණය සාමාන්‍යයෙන් සෙවුමකින් ආරම්භ වේ: යම් රටාවකට ගැලපෙන සියලුම පණිවිඩ සොයා ගන්න. Scalyr හි, මේවා බොහෝ සේවාදායකයන්ගෙන් ලොග් දස හෝ ගිගාබයිට් සිය ගණනක් වේ. නවීන ප්රවේශයන්, රීතියක් ලෙස, සෙවීම සඳහා ප්රශස්තකරණය කරන ලද සමහර සංකීර්ණ දත්ත ව්යුහයක් තැනීම ඇතුළත් වේ. මම නිසැකවම මෙය Google හි දැක ඇත්තෙමි, එහිදී ඔවුන් මේ ආකාරයේ දේවලට ඉතා දක්ෂයි. නමුත් අපි වඩාත් රළු ප්‍රවේශයක් මත පදිංචි විය: ලඝු-සටහන් රේඛීය පරිලෝකනය. එය ක්‍රියාත්මක විය - අපි අපගේ තරඟකරුවන්ට වඩා විශාලත්වයේ ඇණවුම් සෙවිය හැකි අතුරු මුහුණතක් සපයන්නෙමු (අවසානයේ සජීවිකරණය බලන්න).

ප්‍රධාන තීක්ෂ්ණ බුද්ධිය වූයේ නවීන ප්‍රොසෙසර ඇත්ත වශයෙන්ම සරල, සරල මෙහෙයුම් වලදී ඉතා වේගවත් බවයි. I/O වේගය සහ ජාල මෙහෙයුම් මත රඳා පවතින සංකීර්ණ බහු-ස්ථර පද්ධතිවල මෙය මග හැරීම පහසු වන අතර එවැනි පද්ධති අද බහුලව දක්නට ලැබේ. එබැවින් අපි ස්ථර සහ අතිරික්ත සුන්බුන් අවම කරන මෝස්තරයක් සකස් කළා. බහු ප්‍රොසෙසර සහ සර්වර් සමාන්තරව, සෙවුම් වේගය තත්පරයට 1 TB දක්වා ළඟා වේ.

මෙම ලිපියෙන් ප්‍රධාන උපුටා ගැනීම්:

• Brute-force search යනු සැබෑ ලෝකයේ, මහා පරිමාණ ගැටලු විසඳීම සඳහා ශක්‍ය ප්‍රවේශයකි.
• Brute force යනු නිර්මාණ ශිල්පීය ක්‍රමයක් මිස වැඩ-නිදහස් විසඳුමක් නොවේ. ඕනෑම තාක්ෂණයක් මෙන්, එය අනෙක් ඒවාට වඩා සමහර ගැටළු වලට වඩා සුදුසු වන අතර, දුර්වල ලෙස හෝ හොඳින් ක්රියාත්මක කළ හැකිය.
• ම්ලේච්ඡ බලය සාක්ෂාත් කර ගැනීම සඳහා විශේෂයෙන් හොඳය ස්ථාවර ඵලදායිතාව.
• තිරිසන් බලය ඵලදායී ලෙස භාවිතා කිරීම සඳහා කේතය ප්‍රශස්ත කිරීම සහ නියම වේලාවට ප්‍රමාණවත් සම්පත් යෙදීම අවශ්‍ය වේ. ඔබගේ සේවාදායකයන් අධික පරිශීලක නොවන බරක් යටතේ පවතී නම් සහ පරිශීලක මෙහෙයුම් ප්‍රමුඛතාවයක් ලෙස පවතී නම් එය සුදුසු වේ.
• කාර්ය සාධනය රඳා පවතින්නේ අභ්‍යන්තර ලූප් ඇල්ගොරිතම පමණක් නොව සමස්ත පද්ධතියේ සැලසුම මත ය.

(මෙම ලිපිය මතකයේ දත්ත සෙවීම විස්තර කරයි. බොහෝ අවස්ථාවලදී, පරිශීලකයෙකු ලඝු-සටහන් සෙවීමක් සිදු කරන විට, Scalyr සේවාදායකයන් එය දැනටමත් හැඹිලිගත කර ඇත. මීළඟ ලිපියෙන් කෑෂ් නොකළ ලඝු-සටහන් සෙවීම ගැන සාකච්ඡා කරනු ඇත. එම මූලධර්ම අදාළ වේ: කාර්යක්ෂම කේතය, බෲට් බලය විශාල පරිගණක සම්පත් සමඟ).

බෲට් බල ක්රමය

සාම්ප්‍රදායිකව, විශාල දත්ත කට්ටලයක් මූල පද දර්ශකයක් භාවිතයෙන් සෙවුම් කෙරේ. සේවාදායක ලොග සඳහා යොදන විට, මෙයින් අදහස් කරන්නේ ලොගයේ ඇති සෑම අද්විතීය වචනයක්ම සෙවීමයි. සෑම වචනයක් සඳහාම, ඔබ සියලු ඇතුළත් කිරීම් ලැයිස්තුවක් සෑදිය යුතුය. මෙය මෙම වචනය සමඟ සියලුම පණිවිඩ සොයා ගැනීම පහසු කරයි, උදාහරණයක් ලෙස 'දෝෂය', 'ෆයර්ෆොක්ස්' හෝ "ගනුදෙනු_16851951" - සුචිය දෙස බලන්න.

මම Google හි මෙම ප්‍රවේශය භාවිතා කළ අතර එය හොඳින් ක්‍රියාත්මක විය. නමුත් Scalyr එකේ අපි logs byte byte එකෙන් search කරනවා.

ඇයි? වියුක්ත ඇල්ගොරිතම දෘෂ්ටි කෝණයකින්, මූල පද දර්ශක තිරිසන් බල සෙවීම් වලට වඩා බොහෝ කාර්යක්ෂම වේ. කෙසේ වෙතත්, අපි ඇල්ගොරිතම විකුණන්නේ නැත, අපි කාර්ය සාධනය විකුණමු. කාර්ය සාධනය යනු ඇල්ගොරිතම පමණක් නොව, පද්ධති ඉංජිනේරු විද්‍යාව ද වේ. අපි සියල්ල සලකා බැලිය යුතුය: දත්ත පරිමාව, සෙවුම් වර්ගය, පවතින දෘඪාංග සහ මෘදුකාංග සන්දර්භය. අපගේ විශේෂිත ගැටලුව සඳහා, දර්ශකයකට වඩා 'grep' වැනි දෙයක් වඩාත් සුදුසු බව අපි තීරණය කළෙමු.

දර්ශක විශිෂ්ටයි, නමුත් ඒවාට සීමාවන් තිබේ. එක් වචනයක් සොයා ගැනීම පහසුය. නමුත් 'googlebot' සහ '404' වැනි බහු වචන සහිත පණිවිඩ සෙවීම වඩා දුෂ්කර ය. 'අල්ලාගත් ව්‍යතිරේකයක්' වැනි වාක්‍ය ඛණ්ඩයක් සෙවීමට එම වචනය සමඟ සියලුම පණිවිඩ පමණක් නොව, වචනයේ නිශ්චිත ස්ථානය ද වාර්තා කරන වඩාත් අපහසු දර්ශකයක් අවශ්‍ය වේ.

ඔබ වචන සොයන්නේ නැති විට සැබෑ දුෂ්කරතාවය පැමිණේ. අපි හිතමු බොට් වලින් කොච්චර ට්‍රැෆික් එනවද කියලා බලන්න ඕන කියලා. පළමු සිතුවිල්ල වන්නේ 'bot' යන වචනය සඳහා ලඝු-සටහන් සෙවීමයි. ඔබ සමහර බොට් සොයා ගන්නේ මෙලෙසයි: Googlebot, Bingbot සහ තවත් බොහෝ දේ. නමුත් මෙහි 'bot' යනු වචනයක් නොව එහිම කොටසකි. අපි දර්ශකයේ 'bot' ලෙස සෙව්වොත්, 'Googlebot' යන වචනය සහිත පෝස්ට් කිසිවක් අපට හමු නොවේ. ඔබ දර්ශකයේ සෑම වචනයක්ම පරීක්ෂා කර පසුව සොයාගත් මූල පද සඳහා දර්ශකය පරිලෝකනය කළහොත්, සෙවුම බෙහෙවින් මන්දගාමී වනු ඇත. එහි ප්‍රතිඵලයක් ලෙස, සමහර ලොග් වැඩසටහන් කොටස්-වචන සෙවීම් වලට ඉඩ නොදේ, නැතහොත් (හොඳම ලෙස) අඩු කාර්ය සාධනයක් සහිත විශේෂ වාක්‍ය ඛණ්ඩයකට ඉඩ නොදේ. අපට මෙය වළක්වා ගැනීමට අවශ්‍යයි.

තවත් ගැටළුවක් වන්නේ විරාම ලකුණු. ඔබට සියලු ඉල්ලීම් සොයා ගැනීමට අවශ්‍යද 50.168.29.7? අඩංගු ලොග නිදොස් කිරීම ගැන කුමක් කිව හැකිද [error]? උපසිරසි සාමාන්‍යයෙන් විරාම ලකුණු මඟ හරියි.

අවසාන වශයෙන්, ඉංජිනේරුවන් බලවත් මෙවලම් වලට ආදරය කරයි, සමහර විට ගැටළුවක් නිත්ය ප්රකාශනයකින් පමණක් විසඳිය හැකිය. මේ සඳහා Keyword index එක එතරම් සුදුසු නොවේ.

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

මූල පද දර්ශක ද විශාල ඉඩ ප්‍රමාණයක් ගනී, සහ ගබඩා කිරීම ලොග් කළමනාකරණ පද්ධතියක ප්‍රධාන පිරිවැයකි.

අනෙක් අතට, සෑම සෙවුමකටම විශාල පරිගණක බලයක් වැය කළ හැකිය. අපගේ පරිශීලකයින් අද්විතීය විමසුම් සඳහා අධිවේගී සෙවුම් අගය කරයි, නමුත් එවැනි විමසුම් සාපේක්ෂව කලාතුරකින් සිදු වේ. සාමාන්ය සෙවුම් විමසුම් සඳහා, උදාහරණයක් ලෙස, උපකරණ පුවරුව සඳහා, අපි විශේෂ තාක්ෂණික ක්රම භාවිතා කරමු (අපි ඒවා ඊළඟ ලිපියෙන් විස්තර කරමු). වෙනත් ඉල්ලීම් ප්‍රමාණවත් නොවන අතර ඔබට වරකට එකකට වඩා සැකසීමට සිදුවන්නේ කලාතුරකිනි. නමුත් අපගේ සේවාදායකයන් කාර්යබහුල නොවන බව මින් අදහස් නොවේ: ඔවුන් නව පණිවිඩ ලබා ගැනීම, විශ්ලේෂණය කිරීම සහ සම්පීඩනය කිරීම, ඇඟවීම් ඇගයීම, පැරණි දත්ත සම්පීඩනය කිරීම යනාදිය සමඟ කාර්යබහුලයි. මේ අනුව, විමසුම් ක්‍රියාත්මක කිරීමට භාවිතා කළ හැකි ප්‍රොසෙසරවල තරමක් සැලකිය යුතු සැපයුමක් අප සතුව ඇත.

ඔබට තිරිසන් ගැටලුවක් තිබේ නම් (සහ විශාල බලයක්) තිරිසන් බලය ක්‍රියා කරයි

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

අපගේ සෙවුම් කේතයට මුලින් තරමක් විශාල අභ්‍යන්තර ලූපයක් තිබුණි. අපි 4K හි පිටු මත පණිවිඩ ගබඩා කරමු; සෑම පිටුවකම පණිවිඩ කිහිපයක් (UTF-8 හි) සහ එක් එක් පණිවිඩය සඳහා පාර-දත්ත අඩංගු වේ. පාරදත්ත යනු අගයේ දිග, අභ්‍යන්තර පණිවිඩ හැඳුනුම්පත සහ අනෙකුත් ක්ෂේත්‍ර සංකේත කරන ව්‍යුහයකි. සෙවුම් චක්‍රය මෙසේ දිස් විය:

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

(ලඝු-සටහන් සමඟ කෙලින්ම වැඩ කරනවාට වඩා අපි 4K පිටු, පෙළ සහ පාර-දත්ත සමඟ මෙම ආකෘතියෙන් පණිවිඩ ගබඩා කරන්නේ මන්දැයි ඔබ අසනු ඇත. Scalyr එන්ජිම අභ්‍යන්තරව බෙදා හරින ලද දත්ත සමුදායක් මෙන් වීමට හේතු බොහෝමයක් ඇත. ගොනු පද්ධතිය.පෙළ සෙවීම බොහෝ විට ලොග් විග්‍රහ කිරීමෙන් පසු මායිම්වල ඇති DBMS ආකාරයේ පෙරහන් සමඟ ඒකාබද්ධ වේ.අපට එකවර ලොග් දහස් ගණනක් සෙවිය හැකි අතර සරල පෙළ ගොනු අපගේ ගනුදෙනු, ප්‍රතිනිර්මාණය, බෙදා හරින ලද දත්ත කළමනාකරණය සඳහා සුදුසු නොවේ).

මුලදී, එවැනි කේතය brute force optimization සඳහා එතරම් සුදුසු නොවන බව පෙනෙන්නට තිබුණි. "සැබෑ වැඩ" තුළ String.indexOf() CPU පැතිකඩෙහි පවා ආධිපත්‍යය දැරුවේ නැත. එනම්, මෙම ක්රමය ප්රශස්ත කිරීම පමණක් සැලකිය යුතු බලපෑමක් ගෙන එන්නේ නැත.

අපි සෑම පිටුවකම ආරම්භයේ පාර-දත්ත ගබඩා කරන අතර UTF-8 හි සියලුම පණිවිඩවල පෙළ අනෙක් කෙළවරේ අසුරා ඇත. මෙයින් ප්‍රයෝජන ගනිමින්, අපි මුළු පිටුවම එකවර සෙවීමට ලූපය නැවත ලිව්වෙමු:

මෙම අනුවාදය දර්ශනය මත කෙලින්ම ක්‍රියා කරයි raw byte[] සහ සම්පූර්ණ 4K පිටුව හරහා සියලුම පණිවිඩ එකවර සොයයි.

බෲට් ෆෝර්ස් ක්‍රමය සඳහා ප්‍රශස්ත කිරීම මෙය වඩාත් පහසු වේ. අභ්‍යන්තර සෙවුම් ලූපය එක් එක් පළ කිරීම සඳහා වෙන වෙනම නොව මුළු 4K පිටුව සඳහාම එකවර හැඳින්වේ. දත්ත පිටපත් කිරීමක්, වස්තූන් වෙන් කිරීමක් සිදු නොවේ. තවද වඩාත් සංකීර්ණ පාරදත්ත මෙහෙයුම් කැඳවනු ලබන්නේ ප්‍රතිඵලය ධනාත්මක වූ විට මිස සෑම පණිවිඩයක් මතම නොවේ. මේ ආකාරයෙන් අපි ටොන් එකක් උඩින් ඉවත් කර ඇති අතර, ඉතිරි බර කුඩා අභ්‍යන්තර සෙවුම් ලූපයක් තුළ සංකේන්ද්‍රණය වී ඇත, එය තවදුරටත් ප්‍රශස්ත කිරීම සඳහා හොඳින් ගැලපේ.

අපගේ සැබෑ සෙවුම් ඇල්ගොරිතම පදනම් වී ඇත ලියොනිඩ් වොල්නිට්ස්කි ගැන හොඳ අදහසක්. එය Boyer-Moore ඇල්ගොරිතමයට සමාන වන අතර, සෑම පියවරකදීම සෙවුම් තන්තුවේ දිග ආසන්න වශයෙන් මඟ හැරේ. ප්‍රධාන වෙනස වන්නේ එය ව්‍යාජ ගැලපීම් අවම කිරීම සඳහා වරකට බයිට් දෙකක් පරීක්ෂා කිරීමයි.

අපගේ ක්‍රියාත්මක කිරීම සඳහා එක් එක් සෙවීම සඳහා 64K සෙවීම් වගුවක් නිර්මාණය කිරීම අවශ්‍ය වේ, නමුත් එය අප සොයන ගිගාබයිට් දත්ත සමඟ සසඳන විට කිසිවක් නොවේ. අභ්‍යන්තර ලූපය තනි හරයක් මත තත්පරයකට ගිගාබයිට් කිහිපයක් සකසයි. ප්රායෝගිකව, ස්ථාවර කාර්ය සාධනය සෑම හරයකම තත්පරයට 1,25 GB පමණ වන අතර, වැඩිදියුණු කිරීම සඳහා ඉඩ ඇත. අභ්‍යන්තර ලූපයෙන් පිටත උඩිස් කොටසක් ඉවත් කිරීමට හැකි වන අතර, අපි Java වෙනුවට C හි අභ්‍යන්තර ලූපයක් අත්හදා බැලීමට සැලසුම් කරමු.

අපි බලය පාවිච්චි කරනවා

ලොග් සෙවීම "දළ වශයෙන්" ක්‍රියාත්මක කළ හැකි බව අපි සාකච්ඡා කර ඇත, නමුත් අපට කොපමණ "බලයක්" තිබේද? සෑහෙන්න ගොඩක්.

1 හරය: නිවැරදිව භාවිතා කරන විට, නවීන ප්‍රොසෙසරයක තනි හරයක් එහිම ප්‍රබල වේ.

හරය 8ක්: අපි දැනට ඇමේසන් hi1.4xlarge සහ i2.4xlarge SSD සේවාදායකයන් මත ක්‍රියාත්මක වන අතර, ඒ සෑම එකක්ම cores 8ක් (නූල් 16ක්) ඇත. ඉහත සඳහන් කළ පරිදි, මෙම හරය සාමාන්යයෙන් පසුබිම් මෙහෙයුම් සමඟ කාර්යබහුලයි. පරිශීලකයා සෙවීමක් සිදු කරන විට, පසුබිම් මෙහෙයුම් අත්හිටුවනු ලැබේ, සෙවීම සඳහා සියලු හරයන් 8 නිදහස් කරයි. සෙවුම සාමාන්‍යයෙන් තත්පරයකින් අවසන් වේ, ඉන් පසු පසුබිම් වැඩ නැවත ආරම්භ වේ (throttling වැඩසටහන මඟින් සෙවුම් විමසුම්වල බාධාව වැදගත් පසුබිම් කාර්යයට බාධා නොවන බව සහතික කරයි).

හරය 16ක්: විශ්වසනීයත්වය සඳහා, අපි සේවාදායකයන් මාස්ටර්/ස්ලේව් කණ්ඩායම් වලට සංවිධානය කරමු. සෑම ස්වාමියාටම ඔහුගේ විධානය යටතේ එක් SSD සහ EBS සේවාදායකයක් ඇත. ප්‍රධාන සේවාදායකය බිඳ වැටුණහොත්, SSD සේවාදායකය වහාම එහි ස්ථානයට පත්වේ. සෑම විටම පාහේ, ස්වාමියා සහ වහල් හොඳින් ක්‍රියා කරයි, එවිට එක් එක් දත්ත වාරණ විවිධ සේවාදායකයන් දෙකක සෙවිය හැකිය (EBS වහල් සේවාදායකයේ දුර්වල ප්‍රොසෙසරයක් ඇත, එබැවින් අපි එය සලකන්නේ නැත). අපි ඔවුන් අතර කාර්යය බෙදන්නෙමු, එවිට අපට මුළු හරයන් 16 ක් ඇත.

බොහෝ හරයන්: නුදුරු අනාගතයේ දී, අපි ඔවුන් සියලු සුළු නොවන සෑම ඉල්ලීමක් සැකසීමට සහභාගී වන ආකාරයට සේවාදායකයන් හරහා දත්ත බෙදා හරිනු ඇත. සෑම හරයක්ම වැඩ කරනු ඇත. [සටහන: අපි සැලැස්ම ක්‍රියාත්මක කර සෙවුම් වේගය 1 TB/s දක්වා වැඩි කළෙමු, ලිපියේ අවසානයේ ඇති සටහන බලන්න].

සරල බව විශ්වසනීයත්වය සහතික කරයි

බෲට් ෆෝර්ස් ක්‍රමයේ තවත් වාසියක් වන්නේ එහි තරමක් ස්ථාවර ක්‍රියාකාරිත්වයයි. සාමාන්‍යයෙන්, සෙවීම ගැටලුවේ සහ දත්ත කට්ටලයේ විස්තරවලට එතරම් සංවේදී නොවේ (මම හිතන්නේ එය "රළු" ලෙස හඳුන්වන්නේ එබැවිනි).

මූල පද දර්ශකය සමහර විට ඇදහිය නොහැකි තරම් වේගවත් ප්‍රතිඵල නිපදවන අතර තවත් විටෙක එසේ නොවේ. අපි හිතමු ඔබට ගිගාබයිට් 50ක ලඝු-සටහන් ඇති අතර එහි 'customer_5987235982' යන යෙදුම හරියටම තුන් වරක් දිස් වේ. මෙම පදය සඳහා සෙවීමක් දර්ශකයෙන් සෘජුවම ස්ථාන තුනක් ගණන් කරන අතර ක්ෂණිකව සම්පූර්ණ වනු ඇත. නමුත් සංකීර්ණ වයිල්ඩ්කාඩ් සෙවීම් වලට මූල පද දහස් ගණනක් පරිලෝකනය කළ හැකි අතර දිගු කාලයක් ගත වේ.

අනෙක් අතට, බෲට් බල සෙවුම් ඕනෑම විමසුමක් සඳහා වැඩි හෝ අඩු වේගයකින් ක්‍රියා කරයි. දිගු වචන සෙවීම වඩා හොඳය, නමුත් තනි අක්ෂරයක් සෙවීම පවා තරමක් වේගවත් ය.

බෲට් ෆෝර්ස් ක්රමයේ සරලත්වය යනු එහි ක්රියාකාරිත්වය එහි න්යායික උපරිමයට ආසන්න බවයි. අනපේක්ෂිත තැටි අධි බර, අගුලු දැමීම, පොයින්ටර් හඹා යාම සහ අසාර්ථක වීමට හේතු දහස් ගණනක් සඳහා අඩු විකල්ප ඇත. මම පසුගිය සතියේ අපගේ කාර්යබහුලම සේවාදායකයේ Scalyr පරිශීලකයින් විසින් කරන ලද ඉල්ලීම් දෙස බැලුවෙමි. ඉල්ලීම් 14ක් තිබුණා. ඔවුන්ගෙන් හරියටම අටකට තත්පරයකට වඩා ගත විය; මිලි තත්පර 000ක් ඇතුළත 99% සම්පූර්ණ කර ඇත (ඔබ ලොග් විශ්ලේෂණ මෙවලම් භාවිතා කර නොමැති නම්, මාව විශ්වාස කරන්න: එය වේගවත්).

සේවාව භාවිතා කිරීමේ පහසුව සඳහා ස්ථාවර, විශ්වාසනීය කාර්ය සාධනය වැදගත් වේ. එය වරින් වර ප්‍රමාද වුවහොත්, පරිශීලකයින් එය විශ්වාස කළ නොහැකි යැයි වටහා ගන්නා අතර එය භාවිතා කිරීමට මැලි වේ.

ලොග් සෙවීම ක්‍රියාත්මක වේ

මෙන්න Scalyr සෙවුම ක්‍රියාත්මක වන බව පෙන්වන කෙටි සජීවිකරණයක්. අපි සෑම පොදු Github ගබඩාවකම සෑම සිදුවීමක්ම ආයාත කරන demo ගිණුමක් ඇත. මෙම demo තුළ, මම සතියක දත්ත පරීක්ෂා කරමි: දළ වශයෙන් 600 MB අමු ලඝු-සටහන්.

වීඩියෝව මගේ ඩෙස්ක්ටොප් එකේ (සේවාදායකයේ සිට කිලෝමීටර් 5000 ක් පමණ) විශේෂ සූදානමකින් තොරව සජීවීව පටිගත කරන ලදී. ඔබ දකින කාර්ය සාධනය බොහෝ දුරට හේතු වේ වෙබ් සේවාදායක ප්‍රශස්තකරණය, මෙන්ම වේගවත් සහ විශ්වාසනීය පසුබිමක්. 'පූරණය' දර්ශකයක් නොමැතිව විරාමයක් ඇති විට, එය මා විරාමයක් තැබීම නිසා මා ඔබන්න යන දේ ඔබට කියවිය හැක.

අවසාන වශයෙන්

විශාල දත්ත ප්‍රමාණයක් සැකසීමේදී, හොඳ ඇල්ගොරිතමයක් තෝරා ගැනීම වැදගත් වේ, නමුත් “හොඳ” යන්නෙන් “විචිත්‍රවත්” අදහස් නොවේ. ඔබගේ කේතය ප්‍රායෝගිකව ක්‍රියා කරන ආකාරය ගැන සිතන්න. ඇල්ගොරිතමවල න්‍යායික විශ්ලේෂණය සැබෑ ලෝකයේ ඉතා වැදගත් විය හැකි සමහර සාධක ඉවත් කරයි. සරල ඇල්ගොරිතම ප්‍රශස්ත කිරීමට පහසු වන අතර ආන්තික අවස්ථාවන්හිදී වඩා ස්ථායී වේ.

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

තිරිසන් බල ක්‍රමයක් භාවිතා කරමින්, අපි ලඝු-සටහන් සමූහයක් හරහා වේගවත්, විශ්වාසදායක, නම්‍යශීලී සෙවීමක් ක්‍රියාත්මක කළෙමු. මෙම අදහස් ඔබගේ ව්‍යාපෘති සඳහා ප්‍රයෝජනවත් වනු ඇතැයි අපි බලාපොරොත්තු වෙමු.

සංස්කරණය කරන්න: පසුගිය වසර කිහිපය තුළ කාර්ය සාධනය වැඩි වීම පිළිබිඹු කිරීම සඳහා මාතෘකාව සහ පෙළ "තත්පරයට 20 GB හි සොයන්න" සිට "තත්පරයට 1 TB ට සොයන්න" දක්වා වෙනස් වී ඇත. මෙම වේගය වැඩිවීමට මූලික වශයෙන් හේතු වී ඇත්තේ අපගේ වැඩිවන පාරිභෝගික පදනමට සේවය කිරීම සඳහා අප අද ඉදිරිපත් කරන EC2 සේවාදායක වර්ගවල සහ සංඛ්‍යාවේ වෙනස්වීම් හේතුවෙනි. මෙහෙයුම් කාර්යක්ෂමතාවයේ තවත් නාටකාකාර තල්ලුවක් ලබා දෙන වෙනස්කම් ළඟදීම පැමිණේ, අපට ඒවා බෙදා ගැනීමට බලා සිටිය නොහැක.

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