DBA බොට් ජෝ. ඇනටෝලි ස්ටැන්ස්ලර් (Postgres.ai)

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

වීඩියෝ:

ආයුබෝවන් සියල්ලටම! මගේ නම Anatoly Stansler. මම සමාගමක වැඩ කරනවා postgres.ai. සංවර්ධකයින්, DBAs සහ QAs වෙතින් Postgres හි වැඩ කටයුතු හා සම්බන්ධ ප්‍රමාදයන් ඉවත් කිරීමෙන් සංවර්ධන ක්‍රියාවලිය වේගවත් කිරීමට අපි කැපවී සිටිමු.

අපට විශිෂ්ට සේවාදායකයින් සිටින අතර අද වාර්තාවේ කොටසක් ඔවුන් සමඟ වැඩ කිරීමේදී අපට හමු වූ අවස්ථා සඳහා කැප කෙරේ. තරමක් බරපතල ගැටළු විසඳීමට අපි ඔවුන්ට උදව් කළ ආකාරය ගැන මම කතා කරමි.

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

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

නිෂ්පාදන මත සෘජුවම දර්ශක සාදා හෝ යම් වෙනසක් සිදු කර ඇත්තේ කවුද? තරමක්. දත්ත නැති වූ බවට හෝ අක්‍රිය වීමට මෙය හේතු වූයේ කා සඳහාද? එතකොට මේ වේදනාව දන්නවා. දෙවියන්ට ස්තූතියි උපස්ථ තිබේ.

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

එය රිදෙනවා, එය මිල අධිකයි. නොසිටීම වඩාත් සුදුසුය.

සහ එය කිරීමට හොඳම ක්රමය කුමක්ද?

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

මෙය අපට සමහර දෝෂ ඉවත් කිරීමට ඉඩ සලසයි, එනම් ඒවා ප්‍රොඩ් මත සිටීම වළක්වයි.

ගැටලු මොනවාද?

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

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

මෙය පෙර ප්රවේශයට වඩා හොඳයි, නමුත් තවමත් යම් ආකාරයක දෝෂයක් නිෂ්පාදනයට යන බවට ඉහළ සම්භාවිතාවක් පවතී.

එක් එක් සංවර්ධකයාට පරීක්ෂණ බංකුවක්, සම්පූර්ණ ප්‍රමාණයේ පිටපතක් ලබා දීමෙන් අපට වළක්වන්නේ කුමක්ද? මම හිතනවා බාධා කරන දේ පැහැදිලියි කියලා.

ටෙරාබයිට් එකකට වඩා විශාල දත්ත සමුදායක් ඇත්තේ කාටද? කාමරයෙන් අඩකට වඩා.

තවද එක් එක් සංවර්ධකයා සඳහා යන්ත්‍ර තබා ගැනීම එතරම් විශාල නිෂ්පාදනයක් ඇති විට ඉතා මිල අධික වන අතර ඊට අමතරව එය බොහෝ කාලයක් ගත වන බව පැහැදිලිය.

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

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

නමුත් ඔවුන් මෙම ප්‍රවේශය භාවිතා කරන්නේ එය නිෂ්පාදනය විශ්වාසදායක ලෙස තබා ගැනීමට ඔවුන්ට ඉඩ සලසන බැවිනි.

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

තවද මෙය හැකි ය.

තවද මෙම ප්‍රවේශයේදී, අපි එක් එක් සංවර්ධකයින් සඳහා තුනී ක්ලෝන සාදන විට, අපට එය එක් යන්ත්‍රයක බෙදා ගත හැකිය. උදාහරණයක් ලෙස, ඔබට 10TB දත්ත ගබඩාවක් තිබේ නම් සහ එය සංවර්ධකයින් 10 දෙනෙකුට ලබා දීමට අවශ්‍ය නම්, ඔබට XNUMX x XNUMXTB දත්ත සමුදායක් තිබීම අවශ්‍ය නොවේ. එක් යන්ත්‍රයක් භාවිතා කරමින් එක් එක් සංවර්ධකයා සඳහා තුනී හුදකලා පිටපත් සෑදීමට ඔබට අවශ්‍ය වන්නේ එක් යන්ත්‍රයක් පමණි. ඒක වැඩ කරන හැටි ටිකක් පස්සෙ කියන්නම්.

