Sportmaster හි අපි හැඹිලි පද්ධතියක් තෝරා ගත් ආකාරය. 1 කොටස

ආයුබෝවන්! මගේ නම Alexey Pyankov, මම Sportmaster සමාගමේ සංවර්ධකයෙක්. ඒ තුළ තැපැල් 2012 දී ස්පෝර්ට්මාස්ටර් වෙබ් අඩවියේ වැඩ ආරම්භ වූ ආකාරය, අපි "තල්ලු කිරීමට" සමත් වූ මුලපිරීම් මොනවාද සහ අනෙක් අතට, අපි එකතු කළ රේක් මොනවාදැයි මම කීවෙමි.

අද මට වෙනත් මාතෘකාවක් අනුගමනය කරන සිතුවිලි බෙදා ගැනීමට අවශ්‍යයි - අඩවි පරිපාලක ප්‍රදේශයේ java පසුපෙළ සඳහා හැඹිලි පද්ධතියක් තෝරා ගැනීම. මෙම කුමන්ත්‍රණය මට විශේෂ අර්ථයක් ඇත - කතාව දිග හැරුණේ මාස 2 ක් පමණක් වුවද, මෙම දින 60 තුළ අපි පැය 12-16 ක් සහ එක් දිනක්වත් විවේකයක් නොමැතිව වැඩ කළෙමු. මෙතරම් වෙහෙස මහන්සි වී වැඩ කළ හැකි යැයි මම කිසි විටෙකත් නොසිතුවෙමි, සිතුවෙමි.

එමනිසා, මම එය සම්පූර්ණයෙන්ම පූරණය නොවන පරිදි කොටස් 2 කට බෙදා ඇත. ඊට පටහැනිව, පළමු කොටස ඉතා සැහැල්ලු වනු ඇත - සකස් කිරීම, හැඳින්වීම, හැඹිලිය යනු කුමක්ද යන්න පිළිබඳ සමහර සලකා බැලීම්. ඔබ දැනටමත් පළපුරුදු සංවර්ධකයෙකු නම් හෝ හැඹිලි සමඟ වැඩ කර ඇත්නම්, තාක්ෂණික පැත්තෙන් බොහෝ විට මෙම ලිපියේ අලුත් කිසිවක් නොතිබෙනු ඇත. නමුත් කනිෂ්ඨයෙකුට, එවැනි කුඩා සමාලෝචනයකින් ඔහු එවැනි සන්ධිස්ථානයක සිටින විට කුමන දිශාව දෙස බැලිය යුතුද යන්න ඔහුට පැවසිය හැකිය.

Sportmaster වෙබ් අඩවියේ නව අනුවාදය නිෂ්පාදනයට ඇතුළත් කළ විට, දත්ත ලැබුණේ මෘදු ලෙස, එතරම් පහසු නොවන ආකාරයට ය. පදනම වූයේ වෙබ් අඩවියේ පෙර අනුවාදය (බිට්‍රික්ස්) සඳහා සකස් කරන ලද වගු වන අතර එය ETL වෙත ඇදගෙන නව ස්වරූපයකට ගෙන ඒම සහ තවත් පද්ධති දුසිමකින් විවිධ කුඩා දේවල් වලින් පොහොසත් විය. වෙබ් අඩවියේ නව පින්තූරයක් හෝ නිෂ්පාදන විස්තරයක් දිස්වීම සඳහා, ඔබට ඊළඟ දවස දක්වා රැඳී සිටීමට සිදු විය - යාවත්කාලීන කිරීම් රාත්‍රියේ පමණක්, දිනකට වරක්.

මුලදී, නිෂ්පාදනයට යන පළමු සතිවල සිට බොහෝ කරදර ඇති වූ අතර, අන්තර්ගත කළමනාකරුවන්ට එවැනි අපහසුතාවයන් සුළු දෙයක් විය. නමුත්, සෑම දෙයක්ම සමථයකට පත් වූ වහාම, ව්‍යාපෘතියේ සංවර්ධනය දිගටම පැවතුනි - මාස කිහිපයකට පසු, 2015 ආරම්භයේදී, අපි පරිපාලක මණ්ඩලය ක්‍රියාකාරීව සංවර්ධනය කිරීමට පටන් ගත්තෙමු. 2015 සහ 2016 දී, සෑම දෙයක්ම හොඳින් සිදුවෙමින් පවතී, අපි නිතිපතා නිකුත් කරන්නෙමු, පරිපාලක මණ්ඩලය වැඩි වැඩියෙන් දත්ත සකස් කිරීම ආවරණය කරයි, සහ ඉක්මනින් අපගේ කණ්ඩායමට වඩාත්ම වැදගත් හා සංකීර්ණ දෙය - නිෂ්පාදනය භාර දෙනු ඇති බවට අපි සූදානම් වෙමු. පරිපථය (සියලු නිෂ්පාදන පිළිබඳ දත්ත සම්පූර්ණයෙන් සකස් කිරීම සහ නඩත්තු කිරීම). නමුත් 2017 ගිම්හානයේදී, වෙළඳ භාණ්ඩ පරිපථය දියත් කිරීමට පෙර, ව්‍යාපෘතිය ඉතා දුෂ්කර තත්වයකට පත්වනු ඇත - හරියටම හැඹිලිගත කිරීමේ ගැටළු නිසා. මෙම කොටස් දෙකකින් යුත් ප්‍රකාශනයේ දෙවන කොටසේදී මෙම කථාංගය ගැන කතා කිරීමට මට අවශ්‍යය.

