SQLite में चुनिंदा प्रश्नों के "प्रदर्शन में सुधार" के लिए गैर-मानक दृष्टिकोण

आपका स्वागत है!

सबसे पहले, मैं 2 अंक नोट करना चाहूंगा:
- यह लेख काम के एल्गोरिथ्म का वर्णन करता है, न कि विशिष्ट एसक्यूएल प्रश्नों का अनुकूलन कैसे करें;
- लेख में वर्णित दृष्टिकोण "उत्पादक" हार्डवेयर के लिए प्रासंगिक नहीं है, हम इस बारे में बात करेंगे कि कैसे हम एंड्रॉइड चलाने वाले बजट स्मार्टफ़ोन पर डेटाबेस के साथ गहनता से काम कर रहे एप्लिकेशन इंटरफ़ेस की "जवाबदेही" को बढ़ाने में कामयाब रहे;

संक्षेप में आवेदन के बारे में

यह स्पष्ट करने के लिए कि क्या दांव पर है, संक्षेप में मैं आवेदन के बारे में खुद ही कहूंगा: यह मोबाइल ट्रेडिंग के आयोजन के लिए एक प्रणाली थी, अधिकांश उपयोगकर्ता बिक्री एजेंट (टीएएस) हैं। जब कोई टीए एजेंट बिक्री के बिंदु पर आता है, तो उसे बहुत जल्दी खोजने की आवश्यकता होती है। माल, गोदामों में उनकी शेष राशि देखें (अंतिम सिंक्रनाइज़ेशन के समय) और ग्राहक के लिए आवश्यक मात्रा पर ध्यान दें। यानी टीए ऑपरेशन एल्गोरिथ्म इस तरह दिखता है:
- उत्पाद 1 ढूंढें;
- नंबर दर्ज करें;
- आइटम 2 खोजें;
- नंबर दर्ज करें;
...

वे इसे बहुत जल्दी करते हैं :)

खोज आवश्यकताएँ

- उत्पाद के नाम से खोजें (और यह रूसी और अंग्रेजी दोनों में हो सकता है);
- प्रत्येक ग्राहक की एक "स्वयं" मूल्य सूची हो सकती है;
- आपको सभी सामानों को देखने में सक्षम होने की आवश्यकता है, और केवल वे जो स्टॉक में हैं;
- इसमें चयनित सभी उपश्रेणियों के साथ चयनित श्रेणी के लिए उत्पादों की सूची को फ़िल्टर करने की क्षमता है;

स्रोत डेटा

मेरे द्वारा बताए गए आंकड़े वास्तविक हैं, अन्यथा मुझे यह सब नहीं करना होता।
ग्राहकों की संख्या: 500
उत्पादों की संख्या: 5000
प्रत्येक ग्राहक को एक व्यक्तिगत मूल्य प्रदान करते समय, हमें मूल्य तालिका में ५००० * ५०० = २ ५०० ००० पंक्तियाँ मिलती हैं।

इस तथ्य के बावजूद कि SQLite बहुत तेज है, इस समस्या को "सिर पर" हल करना संभव नहीं था। या बल्कि यह कहा जाएगा कि सब कुछ काम किया है, लेकिन पर्याप्त तेजी से नहीं।

निर्णय

पहली स्पष्ट बात यह है कि एसक्यूएल क्वेरी गतिशील रूप से उत्पन्न होती है (यदि वे आवश्यक नहीं हैं, तो इसमें से अनावश्यक जोड़ और शर्तों को बाहर करने के लिए)। प्रयोगों के दौरान यह पता चला कि प्रपत्र में तालिकाओं का संघ:

select * from Table1, Table2 where Table1.Table2Id = Table2.Id 

की तुलना में थोड़ा तेज काम करता है:

 select * from Table1 join Table2 on Table1.Table2Id = Table2.Id 

खैर, और एक और, काफी स्वाभाविक क्षण (हालांकि मैंने तुरंत इसके बारे में नहीं सोचा था), यह फॉर्म की एक क्वेरी है:

 select Table1.Id from Table1, Table2 ... TableN where Table1.Table2Id = Table2.Id ... 

की तुलना में बहुत तेज चलेगा:

 select Table1.Id, ... TableN.FieldN from Table1, Table2 ... TableN where Table1.Table2Id = Table2.Id ... 

यानी एक ही अनुरोध, लेकिन केवल एक फ़ील्ड को वापस करने से बहुत तेज़ी से निष्पादित किया जाएगा यदि आप एक बार में सभी आवश्यक फ़ील्ड को "बाहर निकालने" की कोशिश करते हैं।

लेकिन बाकी डेटा का क्या?

और हम शेष डेटा को सरल प्रश्नों की एक श्रृंखला के साथ प्राप्त करते हैं जैसे:

 select * from Table1 where Id = ? 

यह क्वेरी बहुत तेज़ है क्योंकि आईडी प्राथमिक कुंजी है।

कुल मिलाकर

मुख्य अनुकूलन कारक कई प्रश्नों में डेटा प्राप्त करने की प्रक्रिया का विभाजन था: उनमें से एक पहचानकर्ताओं की सूची लौटाता है, और शेष डेटा बहुत सरल प्रश्नों द्वारा वापस किया जाता है।

जैसा कि मैंने पहले कहा था, इस दृष्टिकोण ने हमें बजट स्मार्टफोन पर एप्लिकेशन की गति में काफी तेजी लाने की अनुमति दी। माल की सूची के माध्यम से स्क्रॉल करते समय (जब प्रत्येक प्रदर्शित सूची आइटम के लिए कई "सरल" प्रश्न किए जाते हैं), कोई भी मंदी आंख को दिखाई नहीं देती है।