සැබෑ උදාහරණය:

• DB - ටෙරාබයිට් 4,5.

• තත්පර 30 කින් අපට ස්වාධීන පිටපත් ලබා ගත හැකිය.

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

මේක නියමයි. මෙහිදී අපි කතා කරන්නේ මැජික් සහ සමාන්තර විශ්වයක් ගැන ය.

අපගේ නඩුවේදී, මෙය OpenZFS පද්ධතිය භාවිතයෙන් ක්රියා කරයි.

OpenZFS යනු ස්නැප්ෂොට් සහ කොටුවෙන් පිටත ක්ලෝන සඳහා සහය දක්වන පිටපත් මත ලිවීමේ ගොනු පද්ධතියකි. එය විශ්වසනීය හා පරිමාණය කළ හැකි ය. ඇය කළමනාකරණය කිරීම ඉතා පහසුය. එය වචනාර්ථයෙන් කණ්ඩායම් දෙකකට යෙදිය හැකිය.

වෙනත් විකල්ප තිබේ:

• lvm,

• ගබඩාව (උදාහරණයක් ලෙස, පිරිසිදු ගබඩාව).

මම මේ කියන Database Lab එක modular එකක්. මෙම විකල්පයන් භාවිතයෙන් ක්රියාත්මක කළ හැකිය. නමුත් දැනට, අපි OpenZFS වෙත අවධානය යොමු කර ඇත්තෙමු, මන්ද විශේෂයෙන් LVM සමඟ ගැටළු ඇති විය.

එය ක්රියා කරන්නේ කෙසේද? අපි දත්ත වෙනස් කරන සෑම අවස්ථාවකම එය උඩින් ලියනවා වෙනුවට, මෙම නව දත්ත නව කාල වකවානුවක, නව සැණරුවකින් බව සරලව සලකුණු කිරීමෙන් අපි එය සුරකිමු.

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

තවද මෙම පරිශීලකයා එවැනි දත්ත කට්ටලයක් සමඟ වැඩ කරනු ඇත. ඔහු ඒවා ක්‍රමක්‍රමයෙන් වෙනස් කරයි, ඔහුගේම ඡායාරූප සාදයි.

අපි ශාඛා කරන්නෙමු. අපගේ නඩුවේ සෑම සංවර්ධකයෙකුටම ඔහු සංස්කරණය කරන ඔහුගේම ක්ලෝනයක් ලබා ගැනීමට අවස්ථාව ලැබෙනු ඇති අතර බෙදා ගන්නා දත්ත සෑම කෙනෙකුම අතර බෙදා ගනු ඇත.

එවැනි පද්ධතියක් නිවසේදී යෙදවීමට, ඔබ ගැටළු දෙකක් විසඳා ගත යුතුය:

• පළමුවැන්න දත්තවල මූලාශ්රය, ඔබ එය ලබා ගන්නේ කොතැනින්ද යන්නයි. ඔබට නිෂ්පාදනය සමඟ අනුකරණය සැකසිය හැක. ඔබට දැනටමත් ඔබ වින්‍යාස කර ඇති උපස්ථ භාවිතා කළ හැකිය, මම බලාපොරොත්තු වෙමි. WAL-E, WAL-G හෝ Barman. තවද ඔබ RDS හෝ Cloud SQL වැනි වලාකුළු විසඳුම් භාවිතා කරන්නේ නම්, ඔබට තාර්කික ඩම්ප් භාවිතා කළ හැකිය. නමුත් අපි තවමත් ඔබට උපස්ථ භාවිතා කිරීමට උපදෙස් දෙන්නෙමු, මන්ද මෙම ප්‍රවේශය සමඟ ඔබ ගොනු වල භෞතික ව්‍යුහය ද රඳවා ගනු ඇත, එමඟින් පවතින ගැටළු අල්ලා ගැනීම සඳහා නිෂ්පාදනයේදී ඔබ දකින ප්‍රමිතිකවලට වඩා සමීප වීමට ඔබට ඉඩ සලසයි.

