පිටුගත විමසුම්වල OFFSET සහ LIMIT භාවිතයෙන් වළකින්න

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

ඔබ කිසියම් කාලයක් සඳහා යෙදුම් හෝ දත්ත සමුදා පසුබිම් නිර්මාණය කර ඇත්නම්, ඔබ බොහෝ විට පිටුගත විමසුම් ධාවනය කිරීමට කේතය ලියා ඇත. උදාහරණයක් ලෙස, මේ වගේ:

SELECT * FROM table_name LIMIT 10 OFFSET 40

එය පවතින ආකාරය?

නමුත් ඔබ ඔබේ පිටුව නිර්මාණය කළේ මේ ආකාරයට නම්, ඔබ එය වඩාත් කාර්යක්ෂමව සිදු නොකළ බව පැවසීමට මට කණගාටුයි.

ඔබට මට විරුද්ධ වීමට අවශ්‍යද? ඔයාට පුළුවන් නෑ වියදම් කිරීමට время. ඉල්ලූම, Shopify и මික්ස්මැක්ස් ඔවුන් දැනටමත් මම අද කතා කිරීමට අවශ්ය තාක්ෂණික ක්රම භාවිතා කරයි.

අවම වශයෙන් කිසිදා භාවිතා නොකළ එක් පසුපෙළ සංවර්ධකයෙකු නම් කරන්න OFFSET и LIMIT පිටුගත විමසුම් ඉටු කිරීමට. MVP (අවම ශක්‍ය නිෂ්පාදනය) සහ කුඩා දත්ත ප්‍රමාණයක් භාවිතා කරන ව්‍යාපෘති වලදී, මෙම ප්‍රවේශය බෙහෙවින් අදාළ වේ. එය "වැඩ කරන්නේ", එසේ කතා කිරීමට.

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

අද අපි සාමාන්‍යයෙන් භාවිතා කරන (ඉතා නරක) පිටුගත විමසුම් එන්ජින් ක්‍රියාත්මක කිරීමේ ගැටළු සහ එවැනි විමසුම් ක්‍රියාත්මක කිරීමේදී ඉහළ කාර්ය සාධනයක් ලබා ගන්නේ කෙසේද යන්න ගැන කතා කරමු.

OFFSET සහ LIMIT වල ඇති වැරැද්ද කුමක්ද?

දැනටමත් පවසා ඇති පරිදි, OFFSET и LIMIT විශාල දත්ත ප්‍රමාණයක් සමඟ වැඩ කිරීමට අවශ්‍ය නොවන ව්‍යාපෘති වලදී ඔවුන් හොඳින් ක්‍රියා කරයි.

දත්ත සමුදාය සේවාදායකයේ මතකයට නොගැලපෙන තරම් විශාල වන විට ගැටළුව පැන නගී. කෙසේ වෙතත්, මෙම දත්ත සමුදාය සමඟ වැඩ කරන විට, ඔබට පිටුගත විමසුම් භාවිතා කළ යුතුය.

මෙම ගැටලුව ප්‍රකාශ වීමට නම්, එක් එක් පිටුගත විමසුමකදී DBMS අකාර්යක්ෂම සම්පූර්ණ වගු පරිලෝකන මෙහෙයුමකට යොමු වන තත්වයක් තිබිය යුතුය (ඇතුළත් කිරීම සහ මකා දැමීමේ මෙහෙයුම් සිදු විය හැකි අතර, අපට යල් පැන ගිය දත්ත අවශ්‍ය නොවේ!).

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

උදාහරණයක් ලෙස, ඔබට පරිශීලකයින් 100000000 ක වාර්තා ඇති අතර ඔබ ගොඩනැගීම සමඟ විමසුමක් ධාවනය කරයි OFFSET 50000000. මෙයින් අදහස් කරන්නේ DBMS හට මෙම සියලුම වාර්තා පූරණය කිරීමට සිදුවනු ඇති බවයි (සහ අපට ඒවා අවශ්‍ය නැත!), ඒවා මතකයේ තබා, ඉන් පසු වාර්තා කර ඇති ප්‍රතිඵල 20ක් ගන්න. LIMIT.

එය මෙසේ විය හැකි යැයි සිතමු: "50000 සිට 50020 සිට 100000 දක්වා පේළි තෝරන්න". එනම්, විමසුම සම්පූර්ණ කිරීම සඳහා පද්ධතියට පළමුව පේළි 50000ක් පැටවීමට අවශ්‍ය වනු ඇත. ඔයාට පේනවද එයාට කොච්චර අනවශ්‍ය වැඩ කරන්න වෙයිද කියලා?

ඔබ මාව විශ්වාස නොකරන්නේ නම්, විශේෂාංග භාවිතයෙන් මා නිර්මාණය කළ උදාහරණය දෙස බලන්න db-fiddle.com. 

db-fiddle.com හි උදාහරණය

