HighLoad++, Mikhail Tyulenev (MongoDB): හේතුඵල අනුකූලතාව: න්‍යායේ සිට ප්‍රායෝගිකත්වය දක්වා

මීළඟ HighLoad++ සම්මන්ත්‍රණය 6 අප්‍රේල් 7 සහ 2020 යන දිනවල ශාන්ත පීටර්ස්බර්ග්හිදී පැවැත්වේ.
විස්තර සහ ටිකට්පත් ලින්ක්. HighLoad++ සයිබීරියාව 2019. ශාලාව "Krasnoyarsk". ජූනි 25, 12:00. මේවා සහ ඉදිරිපත් කිරීම.

HighLoad++, Mikhail Tyulenev (MongoDB): හේතුඵල අනුකූලතාව: න්‍යායේ සිට ප්‍රායෝගිකත්වය දක්වා

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

Mikhail Tyulenev (මෙතැන් සිට MT ලෙස හැඳින්වේ): – මම හේතුඵල අනුකූලතාව ගැන කතා කරන්නම් - මෙය අපි MongoDB හි වැඩ කළ විශේෂාංගයකි. මම වැඩ කරන්නේ බෙදා හරින ලද පද්ධති සමූහයක, අපි එය වසර දෙකකට පමණ පෙර කළා.

HighLoad++, Mikhail Tyulenev (MongoDB): හේතුඵල අනුකූලතාව: න්‍යායේ සිට ප්‍රායෝගිකත්වය දක්වා

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

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

හේතුකාරක අනුකූලතාව. අපි සංකල්ප නිර්වචනය කරමු

ආරම්භය සඳහා, මට සාමාන්‍යයෙන් කියන්නට අවශ්‍ය වන්නේ හේතුකාරක අනුකූලතාව යනු කුමක්ද යන්නයි. චරිත දෙකක් ඇත - Leonard සහ Penny (රූපවාහිනී කතා මාලාව "The Big Bang Theory"):

HighLoad++, Mikhail Tyulenev (MongoDB): හේතුඵල අනුකූලතාව: න්‍යායේ සිට ප්‍රායෝගිකත්වය දක්වා

අපි හිතමු Penny ඉන්නේ යුරෝපයේ සහ Leonard ඇයට පුදුම සාදයක් තියන්න ඕන කියලා. එමෙන්ම ඇයව ඔහුගේ මිතුරු ලැයිස්තුවෙන් ඉවතට විසි කිරීම, ඔහුගේ සියලු මිතුරන්ට සංග්‍රහය පිළිබඳ යාවත්කාලීනයක් යැවීමට වඩා හොඳ දෙයක් ගැන ඔහුට සිතිය නොහැක: "අපි පෙනි සතුටු කරමු!" (ඇය සිටින්නේ යුරෝපයේ, ඇය නිදා සිටියදී, ඇය මේ සියල්ල නොදකින අතර එය නොපෙනේ, ඇය එහි නොමැති නිසා). අවසානයේදී, ඇය මෙම පළ කිරීම මකා, සංග්‍රහයෙන් මකා දමා ප්‍රවේශය ප්‍රතිසාධනය කරයි, එවිට ඇය කිසිවක් නොදකින අතර කිසිදු අපකීර්තියක් සිදු නොවේ.
මේ සේරම හොඳයි, නමුත් අපි හිතමු සිස්ටම් එක බෙදිලා, වැඩේ ටිකක් වැරදුනා කියලා. උදාහරණයක් ලෙස, මෙම සටහන දර්ශනය වූ පසු Penny ගේ ප්‍රවේශ සීමා කිරීම සිදු විය හැක, සිදුවීම් හේතුව සහ බලපෑම අනුව සම්බන්ධ නොවේ නම්. ඇත්ත වශයෙන්ම, මෙය ව්‍යාපාරික කාර්යයක් සිදු කිරීම සඳහා හේතුකාරක අනුකූලතාව අවශ්‍ය වන විට (මෙම අවස්ථාවෙහි) උදාහරණයකි.

ඇත්ත වශයෙන්ම, මේවා දත්ත සමුදායේ ඉතා සුළු නොවන ගුණාංග වේ - ඉතා සුළු පිරිසක් ඒවාට සහාය දක්වයි. අපි ආකෘති වෙත යමු.

අනුකූලතා ආකෘති

දත්ත සමුදායේ අනුකූලතා ආකෘතියක් යනු කුමක්ද? සේවාලාභියාට ලැබිය හැකි දත්ත සහ කුමන අනුපිළිවෙලෙහිද යන්න පිළිබඳව බෙදා හරින ලද පද්ධතියක් ලබා දෙන සහතික සමහරකි.

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

එබැවින්, අනුකූලතා ආකෘති යොදනු ලබන්නේ බෙදා හරින ලද පද්ධති සඳහා පමණි. කලින් පැවති සහ එකම සිරස් පරිමාණයෙන් ක්‍රියාත්මක වූ සියලුම පද්ධති එවැනි ගැටළු වලට මුහුණ දුන්නේ නැත. එක් බෆර හැඹිලියක් තිබූ අතර, සෑම දෙයක්ම එයින් කියවනු ලැබේ.

මාදිලිය ශක්තිමත්

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

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

Spanner හි සහාය දක්වන තවත් ශක්තිමත් දේපලක් ඇත - බාහිර අනුකූලතාව ලෙස හැඳින්වේ. අපි ඒ ගැන ටිකක් පසුව කතා කරමු.

හේතුව

ඊලග එකා තමයි මම කතා කලේ හරියටම කියන එක. Strong සහ Causal අතර තවත් උප ලෙවල් කිහිපයක් තියෙනවා, මම ඒ ගැන කතා කරන්නේ නැහැ, නමුත් ඒවා සියල්ලම Causal දක්වා පහත වැටේ. මෙය වැදගත් ආකෘතියකි, මන්ද එය සියලු මාදිලිවල ශක්තිමත්ම, ජාලයක් හෝ කොටස් ඉදිරිපිට ඇති ශක්තිමත්ම අනුකූලතාවයයි.

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

අවසානයේ

තුන්වන ආකෘතිය වන්නේ අවසාන අනුකූලතාවයයි. සියලුම බෙදා හරින ලද පද්ධති සහය දක්වන්නේ මෙයයි, එය අර්ථවත් කරන අවම ආකෘතියයි. එය පහත සඳහන් දේ අදහස් වේ: අපි දත්තවල යම් වෙනස්කම් ඇති විට, යම් අවස්ථාවක දී ඒවා ස්ථාවර වේ.

එවැනි මොහොතක ඇය කිසිවක් නොකියයි, එසේ නොවුවහොත් ඇය බාහිර අනුකූලතාවයට හැරෙනු ඇත - එය සම්පූර්ණයෙන්ම වෙනස් කථාවක් වනු ඇත. එසේ වුවද, මෙය ඉතා ජනප්රිය ආකෘතියකි, වඩාත් පොදු වේ. පෙරනිමියෙන්, බෙදා හරින ලද පද්ධතිවල සියලුම පරිශීලකයින් අවසාන අනුකූලතාව භාවිතා කරයි.

මට සංසන්දනාත්මක උදාහරණ කිහිපයක් දීමට අවශ්‍යයි:

HighLoad++, Mikhail Tyulenev (MongoDB): හේතුඵල අනුකූලතාව: න්‍යායේ සිට ප්‍රායෝගිකත්වය දක්වා

මෙම ඊතල වලින් අදහස් කරන්නේ කුමක්ද?

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

CAP ප්රමේයය

අනුකූලතාව, ලබා ගත හැකි බව යන වචන ඔබ දකින විට - ඔබේ මතකයට එන්නේ කුමක්ද? ඒක හරි - CAP ප්‍රමේයය! දැන් මට මිථ්‍යාව දුරු කිරීමට අවශ්‍යයි ... ඒ මම නොවේ - අපූරු ලිපියක්, අපූරු පොතක් ලිවූ මාටින් ක්ලෙප්මන් ය.

