සෙවුම් ප්රතිඵල ප්රතිදානය සහ කාර්ය සාධන ගැටළු

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

පිටුකරණ විකල්පය #1

මතකයට එන සරළම විකල්පය වන්නේ සෙවුම් ප්‍රතිඵල එහි වඩාත් සම්භාව්‍ය ආකාරයෙන් පිටුවෙන් පිටුව පෙන්වීමයි.

ඔබගේ යෙදුම සම්බන්ධතා දත්ත සමුදායක් භාවිතා කරන බව කියමු. මෙම අවස්ථාවේදී, මෙම පෝරමයේ තොරතුරු පෙන්වීමට, ඔබට SQL විමසුම් දෙකක් ධාවනය කිරීමට අවශ්‍ය වනු ඇත:

• වත්මන් පිටුව සඳහා පේළි ලබා ගන්න.
• සෙවුම් නිර්ණායකයට අනුරූප මුළු පේළි ගණන ගණනය කරන්න - මෙය පිටු පෙන්වීමට අවශ්ය වේ.

උදාහරණයක් ලෙස ටෙස්ට් MS SQL දත්ත සමුදායක් භාවිතා කරන පළමු විමසුම දෙස බලමු වික්‍රමාන්විත වැඩ 2016 සේවාදායකය සඳහා. මෙම කාර්යය සඳහා අපි Sales.SalesOrderHeader වගුව භාවිතා කරමු:

SELECT * FROM Sales.SalesOrderHeader
ORDER BY OrderDate DESC
OFFSET 0 ROWS
FETCH NEXT 50 ROWS ONLY

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

එය පරීක්ෂණ පදනම මත ඉක්මනින් ක්‍රියාත්මක වේ, නමුත් අපි ක්‍රියාත්මක කිරීමේ සැලැස්ම සහ I/O සංඛ්‍යාලේඛන දෙස බලමු:

Table 'SalesOrderHeader'. Scan count 1, logical reads 698, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

විමසුම් ධාවන කාලය තුළ SET STATISTICS IO ON විධානය ක්‍රියාත්මක කිරීමෙන් ඔබට එක් එක් විමසුම සඳහා I/O සංඛ්‍යාලේඛන ලබා ගත හැක.

ක්‍රියාත්මක කිරීමේ සැලැස්මෙන් ඔබට පෙනෙන පරිදි, වඩාත්ම සම්පත්-දැඩි විකල්පය වන්නේ එකතු කළ දිනය අනුව ප්‍රභව වගුවේ සියලුම පේළි වර්ග කිරීමයි. ගැටළුව වන්නේ වගුවේ පේළි වැඩි වන තරමට වර්ග කිරීම "වඩා අමාරු" වීමයි. ප්රායෝගිකව, එවැනි තත්වයන් වළක්වා ගත යුතුය, එබැවින් එකතු කිරීමේ දිනයට දර්ශකයක් එකතු කර සම්පත් පරිභෝජනය වෙනස් වී ඇත්දැයි බලමු:

Table 'SalesOrderHeader'. Scan count 1, logical reads 165, physical reads 0, read-ahead reads 5, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

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

SELECT * FROM Sales.SalesOrderHeader
WHERE SubTotal > 100
ORDER BY OrderDate DESC
OFFSET 0 ROWS
FETCH NEXT 50 ROWS ONLY

Table 'SalesOrderHeader'. Scan count 1, logical reads 1081, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

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

CREATE INDEX IX_SalesOrderHeader_OrderDate_SubTotal on Sales.SalesOrderHeader(OrderDate, SubTotal);

මෙම උදාහරණ මාලාව දිගු කලක් අඛණ්ඩව කරගෙන යා හැක, නමුත් මට මෙහි ප්‍රකාශ කිරීමට අවශ්‍ය ප්‍රධාන අදහස් දෙක නම්:

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

දැන් අපි ආරම්භයේදීම සඳහන් කළ දෙවන විමසුම වෙත යමු - සෙවුම් නිර්ණායකය තෘප්තිමත් කරන වාර්තා ගණන ගණනය කරන එක. අපි එකම උදාහරණය ගනිමු - $100 ට වඩා වැඩි ඇණවුම් සඳහා සෙවීම:

SELECT COUNT(1) FROM Sales.SalesOrderHeader
WHERE SubTotal > 100

ඉහත දක්වා ඇති සංයුක්ත දර්ශකය අනුව, අපි ලබා ගන්නේ:

Table 'SalesOrderHeader'. Scan count 1, logical reads 698, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

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

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

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

පිටුකරණ විකල්පය #2

හමු වූ මුළු වස්තු ගණන දැන ගැනීම ගැන පරිශීලකයින් සැලකිල්ලක් නොදක්වන බව අපි සිතමු. සෙවුම් පිටුව සරල කිරීමට උත්සාහ කරමු:

ඇත්ත වශයෙන්ම, වෙනස් වී ඇති එකම දෙය නම් නිශ්චිත පිටු අංක වෙත සැරිසැරීමට ක්රමයක් නොමැති අතර, දැන් මෙම වගුව එය ප්රදර්ශනය කිරීම සඳහා කොපමණ ප්රමාණයක් තිබිය හැකිද යන්න දැන ගැනීමට අවශ්ය නොවේ. නමුත් ප්‍රශ්නය පැන නගී - ඊළඟ පිටුව සඳහා දත්ත තිබේදැයි වගුව දැන ගන්නේ කෙසේද (“ඊළඟ” සබැඳිය නිවැරදිව ප්‍රදර්ශනය කිරීම සඳහා)?

පිළිතුර ඉතා සරල ය: ඔබට ප්‍රදර්ශනය සඳහා අවශ්‍ය ප්‍රමාණයට වඩා එක් වාර්තාවක් දත්ත සමුදායෙන් කියවිය හැකි අතර, මෙම “අතිරේක” වාර්තාව තිබීම ඊළඟ කොටස තිබේද යන්න පෙන්වයි. මේ ආකාරයෙන්, ඔබට එක් දත්ත පිටුවක් ලබා ගැනීම සඳහා එක් ඉල්ලීමක් පමණක් ධාවනය කිරීමට අවශ්‍ය වේ, එමඟින් කාර්ය සාධනය සැලකිය යුතු ලෙස වැඩිදියුණු වන අතර එවැනි ක්‍රියාකාරිත්වයට සහාය වීම පහසු කරයි. මගේ භාවිතයේ දී, මුළු වාර්තා ගණන ගණනය කිරීම ප්‍රතික්ෂේප කිරීම 4-5 ගුණයකින් ප්‍රති results ල ලබා දීම වේගවත් කළ අවස්ථාවක් තිබුණි.

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

පේජිං ක්රියාත්මක කිරීමේ සූක්ෂ්මතා

ඉහත දක්වා ඇති සියලුම විමසුම් උදාහරණ "ඕෆ්සෙට් + ගණන්" ප්‍රවේශය භාවිතා කරයි, විමසුම විසින්ම ප්‍රතිඵල පේළි කුමන අනුපිළිවෙලට සහ කොපමණ පේළි ප්‍රමාණයක් ආපසු ලබා දිය යුතුද යන්න සඳහන් කරන විට. පළමුව, මෙම නඩුවේ පරාමිති සමත්වීම වඩාත් හොඳින් සංවිධානය කරන්නේ කෙසේදැයි බලමු. ප්රායෝගිකව, මම ක්රම කිහිපයක් සොයාගෙන ඇත:

• ඉල්ලූ පිටුවේ අනුක්‍රමික අංකය (පිටු දර්ශකය), පිටු ප්‍රමාණය (පිටු ප්‍රමාණය).
• ආපසු ලබා දිය යුතු පළමු වාර්තාවේ අනුක්‍රමික අංකය (ආරම්භක දර්ශකය), ප්‍රතිඵලයේ ඇති උපරිම වාර්තා ගණන (ගණන්).
• ආපසු ලබා දිය යුතු පළමු වාර්තාවේ අනුක්‍රමික අංකය (ආරම්භක දර්ශකය), ආපසු ලබා දිය යුතු අවසාන වාර්තාවේ අනුක්‍රමික අංකය (අවසන් දර්ශකය).