• දෙවෙනි එක තමයි Database Lab එක හොස්ට් කරන්න ඕන තැන. එය වලාකුළු විය හැකිය, එය පරිශ්‍රයේ විය හැකිය. ZFS දත්ත සම්පීඩනය සඳහා සහය දක්වන බව මෙහිදී පැවසීම වැදගත්ය. ඒ වගේම ඒක හොඳටම කරනවා.

එවැනි එක් එක් ක්ලෝනය සඳහා, අපි පදනම සමඟ කරන මෙහෙයුම් මත පදනම්ව, යම් ආකාරයක dev වර්ධනය වනු ඇතැයි සිතන්න. මේ සඳහා, dev හට ඉඩ ද අවශ්‍ය වේ. නමුත් අපි ටෙරාබයිට් 4,5 ක පදනමක් ගත් නිසා ZFS එය ටෙරාබයිට් 3,5 දක්වා සම්පීඩනය කරයි. මෙය සැකසුම් අනුව වෙනස් විය හැක. ඒ වගේම අපිට තවමත් dev සඳහා ඉඩ තියෙනවා.

එවැනි පද්ධතියක් විවිධ අවස්ථා සඳහා භාවිතා කළ හැකිය.

• මේවා සංවර්ධකයින්, විමසුම් වලංගු කිරීම සඳහා DBAs, ප්‍රශස්තකරණය සඳහා.

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

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

මෙම ප්රවේශය සමඟ:

1. "ප්‍රොඩ්" හි දෝෂ වල අඩු සම්භාවිතාව, අපි සම්පූර්ණ ප්‍රමාණයේ දත්තවල සියලුම වෙනස්කම් පරීක්ෂා කළ නිසා.

2. අපට පරීක්ෂණ සංස්කෘතියක් ඇත, මන්ද දැන් ඔබට ඔබේ ස්ථාවරය සඳහා පැය ගණන් බලා සිටීමට අවශ්‍ය නැත.

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

• අඩු ප්රතිනිෂ්පාදනය වනු ඇත. අඩු දෝෂ ප්‍රොඩ් වලින් අවසන් වේ. අපි ඒවා පසුව අඩුවෙන් නැවත සකස් කරන්නෙමු.

• අපට ආපසු හැරවිය නොහැකි වෙනස්කම් ආපසු හැරවිය හැක. මෙය සම්මත ප්රවේශය නොවේ.

1. අපි පරීක්ෂණ බංකුවල සම්පත් බෙදා ගන්නා නිසා මෙය ප්රයෝජනවත් වේ.

දැනටමත් හොඳයි, නමුත් වේගවත් කළ හැක්කේ කුමක්ද?

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

දැන් විෂම චක්‍රයක් තිබේ, සංවර්ධකයෙකු සැබෑ සම්පූර්ණ ප්‍රමාණයේ දත්ත වෙත ප්‍රවේශය ලබා ගැනීම සඳහා විශේෂඥයෙකු විය යුතුය. එවැනි ප්රවේශයක් සමඟ ඔහු විශ්වාස කළ යුතුය.

නමුත් එය නොමැති නම් වර්ධනය වන්නේ කෙසේද. නමුත් ඔබට ඇත්තේ ඉතා කුඩා පරීක්ෂණ දත්ත කට්ටලයක් පමණක් නම්? එවිට ඔබට සැබෑ අත්දැකීමක් නොලැබෙනු ඇත.

මෙම කවයෙන් ඉවත් වන්නේ කෙසේද? ඕනෑම මට්ටමක සංවර්ධකයින්ට පහසු වන පළමු අතුරු මුහුණත ලෙස, අපි Slack bot තෝරා ගත්තෙමු. නමුත් එය වෙනත් ඕනෑම අතුරු මුහුණතක් විය හැකිය.

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

ඒ වගේම Slack අපට සහයෝගීතාව සඳහා අවස්ථා ලබා දෙනවා. මෙය නාලිකාවක් පමණක් වන බැවින්, ඔබට මෙම ඉල්ලීම ගැන සාකච්ඡා කිරීම ආරම්භ කළ හැකිය, එවැනි ඉල්ලීමක් සඳහා වන ත්‍රෙඩ් එකේ, ඔබේ සගයන්, සමාගම තුළ සිටින DBAs ping කරන්න.

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

නමුත් මෙම පරීක්ෂණ පිළිගත හැකි වීමට නම්, ඔබ කෙසේ හෝ මෙම ගැටළුව විසඳා ගත යුතුය.

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

