PostgreSQL විමසුම් තොග ප්‍රශස්තකරණය. කිරිල් බොරොවිකොව් (ටෙන්සර්)

වාර්තාව ඉඩ දෙන සමහර ප්රවේශයන් ඉදිරිපත් කරයි SQL විමසුම් දිනකට මිලියන ගණනක් ඇති විට ඒවායේ ක්‍රියාකාරිත්වය නිරීක්ෂණය කරන්න, සහ නිරීක්ෂණය කරන ලද PostgreSQL සේවාදායකයන් සිය ගණනක් ඇත.

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

උනන්දු වන්නේ කවුද? විශේෂිත ගැටළු සහ විවිධ ප්‍රශස්තිකරණ ශිල්පීය ක්‍රම විශ්ලේෂණය කිරීම SQL විමසුම් සහ PostgreSQL හි සාමාන්‍ය DBA ගැටළු විසඳීම - ඔබටද හැකිය ලිපි මාලාවක් කියවන්න මෙම මාතෘකාව මත.


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

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

සාමාන්‍යයෙන්, අපගේ ගනුදෙනුකරුවන් මිලියනයකට Tensor වේ VLSI අපගේ යෙදුමයි: ආයතනික සමාජ ජාලය, වීඩියෝ සන්නිවේදනය සඳහා විසඳුම්, අභ්යන්තර සහ බාහිර ලේඛන ප්රවාහය සඳහා, ගිණුම්කරණ සහ ගබඩා සඳහා ගිණුම්කරණ පද්ධති,... එනම්, ඒකාබද්ධ ව්යාපාර කළමනාකරණය සඳහා එවැනි "මෙගා-ඒකාබද්ධ", විවිධ 100 කට වඩා ඇත අභ්යන්තර ව්යාපෘති.

ඔවුන් සියල්ලන්ම සාමාන්‍ය ලෙස වැඩ කිරීම සහ සංවර්ධනය කිරීම සහතික කිරීම සඳහා, අපට රට පුරා සංවර්ධන මධ්‍යස්ථාන 10 ක් ඇති අතර ඒවායින් තවත් ඒවා ඇත සංවර්ධකයින් 1000 ක්.

අපි 2008 සිට PostgreSQL සමඟ වැඩ කරමින් සිටින අතර අප විසින් සකසන ලද දේවලින් විශාල ප්‍රමාණයක් රැස් කර ගෙන ඇත - සේවාදායක දත්ත, සංඛ්‍යානමය, විශ්ලේෂණාත්මක, බාහිර තොරතුරු පද්ධති වලින් දත්ත - 400TB ට වැඩි. නිෂ්පාදනයේ පමණක් සේවාදායකයන් 250 ක් පමණ ඇති අතර, සමස්තයක් වශයෙන් අප නිරීක්ෂණය කරන දත්ත සමුදා සේවාදායකයන් 1000 ක් පමණ ඇත.

SQL යනු ප්‍රකාශන භාෂාවකි. ඔබ විස්තර කරන්නේ යමක් ක්‍රියාත්මක විය යුත්තේ කෙසේද යන්න නොව, ඔබට සාක්ෂාත් කර ගැනීමට අවශ්‍ය “කුමක්ද” යන්නයි. ඩීබීඑම්එස් එකට සම්බන්ධ වන්නේ කෙසේද යන්න වඩා හොඳින් දනී - ඔබේ වගු සම්බන්ධ කරන්නේ කෙසේද, පැනවිය යුතු කොන්දේසි මොනවාද, දර්ශකය හරහා යන්නේ කුමක්ද, නොකළ යුතු දේ ...

සමහර DBMSs ඉඟි පිළිගනී: "නැහැ, මෙම වගු දෙක එවැනි පෝලිමකට සම්බන්ධ කරන්න," නමුත් PostgreSQL හට මෙය කළ නොහැක. ප්‍රමුඛ සංවර්ධකයින්ගේ සවිඥානික ආස්ථානය මෙයයි: "අපි සංවර්ධකයින්ට යම් ආකාරයක ඉඟි භාවිතා කිරීමට ඉඩ දෙනවාට වඩා විමසුම් ප්‍රශස්තකරණය අවසන් කිරීමට කැමැත්තෙමු."

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

සාමාන්‍යයෙන්, සංවර්ධකයෙකුට [DBA වෙත] සාමාන්‍යයෙන් එන සම්භාව්‍ය ගැටලු මොනවාද? “මෙන්න අපි ඉල්ලීම ඉටු කළා, සහ සෑම දෙයක්ම අප සමඟ මන්දගාමී වේ, හැම දෙයක්ම එල්ලෙමින් තිබේ, යමක් සිදුවෙමින් පවතී ... යම් ආකාරයක කරදරයක්!"

හේතු සෑම විටම පාහේ සමාන වේ:

• අකාර්යක්ෂම විමසුම් ඇල්ගොරිතම
  සංවර්ධක: "දැන් මම ඔහුට SQL හි වගු 10 ක් ලබා දෙන්නෙමි JOIN හරහා ..." - සහ ඔහුගේ කොන්දේසි ආශ්චර්යමත් ලෙස ඵලදායී ලෙස "බැඳී" ඇති අතර ඔහුට සියල්ල ඉක්මනින් ලැබෙනු ඇතැයි අපේක්ෂා කරයි. නමුත් ප්රාතිහාර්යයන් සිදු නොවන අතර, එවැනි විචල්යතාවයක් සහිත ඕනෑම පද්ධතියක් (එක් FROM එකක වගු 10 ක්) සෑම විටම යම් ආකාරයක දෝෂයක් ලබා දෙයි. [ලිපියක්]
• අදාළ නොවන සංඛ්යා ලේඛන
  මෙම කරුණ විශේෂයෙන් PostgreSQL සඳහා ඉතා අදාළ වේ, ඔබ විශාල දත්ත කට්ටලයක් සේවාදායකයට “වත් කළ” විට, ඉල්ලීමක් කරන විට, එය ඔබේ ටැබ්ලටය “sexcanits” කරයි. මොකද ඊයේ ඒකේ රෙකෝඩ් 10ක් තිබ්බා, අද මිලියන 10ක් තියෙනවා, ඒත් මේ ගැන PostgreSQL තවම දැනුවත් නැති නිසා ඒ ගැන කියන්නම ඕනේ. [ලිපියක්]
• සම්පත් මත "ප්ලග්"
  ඔබ ප්‍රමාණවත් තැටියක්, මතකයක් හෝ ප්‍රොසෙසරයක ක්‍රියාකාරිත්වයක් නොමැති දුර්වල සේවාදායකයක් මත විශාල සහ අධික ලෙස පටවන ලද දත්ත සමුදායක් ස්ථාපනය කර ඇත. එපමණයි ... ඔබට තවදුරටත් පැනීමට නොහැකි කාර්ය සාධන සිවිලිමක් කොහේ හරි තිබේ.
• අවහිර කිරීම
  මෙය දුෂ්කර කරුණකි, නමුත් ඒවා විවිධ වෙනස් කිරීමේ විමසුම් සඳහා වඩාත් අදාළ වේ (ඇතුළු කිරීම, යාවත්කාලීන කිරීම, මකන්න) - මෙය වෙනම විශාල මාතෘකාවකි.

සැලැස්මක් ලබා ගැනීම

...අනෙක් හැමදේටම අපි සැලැස්මක් අවශ්යයි! සර්වර් එක ඇතුලේ මොකද වෙන්නේ කියලා බලන්න ඕනේ.

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

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

විමසුම් සැලැස්ම ලබා ගැනීම සඳහා, පහසුම ක්රමය වන්නේ ප්රකාශය ක්රියාත්මක කිරීමයි EXPLAIN. සියලු සැබෑ ගුණාංග ලබා ගැනීමට, එනම්, පදනම මත විමසුමක් ක්‍රියාත්මක කිරීමට - EXPLAIN (ANALYZE, BUFFERS) SELECT ....

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

සේවාදායකයේ ඉල්ලීම ක්‍රියාත්මක කළ මොහොතේ හරියටම සිදුවූයේ කුමක්ද යන්න තේරුම් ගැනීම සඳහා, බුද්ධිමත් පුද්ගලයින් ලිවීය auto_explain මොඩියුලය. එය වඩාත් පොදු PostgreSQL බෙදාහැරීම් සියල්ලේම පාහේ පවතින අතර, වින්‍යාස ගොනුව තුළ සරලව සක්‍රිය කළ හැක.

යම් ඉල්ලීමක් ඔබ කී සීමාවට වඩා වැඩි කාලයක් ක්‍රියාත්මක වන බව එය වටහා ගන්නේ නම්, එය එසේ වේ මෙම ඉල්ලීමේ සැලැස්මේ "snapshot" සහ ඒවා ලොගයේ එකට ලියයි.

දැන් සියල්ල හොඳින් ඇති බව පෙනේ, අපි ලොගය වෙත ගොස් එහි බලමු ... [පෙළ පා රෙදි]. නමුත් එය ක්‍රියාත්මක කිරීමට 11ms ගත වූ නිසා එය විශිෂ්ට සැලැස්මක් බව හැරෙන්නට අපට ඒ ගැන කිසිවක් පැවසිය නොහැක.

සෑම දෙයක්ම හොඳින් ඇති බව පෙනේ - නමුත් ඇත්ත වශයෙන්ම සිදුවූයේ කුමක්ද යන්න කිසිවක් පැහැදිලි නැත. සාමාන්‍ය කාලය හැරුණු විට, අපට ඇත්ත වශයෙන්ම කිසිවක් නොපෙනේ. සරල පාඨයේ එවැනි "බැටළු පැටවෙකු" දෙස බැලීම සාමාන්යයෙන් දෘශ්යමාන නොවේ.

නමුත් එය නොපැහැදිලි වුවද, එය අපහසු වුවද, වඩාත් මූලික ගැටළු තිබේ:

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

එවැනි අවස්ථාවන්හිදී, "දුර්වලම සම්බන්ධකය කවුද?" යන්න තේරුම් ගන්න. පාහේ කළ නොහැක්කකි. එමනිසා, සංවර්ධකයින් පවා "අත්පොතෙහි" ලියන්නේ එයයි "සැලැස්මක් තේරුම් ගැනීම ඉගෙන ගත යුතු කලාවකි, අත්දැකීමක්...".

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

