~3.5TB डेटा संग्रहीत करना और लगभग 1K/सेकंड 24x7 सम्मिलित करना, और निर्दिष्ट दर पर क्वेरी करना भी SQL सर्वर के साथ संभव है, लेकिन और भी प्रश्न हैं:
- इसके लिए आपको किस उपलब्धता की आवश्यकता है? 99.999% अपटाइम, या 95% पर्याप्त है?
- आपके पास विश्वसनीयता की क्या आवश्यकता है? क्या एक इंसर्ट गुम होने पर आपको $1M खर्च करना पड़ता है?
- आपके पास पुनर्प्राप्ति योग्यता की क्या आवश्यकता है? यदि आप एक दिन का डेटा खो देते हैं, तो क्या इससे कोई फर्क पड़ता है?
- आपके पास निरंतरता की क्या आवश्यकता है? क्या किसी लेखन को अगले पठन पर दिखाई देने की गारंटी की आवश्यकता है?
यदि आपको इन सभी आवश्यकताओं की आवश्यकता है, जिन पर मैंने प्रकाश डाला है, तो आपके द्वारा प्रस्तावित भार हार्डवेयर और लाइसेंसिंग में एक रिलेशनल सिस्टम, किसी भी सिस्टम पर लाखों खर्च करने वाला है, चाहे आप कोई भी नौटंकी करने की कोशिश करें (शार्डिंग, पार्टीशन आदि)। एक नोस्क्ल सिस्टम, उनकी परिभाषा के अनुसार, सभी . को पूरा नहीं करेगा इन आवश्यकताओं।
तो स्पष्ट है कि आपने इनमें से कुछ आवश्यकताओं में पहले ही ढील दे दी है। नोएसक्यूएल सिस्टम्स के लिए विजुअल गाइड पर '3 में से 2 चुनें' प्रतिमान के आधार पर नोस्कल प्रसाद की तुलना करने वाला एक अच्छा विजुअल गाइड है:
ओपी टिप्पणी अपडेट के बाद
SQL सर्वर के साथ यह सीधे आगे कार्यान्वयन होगा:
- एक एकल तालिका संकुल (GUID, समय) कुंजी। हां, खंडित होने जा रहा है, लेकिन क्या विखंडन रीड-आगे को प्रभावित करता है और केवल महत्वपूर्ण रेंज स्कैन के लिए रीड-आगे की आवश्यकता होती है। चूंकि आप केवल विशिष्ट GUID और दिनांक सीमा के लिए क्वेरी करते हैं, इसलिए विखंडन अधिक मायने नहीं रखेगा। हां, एक विस्तृत कुंजी है, इसलिए गैर-पत्ती वाले पृष्ठों में कुंजी घनत्व खराब होगा। हां, यह खराब फिल फैक्टर की ओर ले जाएगा। और हाँ, पृष्ठ विभाजन हो सकता है। इन समस्याओं के बावजूद, आवश्यकताओं को देखते हुए, अभी भी सबसे अच्छा क्लस्टर कुंजी विकल्प है।
- समय के अनुसार तालिका को विभाजित करें ताकि आप स्वचालित स्लाइडिंग विंडो के माध्यम से समाप्त हो चुके रिकॉर्ड को प्रभावी ढंग से हटा सकें। GUID क्लस्टरिंग द्वारा शुरू किए गए खराब भरण कारक और विखंडन को समाप्त करने के लिए पिछले महीने के ऑनलाइन इंडेक्स विभाजन के पुनर्निर्माण के साथ इसे बढ़ाएं।
- पृष्ठ संपीड़न सक्षम करें। चूंकि GUID द्वारा पहले क्लस्टर किए गए कुंजी समूह, GUID के सभी रिकॉर्ड एक-दूसरे के बगल में होंगे, जिससे पृष्ठ संपीड़न को शब्दकोश संपीड़न को परिनियोजित करने का एक अच्छा मौका मिलेगा।
- लॉग फ़ाइल के लिए आपको तेज़ IO पथ की आवश्यकता होगी। आप उच्च थ्रूपुट में रुचि रखते हैं, न कि कम विलंबता पर एक लॉग के लिए 1K इंसर्ट/सेकंड के साथ बनाए रखने के लिए, इसलिए स्ट्रिपिंग एक आवश्यक है।
विभाजन और पृष्ठ संपीड़न प्रत्येक के लिए एंटरप्राइज़ संस्करण SQL सर्वर की आवश्यकता होती है, वे मानक संस्करण पर काम नहीं करेंगे और दोनों ही आवश्यकताओं को पूरा करने के लिए काफी महत्वपूर्ण हैं।
एक साइड नोट के रूप में, यदि रिकॉर्ड फ्रंट-एंड वेब सर्वर फ़ार्म से आते हैं, तो मैं प्रत्येक वेब सर्वर पर एक्सप्रेस डालूंगा और बैक एंड पर INSERT के बजाय, मैं SEND वेब सर्वर के साथ सह-स्थित एक्सप्रेस पर स्थानीय कनेक्शन/लेनदेन का उपयोग करके बैक एंड की जानकारी। यह समाधान के लिए बहुत बेहतर उपलब्धता की कहानी देता है।
तो मैं इसे SQL सर्वर में कैसे करूंगा। अच्छी खबर यह है कि आप जिन समस्याओं का सामना करेंगे, वे अच्छी तरह से समझी जाती हैं और समाधान ज्ञात होते हैं। इसका मतलब यह नहीं है कि यह कैसंड्रा, बिगटेबल या डायनेमो के साथ आप जो हासिल कर सकते हैं उससे बेहतर है। मैं किसी को उनके मामले में तर्क करने के लिए नो-एसक्यूएल-ईश चीजों में अधिक जानकार होने दूंगा।
ध्यान दें कि मैंने कभी भी प्रोग्रामिंग मॉडल, .Net समर्थन और इस तरह का उल्लेख नहीं किया है। मुझे ईमानदारी से लगता है कि वे बड़ी तैनाती में अप्रासंगिक हैं। वे विकास प्रक्रिया में बहुत बड़ा अंतर डालते हैं, लेकिन एक बार तैनात होने के बाद इससे कोई फर्क नहीं पड़ता कि विकास कितना तेज़ था, अगर ओआरएम ओवरहेड प्रदर्शन को मारता है :)