නමුත් මෙම ලිපියෙන් මම දුර සිට ආරම්භ කරමි, මම විශාල ව්‍යාපෘතියකට පෙර අනුචලනය කිරීමට හොඳ පියවරක් වනු ඇති හැඹිලිය පිළිබඳ අදහස් - අදහස් කිහිපයක් ඉදිරිපත් කරමි.

හැඹිලි කාර්යයක් සිදු වූ විට

හැඹිලි කාර්යය නිකම්ම පෙනෙන්නේ නැත. අපි සංවර්ධකයින්, මෘදුකාංග නිෂ්පාදනයක් ලියන අතර එය ඉල්ලුමේ තිබිය යුතුය. නිෂ්පාදිතය ඉල්ලුමේ සහ සාර්ථක නම්, පරිශීලකයින් පැමිණෙනු ඇත. ඒ වගේම තව තවත් එනවා. එවිට බොහෝ පරිශීලකයින් සිටින අතර පසුව නිෂ්පාදිතය අධික ලෙස පටවනු ලැබේ.

පළමු අදියරේදී, අපි ප්‍රශස්තිකරණය සහ කේත කාර්ය සාධනය ගැන සිතන්නේ නැත. ප්රධාන දෙය නම් ක්රියාකාරිත්වය, ඉක්මනින් නියමුවෙකු පෙරළීම සහ උපකල්පන පරීක්ෂා කිරීමයි. බර වැඩි වුවහොත් අපි යකඩ පොම්ප කරන්නෙමු. අපි එය දෙවරක් හෝ තුන් වතාවක්, පස් වතාවක්, සමහර විට 10 ගුණයක් වැඩි කරන්නෙමු. මෙහි කොහේ හරි - මුදල් තවදුරටත් ඉඩ දෙන්නේ නැත. පරිශීලකයින් සංඛ්යාව කොපමණ වාරයක් වැඩි වේද? එය 2-5-10 වගේ නොවේ, නමුත් සාර්ථක නම්, එය 100-1000 සිට 100 දහසක් දක්වා වේ. එනම්, ඉක්මනින් හෝ පසුව, ඔබ ප්රශස්තකරණය කිරීමට සිදු වනු ඇත.

කේතයේ යම් කොටසක් (අපි මෙම කොටස ශ්‍රිතයක් ලෙස හඳුන්වමු) අවිනීත ලෙස දිගු කාලයක් ගත වන බව කියමු, අපට ක්‍රියාත්මක කිරීමේ කාලය අඩු කිරීමට අවශ්‍ය වේ. ශ්‍රිතයක් දත්ත සමුදායකට ප්‍රවේශ වීම විය හැකිය, නැතහොත් එය කිසියම් සංකීර්ණ තර්කනයක් ක්‍රියාත්මක කිරීම විය හැකිය - ප්‍රධාන දෙය නම් එය සම්පූර්ණ කිරීමට බොහෝ කාලයක් ගත වීමයි. ඔබට ක්රියාත්මක කිරීමේ කාලය කොපමණ අඩු කළ හැකිද? සීමාව තුළ, ඔබට එය ශුන්‍යයට අඩු කළ හැකිය, තවත් නැත. ක්‍රියාත්මක කිරීමේ කාලය බිංදුවට අඩු කරන්නේ කෙසේද? පිළිතුර: ක්‍රියාත්මක කිරීම සම්පූර්ණයෙන්ම ඉවත් කරන්න. ඒ වෙනුවට, ප්රතිඵලය වහාම ආපසු ලබා දෙන්න. ප්රතිඵලය ඔබට දැනගත හැක්කේ කෙසේද? පිළිතුර: එය ගණනය කරන්න හෝ කොහේ හරි බලන්න. ගණනය කිරීමට බොහෝ කාලයක් ගත වේ. සහ ඔත්තු බැලීම යනු, උදාහරණයක් ලෙස, එකම පරාමිති සමඟ කැඳවූ විට ශ්‍රිතය අවසන් වරට නිපදවූ ප්‍රතිඵලය මතක තබා ගැනීමයි.

එනම්, කාර්යය ක්රියාත්මක කිරීම අපට වැදගත් නොවේ. ප්රතිඵලය රඳා පවතින්නේ කුමන පරාමිතීන් මතදැයි දැන ගැනීමට පමණක් ප්රමාණවත් වේ. එවිට, පරාමිති අගයන් යම් ආචයනයක යතුරක් ලෙස භාවිතා කළ හැකි වස්තුවක ස්වරූපයෙන් නිරූපණය කරන්නේ නම්, ගණනය කිරීමේ ප්‍රති result ලය සුරැකිය හැකි අතර ඊළඟ වතාවට එය ප්‍රවේශ වූ විට කියවිය හැකිය. මෙම ලිවීම සහ ප්රතිඵලය කියවීම ශ්රිතය ක්රියාත්මක කිරීමට වඩා වේගවත් නම්, වේගය අනුව අපට ලාභයක් ඇත. ලාභයේ ප්‍රමාණය 100, 1000 සහ 100 ගුණයකට ළඟා විය හැකිය (10 ^ 5 යනු ව්‍යතිරේකයකි, නමුත් තරමක් පසුගාමී පදනමක දී එය තරමක් හැකි ය).

