अधिकांश DBAPI कार्यान्वयन पूरी तरह से पंक्तियों को बफ़र करते हैं क्योंकि वे लाए जाते हैं - इसलिए आमतौर पर, SQLAlchemy ORM से पहले भी एक परिणाम को पकड़ लेता है, पूरा परिणाम सेट मेमोरी में होता है।
लेकिन फिर, जिस तरह से Query काम यह है कि यह आपकी वस्तुओं पर लौटने से पहले डिफ़ॉल्ट रूप से दिए गए परिणाम को पूरी तरह से लोड करता है। यहां तर्क उन प्रश्नों के संबंध में है जो साधारण चयन कथनों से अधिक हैं। उदाहरण के लिए, अन्य तालिकाओं में शामिल होने पर जो एक ही वस्तु पहचान को एक परिणाम सेट में कई बार लौटा सकता है (आकांक्षी लोडिंग के साथ आम), पंक्तियों का पूरा सेट स्मृति में होना चाहिए ताकि सही परिणाम वापस किए जा सकें अन्यथा संग्रह और ऐसे केवल आंशिक रूप से आबादी हो सकती है।
तो Query yield_per()
. यह कॉल Query . का कारण बनेगी बैचों में पंक्तियाँ उत्पन्न करने के लिए, जहाँ आप इसे बैच आकार देते हैं। डॉक्स राज्य के रूप में, यह केवल तभी उपयुक्त है जब आप संग्रह की किसी भी प्रकार की उत्सुक लोडिंग नहीं कर रहे हैं, इसलिए यह मूल रूप से है यदि आप वास्तव में जानते हैं कि आप क्या कर रहे हैं। साथ ही, यदि अंतर्निहित डीबीएपीआई प्री-बफर पंक्तियां हैं, तो अभी भी वह मेमोरी ओवरहेड होगी, इसलिए इसका उपयोग न करने से दृष्टिकोण केवल थोड़ा बेहतर होता है।
मैं शायद ही कभी yield_per() use का उपयोग करता हूं; इसके बजाय, मैं विंडो फ़ंक्शंस का उपयोग करके ऊपर आपके द्वारा सुझाए गए LIMIT दृष्टिकोण के बेहतर संस्करण का उपयोग करता हूं। LIMIT और OFFSET में एक बड़ी समस्या है कि बहुत बड़े OFFSET मान क्वेरी को धीमा और धीमा होने का कारण बनते हैं, क्योंकि N का OFFSET इसे N पंक्तियों के माध्यम से पृष्ठ पर ले जाता है - यह एक ही क्वेरी को एक के बजाय पचास बार करने जैसा है, हर बार एक पढ़ना पंक्तियों की बड़ी और बड़ी संख्या। विंडो-फ़ंक्शन दृष्टिकोण के साथ, मैं "विंडो" मानों का एक सेट प्री-फ़ेच करता हूं जो उस तालिका के भाग को संदर्भित करता है जिसे मैं चुनना चाहता हूं। फिर मैं अलग-अलग SELECT स्टेटमेंट देता हूं जो एक बार में उनमें से किसी एक विंडो से खींचे जाते हैं।
विंडो फ़ंक्शन दृष्टिकोण विकी पर है और मैं इसे बड़ी सफलता के साथ उपयोग करता हूं।
यह भी ध्यान दें:सभी डेटाबेस विंडो फ़ंक्शंस का समर्थन नहीं करते हैं; आपको Postgresql, Oracle, या SQL सर्वर की आवश्यकता है। कम से कम Postgresql का उपयोग करने वाला IMHO निश्चित रूप से इसके लायक है - यदि आप एक रिलेशनल डेटाबेस का उपयोग कर रहे हैं, तो आप सर्वश्रेष्ठ का भी उपयोग कर सकते हैं।
