संक्षिप्त जवाब
हां , आप एक अध्ययन किए गए मामले का एक सार्थक बेंचमार्क लिख सकते हैं, यदि आप इसे सावधानी से करते हैं, और यह समझते हैं कि यदि यह विशेष मामले के लिए प्रासंगिक है, तो यह अन्य मामलों के लिए नहीं हो सकता है। एक ही प्रकार (रिलेशनल डेटाबेस बनाम किसी अन्य रिलेशनल डेटाबेस) या विभिन्न प्रकार के डेटाबेस की तुलना करते समय यह समान रूप से सच है।
नहीं , आप एक बेंचमार्क नहीं लिख सकते हैं, जो जादुई रूप से यह साबित करेगा कि एक विशिष्ट डेटाबेस हर मामले में हर मामले में दूसरे से बेहतर है।
लंबा जवाब
यह कहना निश्चित रूप से संभव है कि "एक डेटाबेस से दूसरे में जाकर हमारी साइट के प्रदर्शन में सुधार हुआ है"।
आप पिछले डेटाबेस के प्रदर्शन को मापने के माध्यम से प्रोफाइलिंग या रनटाइम आँकड़ों के माध्यम से प्रश्नों के बारे में पर्याप्त जानकारी इकट्ठा करते हैं और वे कितनी तेज़ हैं।
आप एप्लिकेशन को नए डेटाबेस में ले जाते हैं।
तुम वही उपाय करो।
आप तुलना कीजिए।
उदाहरण के लिए, यदि 3 182 432 उत्पादों की पूरी सूची 2.834 एस में भरी हुई है। एक पुराने डेटाबेस में और 0.920 एस में लोड होता है। एक नए डेटाबेस पर, यह देखते हुए कि दोनों मामलों में, एप्लिकेशन के पास खाली कैश है, यह एक जीत है: नए डेटाबेस ने इस क्वेरी के बारे में आपकी साइट के प्रदर्शन में सुधार किया।
अब, किसी भी प्रदर्शन मीट्रिक के रूप में, यह पक्षपाती है:
सहमत हुए, नई क्वेरी तेज़ है। लेकिन रुकिए, आपके डीबीए को नहीं पता था कि आपने पहले जो डेटाबेस का उपयोग किया था , वह क्वेरी क्यों है, जो सभी उत्पादों को लोड करता है , अनुकूलित नहीं है । यदि आप इसे फिर से लिखते हैं, तो आप उन उत्पादों को 0.855 सेकेंड में लोड कर पाएंगे। 2.834 के बजाय।
ठीक है, आपके पास बेहतर परिणाम है। लेकिन क्या आपको नहीं लगता है कि सिर्फ 10 साल पुराने डेटाबेस के लिए नए डेटा के साथ डेटाबेस की तुलना करना अनुचित है , जिसके लिए अंतिम रखरखाव योजना तीन साल पहले चलाई गई थी? वैसे, आपको नहीं लगता कि आपको पिछले चार वर्षों के दौरान डेटाबेस उत्पाद को कम से कम एक बार अपडेट करना चाहिए था ?
कुछ प्रश्न तेज हैं। कुछ धीमे हैं। आप यह जानने के लिए औसत परिणाम की गणना कैसे करते हैं कि आपने नए डेटाबेस में जाते समय कुल मिलाकर प्रदर्शन प्राप्त किया है? ठीक है, आप सभी 3 182 432 उत्पादों को लोड करने का समय तेज है। लेकिन क्या यह मायने रखता है, जबकि क्वेरी को वेबसाइट पर केवल एक दुर्लभ मामले में निष्पादित किया जाता है जब एक व्यवस्थापक कुछ विशिष्ट कार्य कर रहा है जो उसने पिछले दस वर्षों में केवल दो बार किया? दूसरी ओर, एक ताजा उपयोगकर्ता के लिए होम पेज पर सभी प्रश्नों को निष्पादित करना 0.281 सेकेंड बर्बाद करता है। नए डेटाबेस के साथ, जब यह 0.207 s था। पुराने डेटाबेस के साथ। यह परिणाम बहुत अधिक मायने रखता है, खासकर जब से उन प्रश्नों को लंबे समय तक कैश नहीं किया जा सकता है, और प्रति दिन हजारों बार निष्पादित किया जाता है।
दोनों डेटाबेस को एक ही सर्वर , एक ही हार्डवेयर, एक ही संरचना पर परीक्षण किया जाना चाहिए । उदाहरण के लिए, आप एक एकल हार्ड ड्राइव पर एक डेटाबेस का परीक्षण नहीं कर सकते हैं, और दो SSD के एक RAID1 पर अन्य। जब आप एक बड़े प्रोजेक्ट को एक नए डेटाबेस में माइग्रेट करते हैं, तो संभावना है कि आप नए डेटाबेस को सौ अन्य नए तैनात रैक सर्वर पर होस्ट करेंगे, जब पिछला डेटाबेस अभी भी पिछले मशीनों पर रहेगा।
संक्षेप में, आप किसी एप्लिकेशन के डेटाबेस प्रश्नों को बेंचमार्क कर सकते हैं और सटीक मैट्रिक्स प्राप्त कर सकते हैं । लेकिन फिर, आपको संख्याओं को एक अर्थ देना होगा। इस अवस्था में, यह कहना ललचाता है कि आपने साइट प्रदर्शन प्राप्त कर लिया है: अन्यथा, प्रबंधन यह जानने के लिए क्रोधित होगा कि आपने चीजों को धीमा करने के लिए हजारों डॉलर और महीनों के काम खर्च किए हैं।
सबसे भयानक गलती बेंचमार्क से उन निष्कर्षों को लेना है और "माइक्रोसॉफ्ट एसक्यूएल सर्वर ओरेकल की तुलना में तीन गुना तेज है" जैसे कुछ निष्कर्ष निकालना है: यह कहते हुए कि "जावा PHP से बेहतर है"। बेहतर परिभाषित करें। किन मामलों में बेहतर? किस प्रकार के अनुप्रयोगों के लिए? डेवलपर्स की टीम के लिए
जितना आप व्याख्या और सामान्यीकरण करते हैं, उतनी ही बात अप्रासंगिक और निरर्थक हो जाती है।
क्वेरी select [...]आप फ़ाइल में संशोधन # 832 में पा सकते हैं ProductFactory.cs, लाइन 117 0.5 एस के तहत निष्पादित होती है। नए डेटाबेस के साथ जब गैर-कार्यात्मक आवश्यकताओं एनेक्स एम, स्थिति 3 में निर्दिष्ट शर्तों के तहत परीक्षण किया जाता है। यह गैर-कार्यात्मक आवश्यकता 527 से गुजरने की अनुमति देता है (पृष्ठ 80 देखें, संशोधन 9)। उसी आवश्यकता को पिछले डेटाबेस से संतुष्ट नहीं किया गया था, जब परीक्षा परिणाम 0.9..1.3 s की सीमा में था। उन्हीं स्थितियों में।
एक डेवलपर के लिए सार्थक है, और यह जानने के लिए पर्याप्त है कि क्या परीक्षण किया गया था, कैसे, और क्या परिणाम थे। यह आपके प्रश्न संख्या 2 का उत्तर देता है।
अफसोस की बात है, यह प्रबंधन के लिए कोई मतलब नहीं है। बजाय:
Microsoft SQL सर्वर के नवीनतम संस्करण में MySQL से हमारे उत्पाद को माइग्रेट करने से हमारे उत्पाद के समग्र प्रदर्शन में पांच से सुधार हुआ, साथ ही लागत में दो और पर्यावरणीय पदचिह्न में तीन की कमी आई। हमारा मानना है कि अगले वर्ष हमारे सभी अनुप्रयोगों को Microsoft SQL सर्वर पर माइग्रेट करने से और भी बेहतर परिणाम मिलेंगे और हमारी बाजार प्रतिस्पर्धा बढ़ेगी।
एक शुद्ध विपणन है जिबर-जैबर, और, तकनीकी रूप से, इसका कोई मतलब नहीं है, लेकिन आश्चर्यजनक रूप से प्रबंधन और विपणन विभागों के लिए एक मूल्य है।
अंत में, क्या हम विभिन्न प्रकार के डेटाबेस की तुलना कर सकते हैं? मैं कहूंगा कि यह पूरी तरह से संभव है। मान लीजिए कि मेरे पास बड़ी तस्वीरों की मेजबानी करने वाली एक वेबसाइट है। वे फ़ोटो varbinary(max)Microsoft SQL Server 2005 में संग्रहीत हैं (इसलिए मैं उपयोग नहीं कर सकता filestream)। मैं उन फ़ोटो को लोड करते समय प्रदर्शन के बारे में चिंतित हूं, इसलिए मैं फ़ाइल सिस्टम के बजाय फ़ोटो को स्टोर करने का निर्णय लेता हूं, अपने नए डेटाबेस के रूप में फ़ाइल सिस्टम का उपयोग कर रहा हूं। सबसे पहले, उन फ़ाइलों को डेटाबेस की तुलना में एक ही मशीन पर संग्रहीत किया जाता है। मैं नए समाधान को प्रोफाइल करता हूं, और उस परिणाम को प्राप्त करता हूं जो दिखाता है कि मेरे मामले में, Microsoft SQL Server की तुलना में फाइल सिस्टम से फाइलें 4% तेजी से भरी हुई हैं। बेंचमार्क बहुत स्पष्ट है। अब मैं Microsoft SQL सर्वर के लिए अनुकूलित सर्वर का उपयोग करने के बजाय सीधे फ़ाइल भंडारण के लिए अनुकूलित एक समर्पित सर्वर को तैनात करने के बारे में सोच सकता हूं।