തിരയൽ ഫലങ്ങളുടെ ഔട്ട്പുട്ടും പ്രകടന പ്രശ്നങ്ങളും

നമുക്ക് പരിചിതമായ എല്ലാ ആപ്ലിക്കേഷനുകളിലെയും സാധാരണ സാഹചര്യങ്ങളിലൊന്ന് ചില മാനദണ്ഡങ്ങൾക്കനുസൃതമായി ഡാറ്റ തിരയുകയും വായിക്കാൻ എളുപ്പമുള്ള രൂപത്തിൽ പ്രദർശിപ്പിക്കുകയും ചെയ്യുക എന്നതാണ്. അടുക്കുന്നതിനും ഗ്രൂപ്പുചെയ്യുന്നതിനും പേജിംഗ് ചെയ്യുന്നതിനുമുള്ള അധിക ഓപ്‌ഷനുകളും ഉണ്ടായിരിക്കാം. ടാസ്ക്, സൈദ്ധാന്തികമായി, നിസ്സാരമാണ്, എന്നാൽ അത് പരിഹരിക്കുമ്പോൾ, പല ഡവലപ്പർമാരും നിരവധി തെറ്റുകൾ വരുത്തുന്നു, അത് പിന്നീട് ഉൽപ്പാദനക്ഷമതയെ ബാധിക്കും. ഈ പ്രശ്നം പരിഹരിക്കുന്നതിനുള്ള വിവിധ ഓപ്ഷനുകൾ പരിഗണിക്കാനും ഏറ്റവും ഫലപ്രദമായ നടപ്പാക്കൽ തിരഞ്ഞെടുക്കുന്നതിനുള്ള ശുപാർശകൾ രൂപപ്പെടുത്താനും ശ്രമിക്കാം.

പേജിംഗ് ഓപ്ഷൻ #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.

ചോദ്യം മുഴുവൻ സൂചികയിലൂടെ കടന്നുപോകുന്നത് ആശ്ചര്യകരമല്ല, കാരണം സബ്ടോട്ടൽ ഫീൽഡ് ആദ്യ സ്ഥാനത്തല്ല, അതിനാൽ അന്വേഷണത്തിന് അത് ഉപയോഗിക്കാൻ കഴിയില്ല. സബ്ടോട്ടൽ ഫീൽഡിൽ മറ്റൊരു സൂചിക ചേർത്തുകൊണ്ട് പ്രശ്നം പരിഹരിക്കപ്പെടുന്നു, അതിൻ്റെ ഫലമായി ഇത് 48 ലോജിക്കൽ റീഡുകൾ മാത്രം നൽകുന്നു.

അളവ് കണക്കാക്കുന്നതിനുള്ള അഭ്യർത്ഥനകളുടെ കുറച്ച് ഉദാഹരണങ്ങൾ നിങ്ങൾക്ക് നൽകാം, പക്ഷേ സാരാംശം അതേപടി തുടരുന്നു: ഡാറ്റയുടെ ഒരു ഭാഗം സ്വീകരിക്കുന്നതും മൊത്തം തുക കണക്കാക്കുന്നതും അടിസ്ഥാനപരമായി വ്യത്യസ്തമായ രണ്ട് അഭ്യർത്ഥനകളാണ്, ഒപ്റ്റിമൈസേഷനായി ഓരോന്നിനും അതിൻ്റേതായ നടപടികൾ ആവശ്യമാണ്. പൊതുവേ, രണ്ട് ചോദ്യങ്ങൾക്കും തുല്യമായി പ്രവർത്തിക്കുന്ന സൂചികകളുടെ സംയോജനം നിങ്ങൾക്ക് കണ്ടെത്താൻ കഴിയില്ല.

അതനുസരിച്ച്, അത്തരമൊരു തിരയൽ പരിഹാരം വികസിപ്പിക്കുമ്പോൾ വ്യക്തമാക്കേണ്ട പ്രധാന ആവശ്യകതകളിലൊന്ന്, കണ്ടെത്തിയ വസ്തുക്കളുടെ ആകെ എണ്ണം കാണുന്നത് ഒരു ബിസിനസ്സിന് ശരിക്കും പ്രധാനമാണോ എന്നതാണ്. ഇല്ല എന്ന് പലപ്പോഴും സംഭവിക്കാറുണ്ട്. നിർദ്ദിഷ്‌ട പേജ് നമ്പറുകൾ വഴിയുള്ള നാവിഗേഷൻ, എൻ്റെ അഭിപ്രായത്തിൽ, വളരെ ഇടുങ്ങിയ സ്കോപ്പുള്ള ഒരു പരിഹാരമാണ്, കാരണം മിക്ക പേജിംഗ് സാഹചര്യങ്ങളും "അടുത്ത പേജിലേക്ക് പോകുക" പോലെയാണ്.