නිෂ්පාදනයේදී මෙන් එකම දෘඩාංග තිබීම සිසිල් වනු ඇත, නමුත් එය වෙනස් විය හැකිය.

මතකය සමඟ Postgres ක්රියා කරන ආකාරය මතක තබා ගනිමු. අපට හැඹිලි දෙකක් තිබේ. ගොනු පද්ධතියෙන් එකක් සහ ස්වදේශීය Postgres එකක්, එනම් බෙදාගත් බෆර් කෑෂය.

ඔබ වින්‍යාසය තුළ සඳහන් කරන ප්‍රමාණය මත පදනම්ව, Postgres ආරම්භ වන විට බෙදාගත් බෆර හැඹිලිය වෙන් කරන බව සැලකිල්ලට ගැනීම වැදගත්ය.

දෙවන හැඹිලිය පවතින සියලුම ඉඩ භාවිතා කරයි.

තවද අපි එක් යන්ත්‍රයක ක්ලෝන කිහිපයක් සාදන විට, අපි ක්‍රමයෙන් මතකය පුරවන බව පෙනේ. ඒවගේම හොඳ විදිහට, Shared Buffer Cache යන්ත්‍රයේ තිබෙන මුළු මතක ප්‍රමාණයෙන් 25%ක්.

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

නමුත් අනෙක් අතට, Buffer Cache දර්ශක සඳහා විමසුම් ක්‍රියාත්මක කිරීමට භාවිතා කරයි, එනම් සැලැස්ම අපගේ හැඹිලි කොතරම් විශාලද යන්න මත රඳා පවතී. අපි මෙම පරාමිතිය ගෙන එය අඩු කළහොත්, අපගේ සැලසුම් බොහෝ වෙනස් කළ හැකිය.

උදාහරණයක් ලෙස, අපට prod මත විශාල හැඹිලියක් තිබේ නම්, Postgres දර්ශකයක් භාවිතා කිරීමට කැමති වනු ඇත. සහ එසේ නොවේ නම්, එවිට SeqScan ඇත. අපගේ සැලසුම් සමපාත නොවන්නේ නම් කුමක් සිදුවේද?

නමුත් මෙහිදී අපි නිගමනය කරන්නේ ඇත්ත වශයෙන්ම Postgres හි සැලැස්ම සැලැස්මේ ඇති Shared Buffer හි දක්වා ඇති නිශ්චිත ප්‍රමාණය මත රඳා නොපවතින බවත්, එය effective_cache_size මත රඳා පවතින බවත්ය.

Effective_cache_size යනු අපට ලබා ගත හැකි ඇස්තමේන්තුගත හැඹිලි ප්‍රමාණයයි, එනම් Buffer Cache සහ ගොනු පද්ධති හැඹිලි එකතුවයි. මෙය වින්‍යාසය මගින් සකසා ඇත. තවද මෙම මතකය වෙන් කර නැත.

තවද මෙම පරාමිතිය හේතුවෙන්, අපට මෙම දත්ත නොමැති වුවද, ඇත්ත වශයෙන්ම අප සතුව බොහෝ දත්ත ඇති බව පවසමින් Postgres රවටා ගත හැකිය. මේ අනුව, සැලසුම් සම්පූර්ණයෙන්ම නිෂ්පාදනය සමඟ සමපාත වනු ඇත.

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

• එය දැනට නිෂ්පාදනය මත ඇති බර මත රඳා පවතී.

• එය යන්ත්රයේම ලක්ෂණ මත රඳා පවතී.

තවද මෙය වක්‍ර පරාමිතියකි, නමුත් ඇත්ත වශයෙන්ම අපට ප්‍රතිඵලය ලබා ගැනීම සඳහා මෙම විමසුම කියවන දත්ත ප්‍රමාණයෙන් හරියටම ප්‍රශස්ත කළ හැක.

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

ජෝ විශේෂයෙන් ප්‍රශස්ත කර ඇති ආකාරය දෙස බලමු.

නියම සිස්ටම් එකකින් රික්වෙස්ට් එකක් ගමු. මෙම අවස්ථාවේදී, දත්ත සමුදාය ටෙරාබයිට් 1 කි. ඒවගේම අපිට කැමති 10කට වඩා තිබ්බ අලුත් පොස්ට් ගණන ගණන් කරන්න ඕන.

