🥇खोज परिणाम आउटपुट और प्रदर्शन समस्याएं

हम जिन सभी अनुप्रयोगों का उपयोग करते हैं, उनमें एक सामान्य परिदृश्य यह होता है कि कुछ निश्चित मानदंडों के अनुसार डेटा की खोज की जाती है और उसे ऐसे रूप में प्रदर्शित किया जाता है जिसे पढ़ना आसान हो। इसमें सॉर्टिंग, समूहीकरण और पृष्ठांकन के लिए अतिरिक्त विकल्प भी हो सकते हैं। सिद्धांततः यह कार्य छोटा है, लेकिन इसे हल करते समय कई डेवलपर्स कई गलतियां कर देते हैं, जिसके कारण बाद में प्रदर्शन में हानि होती है। आइए इस समस्या को हल करने के लिए विभिन्न विकल्पों पर विचार करने का प्रयास करें और सबसे प्रभावी कार्यान्वयन चुनने के लिए सिफारिशें तैयार करें।

पेजिंग विकल्प #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 फ़ील्ड में एक और इंडेक्स जोड़कर किया जाता है, और इसके परिणामस्वरूप केवल 48 तार्किक रीड्स प्राप्त होते हैं।

गिनती संबंधी प्रश्नों के कई और उदाहरण दिए जा सकते हैं, लेकिन सार वही रहता है: डेटा का एक हिस्सा प्राप्त करना और कुल राशि की गणना करना दो मौलिक रूप से अलग-अलग अनुरोध हैं, और प्रत्येक को अनुकूलन के लिए अपने स्वयं के उपायों की आवश्यकता होती है। सामान्यतः, ऐसे अनुक्रमितों का संयोजन खोजना संभव नहीं होगा जो दोनों प्रश्नों के लिए समान रूप से काम करें।

तदनुसार, इस तरह के खोज समाधान को विकसित करते समय स्पष्ट की जाने वाली महत्वपूर्ण आवश्यकताओं में से एक यह है कि क्या व्यवसाय के लिए पाई गई वस्तुओं की कुल संख्या देखना वास्तव में महत्वपूर्ण है। अक्सर ऐसा होता है कि नहीं. और विशिष्ट पृष्ठ संख्याओं द्वारा नेविगेशन, मेरी राय में, आवेदन के बहुत ही संकीर्ण दायरे वाला समाधान है, क्योंकि अधिकांश पेजिंग परिदृश्य "अगले पृष्ठ पर जाएं" जैसे दिखते हैं।

पेजिंग विकल्प #2

आइए हम यह मान लें कि उपयोगकर्ताओं को मिली वस्तुओं की कुल संख्या जानने की परवाह नहीं है। आइये खोज पृष्ठ को सरल बनाने का प्रयास करें:

वास्तव में, केवल एक चीज बदली है, वह यह कि विशिष्ट पृष्ठ संख्याओं तक जाने का कोई तरीका नहीं है, तथा अब इस तालिका को यह जानने की आवश्यकता नहीं है कि उन्हें प्रदर्शित करने के लिए कुल कितने पृष्ठ हैं। लेकिन सवाल यह उठता है - तालिका को कैसे पता चलेगा कि अगले पृष्ठ के लिए डेटा है ('अगला' लिंक को सही ढंग से प्रदर्शित करने के लिए)?

इसका उत्तर बहुत सरल है: आप डेटाबेस से प्रदर्शन के लिए आवश्यक रिकॉर्ड से एक अतिरिक्त रिकॉर्ड पढ़ सकते हैं, और इस "अतिरिक्त" रिकॉर्ड की उपस्थिति यह बताएगी कि अगला भाग मौजूद है या नहीं। इसका मतलब यह है कि डेटा के एक पृष्ठ को पुनः प्राप्त करने के लिए, आपको केवल एक क्वेरी करने की आवश्यकता है, जिससे प्रदर्शन में काफी सुधार होता है और ऐसी कार्यक्षमता का समर्थन करना आसान हो जाता है। मेरे व्यवहार में, एक ऐसा मामला आया जब रिकॉर्डों की कुल संख्या गिनने से इनकार करने पर परिणाम जारी करने में 4-5 गुना देरी हो गई।

