දත්ත සමුදායන් ගැන තවත් සංවර්ධකයින් මෙය දැන සිටිය යුතුය

සටහන. පරිවර්තනය.: Jaana Dogan යනු Google හි පළපුරුදු ඉංජිනේරුවරියකි, ඔහු දැනට Go හි ලියා ඇති සමාගමේ නිෂ්පාදන සේවාවන් නිරීක්ෂණය කිරීම සඳහා කටයුතු කරයි. ඉංග්‍රීසි කතා කරන ප්‍රේක්ෂකයින් අතර විශාල ජනප්‍රියත්වයක් ලබා ගත් මෙම ලිපියේ, ඇය විශාල/ඉල්ලන යෙදුම් සංවර්ධකයින් සඳහා සලකා බැලීමට ප්‍රයෝජනවත් වන DBMS (සහ සමහර විට පොදුවේ බෙදා හරින ලද පද්ධති) සම්බන්ධ වැදගත් තාක්ෂණික තොරතුරු 17 කින් එකතු කළාය.

දත්ත සමුදායන් ගැන තවත් සංවර්ධකයින් මෙය දැන සිටිය යුතුය

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

  1. 99,999% ක්ම ජාලය ගැටළු ඇති නොකරන්නේ නම් ඔබ වාසනාවන්තයි.
  2. ACID කියන්නේ විවිධ දේවල්.
  3. සෑම දත්ත සමුදායකම අනුකූලතාව සහ හුදකලා වීම සහතික කිරීම සඳහා තමන්ගේම යාන්ත්‍රණ ඇත.
  4. ශුභවාදී අවහිර කිරීම් ගලවා ගැනීමට පැමිණෙන්නේ සුපුරුදු එකක් පවත්වා ගැනීමට අපහසු වූ විටය.
  5. අපිරිසිදු කියවීම් සහ දත්ත නැතිවීම හැර වෙනත් විෂමතා තිබේ.
  6. දත්ත සමුදාය සහ පරිශීලකයා සෑම විටම ක්‍රියා මාර්ගයට එකඟ නොවේ.
  7. යෙදුම් මට්ටමේ බෙදා හැරීම යෙදුමෙන් පිටත ගෙන යා හැක.
  8. ස්වයංක්‍රීයව වැඩිවීම අනතුරුදායක විය හැක.
  9. පරණ දත්ත ප්රයෝජනවත් විය හැකි අතර අගුලු දැමීම අවශ්ය නොවේ.
  10. ඕනෑම කාල මූලාශ්‍ර සඳහා විකෘති කිරීම් සාමාන්‍ය වේ.
  11. ප්‍රමාදයට බොහෝ අර්ථ ඇත.
  12. නිශ්චිත ගනුදෙනුවක් සඳහා කාර්ය සාධන අවශ්‍යතා ඇගයීමට ලක් කළ යුතුය.
  13. කැදලි ගනුදෙනු අනතුරුදායක විය හැක.
  14. ගනුදෙනු යෙදුම් තත්ත්වයට සම්බන්ධ නොවිය යුතුය.
  15. විමසුම් සැලසුම්කරුවන්ට දත්ත සමුදායන් ගැන බොහෝ දේ පැවසිය හැකිය.
  16. මාර්ගගත සංක්‍රමණය දුෂ්කර නමුත් හැකි ය.
  17. දත්ත සමුදායේ සැලකිය යුතු වැඩි වීමක් අනපේක්ෂිත බව වැඩි කරයි.

මෙම ලිපියේ පෙර අනුවාදයක් පිළිබඳ ඔවුන්ගේ ප්‍රතිපෝෂණය සඳහා මම Emmanuel Odeke, Rein Henrichs සහ වෙනත් අයට ස්තූති කිරීමට කැමතියි.

99,999% ක්ම ජාලය ගැටළු ඇති නොකරන්නේ නම් ඔබ වාසනාවන්තයි.

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

Spanner (Google හි ගෝලීයව බෙදා හරින ලද දත්ත ගබඩාව) සඳහා 99,999% ලබා ගත හැකි අනුපාතයක් සමඟින්, Google හිමිකම් කියයි 7,6% ගැටළු ජාලයට සම්බන්ධ වේ. ඒ අතරම, සමාගම සිය විශේෂිත ජාලය ඉහළ ලබා ගැනීමේ "ප්රධාන කුළුණ" ලෙස හඳුන්වයි. අධ්‍යයනය කරන්න බේලිස් සහ කිංස්බරි, 2014 දී පවත්වන ලද, එක් අභියෝගයක් "බෙදා හරින ලද පරිගණකකරණය පිළිබඳ වැරදි වැටහීම්", 1994 දී Peter Deutsch විසින් සකස් කරන ලදී. ජාලය සැබවින්ම විශ්වාසදායකද?

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

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