හැඹිලි පද්ධතියක් සඳහා මූලික අවශ්‍යතා

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

අපි මේ නඩුව සෙල්ලම් කරමු.

අපි හිතමු අපි දැනට තියෙන load එක Hardware එක්ක දීල දැන් ටිකෙන් ටික caching හදුන්වා දෙනවා. පරිශීලකයින් සංඛ්යාව ටිකක් වර්ධනය වේ, භාරය වර්ධනය වේ - අපි කුඩා හැඹිලි එකතු කරන්න, එය මෙහි සහ එහි ඉස්කුරුප්පු කරන්න. මෙය යම් කාලයක් සඳහා දිගටම පවතින අතර, දැන් බර කාර්යයන් ප්‍රායෝගිකව තවදුරටත් හැඳින්වෙන්නේ නැත - සම්පූර්ණ ප්‍රධාන බර හැඹිලිය මතට වැටේ. මෙම කාලය තුළ පරිශීලකයින් සංඛ්යාව N ගුණයකින් වැඩි වී ඇත.

තවද දෘඪාංගවල ආරම්භක සැපයුම 2-5 ගුණයක් විය හැකි නම්, හැඹිලියේ ආධාරයෙන් අපට කාර්ය සාධනය 10 ගුණයකින් හෝ, හොඳ අවස්ථාවක, 100 ගුණයකින්, සමහර ස්ථානවල සමහර විට සාධකයකින් වැඩි දියුණු කළ හැකිය. 1000. එනම්, එකම දෘඪාංගයේ - අපි 100 ගුණයකින් වැඩි ඉල්ලීම් සකස් කරමු. නියමයි, ඔබ ඉඟුරු පාන් ලැබීමට සුදුසුයි!

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

ආරම්භක භාරයට සාපේක්ෂව, අපගේ යකඩ සංචිතය 2-5 ගුණයක් වූ අතර, මෙම කාලය තුළ බර 10-100 ගුණයකින් වැඩි විය. හැඹිලිය භාවිතා කරමින්, අපි බර ක්‍රියාකාරකම් සඳහා වන ඇමතුම් ඉවත් කළ අතර එම නිසා සියල්ල ක්‍රියාත්මක විය. දැන්, හැඹිලියක් නොමැතිව, අපගේ පද්ධතිය කොපමණ වාරයක් මන්දගාමී වේවිද? අපට කුමක් සිදුවේද? පද්ධතිය වැටෙනු ඇත.

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

නිගමනය: අධික ලෙස පටවා ඇති නිෂ්පාදන ව්‍යාපෘති සඳහා හැඹිලි පද්ධතියක් අවශ්‍ය වන්නේ ඉහළ කියවීමේ සහ ලිවීමේ වේගයක් තිබීම පමණක් නොව, දත්ත ආරක්ෂාව සහ අසාර්ථකත්වයන්ට ප්‍රතිරෝධය සහතික කිරීම සඳහා ය.

තේරීමේ වේදනාව

පරිපාලක මණ්ඩලයක් සහිත ව්‍යාපෘතියක, තේරීම මේ ආකාරයට සිදු විය: පළමුව අපි Hazelcast ස්ථාපනය කළෙමු, මන්ද ප්‍රධාන වෙබ් අඩවියේ අත්දැකීම් වලින් අපි දැනටමත් මෙම නිෂ්පාදනය ගැන හුරුපුරුදුව සිටිමු. නමුත් මෙහිදී මෙම තේරීම අසාර්ථක විය - අපගේ පැටවුම් පැතිකඩ යටතේ, Hazelcast යනු මන්දගාමී නොවේ, නමුත් දරුණු ලෙස මන්දගාමී වේ. ඒ වන විටත් අපි නිකුත් කරන දිනය සඳහා ලියාපදිංචි වී සිටිමු.

ස්පොයිලර්: අපට මෙතරම් විශාල ගනුදෙනුවක් මග හැරී උග්‍ර හා නොසන්සුන්කාරී තත්වයක් ඇති වූ තත්වයන් හරියටම වර්ධනය වූයේ කෙසේද - මම ඔබට දෙවන කොටසේදී කියන්නම් - සහ අපි අවසන් වූ ආකාරය සහ අපි පිටතට ගිය ආකාරය. නමුත් දැන් - මම කියන්නේ එය විශාල ආතතියක් බවත්, “සිතීමට - කෙසේ හෝ මට සිතිය නොහැක, අපි බෝතලය සොලවන්නෙමු.” "බෝතලය සෙලවීම" ද spoiler වේ, පසුව වැඩි විස්තර.

අපි කළ දේ:

1. අපි Google සහ StackOverflow යෝජනා කරන සියලුම පද්ධති ලැයිස්තුවක් සාදන්නෙමු. 30ට ටිකක් වැඩියි
2. නිෂ්පාදනය සඳහා සාමාන්ය බරක් සහිතව අපි පරීක්ෂණ ලියන්නෙමු. මෙය සිදු කිරීම සඳහා, අපි නිෂ්පාදන පරිසරයක් තුළ පද්ධතිය හරහා ගමන් කරන දත්ත වාර්තා කළෙමු - ජාලයේ නොව පද්ධතිය තුළ දත්ත සඳහා ස්නයිෆර් වර්ගයකි. පරීක්ෂණ වලදී හරියටම මෙම දත්ත භාවිතා කරන ලදී.
3. මුළු කණ්ඩායම සමඟම, සෑම කෙනෙකුම ලැයිස්තුවෙන් ඊළඟ පද්ධතිය තෝරා, එය වින්‍යාස කර, පරීක්ෂණ පවත්වයි. එය පරීක්ෂණය සමත් නොවේ, එය බර උසුලන්නේ නැත - අපි එය ඉවතට විසි කර පේළියේ ඊළඟට යන්නෙමු.
4. 17 වන ක්‍රමයේදී සියල්ල බලාපොරොත්තු රහිත බව පැහැදිලි විය. බෝතලය සෙලවීම නවත්වන්න, බැරෑරුම් ලෙස සිතීමට කාලයයි.

නමුත් පෙර සූදානම් කළ පරීක්ෂණ වලදී "වේගය හරහා ගමන් කරන" පද්ධතියක් තෝරා ගැනීමට අවශ්ය වූ විට මෙය විකල්පයකි. තවමත් එවැනි පරීක්ෂණ නොමැති නම් සහ ඔබට ඉක්මනින් තෝරා ගැනීමට අවශ්‍ය නම් කුමක් කළ යුතුද?

අපි මෙම විකල්පය ආදර්ශයට ගනිමු (මධ්‍යම+ සංවර්ධකයෙකු රික්තකයක ජීවත් වේ යැයි සිතීම දුෂ්කර ය, සහ තෝරා ගන්නා අවස්ථාවේ දී කුමන නිෂ්පාදනයක් පළමුව උත්සාහ කළ යුතුද යන්න පිළිබඳ ඔහුගේ මනාපය තවම විධිමත් කර නැත - එබැවින්, වැඩිදුර තර්ක කිරීම න්‍යායික/දර්ශනවාදයට වඩා වැඩි ය. කනිෂ්ඨයෙක් ගැන).

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

ඔබ දැන් ආරම්භ කර එය ගූගල් කරන්නේ නම්, ඇණවුම ලබා දෙන්න හෝ ගන්න, නමුත් පොදුවේ, මාර්ගෝපදේශ මේ වගේ වනු ඇත. පළමුවෙන්ම, ඔබට රෙඩිස් හමුවනු ඇත, එය සෑම තැනකම ඇසේ. එවිට EhCache යනු පැරණිතම සහ වඩාත්ම ඔප්පු කළ පද්ධතිය බව ඔබට වැටහෙනු ඇත. මීළඟට අපි විසඳුමේ අද්විතීය අංගයක් ඇති දේශීය සංවර්ධනයක් වන Tarantool ගැන ලියන්නෙමු. තවද එය දැන් ජනප්‍රියත්වයේ ඉහළ යමින් පවතින අතර SberTech හි සහයෝගය භුක්ති විඳින බැවින්, Ignite. අවසානයේ Hazelcast ද ඇත, මන්ද ව්යවසාය ලෝකයේ එය බොහෝ විට විශාල සමාගම් අතර දක්නට ලැබේ.

ලැයිස්තුව සම්පූර්ණ නොවේ; පද්ධති දුසිම් ගණනක් ඇත. තවද අපි එක දෙයක් පමණක් අවුල් කරන්නෙමු. "රූපලාවන්ය තරඟය" සඳහා තෝරාගත් පද්ධති 5 ක් ගෙන තේරීමක් කරමු. ජයග්‍රාහකයා කවුද?

Redis

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

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

EhCache

EhCache - "ජාවා සඳහා බහුලව භාවිතා වන හැඹිලිය" (නිල වෙබ් අඩවියෙන් සටන් පාඨයේ පරිවර්තනය). එසේම opensource. එතකොට අපිට තේරෙනවා රෙඩිස් ජාවා වලට නෙවෙයි සාමාන්‍ය, ඒකත් එක්ක අන්තර් ක්‍රියා කරන්න ඔයාට wrapper එකක් ඕන. සහ EhCache වඩාත් පහසු වනු ඇත. පද්ධතිය පොරොන්දු වන්නේ වෙන කුමක් ද? විශ්වසනීයත්වය, ඔප්පු කර ඇති, සම්පූර්ණ ක්රියාකාරිත්වය. හොඳයි, එය ද වඩාත් සුලභ ය. සහ ටෙරාබයිට් දත්ත ගබඩා කරයි.

Redis අමතක වී ඇත, මම EhCache තෝරා ගැනීමට සූදානම්.

නමුත් දේශප්‍රේමය පිළිබඳ හැඟීමක් ටැරන්ටූල්හි හොඳ කුමක්දැයි බැලීමට මා තල්ලු කරයි.

ටැරන්ටූල්