HighLoad++, Mikhail Tyulenev (MongoDB): හේතුඵල අනුකූලතාව: න්‍යායේ සිට ප්‍රායෝගිකත්වය දක්වා

CAP ප්‍රමේයය 2000 ගණන්වල සකස් කරන ලද මූලධර්මයක් වන අතර එය අනුකූලතාව, පවතින බව, කොටස්: ඕනෑම දෙකක් ගන්න, ඔබට තුනක් තෝරාගත නොහැක. එය එක්තරා මූලධර්මයක් විය. එය වසර කිහිපයකට පසු ගිල්බට් සහ ලින්ච් විසින් ප්‍රමේයයක් ලෙස ඔප්පු කරන ලදී. ඉන්පසු මෙය මන්ත්‍රයක් ලෙස භාවිතා කිරීමට පටන් ගත්තේය - පද්ධති CA, CP, AP යනාදිය ලෙස බෙදීමට පටන් ගත්තේය.

මෙම ප්‍රමේයය ඇත්ත වශයෙන්ම පහත සඳහන් අවස්ථා සඳහා ඔප්පු විය... පළමුව, පවතින බව සලකනු ලැබුවේ ශුන්‍යයේ සිට සිය ගණනක් දක්වා අඛණ්ඩ අගයක් ලෙස නොවේ (0 - පද්ධතිය “මළ”, 100 - ඉක්මනින් ප්‍රතිචාර දක්වයි; අපි එය එසේ සලකා බැලීමට පුරුදු වී සිටිමු) , නමුත් ඇල්ගොරිතමයේ දේපලක් ලෙස, එහි සියලුම ක්‍රියාත්මක කිරීම් සඳහා එය දත්ත ආපසු ලබා දෙන බවට සහතික වේ.

ප්‍රතිචාර දැක්වීමේ කාලය ගැන වචනයක්වත් නැත! වසර 100කට පසු දත්ත ලබා දෙන ඇල්ගොරිතමයක් ඇත - CAP ප්‍රමේයයේ කොටසක් වන පරම අපූරු ලබා ගත හැකි ඇල්ගොරිතමයකි.
දෙවනුව: මෙම වෙනස්කම් ප්‍රතිප්‍රමාණ කළ හැකි වුවද, එකම යතුරේ අගයන්හි වෙනස්කම් සඳහා ප්‍රමේයය ඔප්පු විය. මෙයින් අදහස් කරන්නේ යථාර්ථයේ දී ඒවා ප්‍රායෝගිකව භාවිතා නොකරන බවයි, මන්ද ආකෘති වෙනස් අවසාන අනුකූලතාව, ශක්තිමත් අනුකූලතාව (සමහර විට).

මේ සියල්ල කුමක් සඳහාද? එපමනක් නොව, CAP ප්රමේයය එය ඔප්පු කරන ලද ආකෘතියේ හරියටම ප්රායෝගිකව අදාළ නොවන අතර කලාතුරකින් භාවිතා වේ. න්යායික ස්වරූපයෙන්, එය කෙසේ හෝ සියල්ල සීමා කරයි. එය බුද්ධිමය වශයෙන් නිවැරදි වන නමුත් පොදුවේ ඔප්පු කර නොමැති නිශ්චිත මූලධර්මයක් බවට පත්වේ.

හේතුකාරක අනුකූලතාව ශක්තිමත්ම ආකෘතියයි

දැන් සිදුවෙමින් පවතින්නේ ඔබට කොටස් තුනම ලබා ගත හැකි වීමයි: Consistency, Availability using Partitions. විශේෂයෙන්ම, Causal අනුකූලතාව ශක්තිමත්ම අනුකූලතා ආකෘතිය වන අතර, එය තවමත් කොටස් (ජාලයේ බිඳීම්) ඉදිරිපිට ක්රියා කරයි. ඒකයි මේ තරම් උනන්දුවක් තියෙන්නේ, ඒකයි අපි ඒක භාර ගත්තේ.

HighLoad++, Mikhail Tyulenev (MongoDB): හේතුඵල අනුකූලතාව: න්‍යායේ සිට ප්‍රායෝගිකත්වය දක්වා

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

MongoDB අභ්යන්තර කුස්සිය

දිවා ආහාරය බව මතක තබාගෙන අපි කුස්සියට ගියෙමු. මම ඔබට පද්ධති ආකෘතිය ගැන කියන්නම්, එනම්, පළමු වරට එවැනි දත්ත ගබඩාවක් ගැන අසන අයට MongoDB යනු කුමක්ද?

HighLoad++, Mikhail Tyulenev (MongoDB): හේතුඵල අනුකූලතාව: න්‍යායේ සිට ප්‍රායෝගිකත්වය දක්වා

HighLoad++, Mikhail Tyulenev (MongoDB): හේතුඵල අනුකූලතාව: න්‍යායේ සිට ප්‍රායෝගිකත්වය දක්වා

MongoDB (මෙතැන් සිට "MongoDB" ලෙස හඳුන්වනු ලැබේ) යනු තිරස් පරිමාණයට, එනම් ෂර්ඩින් කිරීමට සහය වන බෙදාහැරීමේ පද්ධතියකි; සහ එක් එක් ෂාර්ඩ් තුළ එය දත්ත අතිරික්තයට, එනම් අනුකරණයට ද සහාය වේ.

MongoDB හි බෙදා හැරීම (සම්බන්ධතා දත්ත ගබඩාවක් නොවේ) ස්වයංක්‍රීය සමතුලිතතාවයක් සිදු කරයි, එනම්, එක් එක් ලේඛන එකතුව (හෝ සම්බන්ධතා දත්ත අනුව “වගුව”) කැබලිවලට බෙදා ඇති අතර, සේවාදායකය ස්වයංක්‍රීයව ඒවා කැබලි අතර ගෙන යයි.

සේවාලාභියෙකු සඳහා ඉල්ලීම් බෙදා හරින Query Router යනු එය ක්‍රියාත්මක වන යම් සේවාලාභියෙකු වේ. එය දැනටමත් කොහේද සහ කුමන දත්තද යන්න දන්නා අතර සියලු ඉල්ලීම් නිවැරදි ෂාර්ඩ් වෙත යොමු කරයි.

තවත් වැදගත් කරුණක්: MongoDB යනු තනි මාස්ටර් ය. එක් ප්‍රාථමිකයක් ඇත - එයට එහි අඩංගු යතුරු සඳහා සහය දක්වන වාර්තා ගත හැකිය. ඔබට Multi-master write කරන්න බැහැ.

අපි 4.2 නිකුත් කළා - නව රසවත් දේවල් එහි දර්ශනය විය. විශේෂයෙන්, ඔවුන් Lucene - search - එනම් executable java කෙලින්ම Mongo වෙත ඇතුළු කළ අතර, Elastica හි මෙන් Lucene හරහා සෙවීම් සිදු කිරීමට එහිදී හැකි විය.

ඔවුන් නව නිෂ්පාදනයක් සාදන ලදී - ප්‍රස්ථාර, එය ඇට්ලස් (මොන්ගෝගේම වලාකුළ) මත ද ඇත. ඔවුන්ට නිදහස් ස්ථරයක් ඇත - ඔබට එය සමඟ සෙල්ලම් කළ හැකිය. මම ඇත්තටම ප්‍රස්ථාර වලට කැමතියි - දත්ත දෘශ්‍යකරණය, ඉතා බුද්ධිමත්.

අමුද්රව්ය හේතුකාරක අනුකූලතාව