සැලසුම් දෘශ්‍යකරණය

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

අපි මුලින්ම ගියේ "වෙළඳපොල හරහා" - පවතින දේ බැලීමට අන්තර්ජාලය දෙස බලමු.

නමුත් අඩු හෝ වැඩි වශයෙන් සංවර්ධනය වෙමින් පවතින සාපේක්ෂව “සජීවී” විසඳුම් ඉතා ස්වල්පයක් ඇති බව පෙනී ගියේය - වචනාර්ථයෙන්, එකක් පමණි: පැහැදිලි කරන්න.depesz.com Hubert Lubaczewski විසිනි. ඔබ "සංග්‍රහ" ක්ෂේත්‍රයට සැලැස්මේ පෙළ නිරූපණයක් ඇතුළු කළ විට, එය ඔබට විග්‍රහ කළ දත්ත සහිත වගුවක් පෙන්වයි:

• node හි ම සැකසුම් කාලය
• මුළු subtree සඳහා මුළු කාලය
• සංඛ්‍යානමය වශයෙන් අපේක්ෂා කරන ලද වාර්තා සංඛ්‍යාව ලබා ගන්නා ලදී
• නෝඩ් ශරීරයම

මෙම සේවාවට සබැඳි සංරක්ෂිතයක් බෙදා ගැනීමේ හැකියාවද ඇත. ඔබ ඔබේ සැලැස්ම එහි විසි කර මෙසේ කීවේය: "ඒයි, වාස්යා, මෙන්න සබැඳියක්, එහි යම්කිසි වැරැද්දක් තිබේ."

නමුත් කුඩා ගැටළු ද ඇත.

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

දෙවනුව, කියවන දත්ත ප්‍රමාණය පිළිබඳ විශ්ලේෂණයක් නොමැත - ප්‍රතිදානය කරන එකම බෆර EXPLAIN (ANALYZE, BUFFERS), අපට එය මෙහි නොපෙනේ. ඔහු ඒවා විසුරුවා හැරීමට, ඒවා තේරුම් ගැනීමට සහ ඔවුන් සමඟ වැඩ කිරීමට දන්නේ නැත. ඔබ බොහෝ දත්ත කියවන විට සහ ඔබ තැටිය සහ මතක හැඹිලිය වැරදි ලෙස බෙදා හරින බව වටහා ගන්නා විට, මෙම තොරතුරු ඉතා වැදගත් වේ.

තුන්වන සෘණාත්මක කරුණ වන්නේ මෙම ව්යාපෘතියේ ඉතා දුර්වල වර්ධනයයි. කැපවීම් ඉතා කුඩා ය, එය සෑම මාස හයකට වරක් නම් හොඳයි, සහ කේතය පර්ල් හි ඇත.

නමුත් මේ සියල්ල “ගී පද” වේ, අපට කෙසේ හෝ මේ සමඟ ජීවත් විය හැකිය, නමුත් මෙම සේවාවෙන් අපව බෙහෙවින් ඈත් කළ එක් දෙයක් තිබේ. මේවා Common Table Expression (CTE) සහ InitPlan/SubPlan වැනි විවිධ ගතික නෝඩ් විශ්ලේෂණයේ දෝෂ වේ.

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

එවිට අපට වැටහුණා අපේම ලිවීමට කාලය පැමිණ ඇති බව - හූරේ! සෑම සංවර්ධකයෙක්ම මෙසේ කියයි: "දැන් අපි අපේම ලියන්නෙමු, එය ඉතා පහසු වනු ඇත!"

අපි වෙබ් සේවා සඳහා සාමාන්‍ය තොගයක් ගත්තෙමු: Node.js + Express මත පදනම් වූ හරයක්, අලංකාර රූප සටහන් සඳහා Bootstrap සහ D3.js භාවිත කළා. අපගේ අපේක්ෂාවන් සම්පූර්ණයෙන්ම යුක්ති සහගත විය - සති 2 කින් අපට පළමු මූලාකෘතිය ලැබුණි:

• අභිරුචි සැලසුම් විග්‍රහකය
  එනම්, දැන් අපට PostgreSQL මගින් ජනනය කරන ලද ඕනෑම සැලසුමක් විග්‍රහ කළ හැක.
• ගතික නෝඩ් වල නිවැරදි විශ්ලේෂණය - CTE ස්කෑන්, InitPlan, SubPlan
• බෆර බෙදාහැරීමේ විශ්ලේෂණය - දත්ත පිටු මතකයෙන් කියවන ස්ථානය, ස්ථානීය හැඹිලියෙන්, තැටියෙන් කොහිද
• පැහැදිලිකම ලැබුණා
  එබැවින් ලොගයේ මේ සියල්ල "හාරා" නොකිරීමට, නමුත් පින්තූරයේ වහාම "දුර්වලම සබැඳිය" දැකීමට.

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

අපි හඳුන්වන සංක්ෂිප්ත නිරූපණය මෙයයි සැලැස්ම සැකිල්ල.

තවත් පහසු වනු ඇත්තේ කුමක්ද? අපගේ මුළු කාලයෙන් කුමන කොටස කුමන නෝඩයට වෙන් කර ඇත්දැයි බැලීම පහසු වනු ඇත - සහ එය පැත්තට "ඇලවීම" පයි සටහන.