ටැරන්ටූල් - "තත්‍ය කාලීන දත්ත ඒකාබද්ධ කිරීමේ වේදිකාව" යන නාමය සපුරාලයි. එය ඉතා සංකීර්ණ බවක් පෙනේ, එබැවින් අපි පිටුව විස්තරාත්මකව කියවා ශබ්ද නගා ප්‍රකාශයක් සොයා ගනිමු: “RAM හි දත්ත වලින් 100% ක් හැඹිලි කරයි.” මෙය ප්රශ්න මතු කළ යුතුය - සියල්ලට පසු, මතකයට වඩා බොහෝ දත්ත තිබිය හැක. පැහැදිලි කිරීම නම්, ටැරන්ටූල් මතකයෙන් තැටියට දත්ත ලිවීමට අනුක්‍රමිකකරණය ක්‍රියාත්මක නොකරන බවයි. ඒ වෙනුවට, එය ඉතා හොඳ I/O කාර්ය සාධනයක් සහිත ගොනු පද්ධතියකට මතකය සරලව සිතියම්ගත කළ විට, පද්ධතියේ පහත් මට්ටමේ විශේෂාංග භාවිතා කරයි. පොදුවේ ගත් කල, ඔවුන් පුදුම සහ සිසිල් දෙයක් කළා.

අපි ක්රියාත්මක කිරීම් දෙස බලමු: Mail.ru ආයතනික අධිවේගී මාර්ගය, Avito, Beeline, Megafon, Alfa-Bank, Gazprom ...

ටැරන්ටූල් ගැන තවමත් යම් සැකයක් තිබේ නම්, Mastercard හි ක්‍රියාත්මක කිරීමේ නඩුව මා අවසන් කරයි. මම ටැරන්ටූල් ගන්නවා.

නමුත් කොයි හැටි වුවත්…

ඉගිලෙන්න

… තව ටිකක් තියෙනවද ඉගිලෙන්න, "in-memory computing platform... in-memory speeds on data petabytes" ලෙස බිල් කරනු ලැබේ. මෙහි බොහෝ වාසි ද ඇත: බෙදා හරින ලද මතකයේ හැඹිලිය, වේගවත්ම යතුරු අගය ගබඩා කිරීම සහ හැඹිලිය, තිරස් පරිමාණය, ඉහළ ලබා ගැනීමේ හැකියාව, දැඩි අඛණ්ඩතාව. පොදුවේ ගත් කල, වේගවත්ම දැල්වීම බව පෙනේ.

ක්‍රියාත්මක කිරීම්: Sberbank, American Airlines, Yahoo! ජපානය. ඉන්පසුව මම Ignite Sberbank හි ක්‍රියාත්මක කර ඇති බව පමණක් නොව, නිෂ්පාදනය පිරිපහදු කිරීම සඳහා SberTech කණ්ඩායම එහි පුද්ගලයින් Ignite කණ්ඩායම වෙත යවයි. මෙය සම්පූර්ණයෙන්ම ආකර්ශනීය වන අතර මම Ignite ගැනීමට සූදානම්.

එයට හේතුව සම්පූර්ණයෙන්ම අපැහැදිලි ය, මම පස්වන කරුණ දෙස බලමි.

Hazelcast

මම සයිට් එකට යනවා Hazelcast, කියවීම. බෙදා හරින ලද හැඹිලිගත කිරීම සඳහා වේගවත්ම විසඳුම Hazelcast බව පෙනේ. එය අනෙකුත් සියලුම විසඳුම් වලට වඩා විශාලත්වයේ ඇණවුම් වන අතර සාමාන්‍යයෙන් එය මතකයේ දත්ත ජාලයේ ප්‍රමුඛයා වේ. මෙම පසුබිමට එරෙහිව, වෙනත් දෙයක් ගැනීම යනු ඔබටම ගරු කිරීම නොවේ. දත්ත නැතිවීමකින් තොරව පොකුරු අඛණ්ඩව ක්‍රියාත්මක කිරීම සඳහා එය අතිරික්ත දත්ත ගබඩා කිරීම ද භාවිතා කරයි.

ඒක තමයි, මම Hazelcast ගන්න සූදානම්.

සංසන්දනය

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

අපිට මේ වගේ එකක් හම්බෙනවා සමාලෝචනය, අපගේ පද්ධති 5 තෝරන්න.

මෙන්න ඒවා වර්ග කර ඇත: Redis ඉහළින්ම සිටී, Hazelcast දෙවන ස්ථානයේ සිටී, Tarantool සහ Ignite ජනප්‍රිය වෙමින් පවතී, EhCache වී ඇති අතර එලෙසම පවතී.

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

මෙම පද්ධති සියල්ලම හැඹිලි පද්ධති පමණක් නොවේ. දත්ත සැකසීම සඳහා සේවාදායකයා වෙත පොම්ප නොකරන විට, නමුත් අනෙක් අතට: දත්ත මත ක්‍රියාත්මක කළ යුතු කේතය සේවාදායකය වෙත ගෙන යන විට, එහි ක්‍රියාත්මක වන අතර ප්‍රතිඵලය ආපසු ලබා දීම ඇතුළුව ඒවාට බොහෝ ක්‍රියාකාරීත්වයක් ඇත. තවද ඒවා බොහෝ විට හැඹිලිගත කිරීම සඳහා වෙනම පද්ධතියක් ලෙස නොසැලකේ.