මෙම මාතෘකාව පිළිබඳ ප්‍රකාශයට පත් කර ඇති ලිපි 230 ක් පමණ මම ගණන් කළෙමි - ලෙස්ලි ලැම්පර්ට් වෙතින්. දැන් මගේ මතකයෙන් මම ඔබට මෙම ද්රව්යවල කොටස් කිහිපයක් ඉදිරිපත් කරමි.

HighLoad++, Mikhail Tyulenev (MongoDB): හේතුඵල අනුකූලතාව: න්‍යායේ සිට ප්‍රායෝගිකත්වය දක්වා

මේ සියල්ල ආරම්භ වූයේ 1970 ගණන්වල ලියන ලද ලෙස්ලි ලැම්පර්ට්ගේ ලිපියකිනි. ඔබට පෙනෙන පරිදි, මෙම මාතෘකාව පිළිබඳ සමහර පර්යේෂණ තවමත් සිදු වෙමින් පවතී. දැන් හේතුකාරක අනුකූලතාව බෙදා හරින ලද පද්ධති සංවර්ධනය කිරීම සම්බන්ධයෙන් උනන්දුවක් දක්වයි.

සීමා කිරීම්

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

HighLoad++, Mikhail Tyulenev (MongoDB): හේතුඵල අනුකූලතාව: න්‍යායේ සිට ප්‍රායෝගිකත්වය දක්වා

  • පළමුවෙන්ම, මම දැනටමත් පවසා ඇති පරිදි "MongoDB" යනු තනි මාස්ටර් ය (මෙය බෙහෙවින් සරල කරයි).
  • පද්ධතිය කැබලි 10 ක් පමණ සහාය විය යුතු බව අපි විශ්වාස කරමු. මෙම අගය පැහැදිලිව සීමා කරන වාස්තු විද්‍යාත්මක තීරණයක් අපට ගත නොහැක.
  • අපට වලාකුළක් ඇත, නමුත් පුද්ගලයෙකුට ද්විමය බාගත කිරීමේදී, එය ඔහුගේ ලැප්ටොප් පරිගණකයේ ධාවනය කරන විට සහ සෑම දෙයක්ම හොඳින් ක්‍රියාත්මක වන විට ඔහුට තවමත් අවස්ථාව තිබිය යුතු යැයි අපි උපකල්පනය කරමු.
  • පර්යේෂණ කලාතුරකින් උපකල්පනය කරන දෙයක් අපි උපකල්පනය කරමු: බාහිර ගනුදෙනුකරුවන්ට ඔවුන්ට අවශ්‍ය ඕනෑම දෙයක් කළ හැකිය. MongoDB යනු විවෘත මූලාශ්‍රයකි. ඒ අනුව, ගනුදෙනුකරුවන් ඉතා බුද්ධිමත් හා කෝප විය හැකිය - ඔවුන්ට සියල්ල බිඳ දැමීමට අවශ්ය විය හැකිය. බයිසැන්තියානු ෆීලර්ස් ආරම්භ විය හැකි බව අපි අනුමාන කරමු.
  • පරිමිතියෙන් පිටත සිටින බාහිර සේවාලාභීන් සඳහා, වැදගත් සීමාවක් තිබේ: මෙම විශේෂාංගය අක්‍රිය කර ඇත්නම්, කාර්ය සාධනය පිරිහීමක් නිරීක්ෂණය නොකළ යුතුය.
  • තවත් කරුණක් සාමාන්‍යයෙන් ශාස්ත්‍රීය විරෝධී ය: පෙර අනුවාදවල සහ අනාගත ඒවායේ ගැළපුම. පැරණි ධාවක නව යාවත්කාලීන සඳහා සහය විය යුතු අතර දත්ත සමුදාය පැරණි ධාවක සඳහා සහය විය යුතුය.

පොදුවේ ගත් කල, මේ සියල්ල සීමාවන් පනවයි.

හේතුකාරක අනුකූලතා සංරචක

මම දැන් සමහර සංරචක ගැන කතා කරමි. අපි සාමාන්යයෙන් හේතුකාරක අනුකූලතාව සලකා බැලුවහොත්, අපට බ්ලොක් තෝරා ගත හැකිය. අපි නිශ්චිත කොටසකට අයත් කෘති වලින් තෝරා ගත්තෙමු: යැපීම් ලුහුබැඳීම, ඔරලෝසු තෝරා ගැනීම, මෙම ඔරලෝසු එකිනෙක සමමුහුර්ත කළ හැකි ආකාරය සහ අපි ආරක්ෂාව සහතික කරන්නේ කෙසේද - මෙය මම කතා කරන දේ පිළිබඳ දළ දළ සටහනකි:

HighLoad++, Mikhail Tyulenev (MongoDB): හේතුඵල අනුකූලතාව: න්‍යායේ සිට ප්‍රායෝගිකත්වය දක්වා

සම්පූර්ණ යැපුම් ලුහුබැඳීම

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

HighLoad++, Mikhail Tyulenev (MongoDB): හේතුඵල අනුකූලතාව: න්‍යායේ සිට ප්‍රායෝගිකත්වය දක්වා

මෙම උදාහරණයේ, curly වරහන් තුළ ඇති අංකය වාර්තා අංක වේ. සමහර විට අගයන් සහිත මෙම වාර්තා සම්පූර්ණයෙන් පවා මාරු කරනු ලැබේ, සමහර විට සමහර අනුවාද මාරු කරනු ලැබේ. අවසාන කරුණ නම් සෑම වෙනස්කමකම පෙර එක පිළිබඳ තොරතුරු අඩංගු වීමයි (පැහැදිලිවම මේ සියල්ල තමන් තුළම ගෙන යයි).

මෙම ප්‍රවේශය (සම්පූර්ණ ලුහුබැඳීම) භාවිතා නොකිරීමට අප තීරණය කළේ ඇයි? නිසැකවම, මෙම ප්‍රවේශය ප්‍රායෝගික නොවන බැවින්: සමාජ ජාලයක ඕනෑම වෙනසක් රඳා පවතින්නේ එම සමාජ ජාලයට පෙර පැවති සියලුම වෙනස්කම් මත ය, සෑම යාවත්කාලීන කිරීමකදීම ෆේස්බුක් හෝ VKontakte මාරු කිරීම. එසේ වුවද, පූර්ණ යැපුම් ලුහුබැඳීම පිළිබඳ බොහෝ පර්යේෂණ පවතී - මේවා පූර්ව සමාජ ජාල වේ; සමහර තත්වයන් සඳහා එය සැබවින්ම ක්‍රියාත්මක වේ.

පැහැදිලි යැපීම් ලුහුබැඳීම

ඊළඟ එක වඩාත් සීමිතයි. තොරතුරු මාරු කිරීම ද මෙහිදී සලකා බලනු ලැබේ, නමුත් පැහැදිලිවම රඳා පවතින දේ පමණි. රීතියක් ලෙස, යෙදුම මගින් තීරණය කරනු ලබන දේ මත රඳා පවතී. දත්ත ප්‍රතිනිර්මාණය කරන විට, විමසුම ප්‍රතිචාර ලබා දෙන්නේ පෙර යැපුම් තෘප්තිමත් වූ විට පමණි, එනම් පෙන්වයි. හේතුඵල අනුකූලතාව ක්‍රියා කරන ආකාරයෙහි සාරය මෙයයි.

HighLoad++, Mikhail Tyulenev (MongoDB): හේතුඵල අනුකූලතාව: න්‍යායේ සිට ප්‍රායෝගිකත්වය දක්වා

වාර්තාව 5 වාර්තා 1, 2, 3, 4 මත රඳා පවතින බව ඇය දකියි - ඒ අනුව, පෙර සියලු වෙනස්කම් දැනටමත් දත්ත සමුදාය හරහා ගොස් ඇති විට, Penny ගේ ප්රවේශ තීරණය මගින් සිදු කරන ලද වෙනස්කම් වලට සේවාදායකයාට ප්රවේශ වීමට පෙර ඇය බලා සිටී.