ACID කියන්නේ විවිධ දේවල් ගොඩක්

ACID යන කෙටි යෙදුම පරමාණුකත්වය, අනුකූලතාව, හුදකලාව, විශ්වසනීයත්වය යන්නයි. ගනුදෙනු වල මෙම ගුණාංග අසාර්ථක වීම්, දෝෂ, දෘඪාංග අසමත්වීම් ආදියේදී ඒවායේ වලංගුභාවය සහතික කිරීමට අදහස් කෙරේ. ACID හෝ ඒ හා සමාන යෝජනා ක්‍රම නොමැතිව, යෙදුම් සංවර්ධකයින්ට තමන් වගකිව යුතු දේ සහ දත්ත සමුදාය වගකිව යුතු දේ අතර වෙනස හඳුනා ගැනීම දුෂ්කර වනු ඇත. බොහෝ සම්බන්ධතා ගනුදෙනු දත්ත සමුදායන් ACID අනුකූල වීමට උත්සාහ කරයි, නමුත් NoSQL වැනි නව ප්‍රවේශයන් ක්‍රියාත්මක කිරීමට මිල අධික බැවින් ACID ගනුදෙනු නොමැතිව බොහෝ දත්ත සමුදායන් බිහි වී ඇත.

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

සෑම DBMS එකක්ම ACID අනුකූල නොවේ; ඒ අතරම, ACID සඳහා සහය දක්වන දත්ත සමුදා ක්‍රියාත්මක කිරීම් අවශ්‍යතා සමූහය වෙනස් ලෙස තේරුම් ගනී. ACID අවශ්‍යතා ක්‍රියාත්මක කිරීම සඳහා සිදු කළ යුතු බොහෝ වෙළඳාම් නිසා ACID ක්‍රියාත්මක කිරීම් නොගැලපෙන එක් හේතුවක් වේ. නිර්මාපකයින් ඔවුන්ගේ දත්ත සමුදායන් ACID-අනුකූල ලෙස ඉදිරිපත් කළ හැකි නමුත්, "නොහැකි" සිද්ධීන් හැසිරවීමේ යාන්ත්‍රණය මෙන්ම, අන්ත අවස්ථා වල අර්ථ නිරූපණය නාටකාකාර ලෙස වෙනස් විය හැක. අවම වශයෙන්, සංවර්ධකයින්ට ඔවුන්ගේ විශේෂ හැසිරීම් සහ සැලසුම් වෙළඳාම පිළිබඳ නිසි අවබෝධයක් ලබා ගැනීම සඳහා මූලික ක්‍රියාත්මක කිරීමේ සංකීර්ණතා පිළිබඳ ඉහළ මට්ටමේ අවබෝධයක් ලබා ගත හැකිය.

MongoDB ACID අවශ්‍යතාවලට අනුකූලද යන්න පිළිබඳ විවාදය 4 අනුවාදය නිකුත් කිරීමෙන් පසුව පවා දිගටම පවතී. MongoDB දිගු කාලයක් සඳහා සහය නොදක්වයි ලොග් කිරීම, පෙරනිමියෙන් දත්ත සෑම තත්පර 60 කට වරක් නොඅඩු තැටියට කැපවී ඇත. පහත දර්ශනය සිතන්න: යෙදුමක් ලිවීම් දෙකක් (w1 සහ w2) පළ කරයි. MongoDB w1 සාර්ථකව ගබඩා කරයි, නමුත් දෘඪාංග අසමත් වීම නිසා w2 නැති වී යයි.

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

තැටියට කැපවීම මිල අධික ක්රියාවලියකි. නිරන්තර කැපවීම් වළක්වා ගැනීමෙන්, සංවර්ධකයින් විශ්වසනීයත්වයේ වියදමින් පටිගත කිරීමේ කාර්ය සාධනය වැඩි දියුණු කරයි. MongoDB දැනට ලොග් වීමට සහය දක්වයි, නමුත් අපිරිසිදු ලිවීම් පෙරනිමියෙන් සෑම 100ms කට වරක් ලොග් ග්‍රහණය කර ගන්නා බැවින් දත්ත අඛණ්ඩතාවට බලපෑම් කළ හැකිය. එනම්, අවදානම බෙහෙවින් අඩු වුවද, ලඝු-සටහන් සහ ඒවායේ ඉදිරිපත් කර ඇති වෙනස්කම් සඳහා සමාන අවස්ථාවක් තවමත් පවතී.

සෑම දත්ත සමුදායකම තමන්ගේම අනුකූලතාවයක් සහ හුදකලා යාන්ත්‍රණයක් ඇත

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

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

දත්ත සමුදායන් ගැන තවත් සංවර්ධකයින් මෙය දැන සිටිය යුතුය
පවතින සමගාමී ආකෘති සහ ඒවා අතර සම්බන්ධතා සමාලෝචනය