අපි නාලිකාවට පණිවිඩයක් ලියනවා, අපි වෙනුවෙන් ක්ලෝනයක් යොදවා ඇත. එවැනි ඉල්ලීමක් මිනිත්තු 2,5 කින් සම්පූර්ණ වන බව අපට පෙනෙනු ඇත. අප අවධානය යොමු කරන පළමු කරුණ මෙයයි.

B Joe ඔබට සැලැස්ම සහ ප්‍රමිතික මත පදනම්ව ස්වයංක්‍රීය නිර්දේශ පෙන්වනු ඇත.

සාපේක්ෂ වශයෙන් කුඩා පේළි සංඛ්‍යාවක් ලබා ගැනීමට විමසුම ඕනෑවට වඩා දත්ත සකසන බව අපට පෙනෙනු ඇත. විමසුමේ පෙරන ලද පේළි ඕනෑවට වඩා ඇති බව අප දුටු බැවින් යම් ආකාරයක විශේෂිත දර්ශකයක් අවශ්‍ය වේ.

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

තවද, පෙනෙන පරිදි, අපට මෙහි දර්ශක ස්කෑන් කිරීමක් ඇති අතර ඉක්මනින් ක්‍රියා කළ යුතුව තිබුණි, නමුත් අපි බොහෝ රේඛා පෙරූ බැවින් (අපට ඒවා ගණන් කිරීමට සිදු විය), විමසුම සෙමින් ක්‍රියාත්මක විය.

විමසුමේ කොන්දේසි සහ දර්ශකයේ කොන්දේසි අර්ධ වශයෙන් නොගැලපීම හේතුවෙන් මෙය සැලැස්ම තුළ සිදු විය.

අපි දර්ශකය වඩාත් නිවැරදි කිරීමට උත්සාහ කරමු සහ විමසුම් ක්‍රියාත්මක කිරීම ඉන් පසුව වෙනස් වන්නේ කෙසේදැයි බලමු.

දර්ශකය නිර්මාණය කිරීම සඳහා සෑහෙන කාලයක් ගත විය, නමුත් දැන් අපි විමසුම පරීක්ෂා කර බලා විනාඩි 2,5 වෙනුවට කාලය මිලි තත්පර 156 ක් පමණක් වන අතර එය ප්රමාණවත් වේ. ඒ වගේම අපි කියවන්නේ මෙගා බයිට් 6ක දත්ත පමණයි.

දැන් අපි භාවිතා කරන්නේ දර්ශක පමණක් ස්කෑන් කිරීමයි.

තවත් වැදගත් කථාවක් නම්, සැලැස්ම වඩාත් තේරුම්ගත හැකි ආකාරයෙන් ඉදිරිපත් කිරීමට අපට අවශ්යය. අපි Flame Graphs භාවිතයෙන් දෘශ්‍යකරණය ක්‍රියාත්මක කර ඇත.

මෙය වෙනස් ඉල්ලීමකි, වඩා තීව්‍ර ය. තවද අපි පරාමිති දෙකකට අනුව Flame Graphs ගොඩනඟමු: මෙය සැලසුමේ සහ වේලාවේ විශේෂිත නෝඩයක් ගණනය කළ දත්ත ප්‍රමාණයයි, එනම් නෝඩයේ ක්‍රියාත්මක කාලයයි.

මෙහිදී අපට නිශ්චිත නෝඩ් එකිනෙකා සමඟ සංසන්දනය කළ හැකිය. සාමාන්‍යයෙන් වෙනත් විදැහුම්කරණ ක්‍රම වලදී කිරීමට අපහසු ඒවායින් වැඩිපුර හෝ අඩුවෙන් ගන්නේ කුමන ඒවාද යන්න පැහැදිලි වනු ඇත.

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

තවද මෙම මාතෘකාව පිළිබඳව තවමත් සොයා බලා නොමැති සංවර්ධකයින් විසින් පැහැදිලි කරන්න.depesz.com ද භාවිතා කරයි, මන්ද කුමන ප්‍රමිතික වැදගත්ද සහ නැති ඒවා සොයා ගැනීම ඔවුන්ට පහසු වන බැවිනි.

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