මෙය අපට නොගැලපේ, මන්ද තවමත් ඕනෑවට වඩා තොරතුරු ඇති බැවින් එය දේවල් මන්දගාමී වනු ඇත. තවත් ප්රවේශයක් තිබේ ...

ලාම්පු ඔරලෝසුව

ඔවුන් ඉතා පැරණි ය. Lamport Clock යන්නෙන් අදහස් වන්නේ මෙම පරායත්තයන් අදිශ ශ්‍රිතයකට නැවී ඇති බවයි, එය Lamport Clock ලෙස හැඳින්වේ.

පරිමාණ ශ්‍රිතයක් යනු කිසියම් වියුක්ත සංඛ්‍යාවකි. එය බොහෝ විට තාර්කික කාලය ලෙස හැඳින්වේ. සෑම සිදුවීමක් සමඟම, මෙම කවුන්ටරය වැඩි වේ. ක්‍රියාවලියට දැනට දන්නා කවුන්ටරය, එක් එක් පණිවිඩ යවයි. ක්‍රියාවලීන් සමමුහුර්ත විය හැකි බව පැහැදිලිය, ඒවාට සම්පූර්ණයෙන්ම වෙනස් වේලාවන් තිබිය හැකිය. එසේ වුවද, පද්ධතිය කෙසේ හෝ එවැනි පණිවිඩ යැවීමක් සමඟ ඔරලෝසුව සමතුලිත කරයි. මෙම නඩුවේ කුමක් සිදුවේද?

එය පැහැදිලි කිරීම සඳහා මම එම විශාල කැබැල්ල දෙකට බෙදුවෙමි: මිතුරන්ට එකතුවෙන් කොටසක් අඩංගු එක් නෝඩයක ජීවත් විය හැකි අතර සංග්‍රහයට මෙම එකතුවේ කොටසක් අඩංගු වෙනත් නෝඩයක ජීවත් විය හැකිය. ඔවුන් රේඛාවෙන් පිටතට යා හැකි ආකාරය පැහැදිලිද? පළමු සංග්‍රහය මෙසේ කියනු ඇත: "ප්‍රතිනිර්මාණය", පසුව මිතුරන්. Friends collection එකේ Friends ඩිපෙන්ඩන්සි ද ඩිලිවර් කරන තුරු Feed එක නොපෙන්වන බවට සිස්ටම් එක යම් ආකාරයක සහතිකයක් ලබා නොදෙන්නේ නම්, එවිට මා සඳහන් කළ තත්වයම අපට ලැබෙනු ඇත.

සංග්‍රහයේ කවුන්ටර කාලය තාර්කිකව වැඩි වන ආකාරය ඔබට පෙනේ:

HighLoad++, Mikhail Tyulenev (MongoDB): හේතුඵල අනුකූලතාව: න්‍යායේ සිට ප්‍රායෝගිකත්වය දක්වා

එබැවින් මෙම Lamport Clock සහ Causal අනුකූලතාවයේ ප්‍රධාන ගුණාංගය (Lamport Clock හරහා පැහැදිලි කර ඇත) මෙයයි: අපට A සහ ​​B සිදුවීම් තිබේ නම් සහ B Event A* මත රඳා පවතී නම්, එවිට A Event A හි තාර්කික කාලය ට වඩා අඩු බව පහත දැක්වේ. තාර්කික කාලය B ඉසව්වෙන්.

* සමහර විට ඔවුන් පවසන්නේ A සිදු වූයේ B ට පෙර, එනම් A සිදු වූයේ B ට පෙර බවයි - මෙය සාමාන්‍යයෙන් සිදු වූ සමස්ත සිදුවීම් මාලාවම අර්ධ වශයෙන් ඇණවුම් කරන නිශ්චිත සම්බන්ධතාවයකි.

ප්රතිවිරුද්ධය වැරදියි. මෙය ඇත්ත වශයෙන්ම ලැම්පෝට් ඔරලෝසුවේ ප්‍රධාන අවාසි වලින් එකකි - අර්ධ අනුපිළිවෙල. සමගාමී සිදුවීම් ගැන සංකල්පයක් ඇත, එනම් (A පෙර B) හෝ (A සිදු වූයේ B) නොවන සිදුවීම් ය. උදාහරණයක් ලෙස ලෙනාඩ් විසින් මිතුරෙකු ලෙස වෙනත් අයෙකු සමාන්තරව එකතු කිරීම (උදාහරණයක් ලෙස ලෙනාඩ් පවා නොව, ෂෙල්ඩන්).
ලැම්පෝට් ඔරලෝසු සමඟ වැඩ කිරීමේදී බොහෝ විට භාවිතා කරන දේපල මෙයයි: ඔවුන් විශේෂයෙන් කාර්යය දෙස බලන අතර මෙයින් ඔවුන් නිගමනය කරන්නේ සමහර විට මෙම සිදුවීම් රඳා පවතින බවයි. එක් මාර්ගයක් සත්‍ය වන නිසා: LogicalTime A LogicalTime B ට වඩා අඩු නම්, A ට පෙර B සිදු විය නොහැක; සහ වැඩි නම්, සමහර විට.

දෛශික ඔරලෝසුව

Lamport ඔරලෝසුවේ තාර්කික වර්ධනය දෛශික ඔරලෝසුවයි. මෙහි ඇති සෑම නෝඩයක්ම එහි වෙනම ඔරලෝසුවක් ඇති බැවින් ඒවා වෙනස් වන අතර ඒවා දෛශිකයක් ලෙස සම්ප්‍රේෂණය වේ.
මෙම අවස්ථාවේදී, දෛශිකයේ ශුන්‍ය දර්ශකය Feed සඳහා වගකිව යුතු බවත්, දෛශිකයේ පළමු දර්ශකය මිතුරන් සඳහා වන බවත් ඔබට පෙනේ (මෙම සෑම නෝඩයක්ම). දැන් ඒවා වැඩි වනු ඇත: ලිවීමේදී "Feed" හි ශුන්‍ය දර්ශකය වැඩි වේ - 1, 2, 3:

HighLoad++, Mikhail Tyulenev (MongoDB): හේතුඵල අනුකූලතාව: න්‍යායේ සිට ප්‍රායෝගිකත්වය දක්වා

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

අපට කැබලි 10 ක් තිබේ නම්, අපට සංරචක 10 ක් මාරු කළ නොහැක, අපි එය සම්පීඩනය කළත් හෝ වෙනත් දෙයක් ඉදිරිපත් කළත් - මෙම සම්පූර්ණ දෛශිකයේ පරිමාවට වඩා ගෙවීමේ බර තවමත් කිහිප ගුණයකින් කුඩා වනු ඇත. ඒ නිසා හදවත් දත්මිටි කාගෙන අපි මේ ප්‍රවේශය අතහැර වෙනත් ක්‍රමයකට යොමු වුණා.

ස්පානර් TrueTime. පරමාණුක ඔරලෝසුව

මම කිව්වා ස්පානර් ගැන කතාවක් තියෙනවා කියලා. මෙය XNUMX වන ශතවර්ෂයේ කෙළින්ම හොඳ දෙයක්: පරමාණුක ඔරලෝසු, GPS සමමුහුර්තකරණය.

අදහස මොකක්ද? "Spanner" යනු මෑතකදී මිනිසුන්ට පවා ලබා ගත හැකි ගූගල් පද්ධතියකි (ඔවුන් එයට SQL එකතු කර ඇත). එහි සෑම ගනුදෙනුවක්ම යම් කාල මුද්දරයක් ඇත. කාලය සමමුහුර්ත කර ඇති බැවින්*, සෑම සිදුවීමකටම නිශ්චිත වේලාවක් නියම කළ හැකිය - පරමාණුක ඔරලෝසුවලට පොරොත්තු කාලයක් ඇත, ඉන්පසු වෙනස් වේලාවක් “සිදුවීමට” සහතික වේ.