इस दृष्टिकोण के लिए कई उपयोगकर्ता इंटरफ़ेस विकल्प हैं: "वापस" और "आगे" आदेश, जैसा कि ऊपर दिए गए उदाहरण में है, एक "अधिक लोड करें" बटन जो प्रदर्शित परिणामों में एक नया बैच जोड़ता है, "अनंत स्क्रॉलिंग" जो "अधिक लोड करें" सिद्धांत पर काम करता है, लेकिन अगला बैच प्राप्त करने का संकेत तब मिलता है जब उपयोगकर्ता सभी प्रदर्शित परिणामों के अंत तक स्क्रॉल करता है। दृश्य समाधान चाहे जो भी हो, डेटा चयन का सिद्धांत एक ही रहता है।

पेजिंग कार्यान्वयन की बारीकियाँ

उपरोक्त सभी क्वेरी उदाहरण "ऑफ़सेट + काउंट" दृष्टिकोण का उपयोग करते हैं, जहां क्वेरी स्वयं निर्दिष्ट करती है कि परिणाम क्रम में कौन सी पंक्ति लौटानी है और कितनी पंक्तियाँ लौटानी हैं। सबसे पहले, आइए देखें कि इस मामले में मापदंडों के हस्तांतरण को सर्वोत्तम तरीके से कैसे व्यवस्थित किया जाए। व्यवहार में, मुझे कई विधियाँ देखने को मिली हैं:

अनुरोधित पृष्ठ की क्रम संख्या (pageIndex), पृष्ठ आकार (pageSize).
लौटाए जाने वाले प्रथम रिकॉर्ड की क्रमिक संख्या (startIndex), परिणाम में रिकॉर्डों की अधिकतम संख्या (count).
लौटाए जाने वाले प्रथम रिकॉर्ड की क्रमिक संख्या (startIndex), लौटाए जाने वाले अंतिम रिकॉर्ड की क्रमिक संख्या (endIndex).

पहली नज़र में ऐसा लग सकता है कि यह इतना प्राथमिक है कि इसमें कोई अंतर नहीं है। लेकिन ऐसा नहीं है - सबसे सुविधाजनक और सार्वभौमिक विकल्प दूसरा है (startIndex, count)। इसके अनेक कारण हैं:

ऊपर दिए गए +1 रिकॉर्ड पढ़ने के दृष्टिकोण के लिए, pageIndex और pageSize वाला पहला विकल्प अत्यंत असुविधाजनक है। उदाहरण के लिए, हम प्रति पृष्ठ 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)" के रूप में लिखा जा सकता है। इन दो फ़ील्डों वाली एक संयुक्त कुंजी दिए जाने पर, ऐसी क्वेरी काफी आसान होनी चाहिए।