හරි, අපි අත් නොහරිමු, අපි පද්ධතිවල සෘජු සැසඳීමක් සොයා ගනිමු. අපි ඉහළම විකල්ප දෙක ගනිමු - Redis සහ Hazelcast. අපි වේගය ගැන උනන්දු වන අතර, මෙම පරාමිතිය මත පදනම්ව අපි ඒවා සංසන්දනය කරමු.

Hz එදිරිව Redis

අපි මේක හොයාගන්නවා සංසන්දනය:


නිල් යනු Redis, රතු යනු Hazelcast. Hazelcast සෑම තැනකම ජයග්‍රහණය කරන අතර මේ සඳහා තාර්කිකත්වයක් ඇත: එය බහු-නූල්, ඉහළ ප්‍රශස්තිකරණය කර ඇත, සෑම නූල් එකක්ම තමන්ගේම කොටසකින් ක්‍රියා කරයි, එබැවින් අවහිර කිරීම් නොමැත. සහ Redis තනි නූල්; එය නවීන බහු-core CPU වලින් ප්‍රයෝජන නොගනී. Hazelcast සතුව අසමමුහුර්ත I/O ඇත, Redis-Jedis අවහිර කරන සොකට් ඇත. සියල්ලට පසු, Hazelcast ද්විමය ප්‍රොටෝකෝලයක් භාවිතා කරයි, සහ Redis පෙළ කේන්ද්‍රීය වේ, එනම් එය අකාර්යක්ෂමයි.

එසේ නම්, අපි වෙනත් සංසන්දනාත්මක මූලාශ්‍රයක් වෙත හැරෙමු. ඔහු අපට පෙන්වන්නේ කුමක්ද?

රෙඩිස් එදිරිව Hz

තව එකක් සංසන්දනය:


මෙන්න, ඊට පටහැනිව, රතු යනු Redis වේ. එනම්, Redis කාර්ය සාධනය අනුව Hazelcast අභිබවා යයි. Hazelcast පළමු සංසන්දනය දිනා ගත් අතර, රෙඩිස් දෙවැන්න දිනා ගත්තේය. මෙතනම පෙර සංසන්දනය Hazelcast ජයග්‍රහණය කළේ මන්දැයි ඉතා නිවැරදිව පැහැදිලි කළේය.

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

බෝතලය සොලවමින්

අප දැන් කර ඇති සමස්ත ක්‍රියාවලිය පහත රූපකයෙන් මට පැහැදිලි කළ හැකිය: “බෝතලය සෙලවීම”. එනම්, දැන් ඔබට ක්‍රමලේඛනය කිරීමට අවශ්‍ය නැත, දැන් ප්‍රධාන දෙය නම් ස්ටැක්වර්ෆ්ලෝ කියවීමට හැකි වීමයි. මගේ කණ්ඩායමේ පුද්ගලයෙක්, වෘත්තිකයෙක්, තීරණාත්මක අවස්ථාවන්හිදී හරියටම මේ ආකාරයට ක්‍රියා කරයි.

ඔහු මොනවද කරන්නේ? ඔහු කැඩුණු දෙයක් දකියි, තොග හෝඩුවාවක් දකියි, එයින් වචන කිහිපයක් ලබා ගනී (ඒවා වැඩසටහන පිළිබඳ ඔහුගේ ප්‍රවීණත්වය), ගූගල් හි සෙවුම් කරයි, පිළිතුරු අතර ගොඩගැසී ඇත. ප්‍රශ්නයට පිළිතුරු කියවීමෙන් තොරව, නොසිතා, ඔහු තෝරා ගන්නේ “මෙය කරන්න සහ එය කරන්න” යන වාක්‍යයට වඩාත්ම සමාන දෙයක් (එවැනි පිළිතුරක් තෝරා ගැනීම ඔහුගේ දක්ෂතාවයයි, මන්ද එය සැමවිටම වැඩි කැමැත්තක් ලබා ගත් පිළිතුර නොවේ) අදාළ වේ , පෙනුම: යමක් වෙනස් වී ඇත්නම්, විශිෂ්ටයි. එය වෙනස් වී නොමැති නම්, එය ආපසු පෙරළන්න. දියත් කිරීම-පරීක්ෂා කිරීම-සෙවීම නැවත කරන්න. මෙම බුද්ධිමය ආකාරයෙන්, කේතය ටික වේලාවකට පසු ක්‍රියා කරන බව ඔහු සහතික කරයි. ඔහු දන්නේ නැහැ ඇයි, ඔහු කළේ කුමක්ද කියා ඔහු දන්නේ නැහැ, ඔහුට පැහැදිලි කරන්න බැහැ. එහෙත්! මෙම ආසාදනය ක්රියා කරයි. සහ "ගින්න නිවී ඇත." දැන් අපි බලමු අපි මොනවද කළේ කියලා. වැඩසටහන ක්‍රියාත්මක වන විට, එය විශාලත්වයේ අනුපිළිවෙලක් පහසු වේ. ඒ වගේම ගොඩක් කාලය ඉතිරි වෙනවා.

මෙම උදාහරණය සමඟ මෙම ක්රමය ඉතා හොඳින් පැහැදිලි කර ඇත.

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

එවැනි ක්රමයක් තිබේ, ඉතා වේගවත් හා ඉතා ඵලදායී.

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

