संक्षेप में, मैं आपके सीटीओ से सहमत हूँ। आपने शायद स्केलेबिलिटी की कीमत पर कुछ प्रदर्शन प्राप्त किया है (यदि वे शर्तें भ्रमित हैं, तो मैं नीचे स्पष्ट कर दूंगा)। मेरी दो सबसे बड़ी चिंताएं क्षैतिजता को पैमाना बनाने के विकल्पों की कमी और कमी होगी (यह मानते हुए कि आपको इसकी आवश्यकता है)।
डेटा से निकटता: चलो एक कदम पीछे हटते हैं। कोड को एक DB में धकेलने के कुछ अच्छे कारण हैं। मेरा तर्क है कि सबसे बड़ा डेटा के लिए निकटता होगी - उदाहरण के लिए, यदि आप एक मुट्ठी भर मूल्यों को वापस करने के लिए गणना की उम्मीद कर रहे हैं, लेकिन ये लाखों रिकॉर्डों के एकत्रीकरण हैं, लाखों रिकॉर्ड (ऑन-डिमांड) को भेज रहे हैं अन्य जगहों पर एकत्रित किया जाने वाला नेटवर्क बेहद बेकार है, और आपके सिस्टम को आसानी से मार सकता है। यह कहने के बाद, आप डेटा की इस निकटता को अन्य तरीकों से प्राप्त कर सकते हैं, अनिवार्य रूप से कैश या विश्लेषण DBs का उपयोग कर जहां कुछ एकत्रीकरण पूर्ववर्ती किया गया है।
DB में कोड का प्रदर्शन:माध्यमिक निष्पादन प्रभाव, जैसे "निष्पादन योजनाओं का कैशिंग" बहस करना अधिक कठिन है। कभी-कभी, कैश की गई निष्पादन योजनाएं बहुत ही नकारात्मक चीज हो सकती हैं, अगर गलत निष्पादन योजना को कैश किया गया हो। आपके RDBMS के आधार पर, आप इनमें से सबसे अधिक प्राप्त कर सकते हैं, लेकिन आप अधिकांश मामलों में पैरामीट्रिज्ड SQL पर नहीं मिलेंगे, (वे योजनाएं आमतौर पर कैश की जाती हैं, भी)। मैं यह भी तर्क दूंगा कि अधिकांश संकलित या JIT'ed भाषाएँ आमतौर पर बुनियादी कार्यों और गैर-संबंधपरक प्रोग्रामिंग (स्ट्रिंग हेरफेर, लूप, आदि) के लिए अपने एसक्यूएल समकक्षों (जैसे टी-एसक्यूएल या पीएल / एसक्यूएल) से बेहतर प्रदर्शन करती हैं, इसलिए आप संख्या में कमी करने के लिए यदि आपने जावा या सी # का उपयोग किया है, तो वहां कुछ भी खोना नहीं है। ठीक-ठीक अनुकूलन भी काफी कठिन है - DB पर, आप ' अक्सर केवल आपके डेटा संरचना के रूप में एक सामान्य बी-ट्री (इंडेक्स) के साथ अटक जाता है। निष्पक्ष होने के लिए, एक पूर्ण विश्लेषण, जिसमें लंबे समय तक चलने वाले लेनदेन, लॉक एस्केलेशन, आदि जैसी चीजें शामिल हैं, किताबें भर सकती हैं।
स्थिरता: एसक्यूएल एक अद्भुत भाषा है जो इसे करने के लिए डिज़ाइन की गई थी। मुझे यकीन नहीं है कि यह एप्लिकेशन लॉजिक के लिए बहुत अच्छा है। अधिकांश टूलिंग और प्रथाएं जो हमारे जीवन को सहनीय बनाती हैं (TDD, रीफैक्टरिंग, आदि) डेटाबेस प्रोग्रामिंग पर लागू करना मुश्किल है।
प्रदर्शन बनाम मापनीयता:इन शब्दों को स्पष्ट करने के लिए, मेरा मतलब है: प्रदर्शन यह है कि आप जिस लोड को कम लोड मान रहे हैं, उसके लिए आप अपने सिस्टम (और उपयोगकर्ता पर वापस) के माध्यम से जाने के लिए एक ही अनुरोध की अपेक्षा कितनी जल्दी करेंगे। यह अक्सर उन चीजों से सीमित होगा जैसे कि यह उन भौतिक परतों की संख्या के माध्यम से होती है, जो उन परतों को कितनी अच्छी तरह से अनुकूलित करते हैं, आदि। स्केलेबिलिटी उपयोगकर्ताओं की संख्या / भार बढ़ने के साथ प्रदर्शन में परिवर्तन होता है। आपके पास मध्यम / कम प्रदर्शन (अनुरोध के लिए 5 सेकंड +) हो सकता है, लेकिन भयानक स्केलेबिलिटी (लाखों उपयोगकर्ताओं का समर्थन करने में सक्षम)। आपके मामले में, आप शायद अच्छे प्रदर्शन का अनुभव करेंगे, लेकिन आपकी मापनीयता इस बात से बंधी होगी कि आपका शारीरिक रूप से कितना बड़ा सर्वर बन सकता है। कुछ बिंदु पर, आप उस सीमा को मारेंगे, और तेज करने जैसी चीजों के लिए मजबूर होंगे, जो कि अनुप्रयोग की प्रकृति के आधार पर संभव नहीं हो सकता है।
समय से पहले अनुकूलन: अंततः, मुझे लगता है कि आपने समय से पहले अनुकूलन की गलती की है। जैसा कि दूसरों ने बताया है, आपके पास वास्तव में माप नहीं है कि अन्य दृष्टिकोण कैसे काम करेंगे। ठीक है, हम हमेशा एक सिद्धांत को साबित करने या अस्वीकार करने के लिए पूर्ण-पैमाने के प्रोटोटाइप का निर्माण नहीं कर सकते हैं ... लेकिन सामान्य तौर पर, मैं हमेशा एक दृष्टिकोण को चुनने में संकोच करूंगा जो प्रदर्शन के लिए स्थिरता (शायद एक आवेदन की सबसे महत्वपूर्ण गुणवत्ता) को पार करता है ।
संपादित करें: सकारात्मक नोट पर, ऊर्ध्वाधर स्केलिंग कुछ मामलों में काफी दूर तक फैल सकती है। जहां तक मुझे पता है, एसओ काफी समय तक एक ही सर्वर पर चला। मुझे यकीन नहीं है कि यह आपके 10 000 उपयोगकर्ताओं से कैसे मेल खाता है (मुझे लगता है कि यह आपके सिस्टम में वे क्या कर रहे हैं की प्रकृति पर निर्भर करेगा), लेकिन यह आपको एक विचार देता है कि क्या किया जा सकता है (वास्तव में, वहाँ बहुत दूर हैं अधिक प्रभावशाली उदाहरण, यह सिर्फ एक लोकप्रिय होने के लिए होता है जिसे लोग आसानी से समझ सकते हैं)।
EDIT 2: कुछ बातों को स्पष्ट करने और उन पर टिप्पणी करने के लिए:
- पुन: परमाणु स्थिरता - ACID स्थिरता प्रणाली की एक आवश्यकता हो सकती है। उपरोक्त वास्तव में उस के खिलाफ बहस नहीं करता है, और आपको महसूस करना चाहिए कि ACID स्थिरता को आपको DB के अंदर अपने सभी व्यावसायिक तर्क चलाने की आवश्यकता नहीं है। जिस कोड को डीबी में रखने की आवश्यकता नहीं है, उसे स्थानांतरित करके , आप इसे बाकी के DB के भौतिक वातावरण में चलाने के लिए विवश कर रहे हैं - यह आपके DB के वास्तविक डेटा प्रबंधन भाग के समान हार्डवेयर संसाधनों के लिए प्रतिस्पर्धा कर रहा है। अन्य DB सर्वर (लेकिन वास्तविक डेटा नहीं) के लिए केवल कोड को स्केल करने के लिए - यकीन है, यह संभव हो सकता है , लेकिन क्या आप वास्तव में यहां प्राप्त कर रहे हैं, इसके अलावा ज्यादातर मामलों में अतिरिक्त लाइसेंसिंग लागत? उन चीजों को रखें जिन्हें DB पर, DB से दूर होने की आवश्यकता नहीं है।
- पुन: SQL / C # प्रदर्शन - चूंकि यह रुचि का विषय लगता है, आइए चर्चा में थोड़ा जोड़ दें। आप निश्चित रूप से मूल / जावा / सी # कोड को डीबी के अंदर चला सकते हैं, लेकिन जहां तक मुझे पता है, कि यहां चर्चा नहीं की जा रही है - हम टी-एसक्यूएल बनाम सी # जैसे कुछ में विशिष्ट एप्लिकेशन कोड को लागू करने की तुलना कर रहे हैं। ऐसी कई समस्याएं हैं जो अतीत में संबंधपरक कोड के साथ हल करना मुश्किल है - उदाहरण के लिए "अधिकतम समवर्ती लॉगिन" समस्या पर विचार करें, जहां आपके पास एक लॉग या लॉगआउट, और समय का संकेत देने वाले रिकॉर्ड हैं, और आपको बाहर काम करने की आवश्यकता है किसी एक समय में लॉग इन करने वाले उपयोगकर्ताओं की अधिकतम संख्या थी। सरलतम संभव समाधान है कि रिकॉर्ड के माध्यम से पुनरावृत्ति करें और एक काउंटर बढ़ा / घटाकर रखें क्योंकि आप लॉगइन / लॉगआउट का सामना करते हैं, और इस मूल्य का अधिकतम ट्रैक रखते हैं।हो सकता है, मुझे नहीं पता), सबसे अच्छा आप कर सकते हैं एक कर्सर है (विशुद्ध रूप से संबंधपरक समाधान जटिलता के विभिन्न आदेशों पर हैं, और खराब प्रदर्शन में थोड़ी देर के परिणाम का उपयोग करके इसे हल करने का प्रयास करते हैं)। इस मामले में, हां, सी # समाधान वास्तव में टी-एसक्यूएल, अवधि में आप क्या हासिल कर सकते हैं, उससे तेज है। यह दूर की कौड़ी लग सकता है, लेकिन यह समस्या वित्तीय प्रणालियों में खुद को आसानी से प्रकट कर सकती है, यदि आप रिश्तेदार परिवर्तनों का प्रतिनिधित्व करने वाली पंक्तियों के साथ काम कर रहे हैं, और उन पर विंडो एकत्रीकरण की गणना करने की आवश्यकता है। संग्रहित खरीद इनवॉइस भी अधिक महंगे होते हैं - एक ट्रिवियल एसपी को एक लाख बार चालान करें और देखें कि सी # फ़ंक्शन को कॉल करने की तुलना कैसे की जाती है। मैंने ऊपर कुछ अन्य उदाहरणों पर संकेत दिया है - मैंने अभी तक किसी को भी टी-एसक्यूएल (जो वास्तव में कुछ लाभ देता है) में एक उचित हैश तालिका को लागू करने का सामना नहीं किया है, जबकि सी # में करना बहुत आसान है। फिर, वहाँ चीजें हैं जो DBs में कमाल कर रहे हैं, और चीजें हैं जो वे पर इतना भयानक नहीं हैं। जैसे मैं C # में JOINs, SUMs और GROUP BY नहीं करना चाहूंगा, मैं T- SQL में विशेष रूप से सीपीयू इंटेंसिव कुछ भी लिखना नहीं चाहता।