නුදුරු අනාගතයේ දී, අනවශ්‍ය දත්ත ස්වයංක්රීයව ඉවත් කිරීම DBMS [1] හි වැදගත් කාර්යයක් වනු ඇත. මේ අතර, අනවශ්‍ය දත්ත මකා දැමීම හෝ අඩු වියදම් ගබඩා පද්ධති වෙත ගෙනයාම පිළිබඳව අප විසින්ම සැලකිලිමත් විය යුතුය. පේළි මිලියන කිහිපයක් මකා දැමීමට ඔබ තීරණය කළා යැයි සිතමු. තරමක් සරල කාර්යයක්, විශේෂයෙන්ම තත්ත්වය දන්නා අතර සුදුසු දර්ශකයක් තිබේ නම්. "වගුව 1 වෙතින් මකන්න col1 = :value" - වඩා සරල විය හැක්කේ කුමක්ද, හරිද?
වීඩියෝ:
-
මම පළමු වසරේ සිට, එනම් 2007 සිට Highload වැඩසටහන් කමිටුවේ සිටිමි.
-
මම 2005 සිට Postgres සමඟ සිටිමි. බොහෝ ව්යාපෘතිවල එය භාවිතා කර ඇත.
-
2007 සිට RuPostges සමඟ සමූහය.
-
අපි Meetup හි සහභාගිවන්නන් 2100+ දක්වා වර්ධනය වී ඇත. එය දිගු කලක් සැන් ෆ්‍රැන්සිස්කෝ විසින් අභිබවා ගිය නිව් යෝර්ක් නගරයෙන් පසු ලෝකයේ දෙවන ස්ථානයයි.
-
මම අවුරුදු කිහිපයක් කැලිෆෝනියාවේ ජීවත් වෙනවා. මම විශාල සමාගම් ඇතුළුව ඇමරිකානු සමාගම් සමඟ වැඩිපුර ගනුදෙනු කරමි. ඔවුන් Postgres හි ක්රියාකාරී පරිශීලකයන් වේ. ඒ වගේම විවිධ රසවත් දේවල් තියෙනවා.
මගේ සමාගමයි. අපි සංවර්ධන මන්දගාමිත්වය ඉවත් කරන කාර්යයන් ස්වයංක්රීය කිරීමේ ව්‍යාපාරයේ යෙදී සිටිමු.
ඔබ යමක් කරන්නේ නම්, සමහර විට Postgres වටා යම් ආකාරයක ප්ලග් තිබේ. පරිපාලකයා ඔබ වෙනුවෙන් පරීක්ෂණ ස්ථාවරයක් සකසන තෙක් ඔබ බලා සිටිය යුතු යැයි කියමු, නැතහොත් DBA ඔබට ප්‍රතිචාර දක්වන තෙක් ඔබ බලා සිටිය යුතුය. තවද අපි සංවර්ධන, පරීක්ෂණ සහ පරිපාලන ක්‍රියාවලියේ එවැනි බාධක සොයා ගන්නා අතර ස්වයංක්රීයකරණය සහ නව ප්‍රවේශයන් ආධාරයෙන් ඒවා ඉවත් කිරීමට උත්සාහ කරමු.
මම මෑතකදී ලොස් ඇන්ජලීස් හි VLDB හි සිටියෙමි. දත්ත සමුදායන් පිළිබඳ විශාලතම සමුළුව මෙයයි. අනාගතයේදී DBMS ගබඩා කිරීම පමණක් නොව ස්වයංක්රීයව දත්ත මකා දමන බවට වාර්තාවක් තිබුණි. මේක අලුත් මාතෘකාවක්.
සෙටාබයිට් ලෝකයේ වැඩි වැඩියෙන් දත්ත තිබේ - එය පෙටාබයිට් 1 කි. දැන් දැනටමත් ඇස්තමේන්තු කර ඇත්තේ අප සතුව ලෝකයේ සෙටාබයිට් 000 කට වඩා දත්ත ගබඩා කර ඇති බවයි. ඒවගේම තව තවත් ඒවා තියෙනවා.
සහ එය සමඟ කුමක් කළ යුතුද? එය ඉවත් කළ යුතු බව පැහැදිලිය. මෙන්න මේ රසවත් වාර්තාවට සබැඳියක්. නමුත් DBMS හි මෙතෙක් මෙය ක්රියාත්මක කර නොමැත.
සල්ලි ගණන් කරන්න පුළුවන් අයට ඕන දේවල් දෙකක්. ඔවුන්ට අපව මකා දැමීමට අවශ්‍යයි, එබැවින් තාක්ෂණික වශයෙන් අපට එය කළ හැකි විය යුතුය.
මම මීළඟට කියන්න යන්නේ සැබෑ තත්වයන් ගොන්නක්, එනම් මට සහ අවට දත්ත සමුදායන්ට බොහෝ වාර ගණනක්, බොහෝ වාර ගණනක් සිදු වූ දේ සම්පාදනය කරන ආකාරයේ වියුක්ත තත්වයක්. රේක් සෑම තැනකම ඇති අතර සෑම කෙනෙකුම ඒවා මත පාගා දමයි.
අපි හිතමු අපිට පාදයක් හෝ පාද කිහිපයක් වර්ධනය වන බව. ඒ වගේම සමහර වාර්තා පැහැදිලිවම කුණු. උදාහරණයක් ලෙස, පරිශීලකයා එහි යමක් කිරීමට පටන් ගත් නමුත් එය අවසන් කළේ නැත. ටික වේලාවකට පසු, මෙම නිම නොකළ දේ තවදුරටත් ගබඩා කළ නොහැකි බව අපි දනිමු. එනම්, ඉඩ ඉතිරි කර ගැනීම, කාර්ය සාධනය වැඩි දියුණු කිරීම යනාදිය සඳහා අපි සමහර කුණු දේවල් පිරිසිදු කිරීමට කැමතියි.
සාමාන්යයෙන්, කර්තව්යය වන්නේ නිශ්චිත දේවල් මකාදැමීම, සමහර වගුවේ නිශ්චිත රේඛා ස්වයංක්රීය කිරීමයි.
අපට එවැනි ඉල්ලීමක් තිබේ, එය අපි අද කතා කරමු, එනම් කසළ ඉවත් කිරීම ගැන.
අපි පළපුරුදු සංවර්ධකයෙකුගෙන් එය කිරීමට ඉල්ලා සිටියෙමු. ඔහු මෙම ඉල්ලීම භාර ගත්තේය, එය තමාටම පරීක්ෂා කළේය - සියල්ල ක්රියාත්මක වේ. වේදිකාගත කිරීමේදී පරීක්ෂා කර ඇත - සියල්ල හොඳයි. රෝල් කරන ලදී - සියල්ල ක්රියා කරයි. දිනකට වරක් අපි එය ක්රියාත්මක කරමු - සියල්ල හොඳයි.
දත්ත සමුදාය වර්ධනය වන අතර වර්ධනය වේ. Daily DELETE තව ටිකක් හෙමින් වැඩ කරන්න පටන් ගන්නවා.
එවිට අපට දැන් අලෙවිකරණ සමාගමක් ඇති බව අපට වැටහෙන අතර ගමනාගමනය කිහිප ගුණයකින් විශාල වනු ඇත, එබැවින් අපි අනවශ්‍ය දේවල් තාවකාලිකව විරාම කිරීමට තීරණය කරමු. සහ ආපසු යාමට අමතක කරන්න.
මාස කිහිපයකට පසු ඔවුන් සිහිපත් විය. එම සංවර්ධකයා ඉවත් වී හෝ වෙනත් දෙයක කාර්යබහුලව සිටින අතර, එය ආපසු ලබා දෙන ලෙස තවත් කෙනෙකුට උපදෙස් දුන්නේය.
ඔහු dev, වේදිකාගත කිරීම පරීක්ෂා කළේය - සියල්ල හරි. ස්වාභාවිකවම, ඔබ තවමත් එකතු වී ඇති දේ පිරිසිදු කළ යුතුය. ඔහු සෑම දෙයක්ම ක්රියාත්මක වන බව පරීක්ෂා කළේය.
ඊළඟට කුමක් සිදුවේද? එවිට සියල්ල අප වෙනුවෙන් කඩා වැටේ. එය යම් අවස්ථාවක දී සියල්ල පහත වැටෙන පරිදි පහත වැටේ. හැමෝම කම්පනයට පත්වෙලා, කාටවත් තේරෙන්නේ නැහැ මොකද වෙන්නේ කියලා. එවිට කාරණය මෙම DELETE එකේ තිබූ බව පෙනී යයි.
මොකක්හරි වැරැද්දක් වෙලා? වැරදි විය හැකි දේ ලැයිස්තුවක් මෙන්න. මෙයින් වඩාත් වැදගත් වන්නේ කුමක්ද?
-
උදාහරණයක් ලෙස, සමාලෝචනයක් නොතිබුණි, එනම් DBA විශේෂඥයා එය දෙස බැලුවේ නැත. පළපුරුදු ඇසකින් ඔහු වහාම ගැටලුව සොයා ගනු ඇති අතර, ඊට අමතරව, රේඛා මිලියන කිහිපයක් එකතු වී ඇති නිෂ්පාදන සඳහා ඔහුට ප්රවේශය ඇත.
-
සමහර විට ඔවුන් වැරදි දෙයක් පරීක්ෂා කර ඇත.
-
සමහර විට දෘඪාංග යල්පැන ඇති අතර ඔබට මෙම පදනම යාවත්කාලීන කළ යුතුය.
-
නැතහොත් දත්ත සමුදාය තුළම යම් දෝෂයක් ඇති අතර, අපි Postgres සිට MySQL වෙත මාරු විය යුතුය.
-
නැත්තම් ඔපරේෂන් එකේ මොකක් හරි අවුලක් ඇති.
-
සමහර විට වැඩ සංවිධානය කිරීමේදී යම් වැරදි තිබේද, ඔබ යමෙකු ඉවත් කර හොඳම පුද්ගලයින් බඳවා ගත යුතුද?
DBA චෙක්පතක් නොතිබුණි. DBA එකක් තිබේ නම්, ඔහු මෙම පේළි මිලියන කිහිපයක් දකින අතර කිසිදු අත්හදා බැලීමක් නොමැතිව පවා මෙසේ කියනු ඇත: "ඔවුන් එය කරන්නේ නැහැ." මෙම කේතය GitLab, GitHub හි තිබුනේ නම් සහ කේත සමාලෝචන ක්‍රියාවලියක් තිබේ නම් සහ DBA අනුමැතිය නොමැතිව මෙම මෙහෙයුම ප්‍රොඩ් මත සිදුවනු ඇතැයි එවැනි දෙයක් නොතිබුනේ නම්, පැහැදිලිවම DBA පවසනු ඇත: “මෙය කළ නොහැක. .”
තවද ඔබට තැටි IO සමඟ ගැටළු ඇති වන අතර සියලුම ක්‍රියාවලීන් පිස්සු වැටෙනු ඇති බවත්, අගුලු තිබිය හැකි බවත්, ඔබ මිනිත්තු කිහිපයක් සඳහා ස්වයංක්රීය රික්තකය අවහිර කරන බවත් ඔහු කියනු ඇත, එබැවින් මෙය හොඳ නැත.
දෙවන වැරැද්ද - ඔවුන් වැරදි ස්ථානයේ පරීක්ෂා කළා. නිෂ්පාදන මත අනවශ්‍ය දත්ත විශාල ප්‍රමාණයක් එකතු වී ඇති නමුත් සංවර්ධකයාට මෙම දත්ත ගබඩාවේ දත්ත රැස් කර නොතිබූ අතර වේදිකාගත කිරීමේදී කිසිවෙකු මෙම කුණු නිර්මාණය නොකළ බව අපි පසුව දුටුවෙමු. ඒ අනුව, ඉක්මනින් ක්රියාත්මක වූ රේඛා 1 ක් විය.
අපගේ පරීක්ෂණ දුර්වල බව අපි තේරුම් ගනිමු, එනම් ගොඩනඟන ලද ක්රියාවලිය ගැටළු වලට හසු නොවන බව. ප්රමාණවත් DB පරීක්ෂණයක් සිදු කර නැත.
පරමාදර්ශී අත්හදා බැලීමක් වඩාත් සුදුසු වන්නේ එකම උපකරණ මත ය. එකම උපකරණ මත මෙය කිරීම සැමවිටම කළ නොහැකි නමුත් එය දත්ත සමුදායේ සම්පූර්ණ ප්‍රමාණයේ පිටපතක් වීම ඉතා වැදගත් වේ. මේක තමයි මම දැන් අවුරුදු ගාණක් තිස්සේ දේශනා කරන්නේ. ඒ වගේම මම මීට වසරකට පෙර මේ ගැන කතා කළා, ඔබට යූ ටියුබ් හි සියල්ල නැරඹිය හැකිය.
සමහරවිට අපේ උපකරණ නරකද? බැලුවොත් පමාව පැන්නා. ප්‍රයෝජනය 100%ක් බව අපි දැක්කා. ඇත්ත වශයෙන්ම, මේවා නවීන NVMe ධාවකයන් නම්, එය අපට වඩාත් පහසු වනු ඇත. සමහර විට අපි එයින් බිම නොයන්නෙමු.
ඔබට වලාකුළු තිබේ නම්, වැඩිදියුණු කිරීම පහසුවෙන්ම සිදු කෙරේ. නව දෘඪාංග මත නව අනුරූ මතු කළේය. මාරු කිරීම. ඒ වගේම සියල්ල හොඳයි. හරි පහසුයි.
කුඩා තැටි කෙසේ හෝ ස්පර්ශ කළ හැකිද? මෙන්න, DBA ආධාරයෙන්, අපි මුරපොල සුසර කිරීම නම් නිශ්චිත මාතෘකාවකට කිමිදෙමු. අපට මුරපොල සුසර කිරීමක් නොතිබූ බව පෙනේ.
මුරපොල යනු කුමක්ද? එය ඕනෑම DBMS එකක ඇත. ඔබට වෙනස් වන දත්ත මතකයේ ඇති විට, එය වහාම තැටියට ලියා නැත. දත්ත වෙනස් වී ඇති තොරතුරු මුලින්ම ලියන්නේ ඉදිරි ලොගයට ය. තවද යම් අවස්ථාවක දී, DBMS විසින් නියම පිටු තැටියට දැමීමට කාලය පැමිණ ඇති බව තීරණය කරයි, එවිට අපට අසමත් වීමක් තිබේ නම්, අපට අඩු REDO කළ හැකිය. ඒක හරියට සෙල්ලම් බඩුවක් වගේ. අපිව මැරුවොත් අන්තිම චෙක්පොයින්ට් එකෙන් ගේම පටන් ගන්නවා. සියලුම DBMS එය ක්රියාත්මක කරයි.
Postgres හි සැකසුම් පසුගාමී වේ. ඒවා නිර්මාණය කර ඇත්තේ වසර 10-15 පැරණි දත්ත සහ ගනුදෙනු සඳහාය. සහ මුරපොල යනු ව්යතිරේකයක් නොවේ.
මෙන්න අපගේ Postgres පරීක්ෂණ වාර්තාවේ තොරතුරු, එනම් ස්වයංක්රීය සෞඛ්‍ය පරීක්‍ෂණය. ඒ වගේම මෙන්න ටෙරාබයිට් කිහිපයක දත්ත සමුදායක්. 90% ක්ම පාහේ බලහත්කාරයෙන් මුරපොලවල් ඇති බව හොඳින් දැකගත හැකිය.
එයින් අදහස් කරන්නේ කුමක් ද? එහි සැකසුම් දෙකක් තිබේ. මුරපොල කල් ඉකුත්වීමෙන් පැමිණිය හැකිය, උදාහරණයක් ලෙස, විනාඩි 10 කින්. එහෙමත් නැතිනම් සෑහෙන්න ඩේටා පිරෙව්වම එන්න පුළුවන්.
සහ පෙරනිමියෙන් max_wal_saze 1 ගිගාබයිට් ලෙස සකසා ඇත. ඇත්ත වශයෙන්ම, මෙය මෙගාබයිට් 300-400 කට පසුව Postgres හි ඇත්තෙන්ම සිදු වේ. ඔබ බොහෝ දත්ත වෙනස් කර ඇති අතර ඔබගේ මුරපොල සිදුවේ.
කිසිවෙකු එය සුසර නොකළේ නම් සහ සේවාව වර්ධනය වී සමාගම විශාල මුදලක් උපයන්නේ නම්, එයට විශාල ගනුදෙනු තිබේ නම්, මුරපොල විනාඩියකට වරක් පැමිණේ, සමහර විට තත්පර 30 කට වරක් සහ සමහර විට අතිච්ඡාදනය වේ. මෙය තරමක් නරක ය.
ඒවගේම අපි එය අඩුවෙන් එන බවට වග බලා ගත යුතුයි. එනම්, අපට max_wal_size වැඩි කළ හැක. තවද එය අඩු වාර ගණනක් පැමිණෙනු ඇත.
නමුත් අපි එය වඩාත් නිවැරදිව කරන්නේ කෙසේද යන්න සඳහා සම්පූර්ණ ක්‍රමවේදයක් සකස් කර ඇත, එනම්, නිශ්චිත දත්ත මත පදනම්ව, සැකසුම් තෝරා ගැනීම පිළිබඳ තීරණයක් ගන්නේ කෙසේද යන්නයි.
ඒ අනුව අපි දත්ත සමුදායන් පිළිබඳ අත්හදා බැලීම් මාලාවක් දෙකක් සිදු කරනවා.
පළමු මාලාව - අපි max_wal_size වෙනස් කරමු. ඒ වගේම අපි දැවැන්ත මෙහෙයුමක් කරනවා. පළමුව, අපි එය ගිගාබයිට් 1 ක පෙරනිමි සැකසුම් මත කරන්නෙමු. තවද අපි රේඛා මිලියන ගණනක දැවැන්ත මකාදැමීමක් කරන්නෙමු.
එය අපට කොතරම් දුෂ්කර දැයි ඔබට පෙනෙනු ඇත. තැටිය IO ඉතා නරක බව අපට පෙනේ. අපි බලනවා අපි WAL කීයක් හැදුවද කියලා, මේක ගොඩක් වැදගත් නිසා. බලමු චෙක් පොයින්ට් එක කීපාරක් උනාද කියලා. ඒ වගේම අපිට පේනවා ඒක හොඳ නැහැ කියලා.
ඊළඟට අපි max_wal_size වැඩි කරනවා. අපි නැවත කියනවා. අපි වැඩි කරනවා, අපි නැවත කියනවා. සහ බොහෝ වාරයක්. මූලධර්මය අනුව, ලකුණු 10 ක් හොඳයි, එහිදී 1, 2, 4, 8 ගිගාබයිට්. තවද අපි යම් පද්ධතියක හැසිරීම දෙස බලමු. මෙහි උපකරණ නිෂ්පාදනය මත මෙන් විය යුතු බව පැහැදිලිය. ඔබට එකම තැටි, එකම මතක ප්රමාණය සහ එකම Postgres සැකසුම් තිබිය යුතුය.
තවද මේ ආකාරයෙන් අපි අපගේ පද්ධතිය හුවමාරු කර ගන්නා අතර, නරක ස්කන්ධයක් DELETE කිරීමේදී DBMS හැසිරෙන්නේ කෙසේද, එය මුරපොල කරන්නේ කෙසේදැයි අපි දනිමු.
රුසියානු භාෂාවෙන් මුරපොල යනු මුරපොලකි.
උදාහරණය: දර්ශකය අනුව පේළි මිලියන කිහිපයක් මකන්න, පේළි පිටු පුරා "විසිරී" ඇත.
මෙන්න උදාහරණයක්. මෙය යම් පදනමක්. සහ max_wal_size සඳහා ගිගාබයිට් 1ක පෙරනිමි සැකසුම සමඟ, අපගේ තැටි පටිගත කිරීම සඳහා රාක්කයට යන බව ඉතා පැහැදිලිය. මෙම පින්තූරය ඉතා රෝගී රෝගියෙකුගේ සාමාන්ය රෝග ලක්ෂණයකි, එනම්, ඔහු ඇත්තටම නරකක් දැනුනි. තවද එක් මෙහෙයුමක් සිදු විය, පේළි මිලියන කිහිපයක මකාදැමීමක් පමණක් විය.
එවැනි මෙහෙයුමක් ප්‍රොඩ්හි කිරීමට ඉඩ දුන්නොත්, අපි නිකම්ම වැතිර සිටිමු, මන්ද එක් DELETE එකක් රෙජිමේන්තුව තුළ අපව මරා දමන බව පැහැදිලිය.
තවද, ගිගාබයිට් 16 ක් කොහෙද, දත් දැනටමත් ගොස් ඇති බව පැහැදිලිය. දත් දැනටමත් වඩා හොඳයි, එනම්, අපි සිවිලිමට තට්ටු කරනවා, නමුත් එතරම් නරක නැහැ. එතන යම් නිදහසක් තිබුණා. දකුණු පසින් වාර්තාව ඇත. සහ මෙහෙයුම් සංඛ්යාව - දෙවන ප්රස්ථාරය. ගිගාබයිට් 16 ක් වූ විට අප දැනටමත් හුස්ම ගැනීම තරමක් පහසු බව පැහැදිලිය.
තවද ගිගාබයිට් 64 ක් සම්පූර්ණයෙන්ම හොඳ වී ඇති බව දැකිය හැකිය. දැනටමත් දත් උච්චාරණය කර ඇත, වෙනත් මෙහෙයුම් වලින් බේරීමට සහ තැටිය සමඟ යමක් කිරීමට වැඩි අවස්ථාවන් තිබේ.
ඇයි එසේ
මම විස්තර ටිකක් කිමිදෙන්නම්, නමුත් මෙම මාතෘකාව, මුරපොල සුසර කිරීම සිදු කරන්නේ කෙසේද, සම්පූර්ණ වාර්තාවක් ලබා ගත හැකිය, එබැවින් මම වැඩිය පටවන්නේ නැත, නමුත් ඇති දුෂ්කරතා මොනවාදැයි මම ටිකක් ගෙනහැර දක්වමි.
මුරපොල බොහෝ විට සිදු වන්නේ නම්, සහ අපි අපගේ රේඛා අනුක්‍රමිකව යාවත්කාලීන නොකර, දර්ශකය මගින් සොයා ගන්නේ නම්, එය හොඳයි, අපි සම්පූර්ණ වගුව මකා නොදමන නිසා, එය සිදු විය හැකිය, අපි මුලින්ම පළමු පිටුව ස්පර්ශ කළෙමු, පසුව දහස් වෙනි, පසුව පළමු ස්ථානයට ආපසු ගියේය. පළමු පිටුවට මෙම සංචාර අතර, මුරපොල දැනටමත් එය තැටියට සුරකින ලද්දේ නම්, එය නැවත එය සුරකිනු ඇත, මන්ද අප එය දෙවන වරටත් අපිරිසිදු කර ඇත.
තවද අපි එය බොහෝ වාරයක් සුරැකීමට මුරපොලට බල කරන්නෙමු. ඔහුට අතිරික්ත මෙහෙයුම් සිදු වන්නේ කෙසේද?
නමුත් එය පමණක් නොවේ. පිටු Postgres හි කිලෝබයිට් 8 ක් සහ Linux හි කිලෝබයිට් 4 කි. සහ full_page_writes සැකසීමක් ඇත. එය පෙරනිමියෙන් සක්රිය කර ඇත. ඒවගේම මේක හරි, මොකද අපි ඕෆ් කලොත්, ඒක කඩා වැටුනොත් පේජ් එකෙන් බාගයක් විතරක් ඉතුරු වෙන අවදානමක් තියෙනවා.
ඉදිරි ලොගයේ WAL වෙත ලිවීමේ හැසිරීම කෙබඳුද යත්, අපට මුරපොලක් ඇති විට සහ අපි පළමු වරට පිටුව වෙනස් කරන විට, මුළු පිටුවම, එනම් කිලෝබයිට් 8ම ඉදිරි ලොගයට ඇතුල් වේ, නමුත් අපි වෙනස් කළේ රේඛාව, බයිට් 100 ක් බරයි. ඒ වගේම අපි මුළු පිටුවම ලියා ගත යුතුයි.
පසුකාලීන වෙනස්කම් වලදී නිශ්චිත ටියුපල් පමණක් පවතිනු ඇත, නමුත් පළමු වතාවට අපි සියල්ල ලියන්නෙමු.
තවද, ඒ අනුව, මුරපොල නැවත සිදු වූයේ නම්, අපි නැවත මුල සිට සියල්ල ආරම්භ කර මුළු පිටුවම තල්ලු කළ යුතුය. නිතර මුරපොලවල් සමඟ, අපි එකම පිටු හරහා ගමන් කරන විට, full_page_writes = on එය විය හැකි ප්‍රමාණයට වඩා වැඩි වනු ඇත, එනම් අපි තවත් WAL උත්පාදනය කරමු. තවත් ඒවා අනුපිටපත් වෙත, ලේඛනාගාරයට, තැටියට යවනු ලැබේ.
තවද, ඒ අනුව, අපට අතිරික්ත දෙකක් තිබේ.
අපි max_wal_size වැඩි කළහොත්, අපි එය මුරපොල සහ wal රයිටර් යන දෙකටම පහසු කරන බව පෙනේ. ඒ වගේම නියමයි.
ටෙරාබයිට් එකක් දාගෙන ජීවත් වෙමු. එහි ඇති නරක කුමක්ද? මෙය නරක ය, මන්ද අසාර්ථක වූ විට, අපි පැය ගණනක් නගින්නෙමු, මන්ද මුරපොල බොහෝ කලකට පෙර වූ අතර දැනටමත් බොහෝ දේ වෙනස් වී ඇත. ඒ වගේම අපි මේ ඔක්කොම REDO කරන්න ඕන. ඉතින් අපි දෙවන අත්හදා බැලීම් මාලාව කරන්නෙමු.
අපි මෙහෙයුමක් කර මුරපොල අවසන් වීමට ආසන්න වන විට බලමු, අපි -9 Postgres හිතාමතාම මරා දමමු.
ඊට පසු, අපි එය නැවත ආරම්භ කර, මෙම උපකරණය මත එය කොපමණ කාලයක් ඉහළ යනු ඇත්දැයි බලමු, එනම් මෙම නරක තත්වය තුළ එය කොපමණ ප්‍රමාණයක් නැවත සකසයිද යන්න.
තත්වය නරක බව මම දෙවරක් සටහන් කරමි. පළමුව, මුරපොල අවසන් වීමට පෙර අපි කඩා වැටුණෙමු, එබැවින් අපට අහිමි වීමට බොහෝ දේ ඇත. දෙවනුව අපි දැවැන්ත මෙහෙයුමක් කළා. මුරපොලවල් කල් ඉකුත් වී ඇත්නම්, බොහෝ විට, අවසාන මුරපොලේ සිට අඩු WAL ජනනය වනු ඇත. එනම්, එය ද්විත්ව පරාජිතයෙකි.
අපි විවිධ max_wal_size ප්‍රමාණයන් සඳහා එවැනි තත්වයක් මනිනු ලබන අතර max_wal_size 64 gigabytes නම්, ද්විත්ව නරකම අවස්ථාවක අපි විනාඩි 10 ක් නැඟී සිටින බව තේරුම් ගනිමු. ඒ වගේම අපි හිතනවා ඒක අපිට ගැලපෙනවද නැද්ද කියලා. මෙය ව්‍යාපාරික ප්‍රශ්නයකි. අපි ව්‍යාපාරික තීරණ සම්බන්ධයෙන් වගකිව යුතු අයට මේ පින්තූරය පෙන්විය යුතු අතර, “ප්රශ්නයක් ඇති වූ විට අපට කොපමණ කාලයක් වැතිර සිටිය හැකිද? අපි විනාඩි 3-5 ක් නරකම තත්වයේ වැතිර සිටිය හැකිද? සහ ඔබ තීරණයක් ගන්න.
තවද මෙහි සිත්ගන්නා කරුණකි. සම්මන්ත්‍රණයේදී පැට්‍රෝනි ගැන අපට වාර්තා කිහිපයක් තිබේ. සහ සමහර විට ඔබ එය භාවිතා කරයි. මෙය Postgres සඳහා ස්වයංක්රීය අසාර්ථකත්වයකි. GitLab සහ Data Egret මේ ගැන කතා කළා.
ඔබට තත්පර 30 කින් එන ස්වයංක්රීය අසාර්ථකත්වයක් තිබේ නම්, සමහර විට අපට විනාඩි 10 ක් නිදා ගත හැකිද? මක්නිසාද යත් අපි මෙම අවස්ථාව වන විට අනුරුවට මාරු වන අතර සියල්ල හොඳින් සිදුවනු ඇත. මෙය ඉතා වැදගත් කරුණකි. මම පැහැදිලි පිළිතුරක් දන්නේ නැහැ. මෙම මාතෘකාව ක්‍රෑෂ් ප්‍රතිසාධනය වටා පමණක් නොවන බව මට හැඟේ.
අසාර්ථක වීමෙන් පසු අපට දිගු සුවයක් තිබේ නම්, වෙනත් බොහෝ අවස්ථාවන්හිදී අප අපහසුතාවයට පත් වනු ඇත. උදාහරණයක් ලෙස, එකම අත්හදා බැලීම් වලදී, අපි යමක් කරන විට සහ සමහර විට විනාඩි 10 ක් බලා සිටීමට සිදු වේ.
අපිට autofailover එකක් තිබුණත් මම තවම වැඩි දුරක් යන්නේ නැහැ. රීතියක් ලෙස, ගිගාබයිට් 64, 100 වැනි අගයන් හොඳ අගයන් වේ. සමහර විට අඩුවෙන් තෝරා ගැනීම පවා වටී. පොදුවේ ගත් කල, මෙය සියුම් විද්යාවකි.
පුනරාවර්තන සිදු කිරීම සඳහා, උදාහරණයක් ලෙස, max_wal_size =1, 8, ඔබ ස්කන්ධ මෙහෙයුම බොහෝ වාරයක් නැවත කිරීමට අවශ්ය වේ. ඔබ එය කලා. සහ එකම පදනම මත ඔබ එය නැවත කිරීමට අවශ්ය, නමුත් ඔබ දැනටමත් සියල්ල මකා ඇත. කුමක් කරන්න ද?
අපගේ විසඳුම ගැන මම පසුව කතා කරමි, එවැනි අවස්ථාවන්හිදී පුනරාවර්තනය කිරීම සඳහා අප කරන දේ. තවද මෙය වඩාත්ම නිවැරදි ප්රවේශයයි.
නමුත් මේ අවස්ථාවේ දී, අපි වාසනාවන්ත විය. මෙහි සඳහන් වන පරිදි "BEGIN, DELETE, ROLLBACK" නම්, අපට DELETE නැවත කළ හැක. එනම්, අපි එය අප විසින්ම අවලංගු කළහොත්, අපට එය නැවත කළ හැකිය. භෞතිකව ඔබ තුළ දත්ත එකම ස්ථානයේ පවතිනු ඇත. ඔබට බඩ පිපීම පවා නොලැබේ. ඔබට එවැනි DELETEs හරහා නැවත නැවත කළ හැක.
ROLLBACK සමඟින් මෙම මකාදැමීම ඔබට නිසි ලෙස යොදවා ඇති දත්ත සමුදා විද්‍යාගාර නොමැති වුවද, මුරපොල සුසර කිරීම සඳහා වඩාත් සුදුසු වේ.
අපි "i" තීරුවකින් තහඩුවක් සෑදුවෙමු. Postgres හි උපයෝගිතා තීරු ඇත. විශේෂයෙන් ඉල්ලන්නේ නම් මිස ඒවා නොපෙනේ. ඒවා නම්: ctid, xmid, xmax.
Ctid යනු භෞතික ලිපිනයකි. ශුන්‍ය පිටුව, පිටුවේ පළමු ටුපල්.
ROOLBACK වලින් පසුව tuple එකම ස්ථානයේ රැඳී ඇති බව පෙනේ. එනම්, අපට නැවත උත්සාහ කළ හැකිය, එය එලෙසම හැසිරෙනු ඇත. ප්රධාන දෙය මෙයයි.
Xmax යනු ටුපල්ගේ මරණයේ කාලයයි. එය මුද්‍රා තැබූ නමුත්, ගනුදෙනුව ආපසු හැරවූ බව Postgres දනී, එබැවින් එය 0 හෝ එය පෙරළන ලද ගනුදෙනුවක් වුවද කමක් නැත. මෙයින් ඇඟවෙන්නේ DELETE හරහා පුනරාවර්තනය කිරීමට සහ පද්ධති හැසිරීම් වල තොග මෙහෙයුම් පරීක්ෂා කිරීමට හැකි බවයි. ඔබට දුප්පත් අය සඳහා දත්ත සමුදා රසායනාගාර සෑදිය හැකිය.
මේක programmers ගැන. DBA ගැනද, ඔවුන් සෑම විටම මේ සඳහා ක්‍රමලේඛකයින්ට බැණ වදිනවා: “ඔබ මෙතරම් දිගු හා දුෂ්කර මෙහෙයුම් කරන්නේ ඇයි?”. මෙය සම්පූර්ණයෙන්ම වෙනස් ලම්බක මාතෘකාවකි. ඉස්සර පරිපාලනයක් තිබුණා, දැන් සංවර්ධනයක් ඇති වෙනවා.
පැහැදිලිවම, අපි කෑලිවලට කැඩිලා නැහැ. එය පැහැදිලියි. මිලියන ගණනක රේඛා ගොඩක් සඳහා එවැනි DELETE කොටස් වලට නොකැඩිය නොහැක. එය විනාඩි 20 ක් සිදු කරනු ලබන අතර, සෑම දෙයක්ම වැතිරෙනු ඇත. එහෙත්, අවාසනාවකට මෙන්, පළපුරුදු සංවර්ධකයින් පවා ඉතා විශාල සමාගම්වල පවා වැරදි සිදු කරයි.
කැඩීම වැදගත් වන්නේ ඇයි?
-
තැටිය අමාරුයි කියලා අපි දැක්කොත්, අපි එය මන්දගාමී කරමු. අපි කැඩී ගියහොත්, අපට විරාම එකතු කළ හැකිය, අපට තෙරපීම මන්දගාමී කළ හැකිය.
-
තවද අපි දිගු කලක් අන් අයව අවහිර නොකරමු. සමහර අවස්ථාවල දී එය වැදගත් නොවේ, ඔබ කිසිවෙක් වැඩ නොකරන සැබෑ කුණු මකා නම්, බොහෝ විට ඔබ autovacuum වැඩ හැර වෙන කිසිවෙකු අවහිර නොකරනු ඇත, එය ගනුදෙනුව සම්පූර්ණ වන තෙක් බලා සිටිනු ඇත. නමුත් ඔබ වෙනත් කෙනෙකුට ඉල්ලා සිටිය හැකි දෙයක් ඉවත් කළහොත්, ඔවුන් අවහිර කරනු ලැබේ, යම් ආකාරයක දාම ප්රතික්රියාවක් ඇති වේ. වෙබ් අඩවි සහ ජංගම යෙදුම්වල දිගු ගනුදෙනු වළක්වා ගත යුතුය.
මෙය සිත්ගන්නා සුළුය. සංවර්ධකයින් අසන බව මම බොහෝ විට දකිමි: "මම තෝරාගත යුතු ඇසුරුම් ප්රමාණය කුමක්ද?".
බණ්ඩල් ප්රමාණය විශාල වන තරමට ගණුදෙණු උඩිස් මුදල කුඩා වන බව පැහැදිලිය. නමුත් ඒ සමඟම, මෙම ගනුදෙනුව සඳහා කාලය වැඩි වේ.
මට ඉතා සරල රීතියක් ඇත: ඔබට හැකි තරම් ගන්න, නමුත් තත්පරයට ක්රියාත්මක කළ හැකි ඒවා ඉක්මවා නොයන්න.
ඇයි තත්පරයක්? පැහැදිලි කිරීම ඉතා සරල සහ සෑම කෙනෙකුටම, තාක්ෂණික නොවන පුද්ගලයින්ට පවා තේරුම් ගත හැකිය. අපි ප්රතික්රියාවක් දකිනවා. අපි මිලි තත්පර 50 ක් ගනිමු. යමක් වෙනස් වී ඇත්නම්, අපගේ ඇස ප්‍රතික්‍රියා කරයි. අඩු නම්, වඩාත් අපහසු වේ. මිලි තත්පර 100කට පසුව යමක් ප්‍රතිචාර දක්වන්නේ නම්, උදාහරණයක් ලෙස, ඔබ මූසිකය ක්ලික් කර එය ඔබට මිලි තත්පර 100කට පසුව පිළිතුරු දුන්නේ නම්, ඔබට දැනටමත් මෙම සුළු ප්‍රමාදය දැනේ. තත්පරයක් දැනටමත් තිරිංග ලෙස වටහාගෙන ඇත.
ඒ අනුව, අපි අපගේ මහා මෙහෙයුම් තත්පර 10 ක පිපිරීම් වලට කඩා දැමුවහොත්, අපි යමෙකු අවහිර කිරීමේ අවදානමක් ඇත. එය තත්පර කිහිපයක් සඳහා ක්රියා කරනු ඇති අතර, මිනිසුන් දැනටමත් එය දකිනු ඇත. ඒ නිසා මම කැමති තත්පරයකට වඩා වැඩ නොකිරීමටයි. නමුත් ඒ සමඟම, එය ඉතා සියුම් ලෙස බිඳ දමන්න එපා, මන්ද ගනුදෙනුව පොදු කාර්ය සැලකිය යුතු වනු ඇත. පදනම වඩාත් දුෂ්කර වනු ඇත, වෙනත් විවිධ ගැටළු මතු විය හැකිය.
අපි ඇසුරුමේ ප්රමාණය තෝරා ගනිමු. සෑම අවස්ථාවකදීම, අපට එය වෙනස් ආකාරයකින් කළ හැකිය. ස්වයංක්රීය කළ හැක. තවද එක් පැකේජයක් සැකසීමේ කාර්යක්ෂමතාව පිළිබඳව අපට ඒත්තු ගොස් ඇත. එනම්, අපි එක් පැකේජයක් මකා දැමීම හෝ යාවත්කාලීන කිරීම සිදු කරයි.
මාර්ගය වන විට, මම කතා කරන සෑම දෙයක්ම DELETE ගැන පමණක් නොවේ. ඔබ අනුමාන කළ පරිදි, මේවා දත්ත මත සිදුවන ඕනෑම තොග මෙහෙයුම් වේ.
ඒ වගේම අපි දකිනවා සැලැස්ම විශිෂ්ටයි. ඔබට දර්ශක ස්කෑන් කිරීම දැකිය හැකිය, දර්ශක පමණක් ස්කෑන් කිරීම ඊටත් වඩා හොඳය. ඒ වගේම අපිට කුඩා දත්ත ප්‍රමාණයක් සම්බන්ධයි. ඒ වගේම තත්පරයකටත් අඩු කාලයක් සම්පූර්ණ වෙනවා. සුපිරි.
ඒ වගේම අපි තවමත් පරිහානියට පත් නොවන බවට වග බලා ගත යුතුයි. පළමු ඇසුරුම් ඉක්මනින් ක්රියාත්මක වන අතර පසුව එය නරක අතට හැරේ, නරක අතට හැරේ. මෙම ක්රියාවලිය ඔබට බොහෝ පරීක්ෂා කිරීමට අවශ්ය වේ. දත්ත සමුදා විද්‍යාගාර යනු හරියටම මෙයයි.
නිෂ්පාදනයේදී මෙය නිවැරදිව අනුගමනය කිරීමට අපට ඉඩ සලසන පරිදි අපි තවමත් යමක් සූදානම් කළ යුතුය. උදාහරණයක් ලෙස, අපට ලොගයේ වේලාව ලිවිය හැකිය, අපි දැන් සිටින ස්ථානය සහ අප දැන් මකා දැමූ අය ලිවිය හැකිය. තවද මෙය පසුව සිදුවන්නේ කුමක්ද යන්න තේරුම් ගැනීමට අපට ඉඩ සලසයි. යම් දෙයක් වැරදී ගියහොත්, ඉක්මනින් ගැටලුව සොයා ගන්න.
අපට ඉල්ලීම්වල කාර්යක්ෂමතාව පරීක්ෂා කිරීමට අවශ්ය නම් සහ අපට බොහෝ වාරයක් පුනරාවර්තනය කිරීමට අවශ්ය නම්, එවිට සෙසු බොට් වැනි දෙයක් තිබේ. ඔහු දැනටමත් සූදානම්. එය දිනපතා සංවර්ධකයින් දුසිම් ගණනක් භාවිතා කරයි. ඒවගේම ඔයාගෙම පිටපතක් තත්පර 30කින් ඉල්ලපුවම ටෙරාබයිට් විශාල දත්ත ගබඩාවක් දෙන්න එයා දන්නවා. තවද ඔබට එහි යමක් මකා දමා RESET යැයි පවසා නැවත එය මකා දැමිය හැක. ඔබට එය මේ ආකාරයෙන් අත්හදා බැලිය හැකිය. මම මේ දේ සඳහා අනාගතයක් දකිමි. තවද අපි දැනටමත් එය කරමින් සිටිමු.
කොටස් කිරීමේ උපාය මාර්ග මොනවාද? පැකේජයේ සංවර්ධකයින් භාවිතා කරන විවිධ කොටස් කිරීමේ උපාය මාර්ග 3ක් මම දකිමි.
පළමු එක ඉතා සරලයි. අපට සංඛ්‍යාත්මක හැඳුනුම්පතක් තිබේ. ඒවගේම අපි එය විවිධ කාල පරාසයන්ට කඩා ඒ සමඟ වැඩ කරමු. අවාසිය පැහැදිලිය. පළමු කොටසේ, අපට සැබෑ කුණු පේළි 100 ක් තිබිය හැකිය, දෙවන පේළි 5 තුළ හෝ කිසිසේත් නැත, නැතහොත් පේළි 1 ම කුණු බවට පත් වනු ඇත. ඉතා අසමාන වැඩ, නමුත් එය බිඳ දැමීම පහසුය. උපරිම හැඳුනුම්පත අරගෙන කුඩු කළා. මෙය බොළඳ ප්රවේශයකි.
දෙවන උපාය මාර්ගය වන්නේ සමබර ප්රවේශයකි. එය Gitlab හි භාවිතා වේ. ඔවුන් මේසය ගෙන ස්කෑන් කළා. අපි හැඳුනුම්පත් ඇසුරුම්වල මායිම් සොයා ගත්තෙමු, එවිට සෑම ඇසුරුමකම හරියටම වාර්තා 10 ක් තිබුණි. ඒවගේම ඒවා පෝලිමේ තියන්න. ඊට පස්සේ අපි ක්රියාවලිය කරනවා. ඔබට මෙය නූල් කිහිපයකින් කළ හැකිය.
පළමු උපාය මාර්ගයේ ද, මාර්ගය වන විට, ඔබට මෙය නූල් කිහිපයකින් කළ හැකිය. එය අපහසු නැත.
නමුත් සිසිල් සහ වඩා හොඳ ප්රවේශයක් තිබේ. මෙය තුන්වන උපාය මාර්ගයයි. සහ හැකි විට, එය තෝරා ගැනීමට වඩා හොඳය. අපි මෙය කරන්නේ විශේෂ දර්ශකයක පදනම මතය. මෙම අවස්ථාවේදී, එය බොහෝ විට අපගේ කසළ තත්ත්වය සහ හැඳුනුම්පත අනුව දර්ශකයක් වනු ඇත. අපි හැඳුනුම්පත ඇතුළත් කරන්නෙමු, එවිට අපි ගොඩට නොයන ලෙස එය දර්ශකයක් පමණක් ස්කෑන් කරන්නෙමු.
සාමාන්යයෙන්, දර්ශක පමණක් ස්කෑන් කිරීම දර්ශක පරිලෝකනයට වඩා වේගවත් වේ.
තවද අපට මැකීමට අවශ්ය අපගේ හැඳුනුම්පත් අපි ඉක්මනින් සොයා ගනිමු. BATCH_SIZE අපි කලින් තෝරා ගනිමු. ඒ වගේම අපි ඒවා ලබා ගන්නවා පමණක් නොව, අපි ඒවා විශේෂ ආකාරයකින් ලබාගෙන වහාම ඒවා හැක් කරන්නෙමු. නමුත් අපි අගුලු දමන්නේ ඒවා දැනටමත් අගුළු දමා ඇත්නම්, අපි ඒවා අගුළු නොදැමීමට, නමුත් ඉදිරියට ගොස් ඊළඟ ඒවා ගන්න. මෙය යාවත්කාලීන කිරීම මඟ හැරීම සඳහා අගුලු දමා ඇත. Postgres හි මෙම සුපිරි විශේෂාංගය අපට අවශ්ය නම් ත්‍රෙඩ් කිහිපයක වැඩ කිරීමට ඉඩ සලසයි. එය එක් ධාරාවකින් හැකි ය. මෙන්න CTE එකක් - මේක එක ඉල්ලීමක්. මෙම CTE හි දෙවන මහලේ අපට සැබෑ මකාදැමීමක් සිදුවෙමින් පවතී - returning *. ඔබට හැඳුනුම්පත ආපසු ලබා දිය හැකිය, නමුත් එය වඩා හොඳය *ඔබට එක් එක් පේළියේ වැඩි දත්ත නොමැති නම්.
අපට එය අවශ්ය වන්නේ ඇයි? අප නැවත වාර්තා කළ යුත්තේ මෙයයි. ඇත්ත වශයෙන්ම අපි දැන් බොහෝ රේඛා මකා දමා ඇත. තවද අපට ID මගින් හෝ මෙවැනි Create_at මගින් මායිම් ඇත. ඔබට අවම, උපරිමය කළ හැක. වෙන දෙයක් කරන්න පුළුවන්. ඔබට මෙහි බොහෝ දේ කළ හැකිය. තවද එය නිරීක්ෂණය සඳහා ඉතා පහසු වේ.
දර්ශකය ගැන තවත් එක් සටහනක් තිබේ. මෙම කාර්යය සඳහා අපට විශේෂ දර්ශකයක් අවශ්ය බව අපි තීරණය කරන්නේ නම්, එය ගොඩවල් පමණක් ටියුපල් යාවත්කාලීන කිරීම් නරක් නොවන බවට වග බලා ගත යුතුය. එනම්, Postgres සතුව එවැනි සංඛ්යාලේඛන තිබේ. මෙය ඔබගේ වගුව සඳහා pg_stat_user_tables හි දැකිය හැක. හොට් අප්ඩේට්ස් පාවිච්චි කරනවාද නැද්ද කියලා බලන්න පුළුවන්.
ඔබගේ නව දර්ශකය සරලව කපා හැරිය හැකි අවස්ථා තිබේ. තවද ඔබට දැනටමත් ක්රියාත්මක වන අනෙකුත් සියලුම යාවත්කාලීනයන් තිබේ, මන්දගාමී කරන්න. දර්ශකය දර්ශනය වූ නිසා පමණක් නොවේ (එක් එක් දර්ශකය යාවත්කාලීන කිරීම් ටිකක් මන්දගාමී කරයි, නමුත් ටිකක්), නමුත් මෙහි එය තවමත් එය විනාශ කරයි. තවද මෙම වගුව සඳහා විශේෂ ප්‍රශස්තකරණයක් කළ නොහැක. මෙය සමහර විට සිදු වේ. මෙය ස්වල්ප දෙනෙකුට මතක ඇති ඉතා සියුම්කමකි. ඒ වගේම මේ පෝරකය පාගන්නත් ලේසියි. සමහර විට ඔබට අනෙක් පැත්තෙන් ප්රවේශයක් සොයා ගැනීමට අවශ්ය වන අතර තවමත් මෙම නව දර්ශකය නොමැතිව කරන්න, නැතහොත් වෙනත් දර්ශකයක් සාදන්න, නැතහොත් වෙනත් ආකාරයකින්, ඔබට දෙවන ක්‍රමය භාවිතා කළ හැකිය.
නමුත් මෙය වඩාත්ම ප්‍රශස්ත උපාය මාර්ගයයි, කණ්ඩායම් වලට බෙදීම සහ එක් ඉල්ලීමක් සමඟ කණ්ඩායම් වලට වෙඩි තැබීම, ටිකක් මකා දැමීම යනාදිය.
දිගු ගනුදෙනු
අවහිර වූ autovacuum -
අවහිර කිරීමේ ගැටලුව -
#5 වැරැද්ද ලොකු එකක්. Okmeter හි නිකොලායි Postgres අධීක්ෂණය ගැන කතා කළේය. Ideal Postgres අධීක්ෂණය, අවාසනාවකට මෙන්, නොපවතී. සමහරු සමීපයි, සමහරක් දුරයි. Okmeter පරිපූර්ණ වීමට ප්රමාණවත් නමුත් බොහෝ දේ අස්ථානගත වී ඇති අතර එකතු කිරීමට අවශ්ය වේ. ඔබ මේ සඳහා සූදානම් විය යුතුය.
නිදසුනක් වශයෙන්, මිය ගිය ටියුපල් වඩාත් හොඳින් නිරීක්ෂණය කරනු ලැබේ. ඔබ මේසයේ මිය ගිය දේවල් ගොඩක් තිබේ නම්, යමක් වැරදියි. දැන් ප්‍රතික්‍රියා කිරීම වඩා හොඳය, එසේ නොවුවහොත් පිරිහීමක් ඇති විය හැකි අතර අපට වැතිර සිටිය හැකිය. එය සිදු වේ.
විශාල IO එකක් තිබේ නම්, මෙය හොඳ නැති බව පැහැදිලිය.
දිගු ගනුදෙනු ද. OLTP මත දිගු ගනුදෙනුවලට ඉඩ නොදිය යුතුය. තවද ඔබට මෙම ස්නිපටය ගැනීමට සහ දැනටමත් දිගු ගණුදෙණු ලුහුබැඳීමට ඉඩ සලසන ස්නිපටයකට සබැඳියක් මෙන්න.
දිගු ගනුදෙනු නරක ඇයි? මොකද ඔක්කොම ලොක් ටික රිලීස් වෙන්නේ අන්තිමට විතරයි. ඒ වගේම අපි හැමෝවම රවටනවා. Plus, අපි සියලු වගු සඳහා autovacuum අවහිර කරන්නෙමු. ඒක කොහෙත්ම හොඳ නැහැ. ඔබ අනුරුව මත උණුසුම් පොරොත්තු සබල කර ඇතත්, එය තවමත් නරකයි. පොදුවේ ගත් කල, දිගු ගනුදෙනු වළක්වා ගැනීම වඩා හොඳ නැත.
අප සතුව රික්ත නොකළ වගු බොහොමයක් තිබේ නම්, අපට අනතුරු ඇඟවීමක් තිබිය යුතුය. මෙන්න එවැනි තත්වයක් ඇති විය හැකිය. අපට ස්වයංක්රීය රික්තක ක්‍රියාකාරිත්වයට වක්‍රව බලපෑම් කළ හැකිය. මෙය Avito වෙතින් වන කොටසකි, එය මම තරමක් වැඩිදියුණු කළෙමි. තවද එය autovacuum සමඟ අප සතුව ඇති දේ බැලීමට සිත්ගන්නා මෙවලමක් බවට පත් විය. උදාහරණයක් ලෙස, සමහර වගු එහි රැඳී සිටින අතර ඔවුන්ගේ වාරය එනතෙක් බලා නොසිටිනු ඇත. ඔබ එය නිරීක්ෂණයට තල්ලු කර අනතුරු ඇඟවීමක් ද කළ යුතුය.
සහ අවහිර කිරීම් නිකුත් කරයි. බ්ලොක් ගස් වනාන්තරය. කාගෙන් හරි දෙයක් අරන් දියුණු කරන්න ආසයි. ඔන්න මම ඩේටා එග්‍රෙට් එකෙන් කූල් රිකර්සිව් සීටීඊ එකක් ගත්තා අගුලු ගස් තියෙන කැලේක් පෙන්නනවා. මෙය හොඳ රෝග විනිශ්චය මෙවලමකි. එහි පදනම මත, ඔබට අධීක්ෂණය ද ගොඩනගා ගත හැකිය. නමුත් මෙය ප්රවේශමෙන් කළ යුතුය. ඔබ වෙනුවෙන් කුඩා ප්‍රකාශයක්_කාලසීමාවක් කිරීමට අවශ්‍යයි. සහ lock_timeout යෝග්‍යයි.
සමහර විට මෙම සියලු දෝෂ එකතුවෙන් සිදු වේ.
මගේ මතය අනුව, මෙහි ප්රධාන වැරැද්ද සංවිධානාත්මක ය. තාක්ෂණය අදින්නේ නැති නිසා එය සංවිධානාත්මක ය. මෙය අංක 2 - ඔවුන් වැරදි ස්ථානයක පරීක්ෂා කර ඇත.
පරීක්ෂා කිරීමට පහසු නිෂ්පාදන ක්ලෝනයක් අප සතුව නොමැති නිසා අපි වැරදි ස්ථානයක පරීක්ෂා කළෙමු. සංවර්ධකයෙකුට කිසිසේත්ම නිෂ්පාදනයට ප්රවේශය නොමැති විය හැක.
ඒ වගේම අපි එතන නැහැ කියලා බැලුවා. එතන බැලුවා නම් අපිටම බලන්න තිබුණා. එකම දත්ත ප්‍රමාණයක් සහ සමාන ස්ථානයක් ඇති හොඳ පරිසරයක එය පරීක්ෂා කළහොත් සංවර්ධකයා DBA නොමැතිව පවා ඒ සියල්ල දුටුවේය. ඔහු මේ සියලු පිරිහීම දැක ලැජ්ජාවට පත් වනු ඇත.
autovacuum ගැන වැඩි විස්තර. අපි ලයින් මිලියන කිහිපයක දැවැන්ත ස්වීප් එකක් කළ පසු, අපි තවමත් REPACK කළ යුතුයි. මෙය දර්ශක සඳහා විශේෂයෙන් වැදගත් වේ. අපි එහි ඇති සියල්ල පිරිසිදු කළ පසු ඔවුන්ට නරකක් දැනෙනු ඇත.
ඔබට දෛනික පිරිසිදු කිරීමේ කාර්යය නැවත ගෙන ඒමට අවශ්ය නම්, එය නිතර නිතර, නමුත් කුඩා කිරීමට මම යෝජනා කරමි. එය විනාඩියකට වරක් හෝ ඊටත් වඩා බොහෝ විට ටිකක් විය හැකිය. තවද ඔබ කරුණු දෙකක් නිරීක්ෂණය කළ යුතුය: මෙම දෙයෙහි කිසිදු දෝෂයක් නොමැති බව සහ එය පසුගාමී නොවන බව. මම පෙන්නපු trick එක මේක නිකන් විසදෙයි.
අපි කරන්නේ open source. එය GitLab හි පළ කර ඇත. DBA නොමැතිව වුවද මිනිසුන්ට පරීක්ෂා කළ හැකි වන පරිදි අපි එය සකස් කරමු. අපි කරන්නේ Database lab එකක්, ඒ කියන්නේ Joe දැනට වැඩ කරන Base component එකට අපි කියනවා. ඔබට නිෂ්පාදනයේ පිටපතක් ලබා ගත හැකිය. දැන් ජෝ සඳහා ස්ලැක් ක්රියාත්මක කිරීමක් ඇත, ඔබට එහි පැවසිය හැකිය: "එවැනි සහ එවැනි ඉල්ලීමක් පැහැදිලි කරන්න" සහ ඔබේ දත්ත සමුදායේ පිටපත සඳහා ප්රතිඵලය වහාම ලබා ගන්න. ඔබට එහි මකා දැමිය හැකි අතර කිසිවෙකු එය නොදකිනු ඇත.
අපි හිතමු ඔයාට ටෙරාබයිට් 10ක් තියෙනවා කියලා, අපි ඩේටාබේස් ලැබ් එකත් ටෙරාබයිට් 10ක් කරනවා. ටෙරාබයිට් 10ක දත්ත සමුදායන් සමඟින්, සංවර්ධකයින් 10 දෙනෙකුට එකවර වැඩ කළ හැක. සෑම කෙනෙකුටම තමන්ට අවශ්ය දේ කළ හැකිය. මැකීමට, හෙළීමට, යනාදිය හැක. එය එතරම් ෆැන්ටසියකි. අපි මේ ගැන හෙට කතා කරමු.
මෙය තුනී ප්‍රතිපාදන ලෙස හැඳින්වේ. මෙය සියුම් විධිවිධානයකි. මෙය යම් ආකාරයක මනඃකල්පිතයක් වන අතර එය සංවර්ධනයේ ප්‍රමාදයන් විශාල ලෙස ඉවත් කරයි, පරීක්ෂා කිරීමේදී සහ මේ සම්බන්ධයෙන් ලෝකය වඩා හොඳ තැනක් බවට පත් කරයි. එනම්, තොග මෙහෙයුම් සමඟ ගැටළු වළක්වා ගැනීමට එය ඔබට ඉඩ සලසයි.
උදාහරණය: ටෙරාබයිට් 5ක දත්ත ගබඩාව, තත්පර 30කට අඩු කාලයකින් පිටපතක් ලබා ගැනීම. එය ප්රමාණය මත පවා රඳා නොපවතී, එනම් ටෙරාබයිට් කීයක් වුවද කමක් නැත.
අද ඔබට යන්න පුළුවන් සහ අපගේ මෙවලම් හාරා. එහි ඇති දේ බැලීමට ඔබට ලියාපදිංචි විය හැකිය. ඔබට මෙම බොට් ස්ථාපනය කළ හැකිය. එය නොමිලේ. ලියන්න.
ඔබගේ ප්රශ්න
බොහෝ විට සැබෑ තත්වයන් තුළ, වගුවේ තිබිය යුතු දත්ත මකා දැමිය යුතු දේට වඩා බෙහෙවින් අඩු බව පෙනී යයි. එනම්, එවැනි තත්වයක් තුළ, එවැනි ප්රවේශයක් ක්රියාත්මක කිරීම බොහෝ විට පහසු වේ, එය නව වස්තුවක් නිර්මාණය කිරීමට පහසු වන විට, එහි අවශ්ය දත්ත පමණක් පිටපත් කර, පැරණි වගුව කඳට දමන්න. ඔබ මාරු කරන අතරතුර මේ මොහොත සඳහා ක්‍රමලේඛන ප්රවේශයක් අවශ්ය බව පැහැදිලිය. මෙම ප්රවේශය කෙසේද?
මෙය ඉතා හොඳ ප්රවේශයක් සහ ඉතා හොඳ කාර්යයකි. එය pg_repack කරන දෙයට බෙහෙවින් සමාන ය, ඔබ හැඳුනුම්පත් බයිට් 4 ක් සෑදූ විට ඔබ කළ යුතු දේට එය බෙහෙවින් සමාන ය. බොහෝ රාමු මීට වසර කිහිපයකට පෙර මෙය සිදු කර ඇති අතර, තහඩු පමණක් වර්ධනය වී ඇති අතර, ඒවා බයිට් 8 ක් බවට පරිවර්තනය කළ යුතුය.
මෙම කාර්යය තරමක් දුෂ්කර ය. අපි ඒක කළා. ඒ වගේම ගොඩක් පරිස්සම් වෙන්න ඕන. අගුල් ආදිය ඇත.එහෙත් එය කෙරෙමින් පවතී. එනම්, සම්මත ප්රවේශය වන්නේ pg_repack සමඟ යාමයි. ඔබ එවැනි ලේබලයක් ප්රකාශ කරන්න. ඔබ ස්නැප්ෂොට් දත්ත එයට උඩුගත කිරීම ආරම්භ කිරීමට පෙර, ඔබ සියලු වෙනස්කම් නිරීක්ෂණය කරන එක් තහඩුවක් ද ප්රකාශ කරන්න. ඔබට සමහර වෙනස්කම් නිරීක්ෂණය කිරීමට පවා නොහැකි උපක්‍රමයක් තිබේ. සියුම්කම් තියෙනවා. ඉන්පසු ඔබ වෙනස්කම් පෙරළීමෙන් මාරු වේ. අපි සියලු දෙනා වසා දැමූ විට කෙටි විරාමයක් ඇත, නමුත් පොදුවේ මෙය සිදු කෙරේ.
GitHub එකේ pg_repack බැලුවොත්, එතනදී, ID එකක් int 4 ඉඳන් int 8ට හරවන්න වැඩක් තියෙද්දි, pg_repack එක පාවිච්චි කරන්න අදහසක් ආවා. මේකත් පුලුවන් හැබැයි ටිකක් හැක් උනාට මේකටත් වැඩ කරයි. ඔබට pg_repack භාවිතා කරන ප්‍රේරකයට මැදිහත් වී එහි පැවසිය හැකිය: "අපට මෙම දත්ත අවශ්ය නැත", එනම් අපි අපට අවශ්ය දේ පමණක් මාරු කරමු. ඊට පස්සේ එයා නිකම්ම මාරු වෙනවා, එච්චරයි.
මෙම ප්රවේශය සමඟ, අපි තවමත් වගුවේ දෙවන පිටපතක් ලබා ගනිමු, දත්ත දැනටමත් සුචිගත කර ඇති අතර අලංකාර දර්ශක සමඟ ඉතා ඒකාකාරව ගොඩගැසී ඇත.
බඩ පිපීම නොපවතී, එය හොඳ ප්රවේශයකි. නමුත් මේ සඳහා ස්වයංක්‍රීයකරණයක් සංවර්ධනය කිරීමට, එනම් විශ්වීය විසඳුමක් සෑදීමට උත්සාහ කරන බව මම දනිමි. මට මෙම ස්වයංක්රීයකරණය සමඟ ඔබව සම්බන්ධ කර ගත හැක. ඒක Python වලින් ලියල තියෙනව, ඒක හොඳ දෙයක්.
මම MySQL ලෝකයෙන් ටිකක් විතරයි, ඒ නිසා මම අහන්න ආවා. තවද අපි මෙම ප්රවේශය භාවිතා කරමු.
නමුත් එය 90% ක් තිබේ නම් පමණි. අපිට 5% තියෙනවා නම් පාවිච්චි කරන එක එච්චර හොඳ නෑ.
වාර්තාවට ස්තූතියි! නිෂ්පාදනයේ සම්පූර්ණ පිටපතක් සෑදීමට සම්පත් නොමැති නම්, බර හෝ ප්රමාණය ගණනය කිරීමට ඇල්ගොරිතමයක් හෝ සූත්‍රයක් තිබේද?
හොඳ ප්රශ්නයක්. මේ වන විට අපට බහු ටෙරාබයිට් දත්ත සමුදායන් සොයා ගැනීමට හැකි වී ඇත. එහි ඇති දෘඪාංග සමාන නොවුනත්, උදාහරණයක් ලෙස, අඩු මතකය, අඩු ප්‍රොසෙසරය සහ තැටි හරියටම සමාන නොවේ, නමුත් තවමත් අපි එය කරන්නෙමු. සම්පූර්ණයෙන්ම කොතැනකවත් නොමැති නම්, ඔබ සිතා බැලිය යුතුය. මට හෙට වෙනකම් හිතන්න දෙන්න, ඔයා ආවා, අපි කතා කරමු, මේක හොඳ ප්රශ්නයක්.
වාර්තාවට ස්තූතියි! ඔබ මුලින්ම ආරම්භ කළේ එවැනි සහ එවැනි සීමාවන් ඇති සිසිල් Postgres ඇති නමුත් එය වර්ධනය වෙමින් පවතින බවය. තවද මේ සියල්ල විශාල අත්වාරුවකි. මේ සියල්ල Postgres හි දියුණුව සමඟ ගැටෙන්නේ නැතිද, සමහර DELETE deferent පෙනී සිටිනු ඇත, නැතහොත් අප මෙහි ඇති සමහර අමුතු උපක්‍රමවලින් අප මඩන්නට උත්සාහ කරන දේ පහත් මට්ටමක තබා ගත යුතු වෙනත් දෙයක් නොවේද?
අපි SQL එකේ කිව්වා නම් එක ගණුදෙනුවක ගොඩක් වාර්තා මකන්න හෝ යාවත්කාලීන කරන්න කියලා, එතකොට Postgres ඒක එතනට බෙදන්නේ කොහොමද? අපි මෙහෙයුම් වලදී භෞතිකව සීමිතයි. අපි තවමත් දිගු කාලයක් එය කරන්නෙමු. අපි මේ අවස්ථාවේදී අගුළු දමමු, ආදිය.
දර්ශක සමඟ සිදු කර ඇත.
එකම මුරපොල සුසර කිරීම ස්වයංක්රීය කළ හැකි යැයි මට උපකල්පනය කළ හැකිය. කවදා හරි එහෙම වෙන්න පුළුවන්. ඒත් එතකොට මට ප්‍රශ්නය තේරෙන්නේ නැහැ.
ප්‍රශ්නය නම්, එහෙට මෙහෙට යන, මෙන්න ඔබේ එක සමාන්තරව යන සංවර්ධන දෛශිකයක් තිබේද? එම. ඔවුන් තවමත් ඒ ගැන සිතුවේ නැද්ද?
මම දැන් භාවිතා කළ හැකි මූලධර්ම ගැන කතා කළා. තව බොට් එකක් තියෙනවා , මේ සමඟ ඔබට ස්වයංක්රීය මුරපොල සුසර කිරීම කළ හැකිය. එය කවදා හෝ Postgres හි වේවිද? මම දන්නේ නැහැ, ඒක තවම සාකච්ඡා කරලාවත් නැහැ. අපි තවමත් එයින් බොහෝ දුරස් ය. නමුත් අලුත් පද්ධති හදන විද්‍යාඥයෝ ඉන්නවා. තවද ඔවුන් අපව ස්වයංක්රීය දර්ශක වෙත තල්ලු කරයි. වර්ධනයන් ඇත. උදාහරණයක් ලෙස, ඔබට ස්වයංක්රීය සුසර කිරීම දෙස බැලිය හැකිය. එය ස්වයංක්රීයව පරාමිතීන් තෝරා ගනී. නමුත් ඔහු තවමත් ඔබ වෙනුවෙන් මුරපොල සුසර කරන්නේ නැත. එනම්, එය කාර්ය සාධනය, ෂෙල් බෆරය ආදිය සඳහා තෝරා ගනු ඇත.
මුරපොල සුසර කිරීම සඳහා, ඔබට මෙය කළ හැකිය: ඔබට වලාකුළේ පොකුරු දහසක් සහ විවිධ දෘඩාංග, විවිධ අථත්‍ය යන්ත්‍ර තිබේ නම්, ඔබට අපගේ බොට් භාවිතා කළ හැකිය. ස්වයංක්රීයකරණය කරන්න. සහ max_wal_size ඔබගේ ඉලක්ක සැකසීම් අනුව ස්වයංක්රීයව තෝරා ගනු ලැබේ. එහෙත්, අවාසනාවකට මෙන්, මෙතෙක් මෙය හරය තුළ පවා සමීප නොවේ.
සුභ සන්ධ්යාවක් ඔබ දිගු ගනුදෙනු වල අන්තරායන් ගැන කතා කළා. මකාදැමීම් වලදී autovacuum අවහිර වන බව ඔබ පැවසුවා. එය අපට හානියක් කරන්නේ කෙසේද? මොකද අපි වැඩිපුර කතා කරන්නේ ඉඩ නිදහස් කිරීම සහ එය භාවිතා කිරීමට හැකිවීම ගැනයි. අපිට තව මොනවද අඩු?
Autovacuum සමහරවිට මෙහි ඇති ලොකුම ගැටලුව නොවේ. දිගු ගනුදෙනුවකින් වෙනත් ගනුදෙනු අගුළු දැමිය හැකි බව, මෙම හැකියාව වඩාත් භයානක ය. ඇය හමුවීමට හෝ නොවීමට ඉඩ ඇත. ඇය හමු වූවා නම්, එය ඉතා නරක විය හැකිය. සහ autovacuum සමඟ - මෙයද ගැටළුවකි. OLTP හි දිගු ගනුදෙනු වල ගැටළු දෙකක් තිබේ: අගුලු සහ ස්වයංක්රීයව. ඔබට අනුරුව මත උණුසුම් පොරොත්තු ප්‍රතිපෝෂණ සක්‍රීය කර ඇත්නම්, එවිට ඔබට තවමත් ප්‍රධානය මත ස්වයංක්රීය රික්තක අගුලක් ලැබෙනු ඇත, එය අනුරුවෙන් පැමිණේ. නමුත් අඩුම තරමින් අගුල්වත් නොතිබෙනු ඇත. සහ ලොක් වනු ඇත. අපි කතා කරන්නේ දත්ත වෙනස්කම් ගැන, එබැවින් අගුලු දැමීම මෙහි වැදගත් කරුණකි. මේ සියල්ල දිගු, දිගු කාලයක් සඳහා නම්, වැඩි වැඩියෙන් ගනුදෙනු අගුළු දමා ඇත. ඔවුන්ට අන් අය සොරකම් කළ හැකිය. සහ ලොක් ගස් පෙනේ. මම ස්නිපට් එකට සබැඳියක් ලබා දුන්නා. තවද මෙම ගැටළුව ස්වයංක්රීය රික්තකය සමඟ ඇති ගැටලුවට වඩා වේගයෙන් කැපී පෙනේ, එය එකතු විය හැකිය.
වාර්තාවට ස්තූතියි! ඔබ වැරදි ලෙස පරීක්ෂා කළ බව පවසමින් ඔබේ වාර්තාව ආරම්භ කළා. අපි අපේ අදහස දිගටම කරගෙන ගියා, අපි එකම උපකරණය, පාදම එකම ආකාරයකින් ගත යුතුයි. අපි සංවර්ධකයාට පදනමක් දුන්නා කියමු. තවද ඔහු ඉල්ලීම ඉටු කළේය. ඒ වගේම එයා හොඳින් ඉන්නවා වගේ. නමුත් ඔහු සජීවීව පරීක්ෂා කරන්නේ නැත, නමුත් සජීවීව සඳහා, උදාහරණයක් ලෙස, අපට 60-70% ක බරක් තිබේ. අනික අපි මේ tuning එක පාවිච්චි කලත් ඒක එච්චර හොදට වැඩ කරන්නේ නෑ.
කණ්ඩායමේ විශේෂඥයෙකු සිටීම සහ සැබෑ පසුබිම් පැටවීමකින් කුමක් සිදුවේදැයි පුරෝකථනය කළ හැකි DBA විශේෂඥයින් භාවිතා කිරීම වැදගත් වේ. අපි අපේ පිරිසිදු වෙනස්කම් ධාවනය කළ විට, අපි පින්තූරය දකිනවා. නමුත් වඩා දියුණු ප්රවේශයක්, අපි නැවත එකම දේ කළ විට, නමුත් නිෂ්පාදනය සමඟ අනුකරණය කරන ලද බරක් සමඟ. එය තරමක් සිසිල් ය. එතකන් හැදෙන්න ඕනේ. ඒක වැඩිහිටියෙක් වගේ. අපි නිකමට බැලුවේ අපිට තියෙන දේ වගේම අපිට ඇති තරම් සම්පත් තියෙනවද කියලා. ඒක හොඳ ප්රශ්නයක්.
අපි දැනටමත් කසළ තෝරා ගැනීමක් සිදු කරන විට සහ අපට උදාහරණයක් ලෙස මකා දැමූ කොඩියක් තිබේ
Postgres හි autovacuum ස්වයංක්රීයව කරන්නේ මෙයයි.
ඔහ්, ඔහු එය කරයිද?
Autovacuum යනු කසළ එකතු කරන්නා වේ.
ස්තුතියි!
වාර්තාවට ස්තූතියි! ප්රධාන මේසයේ සිට කොතැනක හෝ පැත්තකට සියලුම කුණු අපිරිසිදු වන ආකාරයට කොටස් කර දත්ත ගබඩාවක් වහාම සැලසුම් කිරීමට විකල්පයක් තිබේද?
ඇත්ත වශයෙන්ම තිබේ.
පාවිච්චි නොකළ යුතු මේසයක් අගුලු දමා ඇත්නම් අපව ආරක්ෂා කර ගත හැකිද?
ඇත්ත වශයෙන්ම තිබේ. නමුත් එය කුකුල් මස් හා බිත්තර ප්රශ්නයක් වගේ. අනාගතයේදී කුමක් සිදුවේදැයි අප සියල්ලන්ම දන්නේ නම්, ඇත්ත වශයෙන්ම, අපි සියල්ල සිසිල් කරන්නෙමු. නමුත් ව්යාපාරය වෙනස් වෙමින් පවතී, නව තීරු, නව ඉල්ලීම් තිබේ. ඉන්පසු - අපොයි, අපට එය ඉවත් කිරීමට අවශ්‍යයි. නමුත් මෙම පරමාදර්ශී තත්වය, ජීවිතයේ එය සිදු වේ, නමුත් සෑම විටම නොවේ. නමුත් සමස්තයක් වශයෙන් එය හොඳ අදහසකි. නිකම්ම කප්පාදු කරන්න, එපමණයි.
මූලාශ්රය: www.habr.com