බැලූ බැල්මට පෙනෙන්නේ මෙය එතරම් ප්‍රාථමික බවත් වෙනසක් නැති බවත්ය. නමුත් මෙය එසේ නොවේ - වඩාත්ම පහසු සහ විශ්වීය විකල්පය වන්නේ දෙවන (ආරම්භක දර්ශකය, ගණන් කිරීම) ය. මේ සඳහා හේතු කිහිපයක් තිබේ:

• ඉහත දක්වා ඇති +1 ප්‍රවේශ සෝදුපත් කියවීමේ ප්‍රවේශය සඳහා, pageIndex සහ pageSize සමඟ ඇති පළමු විකල්පය අතිශයින්ම අපහසු වේ. උදාහරණයක් ලෙස, අපට පිටුවකට පළ කිරීම් 50ක් පෙන්වීමට අවශ්‍යයි. ඉහත ඇල්ගොරිතමයට අනුව, ඔබට අවශ්‍ය ප්‍රමාණයට වඩා එක් වාර්තාවක් කියවිය යුතුය. මෙම “+1” සේවාදායකයේ ක්‍රියාත්මක නොවන්නේ නම්, පළමු පිටුව සඳහා අපි 1 සිට 51 දක්වා, දෙවැන්න සඳහා - 51 සිට 101 දක්වා වාර්තා ඉල්ලා සිටිය යුතු බව පෙනේ. ඔබ පිටු ප්‍රමාණය 51 ක් සඳහන් කර pageIndex වැඩි කළහොත්, දෙවන පිටුව 52 සිට 102 දක්වා නැවත පැමිණේ. ඒ අනුව, පළමු විකල්පය තුළ, ඊළඟ පිටුවට යාමට බොත්තමක් නිසියාකාරව ක්‍රියාත්මක කළ හැකි එකම ක්‍රමය නම් සේවාදායකය විසින් “අමතර” රේඛාව සෝදුපත් කර ගැනීමයි, එය ඉතා ව්‍යංග සූක්ෂ්මතාවයක් වනු ඇත.
• තෙවන විකල්පය කිසිසේත්ම තේරුමක් නැත, මන්ද බොහෝ දත්ත සමුදායන්හි විමසුම් ධාවනය කිරීමට ඔබට තවමත් අවසාන වාර්තාවේ දර්ශකයට වඩා ගණන් කිරීම සමත් විය යුතුය. endIndex වෙතින් startIndex අඩු කිරීම සරල අංක ගණිත ක්‍රියාවක් විය හැකි නමුත් එය මෙහි අතිරික්තය.

දැන් අපි "ඕෆ්සෙට් + ප්‍රමාණය" හරහා පේජිං ක්‍රියාත්මක කිරීමේ අවාසි විස්තර කළ යුතුය:

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

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

SELECT * FROM Sales.SalesOrderHeader
ORDER BY OrderDate DESC
OFFSET 0 ROWS
FETCH NEXT 50 ROWS ONLY

ඒවගේම අන්තිම වාර්තාවේ අපිට ලැබුනේ '2014-06-29' කියන order date value එක. ඊළඟ පිටුව ලබා ගැනීමට ඔබට මෙය කිරීමට උත්සාහ කළ හැකිය:

SELECT * FROM Sales.SalesOrderHeader
WHERE OrderDate < '2014-06-29'
ORDER BY OrderDate DESC
OFFSET 0 ROWS
FETCH NEXT 50 ROWS ONLY

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

SELECT * FROM Sales.SalesOrderHeader
WHERE (OrderDate = '2014-06-29' AND SalesOrderID < 75074)
   OR (OrderDate < '2014-06-29')
ORDER BY OrderDate DESC, SalesOrderID DESC
OFFSET 0 ROWS
FETCH NEXT 50 ROWS ONLY