SQL ප්‍රමිතිය නිර්වචනය කරන්නේ හුදකලා මට්ටම් හතරක් පමණි, නමුත් න්‍යායාත්මකව සහ ප්‍රායෝගිකව තවත් බොහෝ දේ ඇත. Jepson.io පවතින සමගාමී ආකෘති පිළිබඳ විශිෂ්ට දළ විශ්ලේෂණයක් ඉදිරිපත් කරයි. උදාහරණයක් ලෙස, Google Spanner ඔරලෝසු සමමුහුර්තකරණය සමඟ බාහිර අනුක්‍රමිකතාව සහතික කරයි, මෙය දැඩි හුදකලා ස්ථරයක් වුවද, එය සම්මත හුදකලා ස්ථරවල අර්ථ දක්වා නැත.

SQL ප්‍රමිතිය පහත හුදකලා මට්ටම් සඳහන් කරයි:

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

මට්ටම අනුක්‍රමික ක්‍රියාත්මක කිරීමට වඩාත්ම මිල අධික වන අතරම, පද්ධතිය මත ඉහළම තරඟකාරී බරක් ඇති කරන අතරම, දත්ත ධාවන තරඟ වල අවදානම අවම කරයි. අනෙකුත් හුදකලා මට්ටම් ක්‍රියාත්මක කිරීමට පහසු වන නමුත් දත්ත ධාවන තරඟ වල සම්භාවිතාව වැඩි කරයි. සමහර DBMS ඔබට අභිරුචි හුදකලා මට්ටමක් සැකසීමට ඉඩ සලසයි, අනෙක් ඒවාට ශක්තිමත් මනාප ඇති අතර සියලු මට්ටම් සඳහා සහය නොදක්වයි.

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

දත්ත සමුදායන් ගැන තවත් සංවර්ධකයින් මෙය දැන සිටිය යුතුය
විවිධ DBMS සඳහා විවිධ හුදකලා මට්ටම්වල සමගාමී විෂමතා සමාලෝචනය

Martin Kleppmann ඔහුගේ ව්යාපෘතියේ ආරාමය විවිධ හුදකලා මට්ටම් සංසන්දනය කරයි, සමගාමී විෂමතා ගැන කතා කරයි, සහ දත්ත සමුදාය විශේෂිත හුදකලා මට්ටමකට අනුගත විය හැකිද යන්න. ක්ලෙප්මන්ගේ පර්යේෂණයෙන් පෙන්නුම් කරන්නේ දත්ත සමුදා සංවර්ධකයින් හුදකලා මට්ටම් ගැන සිතන්නේ කෙසේද යන්නයි.

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

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

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

UPDATE products
SET name = 'Telegraph receiver', version = 2
WHERE id = 1 AND version = 1

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

අපිරිසිදු කියවීම් සහ දත්ත නැතිවීම හැර වෙනත් විෂමතා තිබේ

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

එවැනි විෂමතා සඳහා එක් උදාහරණයක් වන්නේ විකෘති කිරීම වාර්තා කිරීමයි (වැරදි ලියන්න). විකෘති කිරීම් සාමාන්‍යයෙන් ක්‍රියාශීලීව සොයන්නේ නැති නිසා ඒවා හඳුනා ගැනීමට අපහසුය. ඒවා සිදුවන්නේ අපිරිසිදු කියවීම් හෝ දත්ත නැතිවීම නිසා නොව, දත්ත මත තබා ඇති තාර්කික සීමාවන් උල්ලංඝනය කිරීමෙනි.

උදාහරණයක් ලෙස, එක් ක්‍රියාකරුවෙකුට සෑම විටම ඇමතුමක් ලබා ගැනීමට අවශ්‍ය වන අධීක්ෂණ යෙදුමක් සලකා බලමු:

BEGIN tx1;                      BEGIN tx2;
SELECT COUNT(*)
FROM operators
WHERE oncall = true;
0                               SELECT COUNT(*)
                                FROM operators
                                WHERE oncall = TRUE;
                                0
UPDATE operators                UPDATE operators
SET oncall = TRUE               SET oncall = TRUE
WHERE userId = 4;               WHERE userId = 2;
COMMIT tx1;                     COMMIT tx2;

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

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

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

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

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

මුලින්ම බැලූ බැල්මට, පහත වැඩසටහනේ, T1 සහ T2 අනුක්‍රමික ලෙස හැඳින්වේ, නමුත් මෙම කාර්යයන් අවහිර නොකරනවා නම් සහ ප්‍රතිඵලය වහාම පෝරමයට ලබා දෙන්න. පොරොන්දු වෙනවා, එවිට ඇමතුම් අනුපිළිවෙල ඔවුන් දත්ත සමුදායට ඇතුළු වූ අවස්ථා අනුව තීරණය වේ:

result1 = T1() // සැබෑ ප්‍රතිඵල පොරොන්දු වේ
ප්රතිඵල2 = T2()

පරමාණුකත්වය අවශ්‍ය නම් (එනම්, එක්කෝ සියලුම මෙහෙයුම් සම්පූර්ණ කළ යුතුය හෝ ගබ්සා කළ යුතුය) සහ අනුපිළිවෙල වැදගත් නම්, T1 සහ T2 මෙහෙයුම් තනි ගනුදෙනුවක් තුළ සිදු කළ යුතුය.

යෙදුම් මට්ටමේ බෙදා හැරීම යෙදුමෙන් පිටත ගෙන යා හැක

Sharding යනු දත්ත සමුදායක් තිරස් අතට කොටස් කිරීමේ ක්‍රමයකි. සමහර දත්ත සමුදායන් ස්වයංක්‍රීයව දත්ත තිරස් අතට බෙදිය හැකි අතර අනෙක් ඒවා කළ නොහැක, නැතහොත් එය ඉතා හොඳ නැත. දත්ත ගෘහ නිර්මාණ ශිල්පීන්ට/සංවර්ධකයින්ට දත්ත වෙත ප්‍රවේශ වන ආකාරය නිවැරදිව පුරෝකථනය කිරීමට හැකි වූ විට, මෙම කාර්යය දත්ත සමුදායට පැවරීම වෙනුවට පරිශීලක අවකාශයේ තිරස් කොටස් නිර්මාණය කළ හැකිය. මෙම ක්‍රියාවලිය "යෙදුම් මට්ටමේ බෙදා හැරීම" ලෙස හැඳින්වේ. (යෙදුම් මට්ටමේ බෙදා හැරීම).

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

දත්ත සමුදායන් ගැන තවත් සංවර්ධකයින් මෙය දැන සිටිය යුතුය
යෙදුම් සේවාදායකයන් බෙදා හැරීමේ සේවාවෙන් වෙන් කර ඇති ගෘහ නිර්මාණ ශිල්පයක උදාහරණයක්

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

ස්වයංක්‍රීයව වැඩිවීම අනතුරුදායක විය හැක

AUTOINCREMENT යනු ප්‍රාථමික යතුරු ජනනය කිරීමේ පොදු ක්‍රමයකි. දත්ත සමුදායන් ID උත්පාදක ලෙස භාවිතා කරන අවස්ථා බොහෝ විට ඇති අතර, දත්ත සමුදායේ හඳුනාගැනීම් උත්පාදනය කිරීමට සැලසුම් කර ඇති වගු අඩංගු වේ. ස්වයංක්‍රීය වර්ධක භාවිතයෙන් ප්‍රාථමික යතුරු ජනනය කිරීම පරමාදර්ශී වීමට හේතු කිහිපයක් තිබේ:

  • බෙදා හරින ලද දත්ත සමුදායක් තුළ, ස්වයංක්‍රීයව වැඩි කිරීම බරපතල ගැටළුවකි. හැඳුනුම්පත ජනනය කිරීමට, ගෝලීය අගුලක් අවශ්‍ය වේ. ඒ වෙනුවට, ඔබට UUID එකක් ජනනය කළ හැක: මේ සඳහා විවිධ දත්ත සමුදා නෝඩ් අතර අන්තර්ක්‍රියා අවශ්‍ය නොවේ. අගුල් සමඟ ස්වයංක්‍රීයව වැඩි කිරීම මතභේදයට තුඩු දිය හැකි අතර බෙදා හරින ලද අවස්ථා වලදී ඇතුළත් කිරීම් මත කාර්ය සාධනය සැලකිය යුතු ලෙස අඩු කරයි. සමහර DBMSs (උදාහරණයක් ලෙස, MySQL) ප්‍රධාන-ප්‍රධාන අනුකරණය නිසි ලෙස සංවිධානය කිරීම සඳහා විශේෂ වින්‍යාසය සහ වඩාත් ප්‍රවේශම් සහගත අවධානයක් අවශ්‍ය විය හැකිය. වින්‍යාස කිරීමේදී වැරදි සිදු කිරීම පහසුය, එය පටිගත කිරීමේ අසාර්ථකත්වයට හේතු වේ.
  • සමහර දත්ත සමුදායන් ප්‍රාථමික යතුරු මත පදනම්ව කොටස් කිරීමේ ඇල්ගොරිතම ඇත. අඛණ්ඩ හැඳුනුම්පත් අනපේක්ෂිත උණුසුම් ස්ථාන වලට තුඩු දිය හැකි අතර සමහර කොටස්වල බර වැඩි වන අතර අනෙක් ඒවා අක්‍රියව පවතී.
  • ප්‍රාථමික යතුර යනු දත්ත සමුදායක පේළියකට ප්‍රවේශ වීමට වේගවත්ම ක්‍රමයයි. වාර්තා හඳුනා ගැනීමට වඩා හොඳ ක්‍රම සමඟින්, අනුක්‍රමික හැඳුනුම්පත්වලට වගුවල ඇති වැදගත්ම තීරුව අර්ථ විරහිත අගයන්ගෙන් පිරුණු නිෂ්ඵල තීරුවක් බවට පත් කළ හැක. එබැවින්, හැකි සෑම විටම, කරුණාකර ගෝලීය වශයෙන් අද්විතීය සහ ස්වභාවික ප්‍රාථමික යතුරක් තෝරන්න (උදා. පරිශීලක නාමය).