പേജിംഗ് ഓപ്ഷൻ #2

കണ്ടെത്തിയ വസ്തുക്കളുടെ ആകെ എണ്ണം അറിയുന്നതിൽ ഉപയോക്താക്കൾ ശ്രദ്ധിക്കുന്നില്ലെന്ന് നമുക്ക് അനുമാനിക്കാം. തിരയൽ പേജ് ലളിതമാക്കാൻ ശ്രമിക്കാം:

വാസ്തവത്തിൽ, മാറിയ ഒരേയൊരു കാര്യം നിർദ്ദിഷ്‌ട പേജ് നമ്പറുകളിലേക്ക് നാവിഗേറ്റ് ചെയ്യാൻ ഒരു മാർഗവുമില്ല എന്നതാണ്, ഇപ്പോൾ ഈ പട്ടിക പ്രദർശിപ്പിക്കുന്നതിന് എത്ര എണ്ണം ഉണ്ടെന്ന് അറിയേണ്ടതില്ല. എന്നാൽ ചോദ്യം ഉയർന്നുവരുന്നു - അടുത്ത പേജിനായി ("അടുത്തത്" ലിങ്ക് ശരിയായി പ്രദർശിപ്പിക്കുന്നതിന്) ഡാറ്റ ഉണ്ടെങ്കിൽ പട്ടികയ്ക്ക് എങ്ങനെ അറിയാം?

ഉത്തരം വളരെ ലളിതമാണ്: നിങ്ങൾക്ക് ഡാറ്റാബേസിൽ നിന്ന് ഡിസ്പ്ലേയ്ക്ക് ആവശ്യമുള്ളതിനേക്കാൾ ഒരു റെക്കോർഡ് കൂടി വായിക്കാൻ കഴിയും, കൂടാതെ ഈ "അധിക" റെക്കോർഡിൻ്റെ സാന്നിധ്യം അടുത്ത ഭാഗം ഉണ്ടോ എന്ന് കാണിക്കും. ഈ രീതിയിൽ, ഒരു പേജ് ഡാറ്റ ലഭിക്കുന്നതിന് നിങ്ങൾ ഒരു അഭ്യർത്ഥന മാത്രം പ്രവർത്തിപ്പിക്കേണ്ടതുണ്ട്, ഇത് പ്രകടനത്തെ ഗണ്യമായി മെച്ചപ്പെടുത്തുകയും അത്തരം പ്രവർത്തനങ്ങളെ പിന്തുണയ്ക്കുന്നത് എളുപ്പമാക്കുകയും ചെയ്യുന്നു. എൻ്റെ പരിശീലനത്തിൽ, മൊത്തം റെക്കോർഡുകളുടെ എണ്ണം കണക്കാക്കാൻ വിസമ്മതിച്ചപ്പോൾ ഫലങ്ങളുടെ ഡെലിവറി 4-5 മടങ്ങ് വേഗത്തിലാക്കി.

ഈ സമീപനത്തിന് നിരവധി ഉപയോക്തൃ ഇൻ്റർഫേസ് ഓപ്‌ഷനുകൾ ഉണ്ട്: "ബാക്ക്", "ഫോർവേഡ്" കമാൻഡുകൾ, മുകളിലെ ഉദാഹരണത്തിലെന്നപോലെ, ഒരു "ലോഡ് മോർ" ബട്ടൺ, ഇത് പ്രദർശിപ്പിച്ച ഫലങ്ങളിലേക്ക് ഒരു പുതിയ ഭാഗം ചേർക്കുന്നു, "അനന്തമായ സ്ക്രോൾ", അത് പ്രവർത്തിക്കുന്നു. "കൂടുതൽ ലോഡുചെയ്യുക" " എന്ന തത്വമനുസരിച്ച്, എന്നാൽ അടുത്ത ഭാഗം ലഭിക്കുന്നതിനുള്ള സിഗ്നൽ ഉപയോക്താവിന് പ്രദർശിപ്പിച്ച എല്ലാ ഫലങ്ങളും അവസാനം വരെ സ്ക്രോൾ ചെയ്യുക എന്നതാണ്. വിഷ്വൽ സൊല്യൂഷൻ എന്തായാലും, ഡാറ്റ സാമ്പിളിൻ്റെ തത്വം അതേപടി തുടരുന്നു.