අපි නෝඩය දෙසට යොමු කර බලන්න - Seq Scan මුළු කාලයෙන් හතරෙන් එකකට වඩා අඩු කාලයක් ගත වූ අතර ඉතිරි 3/4 CTE ස්කෑන් විසින් ගන්නා ලදී. භීෂණය! මෙය ඔබ ඔබේ විමසුම්වලදී සක්‍රියව භාවිතා කරන්නේ නම් CTE ස්කෑන් "ගිනි අනුපාතය" පිළිබඳ කුඩා සටහනකි. ඒවා ඉතා වේගවත් නොවේ - ඒවා සාමාන්‍ය වගු පරිලෝකනයට වඩා පහත් ය. [ලිපිය] [ලිපිය]

නමුත් සාමාන්‍යයෙන් එවැනි රූපසටහන් වඩාත් සිත්ගන්නාසුළු, වඩාත් සංකීර්ණ වන අතර, අපි වහාම කොටසකට යොමු කර, උදාහරණයක් ලෙස, සමහර Seq Scan "කෑවේ" කාලයෙන් අඩකට වඩා වැඩි බව දකින විට. එපමණක්ද නොව, ඇතුළත යම් ආකාරයක පෙරහනක් තිබුණි, ඒ අනුව බොහෝ වාර්තා ඉවත දමන ලදී ... ඔබට මෙම පින්තූරය කෙලින්ම සංවර්ධකයාට විසි කර මෙසේ පැවසිය හැකිය: “වාස්යා, මෙහි ඔබට සියල්ල නරකයි! එය තේරුම් ගන්න, බලන්න - යමක් වැරදියි! ”

ස්වාභාවිකවම, සමහර "රේක්" සම්බන්ධ විය.

අපට මුලින්ම හමු වූයේ වටකුරු ගැටලුවයි. සැලැස්මේ එක් එක් නෝඩයේ කාලය 1 μs නිරවද්‍යතාවයකින් දැක්වේ. තවද නෝඩ් චක්‍ර ගණන 1000 ඉක්මවන විට - ක්‍රියාත්මක කිරීමෙන් පසු PostgreSQL "නිරවද්‍යතාවයෙන්" බෙදූ විට, නැවත ගණනය කිරීමේදී අපට මුළු කාලය "0.95ms සහ 1.05ms අතර කොතැනක හෝ" ලැබේ. ගණන් කිරීම ක්ෂුද්‍ර තත්පරයට ගිය විට, එය කමක් නැත, නමුත් එය දැනටමත් [මිලි]තත්පර වන විට, “කොපමණද පරිභෝජනය කළ” සැලැස්මේ නෝඩ් වෙත සම්පත් “බැඳීම” කිරීමේදී ඔබ මෙම තොරතුරු සැලකිල්ලට ගත යුතුය.

දෙවන කරුණ, වඩාත් සංකීර්ණ, ගතික නෝඩ් අතර සම්පත් (එම බෆර) බෙදා හැරීමයි. මෙය අපට මූලාකෘතියේ පළමු සති 2 සහ තවත් සති 4 ක් වැය වේ.

මේ ආකාරයේ ගැටලුවක් ලබා ගැනීම තරමක් පහසුය - අපි CTE එකක් කර එහි යමක් කියවමු. ඇත්ත වශයෙන්ම, PostgreSQL "ස්මාර්ට්" වන අතර එහි කිසිවක් කෙලින්ම කියවන්නේ නැත. ඊට පස්සේ අපි ඒකෙන් පළමු වාර්තාවත්, ඒකට එකම CTE එකෙන් එකසිය පළවෙනි එකත් ගන්නවා.

අපි සැලැස්ම දෙස බලා තේරුම් ගනිමු - එය අමුතුයි, අපට Seq ස්කෑන් තුළ බෆර 3ක් (දත්ත පිටු) “පරිභෝජනය” ඇත, CTE ස්කෑන් හි තවත් 1ක් සහ දෙවන CTE ස්කෑන් එකේ තවත් 2ක් ඇත. එනම්, අපි සියල්ල සරලව සාරාංශ කළහොත්, අපට 6 ලැබෙනු ඇත, නමුත් ටැබ්ලටයෙන් අපි කියවන්නේ 3 පමණි! CTE ස්කෑන් ඕනෑම තැනක සිට කිසිවක් කියවන්නේ නැත, නමුත් ක්‍රියාවලි මතකය සමඟ කෙලින්ම ක්‍රියා කරයි. එනම්, මෙහි යමක් පැහැදිලිවම වැරදියි!

ඇත්තටම මේ තියෙන්නේ Seq Scan එකෙන් ඉල්ලපු දත්ත පිටු 3ම, මුලින්ම 1 CTE Scan එක ඉල්ලලා, ඊට පස්සේ 1 වෙනි එක, තව 2ක් එයාට කියෙව්වා.. ඒ කියන්නේ මුළු දත්ත කියවා ඇත්තේ පිටු 2ක් මිස 3ක් නොවේ.