ප්‍රවේශයක් තීරණය කිරීමට පෙර, සුචිගත කිරීම, කොටස් කිරීම සහ බෙදා හැරීම කෙරෙහි ස්වයංක්‍රීයව වැඩි කරන ID සහ UUID වල බලපෑම සලකා බලන්න.

පරණ දත්ත ප්රයෝජනවත් විය හැකි අතර අගුලු දැමීම අවශ්ය නොවේ

Multiversion Concurrency Control (MVCC) ඉහත කෙටියෙන් සාකච්ඡා කරන ලද අනුකූලතා අවශ්‍යතා බොහොමයක් ක්‍රියාත්මක කරයි. සමහර දත්ත සමුදායන් (උදාහරණයක් ලෙස, Postgres, Spanner) දත්ත සමුදායේ පැරණි අනුවාද සහිත ස්නැප්ෂොට් සමඟ ගනුදෙනු "පෝෂණය" කිරීමට MVCC භාවිතා කරයි. ස්නැප්ෂොට් ගනුදෙනු ද අනුකූලතාව සහතික කිරීම සඳහා අනුක්‍රමික කළ හැක. පැරණි ස්නැප්ෂොට් එකකින් කියවන විට, යල් පැන ගිය දත්ත කියවනු ලැබේ.

තරමක් පරණ දත්ත කියවීම ප්‍රයෝජනවත් විය හැක, උදාහරණයක් ලෙස, දත්ත වලින් විශ්ලේෂණ උත්පාදනය කිරීමේදී හෝ දළ වශයෙන් සමස්ථ අගයන් ගණනය කිරීමේදී.

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

දත්ත සමුදායන් ගැන තවත් සංවර්ධකයින් මෙය දැන සිටිය යුතුය
පැසිෆික් සාගරයේ අනෙක් පැත්තේ නවතම අනුවාදය ලබා ගත හැකි වුවද යෙදුම් සේවාදායකය තත්පර 5ක් යල් පැන ගිය දේශීය අනුරුවෙන් දත්ත කියවයි.

DBMS ස්වයංක්‍රීයව පැරණි අනුවාද ඉවත් කරන අතර, සමහර අවස්ථාවලදී, ඉල්ලීම මත මෙය කිරීමට ඔබට ඉඩ සලසයි. උදාහරණයක් ලෙස, Postgres පරිශීලකයින්ට කිරීමට ඉඩ දෙයි VACUUM ඉල්ලීම මත, සහ කලින් කලට මෙම මෙහෙයුම ස්වයංක්රීයව සිදු කරයි. පැයකට වඩා පැරණි ස්නැප්ෂොට් ඉවත් කිරීමට Spanner කසළ එකතු කරන්නෙකු ධාවනය කරයි.

ඕනෑම වේලාවක මූලාශ්‍ර විකෘති කිරීමට යටත් වේ

පරිගණක විද්‍යාවේ හොඳම රහසිගත රහස නම් සියලුම කාල API බොරු වීමයි. ඇත්ත වශයෙන්ම, අපගේ යන්ත්ර නිශ්චිත වත්මන් වේලාව දන්නේ නැත. පරිගණකයේ ක්වාර්ට්ස් ස්ඵටික අඩංගු වන අතර එය කාලය පවත්වා ගැනීමට භාවිතා කරන කම්පන ජනනය කරයි. කෙසේ වෙතත්, ඒවා ප්‍රමාණවත් තරම් නිවැරදි නොවන අතර නිශ්චිත වේලාවට වඩා ඉදිරියෙන්/පසුගාමී විය හැක. මාරුව දිනකට තත්පර 20 දක්වා ළඟා විය හැකිය. එමනිසා, අපගේ පරිගණකවල කාලය වරින් වර ජාලය සමඟ සමමුහුර්ත කළ යුතුය.

සමමුහුර්තකරණය සඳහා NTP සේවාදායකයන් භාවිතා කරයි, නමුත් සමමුහුර්ත කිරීමේ ක්‍රියාවලියම ජාල ප්‍රමාදයන්ට යටත් වේ. එකම දත්ත මධ්‍යස්ථානයේ NTP සේවාදායකයක් සමඟ සමමුහුර්ත කිරීමට පවා යම් කාලයක් ගතවේ. පොදු NTP සේවාදායකයක් සමඟ වැඩ කිරීම ඊටත් වඩා විශාල විකෘතියකට තුඩු දිය හැකි බව පැහැදිලිය.

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