එහි, වම් පසින්, පිට්ටනියේ Schema SQL, දත්ත සමුදාය තුළට පේළි 100000 ක් ඇතුළු කරන කේතයක් ඇත, සහ දකුණු පසින්, ක්ෂේත්රයේ Query SQL, විමසුම් දෙකක් පෙන්වා ඇත. පළමු, මන්දගාමී එක, මේ වගේ ය:

SELECT *
FROM `docs`
LIMIT 10 OFFSET 85000;

එම ගැටලුවට ඵලදායී විසඳුමක් වන දෙවැන්න මේ වගේ ය:

SELECT *
FROM `docs`
WHERE id > 85000
LIMIT 10;

මෙම ඉල්ලීම් ඉටු කිරීම සඳහා, බොත්තම මත ක්ලික් කරන්න Run පිටුවේ ඉහළින්. මෙය සිදු කිරීමෙන් පසු, අපි විමසුම් ක්රියාත්මක කිරීමේ කාලය පිළිබඳ තොරතුරු සංසන්දනය කරමු. අකාර්යක්ෂම විමසුමක් ක්‍රියාත්මක කිරීම දෙවැන්න ක්‍රියාත්මක කිරීමට වඩා අවම වශයෙන් 30 ගුණයක කාලයක් ගත වන බව පෙනේ (මෙම කාලය ධාවනයෙන් ධාවනයට වෙනස් වේ; උදාහරණයක් ලෙස, පළමු විමසුම සම්පූර්ණ කිරීමට ms 37 ක් ගත වූ බව පද්ධතිය වාර්තා කළ හැකි නමුත් ක්‍රියාත්මක කිරීම දෙවන - 1 ms).

තවත් දත්ත තිබේ නම්, සියල්ල ඊටත් වඩා නරක ලෙස පෙනෙනු ඇත (මේ පිළිබඳව ඒත්තු ගැන්වීමට, මගේ දෙස බලන්න උදාහරණයකි පේළි මිලියන 10 ක් සමඟ).

අපි දැන් සාකච්ඡා කළ දේ දත්ත සමුදා විමසුම් ඇත්ත වශයෙන්ම සකසන ආකාරය පිළිබඳ යම් අවබෝධයක් ලබා දිය යුතුය.

අගය වැඩි වන බව කරුණාවෙන් සලකන්න OFFSET - ඉල්ලීම සම්පූර්ණ කිරීමට වැඩි කාලයක් ගතවනු ඇත.

OFFSET සහ LIMIT සංයෝගය වෙනුවට මා භාවිතා කළ යුත්තේ කුමක්ද?

සංයෝජනයක් වෙනුවට OFFSET и LIMIT පහත සඳහන් යෝජනා ක්රමය අනුව ඉදිකරන ලද ව්යුහයක් භාවිතා කිරීම වටී:

SELECT * FROM table_name WHERE id > 10 LIMIT 20

මෙය කර්සරය පාදක කරගත් පිටුවක් සහිත විමසුම් ක්‍රියාවකි.

වත්මන් ඒවා දේශීයව ගබඩා කිරීම වෙනුවට OFFSET и LIMIT සහ එක් එක් ඉල්ලීම සමඟ ඒවා සම්ප්‍රේෂණය කරන්න, ඔබට අවසන් වරට ලැබුණු ප්‍රාථමික යතුර ගබඩා කළ යුතුය (සාමාන්‍යයෙන් මෙය වේ ID) සහ LIMIT, ප්රතිඵලයක් වශයෙන්, ඉහත සඳහන් දේට සමාන විමසුම් ලැබෙනු ඇත.

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

විවිධ විමසුම්වල පහත කාර්ය සාධන සංසන්දනය දෙස බලමු. මෙන්න අකාර්යක්ෂම විමසුමක්.

මන්දගාමී ඉල්ලීම

තවද මෙන්න මෙම ඉල්ලීමේ ප්‍රශස්ත අනුවාදයකි.

ඉක්මන් ඉල්ලීම

විමසුම් දෙකම හරියටම එකම දත්ත ප්‍රමාණයක් ලබා දෙයි. නමුත් පළමු එක සම්පූර්ණ කිරීමට තත්පර 12,80 ක් ගත වන අතර දෙවැන්න තත්පර 0,01 ක් ගතවේ. ඔබට වෙනස දැනෙනවාද?

හැකි ගැටළු

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

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

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

ඔබ මෙම මාතෘකාව ගැන උනන්දුවක් දක්වන්නේ නම් - බලන්නකෝ, බලන්නකෝ и බලන්නකෝ - ප්රයෝජනවත් ද්රව්ය කිහිපයක්.

ප්රතිඵල

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

ඔබ දත්ත සමුදා විමසුම් විශ්ලේෂණය කර ප්‍රශස්ත කරන්නේ කෙසේද?

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