പേജിംഗ് നടപ്പിലാക്കുന്നതിൻ്റെ സൂക്ഷ്മതകൾ

മുകളിൽ നൽകിയിരിക്കുന്ന എല്ലാ ചോദ്യോദാഹരണങ്ങളും "ഓഫ്‌സെറ്റ് + കൗണ്ട്" സമീപനം ഉപയോഗിക്കുന്നു, ചോദ്യം തന്നെ ഏത് ക്രമത്തിലാണ് ഫല വരികളും എത്ര വരികൾ തിരികെ നൽകേണ്ടതെന്നും വ്യക്തമാക്കുമ്പോൾ. ആദ്യം, ഈ കേസിൽ പാരാമീറ്റർ പാസിംഗ് എങ്ങനെ മികച്ച രീതിയിൽ സംഘടിപ്പിക്കാമെന്ന് നോക്കാം. പ്രായോഗികമായി, ഞാൻ നിരവധി രീതികൾ കണ്ടു:

• അഭ്യർത്ഥിച്ച പേജിൻ്റെ സീരിയൽ നമ്പർ (പേജ് ഇൻഡെക്സ്), പേജ് വലുപ്പം (പേജ് വലുപ്പം).
• തിരികെ നൽകേണ്ട ആദ്യ റെക്കോർഡിൻ്റെ സീരിയൽ നമ്പർ (ആരംഭ സൂചിക), ഫലത്തിലെ പരമാവധി റെക്കോർഡുകളുടെ എണ്ണം (എണ്ണം).
• റിട്ടേൺ ചെയ്യേണ്ട ആദ്യത്തെ റെക്കോർഡിൻ്റെ സീക്വൻസ് നമ്പർ (ആരംഭ സൂചിക), അവസാനം റിട്ടേൺ ചെയ്യേണ്ട റെക്കോർഡിൻ്റെ സീക്വൻസ് നമ്പർ (endIndex).

ഒറ്റനോട്ടത്തിൽ ഇത് വളരെ പ്രാഥമികമാണെന്ന് തോന്നാം, വ്യത്യാസമില്ല. എന്നാൽ ഇത് അങ്ങനെയല്ല - ഏറ്റവും സൗകര്യപ്രദവും സാർവത്രികവുമായ ഓപ്ഷൻ രണ്ടാമത്തേതാണ് (ആരംഭ സൂചിക, എണ്ണം). ഇതിന് നിരവധി കാരണങ്ങളുണ്ട്:

• മുകളിൽ നൽകിയിരിക്കുന്ന +1 എൻട്രി പ്രൂഫ് റീഡിംഗ് സമീപനത്തിന്, പേജ് ഇൻഡക്സും പേജ് വലുപ്പവും ഉള്ള ആദ്യ ഓപ്ഷൻ വളരെ അസൗകര്യമാണ്. ഉദാഹരണത്തിന്, ഒരു പേജിന് 50 പോസ്റ്റുകൾ പ്രദർശിപ്പിക്കാൻ ഞങ്ങൾ ആഗ്രഹിക്കുന്നു. മുകളിലുള്ള അൽഗോരിതം അനുസരിച്ച്, നിങ്ങൾ ആവശ്യമുള്ളതിനേക്കാൾ ഒരു റെക്കോർഡ് കൂടി വായിക്കേണ്ടതുണ്ട്. ഈ “+1” സെർവറിൽ നടപ്പിലാക്കിയില്ലെങ്കിൽ, ആദ്യ പേജിനായി ഞങ്ങൾ 1 മുതൽ 51 വരെയും രണ്ടാമത്തേതിന് - 51 മുതൽ 101 വരെയും റെക്കോർഡുകൾ അഭ്യർത്ഥിക്കണമെന്ന് ഇത് മാറുന്നു. നിങ്ങൾ 51-ൻ്റെ പേജ് വലുപ്പം വ്യക്തമാക്കുകയും പേജ് സൂചിക വർദ്ധിപ്പിക്കുകയും ചെയ്താൽ, രണ്ടാമത്തെ പേജ് 52-ൽ നിന്ന് 102-ലേക്ക് മടങ്ങും. അതനുസരിച്ച്, ആദ്യ ഓപ്ഷനിൽ, അടുത്ത പേജിലേക്ക് പോകാൻ ഒരു ബട്ടൺ ശരിയായി നടപ്പിലാക്കുന്നതിനുള്ള ഒരേയൊരു മാർഗ്ഗം സെർവർ "അധിക" ലൈൻ പ്രൂഫ് റീഡ് ചെയ്യുക എന്നതാണ്, അത് വളരെ വ്യക്തമായ സൂക്ഷ്മതയായിരിക്കും.
• മൂന്നാമത്തെ ഓപ്‌ഷനിൽ അർത്ഥമില്ല, കാരണം മിക്ക ഡാറ്റാബേസുകളിലും ചോദ്യങ്ങൾ പ്രവർത്തിപ്പിക്കുന്നതിന്, അവസാന റെക്കോർഡിൻ്റെ സൂചികയേക്കാൾ നിങ്ങൾ ഇപ്പോഴും എണ്ണം പാസാക്കേണ്ടതുണ്ട്. endIndex-ൽ നിന്ന് startIndex കുറയ്ക്കുന്നത് ഒരു ലളിതമായ ഗണിത പ്രവർത്തനമായിരിക്കാം, എന്നാൽ ഇവിടെ അത് അധികമാണ്.