අපි මේ දෙයක් කෙනෙකුට පෙන්වන්නෙමු: "Seryoga, ඔයාට පේනවද!?" ඇත්ත වශයෙන්ම, දුර සිට එය නැවක් මෙන් පෙනේ. නමුත් මේක දිගටම කරගෙන යන්න දෙන්න බැහැ.

තවත් ක්රමයක් තිබේ. ඒවා භාවිතා කරන්නේ හැකර්වරුන් වැනි වඩාත් දියුණු පුද්ගලයින් විසිනි.

මම මේ මිනිහට ටාස්ක් එකක් දුන්නා, එයා හැමදේම කරලා ගියා. ඔබ බලන්න - එය සිදු වී ඇති බව පෙනේ. සහ ටික වේලාවකට පසු, කේතය අවසන් කිරීමට අවශ්ය වූ විට, මෙය ඔහු නිසා ආරම්භ වේ ... ඔහු දැනටමත් බොහෝ දුර ධාවනය කිරීමට සමත් වී ඇති බව හොඳය. බෝතලයක උදාහරණය භාවිතා කරමින් මෙය කරන්නේ මේ අය ය: ඔබට පෙනේ, පතුල කොතැනද, වීදුරුව නැමෙයි. තවද එය විනිවිදභාවයෙන් යුක්තද නැද්ද යන්න සම්පූර්ණයෙන්ම පැහැදිලි නැත. එවිට "හැකර්" මෙම පතුල කපා, එහි නැවක් ඇතුල් කරන්න, ඉන්පසු නැවතත් පතුලේ නැවත ඇලවීම, එය එසේ විය යුතු බව පෙනේ.

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

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

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

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

බෝතල් ගෙල සොයන්නේ කොහෙන්ද

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

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

අපට කේත තර්කය (2) ද අවශ්‍ය වේ, එය ඇත්ත වශයෙන්ම හැඹිලිගත කිරීම ගැන ය. සමහර API හරහා මෙම කේතය සමඟ ගනුදෙනුකරුවන් අන්තර්ක්‍රියා කරයි. සේවාලාභී කේතය (1) එකම JVM තුළ හෝ ජාලය හරහා ප්‍රවේශ විය හැක. ඇතුළත ක්‍රියාත්මක වන තර්කය වන්නේ හැඹිලියේ තැබිය යුතු වස්තූන් මොනවාද සහ ඉවතට විසි කළ යුතු දේ තීරණය කිරීමයි. හැඹිලිය ගබඩා කිරීම සඳහා අපි මතකය (3) භාවිතා කරමු, නමුත් අවශ්‍ය නම්, අපට තැටියේ (4) සමහර දත්ත සුරැකිය හැක.

බර පැටවීම සිදුවන්නේ කුමන කොටස්වලදැයි බලමු. ඇත්ත වශයෙන්ම, සෑම ඊතලයක්ම සහ සෑම නෝඩයක්ම පටවනු ලැබේ. පළමුව, සේවාදායක කේතය සහ api අතර, මෙය ජාල සන්නිවේදනයක් නම්, ගිලාබැසීම තරමක් කැපී පෙනේ. දෙවනුව, api හි රාමුව තුළම - අපි සංකීර්ණ තර්කනය සමඟ එය ඉක්මවා ගියහොත්, අපට CPU සමඟ ගැටළු ඇති විය හැක. තවද තර්කනය මතකය මත කාලය නාස්ති නොකරන්නේ නම් හොඳයි. ගොනු පද්ධතිය සමඟ අන්තර්ක්‍රියා පවතී - සාමාන්‍ය අනුවාදයේ මෙය අනුක්‍රමික / ප්‍රතිසාධනය සහ ලිවීම / කියවීම වේ.

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

දැන්, එක් අතකින්, අපගේ කේතයෙන් ඉල්ලීම් සැකසීමේදී හැඹිලි පද්ධතියේ “මොන ගියර් හැරෙන්නේද” අපට සිතාගත හැකි අතර, අනෙක් අතට, අපගේ කේතය මෙම පද්ධතිය සඳහා කුමන සහ කොපමණ ඉල්ලීම් ජනනය කරයිද යන්න අපට තක්සේරු කළ හැකිය. අපගේ භාවිත නඩුව සඳහා පද්ධතියක් තෝරා ගැනීමට - වැඩි හෝ අඩු සන්සුන් තේරීමක් කිරීමට මෙය ප්රමාණවත් වේ.

Hazelcast

මෙම විසංයෝජනය අපගේ ලැයිස්තුවට යොදන්නේ කෙසේදැයි බලමු. උදාහරණයක් ලෙස, Hazelcast.

Hazelcast වෙතින් දත්ත තැබීමට/ගැනීම සඳහා, සේවාදායක කේතය (1) api වෙත ප්‍රවේශ වේ. Hz ඔබට සේවාදායකය embedded ලෙස ක්‍රියාත්මක කිරීමට ඉඩ සලසයි, මෙම අවස්ථාවේදී, api වෙත ප්‍රවේශ වීම JVM තුළ ඇති ක්‍රම ඇමතුමකි, එය නොමිලේ ලෙස සැලකිය හැකිය.