HighLoad++, Mikhail Tyulenev (MongoDB): හේතුඵල අනුකූලතාව: න්‍යායේ සිට ප්‍රායෝගිකත්වය දක්වා

මේ අනුව, දත්ත සමුදායට ලිවීමෙන් සහ යම් කාලයක් බලා සිටීමෙන්, සිදුවීමේ අනුක්‍රමිකතාව ස්වයංක්‍රීයව සහතික වේ. ප්‍රතිපත්තිමය වශයෙන් සිතාගත හැකි ශක්තිමත්ම අනුකූලතා ආකෘතිය ඔවුන් සතුව ඇත - එය බාහිර අනුකූලතාවයයි.

* Lampart ඔරලෝසු වල ඇති ප්‍රධාන ගැටළුව මෙයයි - ඒවා කිසිවිටක බෙදා හැරෙන පද්ධති මත සමමුහුර්ත නොවේ. ඒවාට අපසරනය විය හැකිය; NTP සමඟ වුවද, ඒවා තවමත් හොඳින් ක්‍රියා නොකරයි. "Spanner" සතුව පරමාණුක ඔරලෝසුවක් ඇති අතර සමමුහුර්තකරණය මයික්‍රො තත්පර වේ.

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

දෙමුහුන් ඔරලෝසුව

හේතුකාරක අනුකූලතාව සහතික කිරීමේදී MongoDB හි සලකුණු වන්නේ මෙයයි. කොහොමද ඒවා හයිබ්‍රිඩ්? දෙමුහුන් යනු පරිමාණ අගයකි, නමුත් එයට සංරචක දෙකක් ඇත:

HighLoad++, Mikhail Tyulenev (MongoDB): හේතුඵල අනුකූලතාව: න්‍යායේ සිට ප්‍රායෝගිකත්වය දක්වා

  • පළමුවැන්න Unix යුගයයි ("පරිගණක ලෝකයේ ආරම්භයේ සිට" තත්පර කීයක් ගතවී ඇත්ද).
  • දෙවැන්න යම් වර්ධකයක් වන අතර, 32-bit unsigned int ද වේ.

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

MongoDB සඳහා මෙය වැදගත් වන්නේ ඇයි? එය ඔබට යම් නිශ්චිත වේලාවක යම් ආකාරයක උපස්ථ අවන්හල් සෑදීමට ඉඩ සලසයි, එනම්, සිදුවීම කාලය අනුව සුචිගත කර ඇත. ඇතැම් සිදුවීම් අවශ්ය වන විට මෙය වැදගත් වේ; දත්ත සමුදායක් සඳහා, සිදුවීම් යනු දත්ත සමුදායේ යම් කාල පරාසයන් තුළ සිදු වූ වෙනස්කම් වේ.

ඔබට පමණක් වැදගත්ම හේතුව මම ඔබට කියමි (කරුණාකර, කිසිවෙකුට නොකියන්න)! අපි මෙය කළේ MongoDB OpLog හි සංවිධිත, සුචිගත දත්ත පෙනෙන්නේ මෙය වන බැවිනි. OpLog යනු දත්ත සමුදායේ නියත වශයෙන්ම සියලුම වෙනස්කම් අඩංගු දත්ත ව්‍යුහයකි: ඒවා පළමුව OpLog වෙත ගොස්, එය ප්‍රතිනිර්මාණය කරන ලද දිනයක් හෝ කැබලි වූ විට ඒවා ගබඩාවටම යොදනු ලැබේ.

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

ඔරලෝසු සමමුහුර්තකරණය

විද්යාත්මක සාහිත්යයේ විස්තර කර ඇති සමමුහුර්ත ක්රම කිහිපයක් තිබේ. මම කතා කරන්නේ අපට වෙනස් කැබලි දෙකක් ඇති විට සමමුහුර්තකරණය ගැන ය. එක් අනුරූ කට්ටලයක් තිබේ නම්, කිසිදු සමමුහුර්ත කිරීමක් අවශ්ය නොවේ: මෙය "තනි මාස්ටර්"; අප සතුව OpLog එකක් ඇත, එයට සියලු වෙනස්කම් වැටේ - මේ අවස්ථාවේ දී, සෑම දෙයක්ම දැනටමත් "Oplog" තුළම අනුපිළිවෙලින් ඇණවුම් කර ඇත. නමුත් අපට විවිධ කොටස් දෙකක් තිබේ නම්, කාල සමමුහුර්තකරණය මෙහිදී වැදගත් වේ. දෛශික ඔරලෝසුව වැඩිපුර උදව් කළේ මෙතැනදීය! නමුත් අපිට ඒවා නැහැ.

HighLoad++, Mikhail Tyulenev (MongoDB): හේතුඵල අනුකූලතාව: න්‍යායේ සිට ප්‍රායෝගිකත්වය දක්වා

දෙවැන්න සුදුසු ය - මෙය “හෘද ස්පන්දන” වේ. සෑම ඒකක කාලයකම සිදුවන සංඥා කිහිපයක් හුවමාරු කර ගත හැකිය. නමුත් හෘද ස්පන්දනය ඉතා මන්දගාමී වේ, අපට අපගේ සේවාදායකයාට ප්‍රමාදයක් ලබා දිය නොහැක.

සැබෑ කාලය ඇත්තෙන්ම පුදුම දෙයක්. නමුත්, නැවතත්, මෙය බොහෝ විට අනාගතයයි ... එය දැනටමත් Atlas හි සිදු කළ හැකි වුවද, දැනටමත් වේගවත් "Amazon" කාලය සමමුහුර්ත කරන්නන් ඇත. නමුත් එය සෑම කෙනෙකුටම ලබා ගත නොහැකි වනු ඇත.

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

ඒ සියල්ල එකට වැඩ කරන්නේ කෙසේද?

මෙන්න මම එක අනුරූ සෙට් එකක් බලනවා ඒක ටිකක් ලේසි කරන්න. ප්‍රාථමික සහ ද්විතීයික වශයෙන් ඇත. ද්විතියිකය ප්‍රතිනිර්මාණය කරන අතර සෑම විටම ප්‍රාථමික සමග සම්පුර්ණයෙන්ම සමමුහුර්ත නොවේ.

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

ඔහු පටිගත කිරීමෙන් පසුව, වැදගත් මොහොතක් සිදු වේ. ඔරලෝසුව "MongoDB" හි ඇති අතර "Oplog" වෙත ලිවීමේදී පමණක් වැඩි වේ. පද්ධතියේ තත්ත්වය වෙනස් කරන සිදුවීම මෙයයි. නියත වශයෙන්ම සියලුම සම්භාව්‍ය ලිපිවල, පණිවිඩයක් නෝඩයකට පහර දෙන විට සිදුවීමක් ලෙස සලකනු ලැබේ: පණිවිඩය පැමිණ ඇත, එයින් අදහස් කරන්නේ පද්ධතිය එහි තත්වය වෙනස් කර ඇති බවයි.

මෙයට හේතුව පර්යේෂණ අතරතුර මෙම පණිවිඩය අර්ථ නිරූපණය කරන්නේ කෙසේද යන්න සම්පූර්ණයෙන්ම පැහැදිලි නැති බැවිනි. එය "Oplog" හි පිළිබිඹු නොවන්නේ නම්, එය කිසිදු ආකාරයකින් අර්ථකථනය නොකරන බව අපි නිසැකවම දනිමු, සහ පද්ධතියේ තත්වයෙහි වෙනසක් "Oplog" හි ඇතුළත් කිරීමක් පමණක් වේ. මෙය අප සඳහා සෑම දෙයක්ම සරල කරයි: ආකෘතිය එය සරල කරයි, සහ එක් අනුරූ කට්ටලයක් තුළ එය සංවිධානය කිරීමට ඉඩ සලසයි, සහ තවත් බොහෝ ප්රයෝජනවත් දේ.