යෙදුම් සහ දත්ත සමුදායන් බොහෝ විට විවිධ යන්ත්‍රවල (විවිධ දත්ත මධ්‍යස්ථානවල නොමැති නම්) ස්ථානගත වී තිබීම නිසා තත්වය තවත් උග්‍ර වේ. මේ අනුව, විවිධ යන්ත්‍ර හරහා බෙදා හරින ලද DB නෝඩ් මත පමණක් කාලය වෙනස් වේ. යෙදුම් සේවාදායකයේ ද එය වෙනස් වනු ඇත.

Google TrueTime සම්පූර්ණයෙන්ම වෙනස් ප්‍රවේශයක් ගනී. බොහෝ අය විශ්වාස කරන්නේ මෙම දිශාවට Google හි ප්‍රගතිය පැහැදිලි වන්නේ පරමාණුක සහ GPS ඔරලෝසු වෙත සාමාන්‍ය සංක්‍රාන්තිය මගිනි, නමුත් මෙය විශාල පින්තූරයේ කොටසක් පමණි. TrueTime ක්‍රියා කරන ආකාරය මෙන්න:

  • TrueTime විවිධ මූලාශ්‍ර දෙකක් භාවිතා කරයි: GPS සහ පරමාණුක ඔරලෝසු. මෙම ඔරලෝසු වල සහසම්බන්ධ නොවන අසාර්ථක මාදිලි ඇත. [විස්තර සඳහා 5 පිටුව බලන්න මෙහි - ආසන්න වශයෙන්. පරිවර්තනය.), එබැවින් ඔවුන්ගේ ඒකාබද්ධ භාවිතය විශ්වසනීයත්වය වැඩි කරයි.
  • TrueTime සතුව අසාමාන්‍ය API එකක් ඇත. එය මිනුම් දෝෂයක් සහ අවිනිශ්චිතතාවයන් සමඟ කාල පරතරයක් ලෙස නැවත ලබා දෙයි. කාලයෙහි සැබෑ මොහොත පවතින්නේ අන්තරයේ ඉහළ සහ පහළ මායිම් අතර කොතැනක හෝ ය. Google හි බෙදා හරින ලද දත්ත සමුදාය වන Spanner, වත්මන් කාලය පරාසයෙන් බැහැර බව පැවසීමට ආරක්ෂිත වන තෙක් බලා සිටී. මෙම ක්‍රමය මඟින් පද්ධතියට යම් ප්‍රමාදයක් හඳුන්වා දෙයි, විශේෂයෙන් ස්වාමිවරුන් මත අවිනිශ්චිතතාවය ඉහළ මට්ටමක පවතී නම්, නමුත් ගෝලීය වශයෙන් බෙදා හරින ලද තත්වයක් තුළ පවා නිවැරදි බව සහතික කරයි.

දත්ත සමුදායන් ගැන තවත් සංවර්ධකයින් මෙය දැන සිටිය යුතුය
Spanner සංරචක TrueTime භාවිතා කරයි, එහිදී TT.now() කාල පරතරයක් ලබා දෙයි, එබැවින් වත්මන් කාලය නිශ්චිත ලක්ෂ්‍යයක් පසු වී ඇති බවට විශ්වාස කළ හැකි වන තෙක් ස්පානර් නිදයි.

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

ප්‍රමාදයට බොහෝ අර්ථ ඇත

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

නිශ්චිත ගනුදෙනුවක් සඳහා කාර්ය සාධන අවශ්‍යතා ඇගයීමට ලක් කළ යුතුය

සමහර විට DBMS හි කාර්ය සාධන ලක්ෂණ සහ එහි සීමාවන් ලිවීම/කියවීම ප්‍රතිදානය සහ ප්‍රමාදය අනුව නියම කෙරේ. මෙය ප්‍රධාන පද්ධති පරාමිති පිළිබඳ සාමාන්‍ය දළ විශ්ලේෂණයක් සපයයි, නමුත් නව DBMS ක්‍රියාකාරිත්වය ඇගයීමේදී, වඩාත් පුළුල් ප්‍රවේශයක් වන්නේ තීරණාත්මක මෙහෙයුම් වෙන වෙනම ඇගයීමයි (එක් එක් විමසුම සහ/හෝ ගනුදෙනු සඳහා). උදාහරණ:

  • අදාළ වගු තුළ නිශ්චිත සීමාවන් සහ පේළි පිරවුම් සහිත නව පේළියක් X වගුවට (පේළි මිලියන 50ක් සහිත) ඇතුළු කරන විට ප්‍රතිදානය සහ ප්‍රමාදය ලියන්න.
  • සාමාන්‍ය මිතුරන් සංඛ්‍යාව 500ක් වන විට යම් පරිශීලකයෙකුගේ මිතුරන්ගේ මිතුරන් පෙන්වීම ප්‍රමාදය.
  • පරිශීලකයා පැයකට X ඇතුළත් කිරීම් සහිත වෙනත් පරිශීලකයින් 100ක් අනුගමනය කරන විට පරිශීලක ඉතිහාසයෙන් ඉහළම ඇතුළත් කිරීම් 500 ලබා ගැනීමේ ප්‍රමාදය.

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

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