(2) හි තර්කනය ක්‍රියා කිරීම සඳහා, Hz අනුක්‍රමික යතුරේ බයිට් අරාවේ හැෂ් මත රඳා පවතී - එනම් යතුර ඕනෑම අවස්ථාවක අනුක්‍රමික වේ. Hz සඳහා මෙය නොවැළැක්විය හැකිය.
නෙරපා හැරීමේ උපාය මාර්ග හොඳින් ක්‍රියාත්මක වේ, නමුත් විශේෂ අවස්ථා සඳහා ඔබට ඔබේම දෑ එකතු කළ හැකිය. ඔබ මෙම කොටස ගැන කරදර විය යුතු නැත.

ගබඩා (4) සම්බන්ධ කළ හැක. මහා. කාවැද්දූ සඳහා අන්තර්ක්‍රියා (5) ක්ෂණික ලෙස සැලකිය හැකිය. පොකුරේ නෝඩ් අතර දත්ත හුවමාරුව (6) - ඔව්, එය පවතී. මෙය වේගයේ වියදමින් වැරදි ඉවසීමේ ආයෝජනයකි. Hz විශේෂාංගය Near-cache මඟින් ඔබට මිල අඩු කිරීමට ඉඩ සලසයි - පොකුරේ ඇති අනෙකුත් නෝඩ් වලින් ලැබෙන දත්ත හැඹිලිගත වනු ඇත.

වේගය වැඩි කිරීම සඳහා එවැනි තත්වයන් තුළ කළ හැක්කේ කුමක්ද?

උදාහරණයක් ලෙස, (2) හි යතුර අනුක්‍රමික වීම වැළැක්වීම සඳහා - උණුසුම්ම දත්ත සඳහා, Hazelcast මත තවත් හැඹිලියක් අමුණන්න. Sportmaster මේ සඳහා කැෆේන් තෝරා ගත්තේය.

(6) මට්ටමේ twisting සඳහා, Hz ගබඩා වර්ග දෙකක් ඉදිරිපත් කරයි: IMap සහ ReplicatedMap.


Hazelcast Sportmaster තාක්‍ෂණ තොගයට ඇතුළු වූ ආකාරය සඳහන් කිරීම වටී.

2012 දී, අපි අනාගත වෙබ් අඩවියේ පළමු නියමුවා මත වැඩ කරන විට, සෙවුම් යන්ත්‍රය ආපසු ලබා දුන් පළමු සබැඳිය බවට පත් වූයේ Hazelcast ය. හඳුනන අය “පළමු වතාවට” පටන් ගත්හ - පැය දෙකකට පසුව, අපි Hz පද්ධතියට ඉස්කුරුප්පු කළ විට, එය ක්‍රියාත්මක වූ බව අපගේ සිත් ගත්තේය. ඒ වගේම හොඳට වැඩ කළා. දවස අවසන් වන විට අපි පරීක්ෂණ ගණනාවක් අවසන් කර සතුටින් සිටියෙමු. Hz කාලයත් සමඟ ඇති කළ විස්මයන් ජය ගැනීමට මෙම ශක්තියේ සංචිතය ප්‍රමාණවත් විය. දැන් Sportmaster කණ්ඩායමට Hazelcast අත්හැරීමට හේතුවක් නැත.

නමුත් "සෙවුම් යන්ත්රයේ පළමු සබැඳිය" සහ "HelloWorld ඉක්මනින් එකලස් කරන ලදී" වැනි එවැනි තර්ක, ඇත්ත වශයෙන්ම, තේරීම සිදු වූ මොහොතේ ව්යතිරේකයක් සහ ලක්ෂණයකි. තෝරාගත් පද්ධතිය සඳහා සැබෑ පරීක්ෂණ ආරම්භ වන්නේ නිෂ්පාදනයට මුදා හැරීමත් සමඟ වන අතර, හැඹිලි ඇතුළු ඕනෑම පද්ධතියක් තෝරාගැනීමේදී ඔබ අවධානය යොමු කළ යුත්තේ මෙම අදියරේදීය. ඇත්ත වශයෙන්ම, අපගේ නඩුවේදී, අපි අහම්බෙන් Hazelcast තෝරා ගත් බව පැවසිය හැකිය, නමුත් පසුව අපි නිවැරදිව තෝරා ගත් බව පෙනී ගියේය.

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

මෙම සියලු අවශ්‍යතා සඳහා, Hazelcast නිසැකවම බිල්පතට ගැලපේ.

ඉදිරියට පැවැත්වේ

නමුත් Hazelcast කෝකටත් තෛලයක් නොවේ. 2017 දී, අපි පරිපාලක හැඹිලිය සඳහා Hazelcast තෝරා ගත්තෙමු, හුදෙක් අතීත අත්දැකීම් වලින් හොඳ හැඟීම් මත පදනම්ව. මෙය ඉතා කුරිරු විහිළුවක ප්‍රධාන කාර්යභාරයක් ඉටු කළ අතර, එම නිසා අපි දුෂ්කර තත්වයකට පත් වූ අතර “වීර ලෙස” දින 60 ක් එයින් ඉවත් විය. නමුත් ඒ ගැන වැඩි විස්තර ඊළඟ කොටසින්.

මේ අතරතුර... සුභ නව කේතයක්!

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