"ഓഫ്‌സെറ്റ് + അളവ്" വഴി പേജിംഗ് നടപ്പിലാക്കുന്നതിൻ്റെ ദോഷങ്ങൾ ഇപ്പോൾ നമ്മൾ വിവരിക്കണം:

• തുടർന്നുള്ള ഓരോ പേജും വീണ്ടെടുക്കുന്നത് മുമ്പത്തേതിനേക്കാൾ ചെലവേറിയതും വേഗത കുറഞ്ഞതുമായിരിക്കും, കാരണം ഡാറ്റാബേസ് തിരയലിനും സോർട്ടിംഗ് മാനദണ്ഡത്തിനും അനുസൃതമായി "ആരംഭം മുതൽ" എല്ലാ റെക്കോർഡുകളിലൂടെയും കടന്നുപോകേണ്ടതുണ്ട്, തുടർന്ന് ആവശ്യമുള്ള ശകലത്തിൽ നിർത്തുക.
• എല്ലാ DBMS-കൾക്കും ഈ സമീപനത്തെ പിന്തുണയ്ക്കാൻ കഴിയില്ല.

ഇതരമാർഗങ്ങളുണ്ട്, പക്ഷേ അവയും അപൂർണ്ണമാണ്. ഈ സമീപനങ്ങളിൽ ആദ്യത്തേതിനെ "കീസെറ്റ് പേജിംഗ്" അല്ലെങ്കിൽ "സീക്ക് മെത്തേഡ്" എന്ന് വിളിക്കുന്നു, അത് ഇപ്രകാരമാണ്: ഒരു ഭാഗം ലഭിച്ചതിന് ശേഷം, പേജിലെ അവസാന റെക്കോർഡിലെ ഫീൽഡ് മൂല്യങ്ങൾ നിങ്ങൾക്ക് ഓർമ്മിക്കാം, തുടർന്ന് അവ നേടുന്നതിന് അവ ഉപയോഗിക്കുക അടുത്ത ഭാഗം. ഉദാഹരണത്തിന്, ഞങ്ങൾ ഇനിപ്പറയുന്ന ചോദ്യം റൺ ചെയ്തു:

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

അവസാന റെക്കോർഡിൽ ഞങ്ങൾക്ക് ഓർഡർ തീയതി മൂല്യം '2014-06-29' ലഭിച്ചു. അടുത്ത പേജ് ലഭിക്കുന്നതിന് നിങ്ങൾക്ക് ഇത് ചെയ്യാൻ ശ്രമിക്കാം:

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-കളിലും ഇത് പിന്തുണയ്ക്കുന്നില്ല; തത്ഫലമായുണ്ടാകുന്ന അടുത്ത-ചങ്ക് ഐഡൻ്റിഫയറിന് പരിമിതമായ ആയുസ്സ് ഉണ്ടായിരിക്കാം, ഇത് ഉപയോക്തൃ ഇടപെടൽ നടപ്പിലാക്കുന്നതിന് പൊതുവെ അനുയോജ്യമല്ല (ഇലാസ്റ്റിക് സെർച്ച് സ്ക്രോൾ API പോലുള്ളവ).