කැදලි ගනුදෙනු අනතුරුදායක විය හැක

සෑම DBMS එකක්ම කැදැලි ගණුදෙනු සඳහා සහය නොදක්වයි, නමුත් ඒවා සිදු කරන විට, එවැනි ගණුදෙණු වලින් අනපේක්ෂිත දෝෂ ඇති විය හැක, ඒවා සැමවිටම පහසුවෙන් හඳුනා ගත නොහැක (එනම්, යම් ආකාරයක විෂමතාවයක් ඇති බව පැහැදිලි විය යුතුය).

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

විවිධ ස්තරවල ගනුදෙනු සංග්‍රහ කිරීම අනපේක්ෂිත කැදලි ගනුදෙනුවලට තුඩු දිය හැකි අතර කේත කියවීමේ දෘෂ්ටි කෝණයෙන් එය කතුවරයාගේ අභිප්‍රාය තේරුම් ගැනීමට අපහසු විය හැකිය. පහත වැඩසටහන දෙස බලන්න:

with newTransaction():
   Accounts.create("609-543-222")
   with newTransaction():
       Accounts.create("775-988-322")
       throw Rollback();

ඉහත කේතයේ ප්‍රතිදානය කුමක් වේවිද? එය ගනුදෙනු දෙකම ආපසු හරවන්නේද, නැතහොත් අභ්‍යන්තර එක පමණක්ද? අප සඳහා ගණුදෙණු නිර්මාණය කිරීම සංග්‍රහ කරන පුස්තකාලවල බහු ස්ථර මත රඳා සිටියහොත් කුමක් සිදුවේද? එවැනි අවස්ථා හඳුනාගෙන වැඩිදියුණු කිරීමට අපට හැකි වේද?

බහු මෙහෙයුම් සහිත දත්ත ස්ථරයක් සිතන්න (උදා. newAccount) දැනටමත් එහිම ගනුදෙනුවල ක්රියාත්මක වේ. ඔබ ඒවා එහිම ගනුදෙනුව තුළ ක්‍රියාත්මක වන ඉහළ මට්ටමේ ව්‍යාපාර තර්කනයේ කොටසක් ලෙස ධාවනය කරන්නේ නම් කුමක් සිදුවේද? මෙම නඩුවේ හුදකලාව සහ අනුකූලතාව කුමක් විය හැකිද?

function newAccount(id string) {
  with newTransaction():
      Accounts.create(id)
}

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

function newAccount(id string) {
   Accounts.create(id)
}
// In main application:
with newTransaction():
   // Read some data from database for configuration.
   // Generate an ID from the ID service.
   Accounts.create(id)
   Uploads.create(id) // create upload queue for the user.

ගනුදෙනු යෙදුම් තත්ත්වයට සම්බන්ධ නොවිය යුතුය

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

var seq int64
with newTransaction():
    newSeq := atomic.Increment(&seq)
    Entries.query(newSeq)
    // Other operations...

ඉහත ගනුදෙනුව අවසන් ප්‍රතිඵලය කුමක් වුවත්, එය ක්‍රියාත්මක කරන සෑම අවස්ථාවකම අනුක්‍රමික අංකය වැඩි කරයි. ජාල ගැටළු හේතුවෙන් කැපවීම අසාර්ථක වුවහොත්, ඔබ නැවත උත්සාහ කරන විට ඉල්ලීම වෙනස් අනුක්‍රමික අංකයකින් ක්‍රියාත්මක වේ.

විමසුම් සැලසුම්කරුවන්ට දත්ත සමුදායක් ගැන බොහෝ දේ පැවසිය හැකිය

විමසුම් සැලසුම්කරුවන් දත්ත සමුදායක් තුළ විමසුමක් ක්‍රියාත්මක කරන්නේ කෙසේද යන්න තීරණය කරයි. ඔවුන් ඉල්ලීම් විශ්ලේෂණය කර යැවීමට පෙර ඒවා ප්‍රශස්ත කරයි. සැලසුම්කරුවන්ට සැපයිය හැක්කේ ඔවුන් සතුව ඇති සංඥා මත පදනම් විය හැකි ඇස්තමේන්තු කිහිපයක් පමණි. උදාහරණයක් ලෙස, පහත විමසුම සඳහා හොඳම සෙවුම් ක්‍රමය කුමක්ද?