दूसरा वैकल्पिक दृष्टिकोण, उदाहरण के लिए, पाया जा सकता है इलास्टिकसर्च स्क्रॉल एपीआई या कॉसमॉस डीबी — जब कोई अनुरोध, डेटा के अतिरिक्त, एक विशेष पहचानकर्ता लौटाता है जिसका उपयोग डेटा के अगले भाग को प्राप्त करने के लिए किया जा सकता है। यदि इस पहचानकर्ता का जीवनकाल असीमित है (जैसे कॉमसोस डीबी में), तो यह पृष्ठों के बीच अनुक्रमिक संक्रमण के साथ पेजिंग को लागू करने का एक शानदार तरीका है (ऊपर उल्लिखित विकल्प #2)। इसके संभावित नुकसान: यह सभी DBMS द्वारा समर्थित नहीं है; अगले भाग के प्राप्त पहचानकर्ता का जीवनकाल सीमित हो सकता है, जो आमतौर पर उपयोगकर्ता इंटरैक्शन (जैसे इलास्टिक सर्च स्क्रॉल एपीआई) को लागू करने के लिए उपयुक्त नहीं होता है।

जटिल निस्पंदन

आइये, इस कार्य को और जटिल बनाते हैं। मान लीजिए कि तथाकथित फेसिटेड सर्च को लागू करने की आवश्यकता है, जो ऑनलाइन स्टोर्स से जुड़े सभी लोगों को अच्छी तरह से ज्ञात है। ऑर्डर तालिका पर आधारित उपरोक्त उदाहरण इस मामले में बहुत सांकेतिक नहीं हैं, इसलिए आइए AdventureWorks डेटाबेस से Product तालिका पर जाएं:

मुखाग्र खोज के पीछे क्या विचार है? इसमें प्रत्येक फ़िल्टर तत्व के लिए इस मानदंड से मेल खाने वाले रिकॉर्ड की संख्या दर्शाई गई है अन्य सभी श्रेणियों में चयनित फ़िल्टर को ध्यान में रखते हुए.

उदाहरण के लिए, यदि हम इस उदाहरण में बाइक श्रेणी और काला रंग चुनते हैं, तो तालिका केवल काली बाइक ही प्रदर्शित करेगी, लेकिन:

"श्रेणियाँ" समूह में प्रत्येक मानदंड के लिए, उस श्रेणी के उत्पादों की संख्या काले रंग में दिखाई जाएगी।
"रंग" समूह में प्रत्येक मानदंड के लिए, उस रंग की साइकिलों की संख्या दर्शाई जाएगी।

ऐसी स्थितियों के लिए आउटपुट का एक उदाहरण यहां दिया गया है:

यदि आप "वस्त्र" श्रेणी को भी चिह्नित करते हैं, तो तालिका में उपलब्ध काले कपड़े भी दिखाए जाएंगे। "रंग" अनुभाग में काले उत्पादों की संख्या भी नई शर्तों के अनुसार पुनर्गणना की जाएगी, लेकिन "श्रेणियां" अनुभाग में कुछ भी नहीं बदलेगा... मुझे उम्मीद है कि ये उदाहरण मुखाग्र खोज के सामान्य एल्गोरिथ्म को समझने के लिए पर्याप्त हैं।

अब आइए कल्पना करें कि इसे रिलेशनल डेटाबेस पर कैसे क्रियान्वित किया जा सकता है। मानदंड के प्रत्येक समूह, जैसे श्रेणी और रंग, के लिए अलग से प्रश्न की आवश्यकता होगी:

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 रिकॉर्ड मिले, दिखाएं?" उपयोगकर्ता या तो खोज शर्तों को बदलना जारी रख सकता है या "दिखाएँ" बटन पर क्लिक कर सकता है। केवल दूसरे मामले में ही परिणाम प्राप्त करने और सभी "पहलू" पर मात्राओं की पुनर्गणना करने के सभी अनुरोध निष्पादित किए जाएंगे। इस मामले में, जैसा कि आप आसानी से देख सकते हैं, आपको परिणामों की कुल संख्या और उसके अनुकूलन प्राप्त करने के अनुरोध से निपटना होगा। यह विधि कई छोटे ऑनलाइन स्टोरों में पाई जा सकती है। जाहिर है कि यह इस समस्या का रामबाण इलाज नहीं है, लेकिन साधारण मामलों में यह एक अच्छा समझौता हो सकता है।
परिणामों को खोजने और पहलुओं की गणना करने के लिए किसी खोज इंजन का उपयोग करें, जैसे कि सोलर, इलास्टिकसर्च, स्फिंक्स, और अन्य। उन सभी को "पहलू" बनाने के लिए डिज़ाइन किया गया है और उल्टे सूचकांक के कारण वे ऐसा काफी प्रभावी ढंग से करते हैं। खोज इंजन किस प्रकार संरचित होते हैं, ऐसे मामलों में वे सामान्य प्रयोजन वाले डाटाबेसों की तुलना में अधिक प्रभावी क्यों होते हैं, उनमें क्या-क्या प्रथाएं और खामियां हैं - यह एक अलग लेख का विषय है। यहां मैं इस तथ्य की ओर ध्यान आकर्षित करना चाहूंगा कि खोज इंजन मुख्य डेटा भंडारण का प्रतिस्थापन नहीं हो सकता है; इसका उपयोग एक अतिरिक्त के रूप में किया जाता है: मुख्य डेटाबेस में कोई भी परिवर्तन जो खोज के लिए महत्वपूर्ण हैं, उन्हें खोज सूचकांक में सिंक्रनाइज़ किया जाता है; खोज तंत्र आमतौर पर केवल खोज इंजन के साथ ही बातचीत करता है और मुख्य डाटाबेस तक नहीं पहुंचता है। यहां सबसे महत्वपूर्ण बिंदु यह है कि इस समन्वयन को विश्वसनीय ढंग से कैसे व्यवस्थित किया जाए। यह सब "प्रतिक्रिया समय" की आवश्यकताओं पर निर्भर करता है। यदि मुख्य डेटाबेस में परिवर्तन और खोज में उसके “प्रकटीकरण” के बीच का समय महत्वपूर्ण नहीं है, तो आप एक ऐसी सेवा बना सकते हैं जो हर कुछ मिनटों में हाल ही में बदले गए रिकॉर्डों की खोज करती है और उन्हें अनुक्रमित करती है। यदि आपको न्यूनतम संभव प्रतिक्रिया समय चाहिए, तो आप कुछ इस प्रकार कार्यान्वित कर सकते हैं लेन-देन आउटबॉक्स खोज सेवा को अद्यतन भेजने के लिए.

निष्कर्ष

सर्वर-साइड पेजिंग को क्रियान्वित करना एक बड़ी जटिलता है और यह केवल तेजी से बढ़ते या बड़े डेटा सेटों के लिए ही उपयुक्त है। "बड़े" या "तेजी से बढ़ते" का मूल्यांकन करने के लिए कोई निश्चित नुस्खा नहीं है, लेकिन मैं इस दृष्टिकोण पर कायम रहूंगा:
- यदि सर्वर समय और नेटवर्क ट्रांसमिशन को ध्यान में रखते हुए डेटा का पूर्ण संग्रह प्राप्त करना सामान्य रूप से प्रदर्शन आवश्यकताओं को पूरा करता है, तो सर्वर साइड पर पेजिंग को लागू करने का कोई मतलब नहीं है।
- निकट भविष्य में ऐसी स्थिति हो सकती है जहां प्रदर्शन संबंधी कोई समस्या न हो, क्योंकि डेटा बहुत कम है, लेकिन डेटा संग्रहण लगातार बढ़ रहा है। यदि डेटा का कुछ सेट अंततः पिछले बिंदु को संतुष्ट करना बंद कर दे, तो पेजिंग को तुरंत शामिल करना बेहतर है।
यदि व्यवसाय की ओर से परिणामों की कुल संख्या दिखाने या पृष्ठ संख्या प्रदर्शित करने की कोई सख्त आवश्यकता नहीं है, और साथ ही आपके सिस्टम में खोज इंजन नहीं है, तो इन बिंदुओं को लागू न करना और विकल्प # 2 पर विचार करना बेहतर है।
यदि मुखाग्र खोज की स्पष्ट आवश्यकता है, तो आपके पास प्रदर्शन से समझौता किए बिना दो विकल्प हैं:
- खोज मानदंड के प्रत्येक परिवर्तन पर सभी मात्राओं की पुनः गणना न करें।
- सोलर, इलास्टिकसर्च, स्फिंक्स और अन्य जैसे खोज इंजनों का उपयोग करें। लेकिन यह समझना चाहिए कि यह मुख्य डाटाबेस का प्रतिस्थापन नहीं हो सकता है, तथा इसका उपयोग खोज समस्याओं के समाधान के लिए मुख्य भंडारण के अतिरिक्त के रूप में किया जाना चाहिए।
इसके अलावा, मुखाग्र खोज के मामले में, खोज परिणाम पृष्ठ की पुनर्प्राप्ति और मात्राओं की गणना को दो समानांतर अनुरोधों में विभाजित करना उचित है। मात्राओं की गणना करने में परिणाम प्राप्त करने से अधिक समय लग सकता है, जबकि परिणाम उपयोगकर्ता के लिए अधिक महत्वपूर्ण होते हैं।
यदि आप खोज के लिए SQL डाटाबेस का उपयोग कर रहे हैं, तो इस भाग से संबंधित किसी भी कोड परिवर्तन का, उचित मात्रा में डाटा (जो "लाइव" डाटाबेस की मात्रा से अधिक हो) पर निष्पादन के लिए अच्छी तरह से परीक्षण किया जाना चाहिए। सभी डेटाबेस इंस्टेंसों पर, विशेषकर लाइव इंस्टेंस पर, क्वेरी निष्पादन समय मॉनिटरिंग का उपयोग करना भी उचित है। भले ही विकास स्तर पर क्वेरी योजनाओं के साथ सब कुछ ठीक था, लेकिन डेटा की मात्रा बढ़ने पर स्थिति काफी बदल सकती है।

स्रोत: www.habr.com