പേജ് ചെയ്ത ചോദ്യങ്ങളിൽ OFFSET, LIMIT എന്നിവ ഉപയോഗിക്കുന്നത് ഒഴിവാക്കുക

ഡാറ്റാബേസ് പ്രകടനം ഒപ്റ്റിമൈസ് ചെയ്യുന്നതിനെക്കുറിച്ച് നിങ്ങൾക്ക് വിഷമിക്കേണ്ടതില്ലാത്ത ദിവസങ്ങൾ കഴിഞ്ഞു. സമയം നിശ്ചലമായി നിൽക്കുന്നില്ല. ഓരോ പുതിയ സാങ്കേതിക സംരംഭകനും അടുത്ത ഫേസ്ബുക്ക് സൃഷ്ടിക്കാൻ ആഗ്രഹിക്കുന്നു, അതേസമയം അവർക്ക് കൈയിൽ കിട്ടുന്ന എല്ലാ ഡാറ്റയും ശേഖരിക്കാൻ ശ്രമിക്കുന്നു. ബിസിനസുകൾക്ക് പണം സമ്പാദിക്കാൻ സഹായിക്കുന്ന മികച്ച ട്രെയിൻ മോഡലുകൾക്ക് ഈ ഡാറ്റ ആവശ്യമാണ്. അത്തരം സാഹചര്യങ്ങളിൽ, പ്രോഗ്രാമർമാർ വലിയ അളവിലുള്ള വിവരങ്ങളുമായി വേഗത്തിലും വിശ്വസനീയമായും പ്രവർത്തിക്കാൻ അനുവദിക്കുന്ന API-കൾ സൃഷ്ടിക്കേണ്ടതുണ്ട്.

നിങ്ങൾ ഏത് സമയത്തും ആപ്ലിക്കേഷനോ ഡാറ്റാബേസ് ബാക്കെൻഡുകളോ രൂപകൽപന ചെയ്യുകയാണെങ്കിൽ, പേജ് ചെയ്ത ചോദ്യങ്ങൾ പ്രവർത്തിപ്പിക്കുന്നതിന് നിങ്ങൾ ഒരുപക്ഷേ കോഡ് എഴുതിയിട്ടുണ്ടാകും. ഉദാഹരണത്തിന്, ഇതുപോലെ:

SELECT * FROM table_name LIMIT 10 OFFSET 40

അതെങ്ങനെയാണ്?

എന്നാൽ നിങ്ങളുടെ പേജിനേഷൻ ഇങ്ങനെയാണ് നിങ്ങൾ ചെയ്തതെങ്കിൽ, നിങ്ങൾ അത് ഏറ്റവും കാര്യക്ഷമമായ രീതിയിലല്ല ചെയ്തതെന്ന് പറയുന്നതിൽ എനിക്ക് ഖേദമുണ്ട്.

നിങ്ങൾക്ക് എന്നെ എതിർക്കണോ? നിങ്ങൾക്ക് കഴിയും അല്ല ചെലവഴിക്കുക время. മടിയുള്ള, Shopify и മിക്സ്മാക്സ് ഇന്ന് ഞാൻ സംസാരിക്കാൻ ആഗ്രഹിക്കുന്ന സാങ്കേതിക വിദ്യകൾ അവർ ഇതിനകം തന്നെ ഉപയോഗിക്കുന്നു.

ഒരിക്കലും ഉപയോഗിക്കാത്ത ഒരു ബാക്കെൻഡ് ഡെവലപ്പറുടെ പേരെങ്കിലും പറയുക OFFSET и LIMIT പേജ് ചെയ്ത അന്വേഷണങ്ങൾ നടത്താൻ. എംവിപിയിലും (മിനിമം പ്രാപ്യമായ ഉൽപ്പന്നം) ചെറിയ അളവിലുള്ള ഡാറ്റ ഉപയോഗിക്കുന്ന പ്രോജക്റ്റുകളിലും ഈ സമീപനം തികച്ചും ബാധകമാണ്. ഇത് "വെറും പ്രവർത്തിക്കുന്നു", അങ്ങനെ സംസാരിക്കാൻ.

