जब इंडेक्स जोड़ने से काम धीमा हो जाता है

दैनिक आँकड़ों की टेबल में एक ही कुंजी है: काउंटर और तारीख, दोनों मिलकर। कोड में पाँच जगहें इससे एक अलग सवाल पूछती हैं — “समय के साथ यह काउंटर” नहीं, बल्कि “इन तारीखों पर सभी काउंटर”। मुख्य पेज की गैलरी, टॉप लिस्ट, साइटमैप, 90 दिन का चार्ट और स्थिति के आँकड़े। तारीख वाले कॉलम पर इंडेक्स न हो, तो इनमें से हर एक सभी 1,14,113 पंक्तियाँ पढ़ता है।

यह इंडेक्स जोड़ने से गैलरी दस गुना तेज़ हो जाती है। इसे जोड़ा नहीं गया। यह रहा वह माप, जिसने यह फ़ैसला किया।

एक क्वेरी काफ़ी तेज़ हुई

गैलरी उन काउंटरों को माँगती है जो आज सक्रिय थे। तारीख पर इंडेक्स न हो, तो वह पूरी टेबल स्कैन करती है; इंडेक्स हो, तो वह एक ही तारीख ढूँढ़ती है और 443 पंक्तियाँ पढ़ती है। 61.5 मिलीसेकंड घटकर 6.1 रह गए। यह कोई बारीक फ़र्क नहीं है, और अगर सिर्फ़ यही मापा गया होता, तो इंडेक्स आज डेटाबेस में होता।

दो क्वेरी धीमी हो गईं

साइटमैप चौदह दिन माँगता है और 19% धीमा हो गया। स्थिति के आँकड़े एक साल माँगते हैं और 10% धीमे हो गए। दोनों मामलों में क्वेरी प्लानर प्राइमरी कुंजी छोड़कर नए इंडेक्स पर चला गया और उसने बदतर विकल्प चुना।

यही हिस्सा समझने लायक है, क्योंकि यह प्लानर का कोई बग नहीं है। सेकंडरी इंडेक्स के ज़रिए किसी दायरे को पढ़ने का मतलब है पहले इंडेक्स में मेल खाती पंक्तियाँ ढूँढ़ना और फिर हर पंक्ति को टेबल से लाना। छोटे से हिस्से के लिए यह फ़ायदे का सौदा है। तेरह महीनों में से चौदह दिनों के लिए भी ये बहुत सारी पंक्तियाँ हैं, जो एक-एक करके लाई जाती हैं, और टेबल का सीधा स्कैन — यानी उसे भौतिक क्रम में पढ़ना, जो डिस्क और कैश को पसंद है — इससे आगे निकल जाता है। प्लानर यह नहीं जानता। उसे एक दायरा और एक इंडेक्स दिखता है, और वह उसे ले लेता है।

यह कहने का कोई तरीका नहीं है कि “यह इंडेक्स सिर्फ़ गैलरी के लिए इस्तेमाल करें।” इंडेक्स उस कॉलम को छूने वाली हर क्वेरी के लिए उपलब्ध होता है, और प्लानर जहाँ भी उसके अनुमान कहें, वहाँ उसका इस्तेमाल करेगा। इंडेक्स जोड़ना उस टेबल की हर क्वेरी में बदलाव है, सिर्फ़ उस एक में नहीं जिसके लिए वह बनाया गया था।

कुल मिलाकर: कुछ नहीं

पाँचों को मिलाकर 555 मिलीसेकंड 524 हो गए। यानी 1.1× का सुधार, जिसके लिए एक छोटे सर्वर पर, जो ये पेज वैसे भी कैश से देता है, स्कीमा बदलना उचित नहीं है।

90 दिन का चार्ट 9% बेहतर हुआ लगता है। इसे गिना नहीं गया, और क्यों नहीं, यह बताना ज़रूरी है। हर क्वेरी तीन बार मापी गई: इंडेक्स के बिना, उसके साथ, और फिर दोबारा उसके बिना। अगर इंडेक्स के बिना दूसरा रन पहले रन के आसपास नहीं आता, तो फ़र्क मशीन की वजह से था, बदलाव की वजह से नहीं। 90 दिन के चार्ट में इंडेक्स के बिना दोनों रन में 13.8% का फ़र्क था — यानी जिस असर का दावा किया जा रहा है, उससे भी ज़्यादा। इसलिए वह पंक्ति कुछ नहीं मापती, और उसे “कुछ नहीं” के रूप में ही बताया गया है।

यह कैसे मापा गया, और यह क्यों मायने रखता है

लाइव टेबल पर नहीं। स्क्रिप्ट उसकी कॉपी बनाती है, कॉपी पर काम करती है और अंत में कॉपी को हटा देती है। प्रोडक्शन टेबल में यह देखने के लिए इंडेक्स जोड़ना कि क्या होता है, हर बुरे झटके पर बस एक ही बार काम करता है।

क्वेरी असली हैं, सीधे कोड से ली गई हैं, काउंटर टेबल के साथ जॉइन समेत। इस टेस्ट के एक पुराने वर्ज़न में उनकी जगह एक सरल क्वेरी इस्तेमाल हुई थी, और उसने कहीं ज़्यादा रोमांचक जवाब दिया था: बीस गुना तेज़। वह सरल क्वेरी ऐसी नहीं थी जिसे कोई चीज़ असल में चलाती हो।

तब संख्या क्या होती

अगर इसे आम तरीके से मापा गया होता — जो क्वेरी धीमी लगे, उसे लें और पहले व बाद का समय नापें — तो जवाब होता “दस गुना तेज़, इसे लाइव करें”। इंडेक्स जोड़ दिया जाता, गैलरी तेज़ हो जाती, साइटमैप और स्थिति पेज धीमे हो जाते, और कोई इन दोनों बातों को आपस में नहीं जोड़ता, क्योंकि उन पर कोई नज़र नहीं रख रहा था।

मोटे तौर पर बात यही है। साझा ढाँचे में किसी बदलाव को उसी मामले पर नहीं परखा जा सकता, जिसकी वजह से वह किया गया। सवाल यह नहीं है कि “क्या इससे उस चीज़ को फ़ायदा होता है जिसे मैं देख रहा हूँ”, बल्कि यह है कि “इसे और क्या-क्या छूता है, और उसका क्या होता है”।

एक विकल्प शायद काम कर सकता है: दोनों कॉलम वाला इंडेक्स, पहले तारीख, ताकि गैलरी का जवाब टेबल पर वापस गए बिना सिर्फ़ इंडेक्स से मिल सके। हो सकता है कि इससे बड़े दायरों पर प्लानर ललचाए भी नहीं। इसे अभी मापा नहीं गया है, इसलिए यह कोई सिफ़ारिश नहीं है — यह अगली चीज़ है जिसे कॉपी पर आज़माया जाएगा।