සැලැස්මක් ක්‍රියාත්මක කිරීම තවදුරටත් ගසක් නොව, හුදෙක් යම් ආකාරයක ආචක්‍රීය ප්‍රස්ථාරයක් බව මෙම පින්තූරය අපට අවබෝධ කර දුන්නේය. අපට මෙවැනි රූප සටහනක් ලැබුණි, එවිට අපට "පළමු ස්ථානයෙන් පැමිණියේ කුමක්ද" යන්න තේරුම් ගත හැකිය. ඒ කියන්නේ මෙන්න අපි pg_class එකෙන් CTE එකක් හදලා, ඒක දෙපාරක් ඉල්ලලා, 2 වෙනි පාර ඉල්ලනකොට අපේ මුළු කාලයම වගේ ශාඛාවට තමයි ගත කළේ. ටැබ්ලට් එකෙන් 101 වන සටහන කියවීමට වඩා 1 වැනි ප්‍රවේශය කියවීම වඩා මිල අධික බව පැහැදිලිය.

අපි ටික වෙලාවක් හුස්ම පිට කළා. ඔවුන් පැවසුවේ “දැන්, නියෝ, ඔබ කුංෆු දන්නවා! දැන් අපගේ අත්දැකීම ඔබේ තිරය මත තිබේ. දැන් ඔබට එය භාවිතා කළ හැකිය." [ලිපිය]

ලොග් ඒකාබද්ධ කිරීම

අපගේ සංවර්ධකයින් 1000ක් සැනසුම් සුසුමක් හෙලුවා. නමුත් අපට ඇත්තේ “සටන්” සේවාදායකයන් සිය ගණනක් පමණක් බව අපි තේරුම් ගත් අතර, සංවර්ධකයින්ගේ පැත්තෙන් මේ “පිටපත් පේස්ට්” කිසිසේත් පහසු නැත. එය අප විසින්ම එකතු කර ගත යුතු බව අපට වැටහුණි.

සාමාන්‍යයෙන්, සංඛ්‍යාලේඛන එකතු කළ හැකි සම්මත මොඩියුලයක් ඇත, කෙසේ වෙතත්, එය වින්‍යාසය තුළ ද සක්‍රිය කළ යුතුය - මෙය මොඩියුලය pg_stat_statements. නමුත් ඔහු අපට ගැළපුණේ නැත.

පළමුව, එය එකම දත්ත සමුදාය තුළ විවිධ යෝජනා ක්‍රම භාවිතා කරමින් එකම විමසුම් සඳහා පවරයි විවිධ QueryIds. එනම්, ඔබ මුලින්ම කරන්නේ නම් SET search_path = '01'; SELECT * FROM user LIMIT 1;ඊට පස්සෙ SET search_path = '02'; සහ එකම ඉල්ලීම, එවිට මෙම මොඩියුලයේ සංඛ්‍යාලේඛන විවිධ වාර්තා ඇති අතර, යෝජනා ක්‍රම සැලකිල්ලට නොගෙන, මෙම ඉල්ලීම් පැතිකඩෙහි සන්දර්භය තුළ විශේෂයෙන් සාමාන්‍ය සංඛ්‍යාලේඛන එකතු කිරීමට මට නොහැකි වනු ඇත.

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

සහ අවසාන මොහොත - "කරුණු" නොමැතිකම. එනම්, ඔබට විමසුම් ක්‍රියාත්මක කිරීමේ නිශ්චිත අවස්ථාවක් ආමන්ත්‍රණය කළ නොහැක - කිසිවක් නැත, ඇත්තේ එකතු කළ සංඛ්‍යාලේඛන පමණි. මෙය සමඟ වැඩ කිරීමට හැකි වුවද, එය ඉතා අපහසු වේ.

ඒ නිසා අපි Copy-paste සටන් කරන්න තීරණය කරලා ලියන්න පටන් ගත්තා එකතු කරන්නා.

එකතු කරන්නා SSH හරහා සම්බන්ධ කරයි, සහතිකයක් භාවිතයෙන් දත්ත සමුදාය සමඟ සේවාදායකයට ආරක්ෂිත සම්බන්ධතාවයක් ඇති කරයි, සහ tail -F ලොග් ගොනුවේ එයට "ඇලෙන්න". ඉතින් මේ සැසියේදී සම්පූර්ණ ලොග් ගොනුවේ සම්පූර්ණ “කැඩපතක්” අපට ලැබේ, සේවාදායකය ජනනය කරන. සේවාදායකයේ පැටවීම අවම වේ, අපි එහි කිසිවක් විග්‍රහ නොකරන නිසා, අපි ගමනාගමනය පිළිබිඹු කරන්නෙමු.

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

ඒ අනුව, අපි සම්බන්ධතා දෙකක් “දිගු” කරමු: පළමුවැන්න ලොගයටම “සවන් දී” එය අප වෙත ගෙන යාම සහ දෙවැන්න වරින් වර පදනම ඉල්ලා සිටීම. “නමුත් id 123 සමඟ ලකුණ අවහිර කර ඇති බව ලොගය පෙන්වයි,” නමුත් මෙය සංවර්ධකයාට කිසිවක් අදහස් නොකරන අතර, “OID = 123 යනු කුමක්ද?” දත්ත සමුදායෙන් විමසීම සතුටක් වනු ඇත. ඒ නිසා අපි කලින් කලට අප ගැන තවමත් නොදන්නා දේ පදනම අසන්නෙමු.

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

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