එක්ව

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

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

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

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

ඔබගේ ප්රශ්න

ආයුබෝවන්! වාර්තාවට ස්තූතියි! ඉතා සිත්ගන්නා සුළුය, විශේෂයෙන් මට, මම කලකට පෙර එම ගැටලුව විසඳා ගත් බැවිනි. ඒ වගේම මට ප්‍රශ්න ගණනාවක් තියෙනවා. අඩුම තරමේ එයින් කොටසක්වත් මට ලැබේවි කියා බලාපොරොත්තු වෙනවා.

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

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

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

එක් එක් ක්ලෝනය සඳහා යම් ttl ඇත. මූලික වශයෙන්, අපට ස්ථාවර ttl ඇත.

රහසක් නොවේ නම් කුමක් ද?

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

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

ZFS හි ඇති ප්‍රධාන ගැටලුව කුමක්ද? ඔබ එකම ධාරකයක ධාවනය කළ යුතු බව, එනම් සියලුම අවස්ථා එකම OS තුළ ජීවත් වනු ඇත. ගබඩා කිරීමේදී, ඔබට විවිධ උපකරණ සම්බන්ධ කළ හැකිය. තවද බාධකය යනු ගබඩා පද්ධතියේ ඇති කුට්ටි පමණි. තවද තාක්ෂණයන් තෝරාගැනීමේ ප්රශ්නය සිත්ගන්නා සුළුය. ඇයි LVM නැත්තේ?

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

Nikolai Samokhvalov: මම තවදුරටත් අදහස් දක්වන්නද? මගේ නම නිකොලායි, අපි ඇනටෝලි සමඟ එකට වැඩ කරනවා. ගබඩා කිරීම විශිෂ්ට බව මම එකඟ වෙමි. තවද අපගේ සමහර පාරිභෝගිකයින් පිරිසුදු ගබඩා ආදිය ඇත.

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

නමුත් ZFS සෑම කෙනෙකුටම ලබා ගත හැකිය. DelPhix දැනටමත් ප්රමාණවත්ය, ඔවුන්ට සේවාදායකයින් 300 ක් ඇත. මෙයින්, Fortune 100 හි සේවාදායකයින් 50 ක් ඇත, එනම් ඔවුන් නාසා වෙත ඉලක්ක කර ඇත. ඒ වගේම තමයි අපිට open source Core එකක් තියෙන්නේ. අපට විවෘත මූලාශ්‍ර නොවන අතුරු මුහුණතක් ඇත. අපි පෙන්වන වේදිකාව මෙයයි. නමුත් අපට අවශ්‍ය වන්නේ එය සෑම කෙනෙකුටම ප්‍රවේශ විය හැකි වීමයි. සියලුම පරීක්ෂකයින් ලැප්ටොප් පරිගණක මත අනුමාන කිරීම නවත්වන පරිදි විප්ලවයක් කිරීමට අපට අවශ්‍යයි. අපි SELECT ලිවිය යුතු අතර එය මන්දගාමී බව වහාම දැකිය යුතුය. DBA ඒ ගැන ඔබට පවසන තෙක් බලා සිටීම නවත්වන්න. මෙන්න ප්රධාන ඉලක්කය. ඒ වගේම මම හිතන්නේ අපි හැමෝම මේකට එයි කියලා. ඒ වගේම අපි මේක හදන්නේ හැමෝටම තියෙන්න. එබැවින් ZFS, එය සෑම තැනකම ලබා ගත හැකි නිසා. ගැටළු විසඳීම සඳහා සහ විවෘත මූලාශ්‍ර බලපත්‍රයක් තිබීම සඳහා ප්‍රජාවට ස්තූතියි.*

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

දෙවන ප්‍රශ්නය වන්නේ ස්ථාවරයේ අසමානතාවයයි. අපි හිතමු මට මෙතන ZFS තියෙනවා, හැම දෙයක්ම නියමයි, නමුත් prod එකේ client ට ZFS නැහැ, නමුත් ext4, උදාහරණයක් ලෙස. මෙම නඩුවේ කෙසේද?

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

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