මෙම විකල්පය නිවැරදිව ක්‍රියා කරයි, නමුත් සාමාන්‍යයෙන් කොන්දේසියේ OR ක්‍රියාකරුවෙකු අඩංගු බැවින් එය ප්‍රශස්ත කිරීම අපහසු වනු ඇත. OrderDate වැඩි වන විට ප්‍රාථමික යතුරේ අගය වැඩි වන්නේ නම්, SalesOrderID මඟින් පෙරහනක් පමණක් තැබීමෙන් තත්ත්වය සරල කළ හැක. නමුත් ප්‍රාථමික යතුරේ අගයන් සහ ප්‍රතිඵලය වර්ග කර ඇති ක්ෂේත්‍රය අතර දැඩි සහසම්බන්ධයක් නොමැති නම්, බොහෝ DBMS වල මෙම OR වැළැක්විය නොහැක. මා දන්නා ව්‍යතිරේකයක් වන්නේ ටුපල් සැසඳීම් සඳහා සම්පුර්ණයෙන්ම සහය දක්වන PostgreSQL වන අතර ඉහත කොන්දේසිය "WHERE (OrderDate, SalesOrderID) < ('2014-06-29', 75074)" ලෙස ලිවිය හැක. මෙම ක්ෂේත්‍ර දෙක සමඟ සංයුක්ත යතුරක් ලබා දී ඇති අතර, මෙවැනි විමසුමක් තරමක් පහසු විය යුතුය.

