पुराने डेटा का संग्रह

Question

वर्तमान में हम कुछ प्रदर्शन समस्याओं में चल रहे हैं क्योंकि हमारा डेटाबेस बहुत बड़ा हो रहा है। पिछले 10 वर्षों से संग्रहीत डेटा हैं और मुझे कोई कारण नहीं दिखता है कि 2 वर्ष से अधिक पुराने डेटा को नए डेटा के समान तालिकाओं में संग्रहीत किया जाना है।

अब चूंकि मेरे पास डेटाबेस को प्रबंधित करने का बहुत गहरा अनुभव नहीं है, इसलिए मैं पुराने डेटा को संग्रहीत करने के सर्वोत्तम तरीकों की तलाश कर रहा हूं।

---

जानकारी

• डेटाबेस में कुल मिलाकर लगभग 310'000'000 रिकॉर्ड हैं।

• हार्ड डिस्क पर डेटाबेस को 250 जीबी की आवश्यकता होती है।

• सर्वर संस्करण संगतता स्तर SQL Server 2005 (90) के साथ SQL Server 2008 है, लेकिन हम जल्द ही SQL Server 2012 में अपग्रेड करने की योजना बना रहे हैं

---

मैंने दो संभावनाओं के बारे में सोचा है:

नया डेटाबेस

उत्पादन सर्वर पर एक के समान डेटाबेस बनाएँ और नए डेटाबेस में सभी पुराने डेटा डालें।

• नुकसान: चूंकि लिंक किए गए सर्वरों को हमारे वातावरण में अनुमति नहीं है, इसलिए यदि आवश्यक हो तो पुराने डेटा से जुड़ना मुश्किल होगा

इतिहास स्कीमा

उत्पादन डेटाबेस में समान तालिकाओं के साथ एक नया स्कीमा fe [hist] बनाएं । नए स्कीमा में इन नए तालिकाओं में सभी पुराने डेटा डालें।

• फायदा: अगर भविष्य में पुराने डेटा की जरूरत होगी, तो इसमें आसानी होगी

---

---

• क्या आप एक के बाद एक समाधान निकालते हैं?
  • क्यूं कर?
• क्या कोई बेहतर संभावनाएं हैं?
• क्या ऐसे मौजूदा उपकरण हैं जिनके साथ यह कार्य आसानी से संभव है?
• कोई और विचार?

अग्रिम में धन्यवाद

संपादित करें

अतिरिक्त प्रश्न:

क्या नव निर्मित संग्रह तालिका को भी प्राथमिक / विदेशी कुंजी की आवश्यकता होगी?

या वे सिर्फ कॉलम होना चाहिए, लेकिन बिना चाबी / बाधाओं के?

Comments

यह शायद ध्यान देने योग्य है कि आप किस संस्करण का उपयोग कर रहे हैं, और std / ent आदि

— dwjv

इस संकेत के लिए धन्यवाद, मैंने अतिरिक्त जानकारी में संस्करण जोड़ा है। वास्तव में आप std / ent से क्या मतलब है? :-)

— ज़राफिम

मेरे माफी, मानक या उद्यम संस्करण।

— dwjv

आह ठीक है :-) यह एंटरप्राइज़ संस्करण है

— xeraphim

Answer 1

मुझे लगता है कि आपके कई सवालों का जवाब यह निर्भर करता है। आपको कौन सी प्रदर्शन समस्याएं हो रही हैं? यह असामान्य लगता है कि एक डेटाबेस में आकार में 250GB तक बढ़ने से प्रदर्शन समस्याएं होंगी।

शायद आपके सवाल पूरे तथ्य तालिका पर टेबल स्कैन कर रहे हैं, तब भी जब तिथि सीमा का केवल एक छोटा सा हिस्सा (जैसे, पिछले वर्ष) की आवश्यकता है? यदि कोई विशेष क्वेरी है जिसे ऑप्टिमाइज़ करना सबसे महत्वपूर्ण है, तो अपने स्कीमा, क्वेरी, और वास्तविक निष्पादन योजना को किसी अन्य प्रश्न में पोस्ट करने पर विचार करें, यह देखने के लिए कि क्या इसे अनुकूलित किया जा सकता है।