"Oplog" වෙත දැනටමත් ලියා ඇති අගය ආපසු ලබා දී ඇත - "Oplog" හි දැනටමත් මෙම අගය අඩංගු බව අපි දනිමු, එහි කාලය 12 වේ. දැන්, කියවන, කියවීම ආරම්භ වන්නේ වෙනත් node එකක් (Secondary) වන අතර, එය පසුClusterTime තුළ සම්ප්‍රේෂණය වේ. පණිවිඩය. ඔහු මෙසේ කියයි: "අවම වශයෙන් 12 න් පසුව හෝ දොළහ තුළ සිදු වූ සියල්ල මට අවශ්ය වේ" (ඉහත පින්තූරය බලන්න).

මේකට තමයි Causal a consistent (CAT) කියන්නේ. න්‍යාය තුළ එවැනි සංකල්පයක් ඇත, මෙය යම් කාල පෙත්තක් වන අතර එයම අනුකූල වේ. මෙම අවස්ථාවේ දී, 12 වන විට නිරීක්ෂණය කරන ලද පද්ධතියේ තත්වය මෙය බව අපට පැවසිය හැකිය.

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

HighLoad++, Mikhail Tyulenev (MongoDB): හේතුඵල අනුකූලතාව: න්‍යායේ සිට ප්‍රායෝගිකත්වය දක්වා

බොහෝ දුරට ඒ සියල්ල ක්‍රියාත්මක වන ආකාරයයි. පාහේ.

"පාහේ" යන්නෙන් අදහස් කරන්නේ කුමක්ද? මේ සියල්ල ක්‍රියාත්මක වන ආකාරය කියවා අවබෝධ කරගත් යම් පුද්ගලයෙක් ඇතැයි සිතමු. ClusterTime සිදුවන සෑම අවස්ථාවකම එය අභ්‍යන්තර තාර්කික ඔරලෝසුව යාවත්කාලීන කරන අතර ඊළඟ ප්‍රවේශය එකකින් වැඩි වන බව මට වැටහුණි. මෙම කාර්යය පේළි 20 ක් ගනී. මෙම පුද්ගලයා විශාලතම 64-bit අංකය සම්ප්‍රේෂණය කරන බව කියමු, එය අඩු කරන්න.

"එක අඩු" ඇයි? අභ්‍යන්තර ඔරලෝසුව මෙම අගයට ආදේශ කරනු ඇති බැවින් (පැහැදිලිවම, මෙය කළ හැකි විශාලතම සහ වත්මන් වේලාවට වඩා විශාලය), එවිට “Oplog” හි ප්‍රවේශයක් සිදුවනු ඇත, සහ ඔරලෝසුව වෙනත් ඒකකයකින් වැඩි කරනු ඇත - සහ දැනටමත් පවතිනු ඇත. උපරිම අගයක් වන්න (සියලු ඒකක සරලව ඇත, යන්නට වෙනත් තැනක් නැත) , unsaint ints).

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

HighLoad++, Mikhail Tyulenev (MongoDB): හේතුඵල අනුකූලතාව: න්‍යායේ සිට ප්‍රායෝගිකත්වය දක්වා

එපමණක්ද නොව, මෙය වෙනත් ස්ථානයක ප්‍රතිනිර්මාණය කළහොත්, සම්පූර්ණ පොකුර සරලව පහතට වැටේ. ඕනෑම කෙනෙකුට ඉතා ඉක්මනින් හා පහසුවෙන් සංවිධානය කළ හැකි සම්පූර්ණයෙන්ම පිළිගත නොහැකි තත්වයක්! ඒ නිසා අපි මේ මොහොත ඉතාමත් වැදගත් එකක් ලෙස සැලකුවා. එය වළක්වා ගන්නේ කෙසේද?

අපගේ මාර්ගය වන්නේ පොකුරු කාලය අත්සන් කිරීමයි

පණිවිඩයේ (නිල් අකුරු වලට පෙර) එය සම්ප්‍රේෂණය වන්නේ එලෙස ය. නමුත් අපි අත්සනක් ජනනය කිරීමට පටන් ගත්තෙමු (නිල් පෙළ):

HighLoad++, Mikhail Tyulenev (MongoDB): හේතුඵල අනුකූලතාව: න්‍යායේ සිට ප්‍රායෝගිකත්වය දක්වා

අත්සන ජනනය කරනු ලබන්නේ දත්ත සමුදාය තුළ, ආරක්ෂිත පරිමිතියක් තුළ ගබඩා කර ඇති යතුරක් මගිනි; එයම උත්පාදනය කර යාවත්කාලීන වේ (පරිශීලකයන්ට ඒ ගැන කිසිවක් නොපෙනේ). හැෂ් එකක් ජනනය වන අතර, සෑම පණිවිඩයක්ම සාදන විට අත්සන් කර ලැබුණු විට වලංගු වේ.
මිනිසුන්ගේ සිත් තුළ පැන නගින ප්‍රශ්නය: “මෙය කොපමණ ප්‍රමාද වේද?” විශේෂයෙන්ම මෙම විශේෂාංගය නොමැති විට එය ඉක්මනින් වැඩ කළ යුතු බව මම ඔබට කීවෙමි.

මෙම නඩුවේ හේතුකාරක අනුකූලතාව භාවිතා කිරීම යන්නෙන් අදහස් කරන්නේ කුමක්ද? මෙය afterClusterTime පරාමිතිය පෙන්වීමට ය. මෙය නොමැතිව, එය කෙසේ හෝ අගයන් සමත් වනු ඇත. 3.6 අනුවාදයෙන් ආරම්භ වන ඕපාදූප කීම සැමවිටම ක්‍රියාත්මක වේ.

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

ඉක්මනින් කරන්න!

එය තරමක් සරල දෙයක්, නමුත් උපක්රමය සිත්ගන්නා සුළුය - මම එය බෙදා ගන්නෙමි, සමහර විට යමෙකු උනන්දු වනු ඇත.
අත්සන් කළ දත්ත ගබඩා කරන හැෂ් එකක් අප සතුව ඇත. සියලුම දත්ත හැඹිලිය හරහා ගමන් කරයි. හැඹිලිය නිශ්චිත වේලාවට අත්සන් නොකරයි, නමුත් පරාසය. යම් අගයක් පැමිණි විට, අපි පරාසයක් ජනනය කර, අවසාන බිටු 16 වසන් කර, අපි මෙම අගය අත්සන් කරමු:

HighLoad++, Mikhail Tyulenev (MongoDB): හේතුඵල අනුකූලතාව: න්‍යායේ සිට ප්‍රායෝගිකත්වය දක්වා

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

අප ඉගෙනගෙන ඇත්තේ කුමක්ද?

මෙයින් අප උගත් පාඩම්:

  • අපට රසවත් දේවල් රාශියක් ඇති නිසා අපි ද්රව්ය, කථා, ලිපි කියවිය යුතුය. අපි යම් විශේෂාංගයක් මත වැඩ කරන විට (විශේෂයෙන් දැන්, අපි ගනුදෙනු කළ විට, ආදිය), අපි කියවා තේරුම් ගත යුතුය. එය කාලය ගත වේ, නමුත් එය සැබවින්ම ඉතා ප්‍රයෝජනවත් වන්නේ එය අප සිටින්නේ කොතැනද යන්න පැහැදිලි කරන බැවිනි. අපි අලුත් දෙයක් සමඟ එන බවක් පෙනෙන්නට නැත - අපි අමුද්රව්ය ගත්තා.

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

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

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

HighLoad++, Mikhail Tyulenev (MongoDB): හේතුඵල අනුකූලතාව: න්‍යායේ සිට ප්‍රායෝගිකත්වය දක්වා