SELECT * FROM articles where author = "rakyll" order by title;

ප්රතිඵල ක්රම දෙකකින් ලබා ගත හැක:

  • සම්පූර්ණ වගු පරිලෝකනය: ඔබට වගුවේ ඇති එක් එක් ප්‍රවේශය දෙස බලා ගැලපෙන කර්තෘ නාමයක් සමඟ ලිපි ආපසු ලබා දිය හැක, පසුව ඒවා ඇණවුම් කරන්න.
  • දර්ශක ස්කෑන්: ඔබට ගැලපෙන හැඳුනුම්පත් සොයා ගැනීමට, එම පේළි ලබා ගැනීමට, පසුව ඒවා ඇණවුම් කිරීමට සුචියක් භාවිතා කළ හැක.

විමසුම් සැලසුම්කරුගේ කාර්යය වන්නේ කුමන උපාය මාර්ගය වඩාත් සුදුසුද යන්න තීරණය කිරීමයි. විමසුම් සැලසුම්කරුවන්ට ඇත්තේ සීමිත පුරෝකථන හැකියාවන් පමණක් බව සලකා බැලීම වටී. මෙය වැරදි තීරණ වලට තුඩු දිය හැකිය. ඩීබීඒ හෝ සංවර්ධකයින්ට දුර්වල ක්‍රියාකාරී විමසුම් හඳුනා ගැනීමට සහ මනාව සකස් කිරීමට ඒවා භාවිතා කළ හැක. DBMS හි නව අනුවාද මඟින් විමසුම් සැලසුම්කරුවන් වින්‍යාසගත කළ හැකි අතර, නව අනුවාදය මඟින් කාර්ය සාධන ගැටළු ඇති වුවහොත් දත්ත සමුදාය යාවත්කාලීන කිරීමේදී ස්වයං-රෝග විනිශ්චය උපකාර විය හැක. මන්දගාමී විමසුම් ලොග, ප්‍රමාද ගැටළු වාර්තා, හෝ ක්‍රියාත්මක කිරීමේ කාල සංඛ්‍යාලේඛන ප්‍රශස්තකරණය අවශ්‍ය විමසුම් හඳුනා ගැනීමට උපකාරී වේ.

විමසුම් සැලසුම්කරු විසින් ඉදිරිපත් කරන ලද සමහර ප්‍රමිතික ඝෝෂාවට ලක් විය හැක (විශේෂයෙන් ප්‍රමාදය හෝ CPU කාලය ඇස්තමේන්තු කරන විට). උපලේඛනකරුවන්ට හොඳ එකතු කිරීමක් වන්නේ ක්‍රියාත්මක කිරීමේ මාර්ගය සොයා ගැනීම සහ ලුහුබැඳීම සඳහා මෙවලම් වේ. එවැනි ගැටළු හඳුනා ගැනීමට ඔවුන් ඔබට ඉඩ සලසයි (අහෝ, සියලුම DBMS එවැනි මෙවලම් සපයන්නේ නැත).

මාර්ගගත සංක්‍රමණය දුෂ්කර නමුත් හැකි ය

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

විවිධ මාර්ගගත සංක්‍රමණ ආකෘති ඇත. මෙන්න ඒවායින් එකක්:

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

අමතර තොරතුරු සඳහා, සම්බන්ධ කර ගැනීමට මම නිර්දේශ කරමි ලිපියයි, මෙම ආකෘතිය මත පදනම්ව Stripe හි සංක්‍රමණ උපාය මාර්ගය විස්තර කරයි.

දත්ත සමුදායේ සැලකිය යුතු වැඩි වීමක් අනපේක්ෂිත බව වැඩි කරයි

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

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

...

මෙම ලිපිය ප්‍රකාශයට පත් කිරීම ගැන මා සිතන්නට පටන් ගත් විට, මගේ මුල් ලැයිස්තුවේ තවත් අයිතම පහක් තිබුණි. ඊට පස්සේ විශාල සංඛ්යාවක් ආවා නව අදහස් ආවරණය කළ හැකි වෙනත් දේ ගැන. එමනිසා, ලිපිය උපරිම අවධානය යොමු කළ යුතු අවම වශයෙන් පැහැදිලි ගැටළු ස්පර්ශ කරයි. කෙසේ වෙතත්, මෙම මාතෘකාව අවසන් වී ඇති බව මින් අදහස් නොවේ, මම තවදුරටත් මගේ අනාගත ද්‍රව්‍ය තුළ එය වෙත ආපසු නොඑන අතර වර්තමාන එකට වෙනස්කම් සිදු නොකරමි.

ප්රාදේශීය සභා

අපගේ බ්ලොග් අඩවියේ ද කියවන්න:

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

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