දෙවන විකල්ප ප්‍රවේශයක් සොයාගත හැකිය, උදාහරණයක් ලෙස ElasticSearch අනුචලන API හෝ කොස්මොස් ඩී.බී - ඉල්ලීමක්, දත්ත වලට අමතරව, ඔබට ඊළඟ දත්ත කොටස ලබා ගත හැකි විශේෂ හඳුනාගැනීමක් ලබා දෙන විට. මෙම හැඳුනුම්කාරකයට අසීමිත ආයු කාලයක් තිබේ නම් (කොම්සෝස් ඩීබී හි මෙන්), පිටු අතර අනුක්‍රමික සංක්‍රාන්තියක් සමඟින් පිටුකරණය ක්‍රියාත්මක කිරීමට මෙය විශිෂ්ට ක්‍රමයකි (ඉහත සඳහන් කළ විකල්ප #2). එහි ඇති විය හැකි අවාසි: එය සියලුම DBMS වල සහය නොදක්වයි; ප්‍රතිඵලයක් ලෙස ලැබෙන මීළඟ කුට්ටි හඳුනාගැනීමේ සීමිත ආයු කාලයක් තිබිය හැක, එය සාමාන්‍යයෙන් පරිශීලක අන්තර්ක්‍රියා ක්‍රියාවට නැංවීම සඳහා සුදුසු නොවේ (ElasticSearch scroll API වැනි).

සංකීර්ණ පෙරීම

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

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

උදාහරණයක් ලෙස, අපි මෙම උදාහරණයේ Bikes කාණ්ඩය සහ කළු වර්ණය තෝරා ගන්නේ නම්, වගුවේ පෙන්වන්නේ කළු බයිසිකල් පමණි, නමුත්:

• ප්‍රවර්ග සමූහයේ එක් එක් නිර්ණායක සඳහා, එම කාණ්ඩයේ නිෂ්පාදන ගණන කළු පැහැයෙන් පෙන්වනු ඇත.
• "වර්ණ" කාණ්ඩයේ එක් එක් නිර්ණායක සඳහා, මෙම වර්ණයෙහි බයිසිකල් සංඛ්යාව පෙන්වනු ලැබේ.

මෙන්න එවැනි කොන්දේසි සඳහා ප්රතිඵල ප්රතිදානය පිළිබඳ උදාහරණයක්:

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

දැන් අපි හිතමු මෙය සාපේක්ෂ පදනමක් මත ක්‍රියාත්මක කරන්නේ කෙසේද කියා. ප්‍රවර්ගය සහ වර්ණය වැනි සෑම නිර්ණායක කණ්ඩායමකටම වෙනම විමසුමක් අවශ්‍ය වනු ඇත:

SELECT pc.ProductCategoryID, pc.Name, COUNT(1) FROM Production.Product p
  INNER JOIN Production.ProductSubcategory ps ON p.ProductSubcategoryID = ps.ProductSubcategoryID
  INNER JOIN Production.ProductCategory pc ON ps.ProductCategoryID = pc.ProductCategoryID
WHERE p.Color = 'Black'
GROUP BY pc.ProductCategoryID, pc.Name
ORDER BY COUNT(1) DESC

SELECT Color, COUNT(1) FROM Production.Product p
  INNER JOIN Production.ProductSubcategory ps ON p.ProductSubcategoryID = ps.ProductSubcategoryID
WHERE ps.ProductCategoryID = 1 --Bikes
GROUP BY Color
ORDER BY COUNT(1) DESC

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

සාමාන්‍යයෙන් මෙම ප්‍රකාශවලින් පසුව මට විසඳුම් කිහිපයක් ඉදිරිපත් කරනු ලැබේ, එනම්:

• සියලුම ප්‍රමාණ ගණන් එක් විමසුමකට ඒකාබද්ධ කරන්න. තාක්‍ෂණිකව මෙය UNION මූල පදය භාවිතයෙන් කළ හැකි නමුත් එය ක්‍රියාකාරීත්වයට බොහෝ සෙයින් උදව් නොකරනු ඇත - දත්ත සමුදායට තවමත් මුල සිටම එක් එක් කොටස් ක්‍රියාත්මක කිරීමට සිදුවේ.
• හැඹිලි ප්රමාණ. මම ගැටලුවක් විස්තර කරන සෑම අවස්ථාවකම පාහේ මෙය මට යෝජනා කෙරේ. අවවාදය නම් මෙය සාමාන්‍යයෙන් කළ නොහැකි දෙයකි. අපි කියමු අපට "මුහුණු" 10 ක් ඇති අතර, ඒ සෑම එකක්ම අගයන් 5 ක් ඇත. එකම අන්තර්ජාල වෙළඳසැල් වල දැකිය හැකි දේට සාපේක්ෂව මෙය ඉතා "නිහතමානී" තත්වයකි. එක් මුහුණත මූලද්‍රව්‍යයක් තෝරාගැනීම අනෙක් 9 ක ප්‍රමාණවලට බලපායි, වෙනත් වචන වලින් කිවහොත්, එක් එක් නිර්ණායක සංයෝජනය සඳහා ප්‍රමාණ වෙනස් විය හැකිය. අපගේ උදාහරණයේ දී, පරිශීලකයාට තෝරා ගත හැකි නිර්ණායක 50 ක් ඇත, එබැවින් හැකි සංයෝජන 250 ක් ඇත. එවැනි දත්ත මාලාවක් පිරවීමට ප්රමාණවත් මතකයක් හෝ කාලයක් නොමැත. මෙහිදී ඔබට විරුද්ධ විය හැකි අතර සියලු සංයෝජන සැබෑ නොවන අතර පරිශීලකයා කලාතුරකින් 5-10 නිර්ණායක තෝරා ගනී. ඔව්, කම්මැලි පැටවීම සිදු කළ හැකි අතර මෙතෙක් තෝරාගෙන ඇති ප්‍රමාණයෙන් පමණක් හැඹිලිගත කළ හැකිය, නමුත් තෝරා ගැනීම් වැඩි වන තරමට, එවැනි හැඹිලියක කාර්යක්ෂමතාව අඩු වන අතර ප්‍රතිචාර දැක්වීමේ වේලාවේ ගැටළු වඩාත් කැපී පෙනෙන වනු ඇත (විශේෂයෙන් නම් දත්ත කට්ටලය නිතිපතා වෙනස් වේ).

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

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

සොයා ගැනීම්

1. සේවාදායක පැත්තේ පිටුකරණය ක්‍රියාත්මක කිරීම සැලකිය යුතු සංකූලතාවයක් වන අතර එය අර්ථවත් වන්නේ වේගයෙන් වර්ධනය වන හෝ සරලව විශාල දත්ත කට්ටල සඳහා පමණි. "විශාල" හෝ "වේගයෙන් වර්ධනය වන" ඇගයීම සඳහා නිශ්චිත වට්ටෝරුවක් නොමැත, නමුත් මම මෙම ප්රවේශය අනුගමනය කරමි:
   • සම්පූර්ණ දත්ත එකතුවක් ලැබීම, සේවාදායක කාලය සහ ජාල සම්ප්‍රේෂණය සැලකිල්ලට ගනිමින්, සාමාන්‍යයෙන් කාර්ය සාධන අවශ්‍යතාවලට ගැලපේ නම්, සේවාදායකයේ පිටුකරණය ක්‍රියාත්මක කිරීමේ තේරුමක් නැත.
   • නුදුරු අනාගතයේ දී කාර්ය සාධන ගැටළු අපේක්ෂා නොකරන තත්වයක් තිබිය හැකිය, මන්ද කුඩා දත්ත ඇති නමුත් දත්ත එකතු කිරීම නිරන්තරයෙන් වර්ධනය වේ. අනාගතයේ සමහර දත්ත කට්ටලයක් පෙර කරුණ තවදුරටත් තෘප්තිමත් නොකළ හැකි නම්, වහාම පිටුගත කිරීම ආරම්භ කිරීම වඩා හොඳය.
2. සම්පූර්ණ ප්‍රතිඵල සංඛ්‍යාව පෙන්වීමට හෝ පිටු අංක ප්‍රදර්ශනය කිරීමට ව්‍යාපාරයේ දැඩි අවශ්‍යතාවයක් නොමැති නම් සහ ඔබේ පද්ධතියට සෙවුම් යන්ත්‍රයක් නොමැති නම්, මෙම කරුණු ක්‍රියාත්මක නොකිරීමට සහ #2 විකල්පය සලකා බැලීම වඩා හොඳය.
3. මුහුණු සෙවීම සඳහා පැහැදිලි අවශ්‍යතාවයක් තිබේ නම්, කාර්ය සාධනය කැප නොකර ඔබට විකල්ප දෙකක් තිබේ:
   • සෙවුම් නිර්ණායක වෙනස් වන සෑම අවස්ථාවකම සියලු ප්රමාණ නැවත ගණනය නොකරන්න.
   • Solr, ElasticSearch, Sphinx සහ වෙනත් සෙවුම් යන්ත්‍ර භාවිතා කරන්න. නමුත් එය ප්රධාන දත්ත ගබඩාව සඳහා ආදේශකයක් විය නොහැකි බව තේරුම් ගත යුතු අතර, සෙවුම් ගැටළු විසඳීම සඳහා ප්රධාන ගබඩාවට එකතු කිරීමක් ලෙස භාවිතා කළ යුතුය.
4. එසේම, මුහුණත සෙවීමේදී, සෙවුම් ප්‍රතිඵල පිටුව ලබා ගැනීම සහ ගණන් කිරීම සමාන්තර ඉල්ලීම් දෙකකට බෙදීම අර්ථවත් කරයි. ප්‍රමාණ ගණන් කිරීම ප්‍රතිඵල ලබා ගැනීමට වඩා වැඩි කාලයක් ගත විය හැකි අතර, ප්‍රතිඵල පරිශීලකයාට වඩා වැදගත් වේ.
5. ඔබ සෙවීම සඳහා SQL දත්ත සමුදායක් භාවිතා කරන්නේ නම්, මෙම කොටසට අදාළ ඕනෑම කේත වෙනසක් සුදුසු දත්ත ප්‍රමාණයක (සජීවී දත්ත ගබඩාවේ පරිමාව ඉක්මවා) කාර්ය සාධනය සඳහා හොඳින් පරීක්‍ෂා කළ යුතුය. දත්ත සමුදායේ සියලුම අවස්ථාවන්හිදී සහ විශේෂයෙන් “සජීවී” එකෙහි විමසුම් ක්‍රියාත්මක කිරීමේ කාලය නිරීක්ෂණය කිරීම ද යෝග්‍ය වේ. සංවර්ධන අදියරේදී විමසුම් සැලසුම් සමඟ සෑම දෙයක්ම හොඳින් තිබුණද, දත්ත පරිමාව වර්ධනය වන විට, තත්වය සැලකිය යුතු ලෙස වෙනස් විය හැකිය.

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