මම මේකෙන් ඉවර කරන්නම්. ඔයාට ස්තූතියි!

ඔබගේ ප්රශ්න

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

MT: - ඇත්තෙන්ම විශිෂ්ට ප්රශ්නයක්! මට අවශ්‍ය වූයේ කුරුලෑ ගැන කතා කිරීමට පමණි. මම ප්‍රශ්නය නිවැරදිව තේරුම් ගන්නේ නම්, අපට පහත තත්වය ඇත: ෂාර්ඩ් 1 සහ ෂාර්ඩ් 2 ඇත, කියවීම සිදුවන්නේ මෙම කැබලි දෙකෙන් - ඒවාට විෂමතාවයක් ඇත, ඔවුන් එකිනෙකා සමඟ අන්තර් ක්‍රියා නොකරයි, මන්ද ඔවුන් දන්නා කාලය වෙනස් බැවින්, විශේෂයෙන්ම ඒවා ඔප්ලොග් වල පවතින කාලය.
අපි කියමු shard 1 වාර්තා මිලියනයක් සෑදුවා, shard 2 කිසිවක් කළේ නැහැ, සහ ඉල්ලීම කෑලි දෙකකට ආවා. ඒවගේම පලවෙනි එකට මිලියනයකට වඩා afterClusterTime එකක් තියෙනවා. එවැනි තත්වයක් තුළ, මම පැහැදිලි කළ පරිදි, shard 2 කිසි විටෙකත් ප්‍රතිචාර නොදක්වයි.

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

MT: - සමමුහුර්ත කිරීමට ඉතා පහසුය. ෂාර්ඩ්, afterClusterTime ඔහු වෙත පැමිණෙන විට සහ ඔහු "Oplog" හි කාලය සොයා නොගන්නා විට, අනුමත කිරීමක් ආරම්භ නොකරයි. එනම්, ඔහු තම දෑතින් තම කාලය මෙම අගයට ඔසවයි. මෙයින් අදහස් කරන්නේ මෙම ඉල්ලීමට ගැළපෙන සිදුවීම් එහි නොමැති බවයි. ඔහු මෙම සිදුවීම කෘත්‍රිමව නිර්මාණය කර ඒ අනුව හේතුඵල සමාපත්ති බවට පත්වේ.

බී: - මෙයින් පසු ජාලයේ කොතැනක හෝ නැති වූ වෙනත් සිදුවීම් ඔහු වෙත පැමිණියහොත් කුමක් කළ යුතුද?

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

HighLoad++, Mikhail Tyulenev (MongoDB): හේතුඵල අනුකූලතාව: න්‍යායේ සිට ප්‍රායෝගිකත්වය දක්වා

බී: – මට පෝලිම් සම්බන්ධයෙන් ප්‍රශ්න කිහිපයක් තිබේ. හේතුකාරක අනුකූලතාව උපකල්පනය කරන්නේ නිශ්චිත ක්‍රියා පෝලිමක් සිදු කළ යුතු බවයි. අපගේ එක් පැකේජයක් අතුරුදහන් වුවහොත් කුමක් සිදුවේද? ඔන්න 10 වෙනිද, 11 වෙනිද ඇවිත්... 12 වෙනිදා අතුරුදහන් වෙලා, අනිත් හැමෝම බලන් ඉන්නවා ඒක ඇත්ත වෙනකම්. හදිසියේම අපගේ මෝටර් රථය මිය ගියේය, අපට කිසිවක් කළ නොහැක. ක්‍රියාත්මක කිරීමට පෙර එකතු වන පෝලිමේ උපරිම දිගක් තිබේද? එක් රාජ්‍යයක් අහිමි වූ විට සිදුවන මාරාන්තික අසාර්ථකත්වය කුමක්ද? එපමණක්ද නොව, අපි යම් පෙර තත්වයක් ඇති බව ලියා ඇත්නම්, අපි කෙසේ හෝ එයින් ආරම්භ කළ යුතුද? නමුත් ඔවුන් ඔහුව ඉවතට තල්ලු කළේ නැත!

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

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

බී: - අපි අප වෙනුවෙන් බෙදා හැරීම සිදු කරන අවස්ථාවක් නිර්මාණය කරන විට (පිළිවෙලින් ස්වාමියා නොව වහලා), එය එහිම යන්ත්‍රයේ යුනික්ස් වේලාව මත හෝ "ස්වාමියාගේ" වේලාව මත රඳා පවතී; එය පළමු වරට හෝ වරින් වර සමමුහුර්ත වේද?

MT: - මම දැන් පැහැදිලි කරන්නම්. ෂාර්ඩ් (එනම් තිරස් කොටස) - සෑම විටම එහි ප්‍රාථමිකයක් ඇත. ඒවගේම ෂාර්ඩ් එකකට "ස්වාමියා" තිබිය හැකි අතර අනුපිටපත් තිබිය හැකිය. නමුත් ෂාර්ඩ් සෑම විටම පටිගත කිරීමට සහය දක්වයි, මන්ද එය යම් වසමකට සහය විය යුතුය (ෂර්ඩ් ප්‍රාථමිකය ඇත).

බී: - ඉතින් හැම දෙයක්ම "ස්වාමියා" මත සම්පූර්ණයෙන්ම රඳා පවතීද? ප්‍රධාන කාලය සැමවිටම භාවිතා කරන්නේද?

MT: - ඔව්. ඔබට සංකේතාත්මකව පැවසිය හැකිය: "මාස්ටර්", "ඔප්ලොග්" වෙත ඇතුල් වීම සිදු වන විට ඔරලෝසුව ටික් වේ.

බී: - අපට සම්බන්ධ වන සේවාදායකයෙක් සිටින අතර කාලය ගැන කිසිවක් දැන ගැනීමට අවශ්‍ය නොවේද?

MT: - ඔබ කිසිවක් දැන ගැනීමට අවශ්ය නැත! සේවාදායකයා මත එය ක්‍රියා කරන ආකාරය ගැන අපි කතා කරන්නේ නම්: සේවාදායකයාට හේතුකාරක අනුකූලතාව භාවිතා කිරීමට අවශ්‍ය වූ විට, ඔහු සැසියක් විවෘත කළ යුතුය. දැන් සෑම දෙයක්ම තිබේ: සැසියේ ගනුදෙනු, සහ අයිතිවාසිකම් ලබා ගැනීම ... සැසියක් යනු සේවාදායකයා සමඟ සිදුවන තාර්කික සිදුවීම් අනුපිළිවෙලයි.

ඔහු මෙම සැසිය විවෘත කර එහි දී ඔහුට අවශ්‍ය බව පවසන්නේ නම් (සැසිය පෙරනිමියෙන් හේතුඵල අනුකූලතාවයට සහය දක්වයි නම්), සියල්ල ස්වයංක්‍රීයව ක්‍රියාත්මක වේ. රියදුරු මෙම කාලය මතක තබා නව පණිවිඩයක් ලැබුණු විට එය වැඩි කරයි. දත්ත ආපසු ලබා දුන් සේවාදායකයෙන් පෙර එක ලබා දුන් ප්‍රතිචාරය එය මතක තබා ගනී. මීළඟ ඉල්ලීමෙහි afterCluster ("මෙයට වඩා වැඩි කාලය") අඩංගු වේ.

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

බී: - පරිගණක විද්‍යාවේ නව ස්ථරයක් - CRDT (ගැටුම් රහිත ප්‍රතිවර්තිත දත්ත වර්ග) දත්ත වර්ග - අවසාන අනුකූලතාව යන මාතෘකාවට දැඩි ලෙස සම්බන්ධ වේ. මෙම වර්ගයේ දත්ත දත්ත සමුදායට අනුකලනය කිරීම ගැන ඔබ සලකා බැලුවද ඒ ගැන ඔබට කුමක් කිව හැකිද?