എന്നാൽ ആദ്യം മുതൽ നിങ്ങൾക്ക് വിശ്വസനീയവും കാര്യക്ഷമവുമായ സിസ്റ്റങ്ങൾ സൃഷ്ടിക്കണമെങ്കിൽ, അത്തരം സിസ്റ്റങ്ങളിൽ ഉപയോഗിക്കുന്ന ഡാറ്റാബേസുകൾ അന്വേഷിക്കുന്നതിന്റെ കാര്യക്ഷമതയെക്കുറിച്ച് നിങ്ങൾ മുൻകൂട്ടി ശ്രദ്ധിക്കണം.

പേജ് ചെയ്‌ത ക്വറി എഞ്ചിനുകളുടെ സാധാരണയായി ഉപയോഗിക്കുന്ന (വളരെ മോശമായ) നിർവ്വഹണത്തിലെ പ്രശ്‌നങ്ങളെക്കുറിച്ചും അത്തരം അന്വേഷണങ്ങൾ എക്‌സിക്യൂട്ട് ചെയ്യുമ്പോൾ ഉയർന്ന പ്രകടനം എങ്ങനെ നേടാമെന്നതിനെക്കുറിച്ചും ഇന്ന് നമ്മൾ സംസാരിക്കും.

OFFSET, LIMIT എന്നിവയിൽ എന്താണ് തെറ്റ്?

ഇതിനകം പറഞ്ഞതുപോലെ, OFFSET и LIMIT വലിയ അളവിലുള്ള ഡാറ്റ ഉപയോഗിച്ച് പ്രവർത്തിക്കേണ്ട ആവശ്യമില്ലാത്ത പ്രോജക്റ്റുകളിൽ അവർ നന്നായി പ്രവർത്തിക്കുന്നു.

ഡാറ്റാബേസ് സെർവറിന്റെ മെമ്മറിയിൽ ചേരാത്ത വലുപ്പത്തിലേക്ക് വളരുമ്പോഴാണ് പ്രശ്നം ഉണ്ടാകുന്നത്. എന്നിരുന്നാലും, ഈ ഡാറ്റാബേസിൽ പ്രവർത്തിക്കുമ്പോൾ, നിങ്ങൾ പേജ് ചെയ്ത ചോദ്യങ്ങൾ ഉപയോഗിക്കേണ്ടതുണ്ട്.

ഈ പ്രശ്‌നം സ്വയം പ്രകടമാകുന്നതിന്, ഓരോ പേജ് ചെയ്‌ത അന്വേഷണത്തിലും കാര്യക്ഷമമല്ലാത്ത ഫുൾ ടേബിൾ സ്കാൻ പ്രവർത്തനത്തിലേക്ക് 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 മടങ്ങ് കൂടുതൽ സമയമെടുക്കുമെന്ന് ഇത് മാറുന്നു (ഈ സമയം ഓട്ടം മുതൽ റൺ വരെ വ്യത്യാസപ്പെടുന്നു; ഉദാഹരണത്തിന്, ആദ്യ ചോദ്യം പൂർത്തിയാക്കാൻ 37 എംഎസ് എടുത്തതായി സിസ്റ്റം റിപ്പോർട്ട് ചെയ്തേക്കാം, പക്ഷേ അതിന്റെ നിർവ്വഹണം രണ്ടാമത്തേത് - 1 എംഎസ്).

കൂടുതൽ ഡാറ്റ ഉണ്ടെങ്കിൽ, എല്ലാം കൂടുതൽ മോശമായി കാണപ്പെടും (ഇത് ബോധ്യപ്പെടാൻ, എന്റെ കാര്യം നോക്കുക ഉദാഹരണം 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