නමුත් සරලව දත්ත "වත් කිරීම" ඇත්ත වශයෙන්ම අපගේ තාක්ෂණය නොවේ. මන්ද, ඔබට සේවාදායකයන් සියයක තත්පරයකට ආසන්න වශයෙන් 50k ඉල්ලීම් තිබේ නම්, මෙය දිනකට 100-150GB ලොග් ජනනය කරයි. එමනිසා, අපි ප්රවේශමෙන් පදනම "කපා" කිරීමට සිදු විය.

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

දෙවනුව, අපි ඉගෙන ගත්තා (බලහත්කාරයෙන්) භාවිතා කරමින් ලිවීමට ඉතා, ඉතා වේගවත් COPY. එනම්, නිකම්ම නොවේ COPYඔහු වඩා වේගවත් නිසා INSERT, සහ ඊටත් වඩා වේගවත්.

තුන්වන කරුණ - මට සිදු විය පිළිවෙලින් ප්‍රේරක සහ විදේශීය යතුරු අතහැර දමන්න. එනම්, අපට කිසිසේත් යොමු කිරීමේ අඛණ්ඩතාවක් නොමැත. මක්නිසාද යත් ඔබට FK යුගලයක් ඇති වගුවක් තිබේ නම් සහ ඔබ දත්ත සමුදා ව්‍යුහයේ පවසන්නේ “මෙන්න FK විසින් යොමු කරන ලද ලොග් වාර්තාවක්, උදාහරණයක් ලෙස, වාර්තා සමූහයකට”, එවිට ඔබ එය ඇතුළු කරන විට, PostgreSQL එය භාරගෙන අවංකව කරන්නේ කෙසේද යන්න හැර වෙන කිසිවක් ඉතිරිව නැත SELECT 1 FROM master_fk1_table WHERE ... ඔබ ඇතුළු කිරීමට උත්සාහ කරන හැඳුනුම්කාරකය සමඟ - මෙම වාර්තාව එහි තිබේ දැයි පරීක්ෂා කිරීමට, ඔබ මෙම විදේශ යතුර ඔබේ ඇතුළු කිරීමත් සමඟ “කැඩී” නොකරන්න.

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

ඊළඟ කරුණ වන්නේ එකතු කිරීම සහ හෑෂ් කිරීමයි. මුලදී, අපි ඒවා දත්ත සමුදායේ ක්‍රියාත්මක කළෙමු - සියල්ලට පසු, වාර්තාවක් පැමිණි විට, එය යම් ආකාරයක ටැබ්ලටයකින් කිරීම පහසුය. ප්‍රේරකයේම "plus one". හොඳයි, එය පහසු ය, නමුත් එකම නරක දෙය - ඔබ එක් වාර්තාවක් ඇතුළු කරයි, නමුත් වෙනත් වගුවකින් වෙනත් දෙයක් කියවීමට සහ ලිවීමට බල කෙරේ. එපමණක්ද නොව, ඔබ කියවීමට සහ ලිවීමට පමණක් නොව, ඔබ එය සෑම විටම කරන්න.

දැන් ඔබට නිශ්චිත ධාරකයක් හරහා ගොස් ඇති ඉල්ලීම් ගණන ගණනය කරන වගුවක් ඇති බව සිතන්න: +1, +1, +1, ..., +1. ඔබට, ප්‍රතිපත්තිමය වශයෙන්, මෙය අවශ්‍ය නොවේ - ඒ සියල්ල කළ හැකි ය එකතුකරන්නාගේ මතකයේ එකතුව සහ එක ගමනකින් දත්ත සමුදායට යවන්න +10.

ඔව්, සමහර ගැටළු වලදී, ඔබේ තාර්කික අඛණ්ඩතාව "බිඳ වැටිය හැක", නමුත් මෙය පාහේ යථාර්ථවාදී නොවන අවස්ථාවකි - ඔබට සාමාන්‍ය සේවාදායකයක් ඇති නිසා, එය පාලකයේ බැටරියක් ඇති නිසා, ඔබට ගනුදෙනු ලොගයක්, ලොගයක් ඇත. ගොනු පද්ධතිය ... පොදුවේ, එය වටින්නේ නැත. ධාවන ප්‍රේරක/FK මඟින් ඔබට ලැබෙන ඵලදායිතාව අහිමි වීම ඔබ දරන වියදමට වටින්නේ නැත.

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

පෙළ - ඉල්ලීම, සැලැස්ම, අච්චුව, ... අපි එය එකතු කරන්නාගේ පැත්තෙන් ගණනය කර, දත්ත ගබඩාවට සූදානම් කළ හැඳුනුම්පත "වත් කරන්නෙමු" යන පාඨයෙන් MD5 භාවිතා කිරීමට අපට එය පරිපූර්ණ විය. MD5 හි දිග සහ දෛනික කොටස් කිරීම අපට සිදුවිය හැකි ගැටුම් ගැන කරදර නොවන්න.

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

