"संग्रहीत लेकिन उपलब्ध" डेटा के लिए SQL सर्वर डेटाबेस डिज़ाइन

Question

हमारे पास यह बड़ा डेटाबेस (> 1 टीबी) है जिसे हम "सिकोड़ना" चाहते हैं। डेटाबेस एक मुख्य इकाई के चारों ओर घूमता है, चलो इसे "भेंट" कहते हैं। चर्चा के लिए, मान लें कि यह एक चिकित्सा पद्धति का डेटाबेस है।

कुल 30 विज़िट "प्रकार" हैं, जैसे कि प्रक्रिया, वार्षिक, अनुवर्ती, टीकाकरण आदि, जिनमें से प्रत्येक "विज़िट", जैसे "विज़िट_इमुनो" के लिए एक सहायक तालिका है।

डेटाबेस ने 2000 के बाद से 12 साल के कुछ डेटा को संचित किया है। किसी ने प्रस्ताव दिया है कि हम "लाइव" संस्करण में लगभग 3 साल का डेटा रखते हैं और बाकी के "old_data" डेटाबेस में रहते हैं। सामान्य होने के बाद से तारीख केवल "विज़िट" तालिका में संग्रहीत की जाती है। विजिट टेबल में एक ROWVERSIONकॉलम और एक BIGINTछद्म पहचान (क्लस्टर) है। सभी इरादों और उद्देश्यों के लिए, मान लें कि क्लस्टरिंग कुंजी एक SEQUENCE (SQL Server 2012 एंटरप्राइज) द्वारा पॉप्युलेट की गई है - हम इसे नाम देंगे cid।

visit.dateजब एक डॉक्टर विस्तारित visitations और उसके डेटा के "अटैची" के साथ रिटर्न पर चला जाता है क्लस्टरिंग कुंजी, उदाहरण के लिए के रूप में एक ही क्रम में हमेशा नहीं है, यह मुख्य तालिका में विलय हो जाता है। "विज़िट" टेबल के लिए कुछ अपडेट भी हैं जो ROWVERSIONस्तंभ को सिंक cidऔर dateकॉलम दोनों से बाहर करने का कारण बनेंगे - इसे बस रखने के लिए, न तो ROWVERSIONऔर न ही cidइस कारण के लिए उपयुक्त विभाजन कुंजी बनाएंगे।

"लाइव" से डेटा हटाने के लिए व्यापार नियम यह है कि visit.date36 महीने से अधिक होना चाहिए और एक बच्चा visit_paymentरिकॉर्ड होना चाहिए। इसके अलावा, "old_data" डेटाबेस में बेस टेबल के अलावा कोई भी नहीं है visit%।

तो हम साथ समाप्त करते हैं:

लाइव डीबी (दैनिक उपयोग) - सभी टेबल ओल्ड-डेटा डीबी - visit%टेबल के लिए पुराने डेटा

प्रस्ताव एक संयुक्त डीबी के लिए कहता है जो एक शेल है जिसमें सभी बेस टेबलों के सिवाय एक समानार्थी शब्दLive DB (सिवाय इसके visit%) प्लस व्यूज़ हैं जो visit%दो डेटाबेस में टेबल के पार UNION ALL हैं ।

Old-Dataडीबी में समान इंडेक्स बनाए जाने पर , क्या सवाल UNION-ALL व्यूज पर अच्छा प्रदर्शन करेंगे ? यूनिअन-ऑल व्यू के लिए निष्पादन योजना में किस प्रकार के क्वेरी पैटर्न हो सकते हैं ?

Comments

क) पुराने डेटा को संग्रहीत करने और उसे सुलभ रखने के लिए) प्रेरणा क्या है? ओवरहेड रखरखाव? प्रदर्शन की समस्याएं? क्या संग्रहीत डेटा को एप्लिकेशन तक मूल रूप से पहुंच योग्य होना चाहिए? आवेदन में संशोधन के साथ या उसके बिना?

— मार्क स्टोरी-स्मिथ

(a) मुख्य db को छोटा रखना। इसे 3 अन्य एनवीएस - देव, प्री-टेस्ट, टेस्ट में दोहराया जाता है। महंगे भंडारण द्वारा समर्थित सभी प्रतिकृति दर्पण और बैकअप भी हैं। (b) क्योंकि डाउनस्ट्रीम सिस्टम में वर्तमान में सभी डेटा तक पहुंच है, इसलिए यह यथास्थिति बनाए रखता है। (c) एप्लिकेशन का एक उदाहरण "संयुक्त" DB के खिलाफ सभी दृश्यों के साथ चल सकता है, लेकिन मुझे संदेह है कि यह बिल्कुल भी प्रदर्शन नहीं कर सकता है।