මට ප්‍රශ්න දෙකක් තියෙනවා. මේක හරිම අපූරු දෙයක්. ක්‍රෙඩිට් කාඩ් අංක වැනි නිෂ්පාදන දත්ත තීරණාත්මක වන අවස්ථා තිබේද? දැනටමත් යමක් සූදානම්ද නැතහොත් එය වෙනම කාර්යයක්ද? දෙවන ප්‍රශ්නය - MySQL සඳහා මෙවැනි දෙයක් තිබේද?

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

MySQL ගැන. මෙම පද්ධතිය තැටියේ රාජ්ය ගබඩා කරන ඕනෑම දෙයක් සඳහා භාවිතා කළ හැක. අපි Postgres කරන නිසා, අපි දැන් Postgres සඳහා සියලුම ස්වයංක්‍රීයකරණය මුලින්ම කරනවා. අපට උපස්ථයකින් දත්ත ලබා ගැනීම ස්වයංක්‍රීය කිරීමට අවශ්‍යයි. අපි Postgres නිවැරදිව වින්‍යාස කරමින් සිටිමු. සැලසුම් ගැලපීම ආදිය කරන්නේ කෙසේදැයි අපි දනිමු.

නමුත් පද්ධතිය දිගු කළ හැකි බැවින්, එය MySQL සඳහාද භාවිතා කළ හැක. සහ එවැනි උදාහරණ තිබේ. Yandex හි සමාන දෙයක් ඇත, නමුත් ඔවුන් එය කොතැනකවත් ප්රකාශයට පත් නොකරයි. ඔවුන් එය Yandex.Metrica ඇතුළත භාවිතා කරයි. ඒවගේම MySQL ගැන කතාවක් විතරයි තියෙන්නේ. නමුත් තාක්ෂණයන් සමානයි, ZFS.

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

මම වහාම දෙවන ප්‍රශ්නය නැවතුම්පොළවල සමානකම, සැලසුම්වල සමානකම ගැන අසමි. මෙම සැලැස්ම Postgres විසින් එකතු කරන ලද සංඛ්යාලේඛන මත ද රඳා පවතී. ඔබ මෙම ගැටලුව විසඳන්නේ කෙසේද?

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

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

සෑම අවස්ථාවකදීම දර්ශකය නිර්මාණය කරන්නේද?

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

සංඛ්‍යාලේඛන පිළිබඳ ප්‍රශ්නය සඳහා, අපි උපස්ථයකින් ප්‍රතිසාධනය කරන්නේ නම්, අපි අනුකරණය කරන්නේ නම්, අපගේ සංඛ්‍යාලේඛන හරියටම සමාන වනු ඇත. සම්පූර්ණ භෞතික දත්ත ව්‍යුහය අප සතුව ඇති නිසා, එනම්, අපි සියලු සංඛ්‍යාලේඛන ප්‍රමිතික සමඟ දත්ත එලෙසම ගෙන එන්නෙමු.

මෙන්න තවත් ගැටලුවක්. ඔබ වලාකුළු විසඳුමක් භාවිතා කරන්නේ නම්, එහි ඇත්තේ තාර්කික ඩම්ප් පමණි, මන්ද ගූගල්, ඇමේසන් ඔබට භෞතික පිටපතක් ගැනීමට ඉඩ නොදේ. ගැටලුවක් ඇති වේ.

වාර්තාවට ස්තූතියි. MySQL සහ resource sharing ගැන මෙතන හොඳ ප්‍රශ්න දෙකක් තිබුණා. එහෙත්, ඇත්ත වශයෙන්ම, ඒ සියල්ල පැමිණෙන්නේ මෙය විශේෂිත DBMS හි මාතෘකාවක් නොව සමස්තයක් ලෙස ගොනු පද්ධතියයි. තවද, ඒ අනුව, සම්පත් බෙදාගැනීමේ ගැටළු ද එතැන් සිට විසඳිය යුතුය, අවසානයේ එය Postgres නොවේ, නමුත් ගොනු පද්ධතියේ, සේවාදායකයේ, උදාහරණයක් ලෙස.

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

ZFS වැඩ කරන්නේ එහෙම නිසා එයාල යන්නෙ නෑ. replication නිසා එන file system එකේ වෙනස්කම් අපිට එක thread එකක වෙනම තියාගන්න පුළුවන්. සහ සංවර්ධකයින් භාවිතා කරන ක්ලෝන දත්තවල පැරණි අනුවාද වල තබා ගන්න. එය අපට වැඩ කරයි, මේ සමඟ සෑම දෙයක්ම පිළිවෙලට තිබේ.