ඔබ සාමාන්‍යයෙන් දත්ත ලියන්නේ කෙසේද? අප සතුව යම් ආකාරයක දත්ත කට්ටලයක් ඇත, අපි එය වගු කිහිපයකට බෙදා, පසුව එය පිටපත් කරන්න - පළමුව පළමු එකට, පසුව දෙවැන්නට, තුන්වන එකට... එය අපහසුයි, මන්ද අපි එක් දත්ත ප්‍රවාහයක් පියවර තුනකින් ලියන බව පෙනේ. අනුපිළිවෙලින්. අප්‍රසන්නයි. එය වේගයෙන් කළ හැකිද? පුළුවන්!

මෙය සිදු කිරීම සඳහා, මෙම ප්රවාහයන් එකිනෙකට සමාන්තරව දිරාපත් කිරීම පමණක් ප්රමාණවත් වේ. අපට දෝෂ, ඉල්ලීම්, සැකිලි, අවහිර කිරීම්, ... වෙනම නූල් වල පියාසර කිරීම - සහ අපි ඒ සියල්ල සමාන්තරව ලියන බව පෙනේ. මේ සඳහා ප්රමාණවත් එක් එක් ඉලක්ක වගුව සඳහා COPY නාලිකාවක් නිරන්තරයෙන් විවෘතව තබා ගන්න.

එනම්, එකතු කරන්නා තුළ සෑම විටම ධාරාවක් තිබේ, මට අවශ්‍ය දත්ත ලිවිය හැක. නමුත් දත්ත සමුදාය මෙම දත්ත දකින අතර, මෙම දත්ත ලියා ඇති තෙක් යමෙකු රැඳී නොසිටින්න, නිශ්චිත කාල පරතරයන්හිදී පිටපතට බාධා කළ යුතුය. අප සඳහා, වඩාත් ඵලදායී කාලපරිච්ඡේදය 100ms පමණ විය - අපි එය වසා දමා වහාම එම වගුව වෙත නැවත විවෘත කරමු. සමහර කඳු මුදුන් වලදී අපට එක ප්‍රවාහයක් ප්‍රමාණවත් නොවන්නේ නම්, අපි යම් සීමාවක් දක්වා එකතු කරන්නෙමු.

මීට අමතරව, එවැනි පැටවුම් පැතිකඩක් සඳහා, කණ්ඩායම් වශයෙන් වාර්තා එකතු කරන විට ඕනෑම එකතු කිරීමක් නරක බව අපි සොයා ගත්තෙමු. සම්භාව්‍ය නපුර යනු INSERT ... VALUES සහ තවත් වාර්තා 1000ක්. මන්ද එම අවස්ථාවේදී ඔබට මාධ්‍යයේ ලිවීමේ උච්චස්ථානයක් ඇති අතර, තැටියට යමක් ලිවීමට උත්සාහ කරන අනෙක් සියල්ලන්ම බලා සිටිනු ඇත.

එවැනි විෂමතා ඉවත් කිරීම සඳහා, කිසිවක් එකතු නොකරන්න, කොහෙත්ම බෆර් කරන්න එපා. තවද තැටියට බෆරය සිදු වන්නේ නම් (වාසනාවකට මෙන්, Node.js හි Stream API ඔබට සොයා ගැනීමට ඉඩ සලසයි) - මෙම සම්බන්ධතාවය කල් දමන්න. ඔබට එය නැවත නොමිලේ යැයි සිදුවීමක් ලැබුණු විට, සමුච්චිත පෝලිමේ සිට එයට ලියන්න. එය කාර්යබහුල වන අතර, ඊළඟ නිදහස් එක තටාකයෙන් ගෙන එයට ලියන්න.

දත්ත පටිගත කිරීම සඳහා මෙම ප්‍රවේශය හඳුන්වා දීමට පෙර, අපට ආසන්න වශයෙන් 4K ලිවීමේ මෙහෙයුම් තිබුණි, මේ ආකාරයෙන් අපි භාරය 4 ගුණයකින් අඩු කළෙමු. නව නිරීක්ෂණ දත්ත සමුදායන් හේතුවෙන් දැන් ඒවා තවත් 6 ගුණයකින් වර්ධනය වී ඇත - 100MB/s දක්වා. දැන් අපි පසුගිය මාස 3 සඳහා ලොග් ගබඩා කරන්නේ 10-15TB පමණ පරිමාවකින්, මාස තුනකින් ඕනෑම සංවර්ධකයෙකුට ඕනෑම ගැටළුවක් විසඳීමට හැකි වනු ඇතැයි බලාපොරොත්තු වෙමු.

අපි ගැටලු තේරුම් ගනිමු

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

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

අපි ප්රධාන කරුණු තුනක් හඳුනාගෙන ඇත:

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

අපට ඉල්ලීමක් එවූ "කවුද" යන්න තේරුම් ගැනීමට, අපි සම්මත මෙවලමක් භාවිතා කරමු - සැසි විචල්‍යයක් සැකසීම: SET application_name = '{bl-host}:{bl-method}'; — අපි ඉල්ලීම එන ව්‍යාපාර තාර්කික සත්කාරකයේ නම සහ එය ආරම්භ කළ ක්‍රමයේ හෝ යෙදුමේ නම යවමු.