— 17

बस स्पष्ट करने के लिए, संग्रहीत डेटा अभी भी पढ़ा-लिखा है, सही है? या यह केवल पढ़ने के लिए है?

— जॉन सीगेल

पुराना डेटा केवल-पढ़ने के लिए और 100% भरे हुए पृष्ठों में बदल जाएगा। यदि कोई व्यक्ति पुराने डेटा पर मूर्खतापूर्ण तरीके से कुछ करने की कोशिश करता है, तो संयुक्त विचारों से जुड़ने वाले ऐप की आवृत्ति में त्रुटियां हो सकती हैं - हमें परवाह नहीं है।

— 孔夫子

मुझे लगता है कि ऐतिहासिक डेटा और आंशिक बैकअप / पुनर्स्थापना के लिए केवल-पढ़ने के लिए फ़ाइलग्रुप इसे कवर करेगा, शेल डेटाबेस और समानार्थक शब्दों के बिना जोड़े के। मुझे लगता है कि जैसा कि मैंने कुछ समय के लिए यांत्रिकी के साथ ध्यान नहीं दिया है और मुझे अपनी स्मृति को ताज़ा करने की आवश्यकता है। कोई विचार नहीं है कि यह प्रतिकृति के साथ कैसे फिट होगा, लेकिन मैं सवाल करूंगा कि आप एक लाइव डेटाबेस को फिर से नीचे के वातावरण में क्यों बदल रहे हैं।

— मार्क स्टोरी-स्मिथ

Answer 1

सुविधा के लिए, मान लें कि लाइव डेटाबेस कहा जाता है LiveDbऔर प्राप्त डेटाबेस कहा जाता हैArchiveDb

• एक समानार्थी शब्द के माध्यम से डेटाबेस LiveDbमें तालिकाओं की ओर इशारा करते हुए एक सभी दृश्य जोड़ें ArchiveDb(समानार्थी शब्द के साथ एक संयुक्त DB करने की कोई आवश्यकता नहीं है)
• यदि यह पहले से ही नहीं है, तो visit.dateइस विभाजन को "विभाजन" पर और इसे असामान्य करें visit_payments(इससे सह-स्थित जुड़ाव प्रदर्शन में सुधार होता है)
• यदि संभव हो तो केवल दो बड़ी तालिकाओं को संग्रहीत करें (ऑप्टिमाइज़र को ट्रिप करने की संभावना कम कर देता है)। यूनिअन ऑल व्यू और अन्य तालिकाओं को रखें LiveDbताकि सभी छोटे तालिकाओं में शामिल हो जाएं जिन्हें स्थानीय रखा गया है
• दोनों में तालिकाओं पर एक CHECK बाधा जोड़ें LiveDbऔर ArchiveDb जो visit.dateतालिका में निहित सीमा का वर्णन करता है । यह ऑप्टिमाइज़र संग्रह और स्तंभ दोनों को स्कैन करने में मदद करता है जिसमें कॉलम होता है visit.data। आपको समय-समय पर इस बाधा को अद्यतन करना होगा।
• यूनिअन ऑल व्यू में, व्हेयर मानदंड जोड़ें जो फ़िल्टर करता है visit.data। यह संकेत के अलावा है जो आपने पहले ही चेक की कमी में प्रदान किया है। यह फ़िल्टर को नीचे धकेलने की संभावना को अधिकतम करता है
• यदि आपके पास ईई है, तो संग्रह डेटाबेस में तालिका को विभाजित करें (लेकिन लाइव डेटाबेस में नहीं)। यदि आप वास्तव में फैंसी प्राप्त करना चाहते हैं, तो बैकअप समय पर सहेजने के लिए फ़ाइल डेटाबेस स्तर बैकअप / संग्रह डेटाबेस का उपयोग करें।
• AchiveDbअगर यह पहले से ही नहीं है तो SIMPLE रिकवरी मोड में डालने पर विचार करें । आपको लेनदेन लॉग बैकअप की आवश्यकता नहीं हैArchiveDb
• INSERT का उपयोग करें ... (TABLOCK) के साथ चयन करें ... (ROWLOCK) के साथ गंतव्य पर न्यूनतम लॉगिंग को मजबूर करने के लिए जब LiveDbऔर के बीच डेटा ले जा रहा हो ArchiveDb

