N plus one query की समस्या क्या है और आप उसे कैसे ठीक करते हैं?

आप एक query से list लाते हैं, फिर rows पर loop करके हर row के लिए एक और query दागते हैं, तो 200 posts 201 round trips बन जाते हैं। इसे एक ही पास में जुड़े हुए rows लाकर ठीक करें: एक join, parent id से keyed एक IN query, या ऐसा batching loader जो एक request tick के अंदर ids जमा कर ले। पहचान यह है कि latency नतीजों की गिनती के साथ सीधी रेखा में बढ़ती है जबकि हर अकेली query तेज़ दिखती है।

यह आमतौर पर उसी पल दिखता है जब कोई list render करता है। आप orders लाते हैं, फिर template में order.customer.name छूते हैं, और ORM चुपचाप हर row के लिए एक query दाग देता है। अकेले वे आधे मिलीसेकंड की हैं, तो कुछ टूटा हुआ नहीं दिखता जब तक list बढ़ न जाए और endpoint चार सेकंड न लेने लगे। मैं इसे query की अवधि नहीं, प्रति request query की गिनती देखकर पकड़ता हूं; ज़्यादातर APM टूल यह सीधे दिखाते हैं, और स्थानीय रूप से मैं query logging चालू करके गिनता हूं। इलाज शक्ल पर निर्भर है। सादे belongs to रिश्ते के लिए eager load या join ठीक है। ऐसे one to many के लिए जहां join rows को गुणा कर देगा, मैं IN clause वाली दूसरी query और memory में जोड़ना पसंद करता हूं। GraphQL API में यह dataloader ही होना चाहिए, क्योंकि resolvers को पता ही नहीं होता कि उन्हें एक साथ बुलाया जा रहा है। जिससे मैं बचता हूं वह है डिफ़ॉल्ट रूप से सब कुछ eager load करना, क्योंकि वह एक समस्या के बदले आधा डेटाबेस memory में खींच लेने की समस्या दे देता है।