අපි ඉල්ලීමේ “හිමිකරු” පසු කළ පසු, එය ලොගයට ප්‍රතිදානය කළ යුතුය - මේ සඳහා අපි විචල්‍යය වින්‍යාස කරමු log_line_prefix = ' %m [%p:%v] [%d] %r %a'. උනන්දුවක් දක්වන අය සඳහා, සමහරවිට අත්පොත බලන්නඒ සියල්ලෙන් අදහස් කරන්නේ කුමක්ද? ලොගයේ අප දකින බව පෙනේ:

• время
• ක්රියාවලිය සහ ගනුදෙනු හඳුනාගැනීම්
• දත්ත සමුදායේ නම
• මෙම ඉල්ලීම එවූ පුද්ගලයාගේ IP
• සහ ක්රමයේ නම

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

එහෙනම් මෙන්න කප්පාදුව "එක් සේවාදායකයක් - එක් දිනක්" එය අපට ඕනෑම විශ්ලේෂණයක් සඳහා ප්‍රමාණවත් විය.

පළමු විශ්ලේෂණ අංශය සමාන වේ "නියැදිය" - සියලුම සංඛ්‍යාත්මක දර්ශක වලින් ඉවත් කරන ලද සැලැස්ම ඉදිරිපත් කිරීමේ සංක්ෂිප්ත ආකාරයකි. දෙවන කප්පාදුව යෙදුම හෝ ක්‍රමය වන අතර තුන්වන කප්පාදුව අපට ගැටළු ඇති කළ නිශ්චිත සැලසුම් නෝඩයයි.

අපි නිශ්චිත අවස්ථාවන්ගෙන් සැකිලි වෙත මාරු වූ විට, අපට එකවර වාසි දෙකක් ලැබුණි:

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

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

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

ඔබට ඕනෑම තීරුවකින් වර්ග කර ඔබ දැන් ගනුදෙනු කරන්නේ කුමක් දැයි තීරණය කළ හැකිය - ප්‍රොසෙසරයේ හෝ තැටියේ පැටවීම, හෝ මුළු ඉල්ලීම් ගණන... අපි එය වර්ග කර, “ඉහළම” ඒවා දෙස බලා, එය නිවැරදි කළෙමු. යෙදුමේ නව අනුවාදයක් නිකුත් කරන ලදී.
[වීඩියෝ දේශනය]

සහ වහාම ඔබට වැනි ඉල්ලීමකින් එකම අච්චුව සමඟ එන විවිධ යෙදුම් දැකිය හැකිය SELECT * FROM users WHERE login = 'Vasya'. ඉදිරිපස, පසුපෙළ, සැකසීම... තවද පරිශීලකයා ඔහු සමඟ අන්තර් ක්‍රියා නොකරන්නේ නම් සැකසීම මඟින් ඔහුව කියවන්නේ මන්දැයි ඔබ කල්පනා කරයි.

ප්‍රතිවිරුද්ධ ක්‍රමය නම් යෙදුමෙන් එය කරන්නේ කුමක්ද යන්න වහාම බැලීමයි. උදාහරණයක් ලෙස, ඉදිරිපස කොටස මෙයයි, මෙයයි, මෙයයි, මෙය පැයකට වරක් (කාල නියමය උපකාරී වේ). ප්‍රශ්නය වහාම පැන නගී: පැයකට වරක් යමක් කිරීම පෙරමුණේ කාර්යය නොවන බව පෙනේ ...

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

ඔබට තහඩුව මත සුදුසු දර්ශකයක් නොමැත, ඔබ එයට ඉල්ලීමක් කරයි, එය දර්ශකය පසුකර පියාසර කරයි, Seq Scan වෙත වැටේ ... ඔබ එකක් හැර සියලුම වාර්තා පෙරා ඇත. ඔබට දිනකට 100M පෙරන ලද වාර්තා අවශ්‍ය වන්නේ ඇයි? දර්ශකය පෙරළීම වඩා හොඳ නොවේද?

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

විමසුම් ලියූ සෑම කෙනෙකුම බොහෝ විට මෙම රටාවට මුහුණ දී ඇත: “මට වාස්‍යා සඳහා අවසාන ඇණවුම, එහි දිනය දෙන්න.” තවද ඔබට දිනය අනුව දර්ශකයක් නොමැති නම් හෝ ඔබ භාවිතා කළ දර්ශකයේ දිනයක් නොමැති නම්, ඔබ එසේ කරනු ඇත. හරියටම එකම "රේක්" මත පියවර තබන්න.

නමුත් මෙය “රේක්” බව අපි දනිමු - එබැවින් ඔහු කළ යුතු දේ සංවර්ධකයාට වහාම නොකියන්නේ මන්ද? ඒ අනුව, දැන් සැලැස්මක් විවෘත කරන විට, අපගේ සංවර්ධකයා වහාම ඉඟි සහිත ලස්සන පින්තූරයක් දකින අතර, ඔවුන් වහාම ඔහුට මෙසේ කියයි: "ඔබට එහෙන් මෙහෙන් ගැටලු ඇති නමුත් ඒවා මේ ආකාරයෙන් සහ ඒ ආකාරයෙන් විසඳනු ලැබේ."

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

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