उपरोक्त सभी यह गारंटी नहीं देते हैं कि आशावादी आर्काइव तालिकाओं को स्कैन और स्कैन से समाप्त कर देगा, लेकिन यह अधिक संभावना बनाता है।

जब उन्मूलन नहीं होता है। ये वे प्रभाव हैं जो आप देख सकते हैं (यह सूची अधूरी हो सकती है)। तलाश के लिए, आपको प्रत्येक क्वेरी पर एक अतिरिक्त तलाश मिलेगी (यह IOPS को बढ़ाता है)। स्कैन के लिए, परिणाम प्रदर्शन के लिए विनाशकारी हो सकते हैं क्योंकि आप संग्रह और लाइव टेबल दोनों को स्कैन कर सकते हैं। यहां वे विशिष्ट तरीके दिए गए हैं जिनसे आप ऑप्टिमाइज़र को देख सकते हैं:

• यदि आप visit%एक साथ तालिकाओं में शामिल होते हैं और visit.dataशामिल होने के मानदंड में शामिल नहीं होते हैं (यही कारण है कि आप वंचित करना चाहते हैं)। इस वजह से, आप अपने कुछ प्रश्नों को संशोधित करना चाह सकते हैं
• यदि आपको एक visit.dataऔर तालिका के बीच एक हैश मिलती है (उदाहरण के लिए एक दिनांक आयाम), तो आपको तालिकाओं का सही उन्मूलन नहीं मिल सकता है
• यदि आप संग्रहीत तालिकाओं पर डेटा एकत्र करने का प्रयास करते हैं
• यदि आप किसी भी चीज़ पर फ़िल्टर करते हैं visit.data, उदाहरण के लिए दृश्य की कुंजी पर सीधे तलाश करें।

अंतिम परिदृश्य के लिए, आप cidइस पर एक और चेक बाधा जोड़कर सबसे बुरे प्रभावों से खुद को बचा सकते हैं - यदि यह संभव है। आपने उल्लेख किया है कि cidतालिका में पंक्तियों की तारीखों और प्रगति के संबंध में "स्वच्छ" न होने का क्रम । हालाँकि, क्या आप एक तालिका बनाए रख सकते हैं जिसमें जानकारी है: " cidइस संख्या के बाद से ऊपर नहीं हैं visit.data" या समान? इसके बाद अतिरिक्त बाधा उत्पन्न हो सकती है।

इस बारे में सावधान रहने की एक और बात यह है कि विभाजन के दृश्य को क्वेरी करते समय समानांतर क्वेरीज़ बहुत सारे थ्रेड्स को खोल सकती हैं (जैसा कि दोनों "सब-टेबल" समान समानांतर ऑप्टिमाइज़ेशन के साथ सामने आएंगे)। उस कारणों के लिए, आप सर्वर पर MAXDOP या समानांतर चलने वाले प्रश्नों को सीमित कर सकते हैं।

वैसे, यदि आप प्रश्नों को अच्छी तरह से जानते हैं - तो आपको दो डेटाबेस में समान अनुक्रमित की आवश्यकता नहीं हो सकती है (यह मानता है कि आप 100% सुनिश्चित हैं कि आपको तालिकाओं का सही उन्मूलन मिल जाएगा)। आप कॉलम स्टोर के लिए उपयोग करने पर भी विचार कर सकते हैं ArchiveDb।

Answer 2

जिस तरह से हमने किया है वह पुराने डेटा को बैचों में एक नए बनाए गए डेटाबेस में लिखने और पुराने डेटा को लाइव डीबी से हटाने के लिए है। इस तरह दोनों डीबी सुलभ हैं। आप नए बनाए गए डेटाबेस का भी बैकअप ले सकते हैं और उत्पादन सर्वर से बड़े पदचिह्न को हटाने के लिए इसे कहीं और पुनर्स्थापित कर सकते हैं। आशा है कि आपकी आवश्यकताओं के लिए एक स्वीकार्य समाधान है।

Comments

आवेदन संगतता बनाए रखने के लिए ओपी को इससे आगे जाना होगा। क्या आपने प्रश्न पढ़ा है?

— जॉन सिगेल