സങ്കീർണ്ണമായ ഫിൽട്ടറിംഗ്

നമുക്ക് ചുമതല കൂടുതൽ സങ്കീർണ്ണമാക്കാം. ഓൺലൈൻ സ്റ്റോറുകളിൽ നിന്ന് എല്ലാവർക്കും വളരെ പരിചിതമായ, മുഖാമുഖ തിരയൽ എന്ന് വിളിക്കപ്പെടുന്നവ നടപ്പിലാക്കാൻ ഒരു ആവശ്യകതയുണ്ടെന്ന് കരുതുക. ഓർഡറുകൾ പട്ടികയെ അടിസ്ഥാനമാക്കിയുള്ള മുകളിലുള്ള ഉദാഹരണങ്ങൾ ഈ സാഹചര്യത്തിൽ വളരെ ചിത്രീകരണമല്ല, അതിനാൽ നമുക്ക് AdventureWorks ഡാറ്റാബേസിൽ നിന്ന് ഉൽപ്പന്ന പട്ടികയിലേക്ക് മാറാം:

മുഖാന്വേഷണത്തിന് പിന്നിലെ ആശയം എന്താണ്? ഓരോ ഫിൽട്ടർ ഘടകത്തിനും ഈ മാനദണ്ഡം പാലിക്കുന്ന റെക്കോർഡുകളുടെ എണ്ണം കാണിക്കുന്നു എന്നതാണ് വസ്തുത മറ്റെല്ലാ വിഭാഗങ്ങളിലും തിരഞ്ഞെടുത്ത ഫിൽട്ടറുകൾ കണക്കിലെടുക്കുന്നു.

ഉദാഹരണത്തിന്, ഞങ്ങൾ ഈ ഉദാഹരണത്തിൽ ബൈക്കുകളുടെ വിഭാഗവും കറുപ്പ് നിറവും തിരഞ്ഞെടുക്കുകയാണെങ്കിൽ, പട്ടിക കറുത്ത ബൈക്കുകൾ മാത്രമേ കാണിക്കൂ, പക്ഷേ:

• വിഭാഗങ്ങളുടെ ഗ്രൂപ്പിലെ ഓരോ മാനദണ്ഡത്തിനും, ആ വിഭാഗത്തിൽ നിന്നുള്ള ഉൽപ്പന്നങ്ങളുടെ എണ്ണം കറുപ്പിൽ കാണിക്കും.
• "നിറങ്ങൾ" ഗ്രൂപ്പിൻ്റെ ഓരോ മാനദണ്ഡത്തിനും, ഈ നിറത്തിൻ്റെ സൈക്കിളുകളുടെ എണ്ണം കാണിക്കും.

അത്തരം വ്യവസ്ഥകൾക്കുള്ള ഫല ഔട്ട്പുട്ടിൻ്റെ ഒരു ഉദാഹരണം ഇതാ:

നിങ്ങൾ "വസ്ത്രം" വിഭാഗവും പരിശോധിക്കുകയാണെങ്കിൽ, സ്റ്റോക്കിലുള്ള കറുത്ത വസ്ത്രങ്ങളും പട്ടിക കാണിക്കും. "കളർ" വിഭാഗത്തിലെ കറുത്ത ഉൽപ്പന്നങ്ങളുടെ എണ്ണവും പുതിയ വ്യവസ്ഥകൾക്കനുസരിച്ച് വീണ്ടും കണക്കാക്കും, "വിഭാഗങ്ങൾ" വിഭാഗത്തിൽ മാത്രം ഒന്നും മാറില്ല... സാധാരണ മുഖമുള്ള തിരയൽ അൽഗോരിതം മനസ്സിലാക്കാൻ ഈ ഉദാഹരണങ്ങൾ മതിയെന്ന് ഞാൻ പ്രതീക്ഷിക്കുന്നു.

ഇനി ഇത് എങ്ങനെ ആപേക്ഷിക അടിസ്ഥാനത്തിൽ നടപ്പിലാക്കാം എന്ന് നമുക്ക് ഊഹിക്കാം. വിഭാഗവും വർണ്ണവും പോലെയുള്ള ഓരോ ഗ്രൂപ്പിനും ഒരു പ്രത്യേക ചോദ്യം ആവശ്യമാണ്:

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