क्या आप दूसरे पर एक समाधान पसंद करते हैं?

मैं आम तौर पर इतिहास डेटाबेस को पसंद करता हूं, और मुझे लगता है कि गाय ने उसकी प्रतिक्रिया में इसके अच्छे कारणों का वर्णन किया है ।

एक इतिहास डेटाबेस (एक स्कीमा के विपरीत) के लिए मुझे जो प्राथमिक नुकसान दिखाई देता है वह यह है कि अब आप अपनी संग्रह तालिका के लिए विदेशी कुंजियों का उपयोग नहीं कर सकते। यह आपके लिए ठीक हो सकता है, लेकिन इसके बारे में जागरूक होना कुछ है।

इस दृष्टिकोण के लिए आपके द्वारा सूचीबद्ध नुकसान सही नहीं है; आप एक ही सर्वर पर आसानी से डेटाबेस में क्वेरी कर पाएंगे और क्वेरी ऑप्टिमाइज़र आमतौर पर क्रॉस-डेटाबेस क्वेरी को बहुत अच्छी तरह से हैंडल करता है।

क्या कोई बेहतर संभावनाएं हैं?

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

क्या नव निर्मित संग्रह तालिका को भी प्राथमिक / विदेशी कुंजी की आवश्यकता होगी? या वे सिर्फ कॉलम होना चाहिए, लेकिन बिना चाबी / बाधाओं के?

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

कोई और विचार?

चूंकि आप एंटरप्राइज़ संस्करण का उपयोग कर रहे हैं और SQL 2008+ में अपग्रेड करने की योजना बना रहे हैं, आप इस तालिका के लिए डेटा संपीड़न पर विचार कर सकते हैं । संपीड़न निश्चित रूप से डिस्क स्थान को कम कर देगा, लेकिन आपके सर्वर की डिस्क और सीपीयू संसाधनों के आधार पर यह डिस्क I / O को कम करके रीड मेमोरी के लिए क्वेरी प्रदर्शन को बेहतर कर सकता है (मेमोरी उपयोग अधिक डेटा एक बार में कैश में फिट बैठता है)।

Answer 2

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

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

Comments

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

— मैक्स वर्नोन

Answer 3

मेरे अनुभव में एक दूसरा डेटाबेस दो कारणों से पसंदीदा विकल्प होगा।

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

आपको अभी भी प्राथमिक डेटाबेस से सभी ऐतिहासिक डेटा को हटाने की आवश्यकता होगी लेकिन इसमें शेड्यूल किया जा सकता है।

Answer 4

अभी के लिए लाइसेंस को अनदेखा करना जहां मैं अपना समय नहीं बिता रहा हूं।

IMHO, संग्रह डेटाबेस है सबसे आसान लागू करने और बनाए रखने के लिए। वे अलग हैं, शिथिल युग्मित इकाइयाँ। डेटा आंदोलन और लोड / संसाधन नियंत्रण की स्पष्ट सीमाएं हैं। बेहतर प्रदर्शन प्रबंधन के लिए आसानी से एक अलग उदाहरण या सर्वर पर जा सकते हैं और लागत एक प्रमुख मुद्दा नहीं है। ध्यान दें कि सबसे सरल! = सबसे सस्ता या कम से कम प्रयास। यह वास्तव में एक बहुत अधिक कार्य है, लेकिन वे दो महत्वपूर्ण अपवादों के साथ सभी सरल कार्य कर रहे हैं:

1. बाधा प्रवर्तन - क्रॉस डेटाबेस में क्रॉस डेटाबेस जैसी कोई चीज नहीं है, इसलिए आपको यह तय करने की आवश्यकता है कि यह सौदा ब्रेकर है या नहीं।
2. क्रॉस डेटाबेस क्वेरीज़ वितरित डिस्ट्रीब्यूटर्स का उपयोग करती है जो अभी भी OLEDB पर निर्भर है जो कि वंचित है। इसका मतलब है कि आप नए डेटा प्रकारों के साथ समस्याओं का सामना कर सकते हैं और यदि आप प्रदर्शन के मुद्दों का सामना करते हैं, तो यह संभावना नहीं है कि वे कभी भी ठीक हो जाएंगे