යාවත්කාලීන කිරීම අතිරේක ස්ථරයක් ලෙස සිදුවනු ඇති අතර, මෙම ස්තරය මත පදනම්ව සියලුම නව පින්තූර දැනටමත් යයි, හරිද?

පෙර අනුරූ වලින් වූ පෙර ස්ථර වලින්.

පෙර තිබූ ලේයර ගැලවී යනු ඇත, නමුත් ඒවා පැරණි ලේයරයට යොමු කරයි, යාවත්කාලීනයේදී ලැබුණු අවසාන ස්ථරයෙන් ඔවුන් නව පින්තූර ගන්නවාද?

පොදුවේ, ඔව්.

එවිට ප්රතිවිපාකයක් ලෙස අපට ස්තරවල අත්තික්කා දක්වා ඇත. කාලයත් සමඟ ඒවා සම්පීඩනය කළ යුතුද?

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

හෙලෝ, වාර්තාවට ස්තූතියි! ජෝ ගැන ප්‍රශ්නය. ඔබ කීවේ පාරිභෝගිකයා සෑම කෙනෙකුටම දත්ත වෙත ප්‍රවේශය ලබා දීමට කැමති නැති බවයි. නිශ්චිතවම කිවහොත්, පුද්ගලයෙකුට පැහැදිලි විශ්ලේෂණයේ ප්‍රති result ලය තිබේ නම්, ඔහුට දත්ත පරීක්ෂා කළ හැකිය.

එය ඒ වගේ දෙයක්. උදාහරණයක් ලෙස, අපට ලිවිය හැකිය: "ඉ-තැපෑලෙන් තෝරන්න = ඒ වෙත". එනම්, අපි දත්තම නොදකිමු, නමුත් අපට වක්ර සංඥා කිහිපයක් දැකිය හැකිය. මෙය තේරුම් ගත යුතුය. නමුත් අනෙක් අතට, ඒ සියල්ල තිබේ. අපට ලොග් විගණනයක් ඇත, සංවර්ධකයින් කරන්නේ කුමක්දැයි දකින අනෙකුත් සගයන් අපට පාලනය කරයි. කවුරුහරි මෙය කිරීමට උත්සාහ කළහොත්, ආරක්ෂක සේවය ඔවුන් වෙත පැමිණ මෙම ගැටලුව සම්බන්ධයෙන් කටයුතු කරනු ඇත.

සුභ සන්ධ්යාවක් වාර්තාවට ස්තූතියි! මට කෙටි ප්‍රශ්නයක් ඇත. සමාගම Slack භාවිතා නොකරන්නේ නම්, දැන් එයට යම් බැඳීමක් තිබේද, නැතහොත් පරීක්ෂණ යෙදුමක් දත්ත සමුදායන් වෙත සම්බන්ධ කිරීම සඳහා සංවර්ධකයින්ට අවස්ථා යෙදිය හැකිද?

දැන් Slack වෙත සබැඳියක් ඇත, එනම් වෙනත් පණිවිඩකරුවෙකු නොමැත, නමුත් මට ඇත්තෙන්ම වෙනත් පණිවිඩකරුවන් සඳහාද සහාය දැක්වීමට අවශ්‍යය. ඔබට කුමක් කළ හැකිද? ඔබට ජෝ නොමැතිව DB Lab යෙදවිය හැක, REST API ආධාරයෙන් හෝ අපගේ වේදිකාවේ ආධාරයෙන් ගොස් ක්ලෝන සාදා PSQL සමඟ සම්බන්ධ විය හැක. නමුත් ඔබේ සංවර්ධකයින්ට දත්ත වෙත ප්‍රවේශය ලබා දීමට ඔබ සූදානම් නම් මෙය කළ හැකිය, මන්ද තවදුරටත් කිසිදු තිරයක් නොමැති බැවිනි.

මට මෙම ස්ථරය අවශ්ය නොවේ, නමුත් මට එවැනි අවස්ථාවක් අවශ්යයි.

එවිට ඔව්, එය කළ හැකිය.

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