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