पुरालेख स्कीमा या सिर्फ संग्रह तालिका लागू करने के लिए थोड़ा अधिक जटिल है लेकिन उपयोग करने के लिए बहुत आसान है। एक ही डेटाबेस में सभी वस्तुओं का मतलब है कि आपको एक्सेस कंट्रोल को दोहराने और बनाए रखने की आवश्यकता नहीं है। आसान प्रदर्शन ट्यूनिंग, निगरानी, ​​समस्या निवारण, आदि के लिए कोई क्रॉस डेटाबेस प्रश्न नहीं बना रहा है ...

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

कुछ महत्वपूर्ण विचार:

• क्या प्रश्न ऐतिहासिक / कोल्ड डेटा को नियमित रूप से लौटाते हैं या क्या कोल्ड डेटा को बार-बार एक्सेस किया जाता है?
• क्या ऐतिहासिक डेटा अपरिवर्तनीय है या इसे नियमित रूप से अपडेट / डिलीट किया जाता है?
• पंक्ति आकार के आधार पर 310 मीटर पंक्तियां "मध्यम" (सभी तालिका में सभी को मानते हुए) हैं। क्या आपके पास पंक्ति आकार का डेटा है? वह 310 GB पंक्ति कितनी है?
• उस तालिका की वृद्धि दर क्या है?
• क्या आप एप्लिकेशन कोड और उसके SQL प्रश्नों को संशोधित करने में सक्षम हैं?

ये महत्वपूर्ण विचार हैं क्योंकि वे आपके द्वारा चुने गए समाधान पर महत्वपूर्ण प्रभाव डाल सकते हैं या कुछ समाधानों की अनुमति भी नहीं दे सकते हैं। उदाहरण के लिए, यदि आपका ऐतिहासिक डेटा संशोधित / नियमित रूप से (सप्ताह में एक से अधिक बार) अद्यतन किया जाता है, तो एक अलग डेटाबेस का उपयोग करने का मतलब है कि आपको या तो उन प्रश्नों के लिए डीटीसी का उपयोग करना होगा या मैन्युअल रूप से लेनदेन सुरक्षा का प्रबंधन करना होगा (हमेशा सही करने का आश्वासन देने के लिए गैर तुच्छ)। लागत अपरिवर्तनीय ऐतिहासिक डेटा से काफी अधिक है।

इसके अलावा, यदि आप उन्नयन के बारे में सोच रहे हैं, तो 2016 पर विचार करें और नया स्ट्रेच डेटाबेस फीचर: https://msdn.microsoft.com/en-us/library/dn935011.aspx

Answer 5

मैं निम्नलिखित कारणों से एक अलग तार्किक डेटाबेस में डेटाबेस को विभाजित करना पसंद करूंगा:

1. संसाधन आवश्यकताएँ

इसे अलग डेटाबेस में विभाजित करके, इसे एक अलग ड्राइव पर संग्रहीत किया जा सकता है और मुख्य उत्पादन डेटा के लिए एक अलग दर पर निगरानी रखी जा सकती है।

2. प्रदर्शन

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

3. सरल बैकअप

मुख्य SQL डेटाबेस में संग्रहीत डेटा को 'live / current' रिकॉर्ड के रूप में आवश्यक नहीं समझा जा सकता है। इसका मतलब यह हो सकता है कि संग्रहीत डेटा को कम बार बैकअप दिया जा सकता है। यह भी कि कैसे संग्रहीत डेटा लॉग किया गया है की अनुक्रमिक प्रकृति के कारण, यह एक बार फिर संग्रहीत डेटाबेस के बैकअप अनुभागों के लिए संभव हो सकता है और फिर कभी नहीं। जैसे ही आर्काइव डेटा 2014 के लिए आर्काइव डेटाबेस में लिखा जाता है, उस डेटा में फिर कभी कोई बदलाव नहीं होगा।

नोट: मुझे लगता है कि आपके कई सवालों का जवाब आपकी परिस्थितियों, डेटा की प्रकृति और आपके द्वारा की जा रही प्रदर्शन समस्याओं पर निर्भर करता है।