MT: - හොඳ ප්රශ්නයක්! ලිවීමේ ගැටුම් සඳහා CRDT අර්ථවත් කරයි: MongoDB හි, තනි මාස්ටර්.

බී: - මට devops වෙතින් ප්‍රශ්නයක් තිබේ. සැබෑ ලෝකයේ, බයිසැන්තියානු අසාර්ථකත්වය සිදු වන විට එවැනි ජේසුයිටිකල් තත්වයන් ඇති අතර, ආරක්ෂිත පරිමිතිය තුළ සිටින නපුරු මිනිසුන් ප්‍රොටෝකෝලය තුළට තල්ලු කිරීමට පටන් ගනී, යාත්‍රා පැකේජ විශේෂ ආකාරයකින් යවනවාද?

HighLoad++, Mikhail Tyulenev (MongoDB): හේතුඵල අනුකූලතාව: න්‍යායේ සිට ප්‍රායෝගිකත්වය දක්වා

MT: – පරිමිතිය ඇතුලේ ඉන්න නපුරු මිනිස්සු ට්‍රෝජන් අශ්වයෙක් වගේ! පරිමිතිය ඇතුලේ ඉන්න නපුරු මිනිස්සුන්ට ගොඩක් නරක දේවල් කරන්න පුළුවන්.

බී: – දළ වශයෙන් කිව්වොත්, සර්වර් එකේ සිදුරක් දාලා, අලි ඇතුන්ගේ වත්තක් දාලා මුළු පොකුරම සදහටම කඩාවැටීමට ඉඩ තිබෙන බව පැහැදිලියි... අතින් යථා තත්ත්වයට පත් වෙන්න කාලයක් ගත වෙනවා... මේක, මෘදුව කියනවා නම්, වැරදි. අනෙක් අතට, මෙය සිත්ගන්නා සුළුය: සැබෑ ජීවිතයේ දී, ප්රායෝගිකව, ස්වභාවිකවම සමාන අභ්යන්තර ප්රහාරයන් සිදු වන විට තත්වයන් තිබේද?

MT: - මම සැබෑ ජීවිතයේ ආරක්ෂක කඩවීම් වලට මුහුණ දෙන්නේ කලාතුරකිනි, ඒවා සිදු වේද යන්න මට කිව නොහැක. නමුත් අපි සංවර්ධන දර්ශනය ගැන කතා කරන්නේ නම්, අපි සිතන්නේ මේ ආකාරයට ය: අපට ආරක්ෂාව සපයන පිරිමි ළමයින්ට සපයන පරිමිතියක් ඇත - මෙය මාලිගාවක්, පවුරක්; සහ පරිමිතිය ඇතුළත ඔබට අවශ්ය ඕනෑම දෙයක් කළ හැකිය. බැලීමේ හැකියාව පමණක් ඇති පරිශීලකයින් සිටින අතර නාමාවලිය මකා දැමීමේ හැකියාව ඇති පරිශීලකයින් සිටින බව පැහැදිලිය.

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

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

MT: "මම කවදාවත් එවැනි දේවල් ගැන අසා නැහැ." මේ ආකාරයෙන් ඔබට සේවාදායකයක් බිඳ දැමිය හැකි බව රහසක් නොවේ. ඇතුළත අසමත් වීම, ප්‍රොටෝකෝලයෙන් සිටීම, පණිවිඩයේ මෙවැනි දෙයක් ලිවිය හැකි බලයලත් පරිශීලකයෙකු වීම... ඇත්ත වශයෙන්ම, එය කළ නොහැක්කකි, මන්ද එය තවමත් සත්‍යාපනය වනු ඇත. මෙම සත්‍යාපනය අවශ්‍ය නොවන පරිශීලකයින් සඳහා අක්‍රිය කළ හැකිය - එවිට එය ඔවුන්ගේ ගැටලුවයි; ඔවුන්, දළ වශයෙන්, බිත්ති තමන් විසින්ම විනාශ කළ අතර, ඔබට අලියෙකු එහි තල්ලු කළ හැකිය, එය පාගා දමනු ඇත ... නමුත් පොදුවේ, ඔබට අලුත්වැඩියා කරන්නෙකු ලෙස සැරසී, පැමිණ එය අදින්න!

බී: - වාර්තාවට ස්තූතියි. සර්ජි (Yandex). අනුරූ කට්ටලයේ ඡන්දදායක සාමාජිකයින් සංඛ්‍යාව සීමා කරන නියතයක් මොං හි ඇති අතර මෙම නියතය 7 (හත්) වේ. මෙය නියතයක් වන්නේ ඇයි? මෙය යම් ආකාරයක පරාමිතියක් නොවන්නේ ඇයි?

MT: - අපි සතුව නෝඩ් 40 ක් සහිත අනුරූ කට්ටල ඇත. සෑම විටම බහුතරයක් ඇත. කුමන අනුවාදයදැයි මම නොදනිමි ...

බී: – Replica කට්ටලය තුළ ඔබට ඡන්දය ප්‍රකාශ නොකරන සාමාජිකයන් ධාවනය කළ හැකි නමුත් උපරිම වශයෙන් ඡන්දය ප්‍රකාශ කරන සාමාජිකයින් 7ක් ඇත. අපගේ අනුරූ කට්ටලය දත්ත මධ්‍යස්ථාන 3ක් පුරා පැතිරී ඇත්නම් මෙම අවස්ථාවේදී වසා දැමීමෙන් බේරෙන්නේ කෙසේද? එක් දත්ත මධ්‍යස්ථානයක් පහසුවෙන් ක්‍රියා විරහිත කළ හැකි අතර තවත් යන්ත්‍රයක් පිටතට වැටිය හැක.

MT: - මෙය දැනටමත් වාර්තාවේ විෂය පථයෙන් ටිකක් ඔබ්බට ය. මෙය සාමාන්‍ය ප්‍රශ්නයකි. සමහර විට මට ඒ ගැන පසුව කියන්න පුළුවන්.

HighLoad++, Mikhail Tyulenev (MongoDB): හේතුඵල අනුකූලතාව: න්‍යායේ සිට ප්‍රායෝගිකත්වය දක්වා

සමහර දැන්වීම් 🙂

අප සමඟ රැඳී සිටීම ගැන ඔබට ස්තුතියි. ඔබ අපේ ලිපි වලට කැමතිද? වඩාත් රසවත් අන්තර්ගතය බැලීමට අවශ්‍යද? ඇණවුමක් කිරීමෙන් හෝ මිතුරන්ට නිර්දේශ කිරීමෙන් අපට සහාය වන්න, $4.99 සිට සංවර්ධකයින් සඳහා cloud VPS, ඔබ වෙනුවෙන් අප විසින් නිර්මාණය කරන ලද ප්‍රවේශ මට්ටමේ සේවාදායකයන්ගේ අද්විතීය ප්‍රතිසමයක්: VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps ගැන සම්පූර්ණ සත්‍යය $19 සිට හෝ සේවාදායකයක් බෙදා ගන්නේ කෙසේද? (RAID1 සහ RAID10, cores 24 දක්වා සහ 40GB DDR4 දක්වා ඇත).

Dell R730xd ඇම්ස්ටර්ඩෑම් හි Equinix Tier IV දත්ත මධ්‍යස්ථානයේ 2 ගුණයක් ලාභදායීද? මෙතන විතරයි 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV $199 සිට නෙදර්ලන්තයේ! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $99 සිට! ගැන කියවන්න යටිතල පහසුකම් සංස්ථාව ගොඩනගන්නේ කෙසේද? සතයක් සඳහා යුරෝ 730 ක් වටිනා Dell R5xd E2650-4 v9000 සේවාදායකය භාවිතා කරන පන්තිය?

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

අදහස් එක් කරන්න