SQL सर्वर में बड़ी तालिकाओं को विभाजित करने का सबसे अच्छा तरीका क्या है?

Question

हाल के एक प्रोजेक्ट में "लीड" डेवलपर ने डेटाबेस स्कीमा तैयार किया जहां "बड़े" टेबल को दो अलग-अलग डेटाबेसों में विभाजित किया जाएगा, जो मुख्य डेटाबेस पर एक दृश्य के साथ विभाजित होंगे जो दो अलग-अलग डेटाबेस-टेबल को एक साथ जोड़ देगा। मुख्य डेटाबेस वह है जो एप्लिकेशन को बंद कर दिया गया था, इसलिए इन तालिकाओं को सामान्य टेबल की तरह देखा और महसूस किया गया (अद्यतन करने के आसपास कुछ quirky चीजों को छोड़कर)। यह एक बड़ी प्रदर्शन समस्या की तरह लग रहा था। हमें इन तालिकाओं के चारों ओर प्रदर्शन के साथ समस्याएं दिखाई देती हैं लेकिन उन्हें अपने डिजाइन के बारे में अपना मन बदलने के लिए कुछ भी नहीं है। बस सोच रहा है कि ऐसा करने का सबसे अच्छा तरीका क्या है, या यदि यह करने योग्य भी है?

Answer 1

मुझे नहीं लगता है कि तुम सच एक ही सर्वर में एकाधिक डेटाबेस भर में मेज विभाजन से कुछ भी हासिल करने के लिए जा रहे हैं है। आपके द्वारा अनिवार्य रूप से किया गया है, एक ही SQL सर्वर उदाहरण के तहत कई उदाहरणों (यानी दो अलग-अलग डीबी में खुलते हैं) के साथ पहली बार "टेबल" के साथ काम करने में ओवरहेड बढ़ा दिया गया है।

आपके पास कितने डेटासेट हैं? मेरे पास SQL ​​सर्वर में 6 मिलियन पंक्ति तालिका वाला क्लाइंट है जिसमें 2 साल के बिक्री डेटा शामिल हैं। वे इसे लेनदेन के लिए और किसी भी उल्लेखनीय गति समस्याओं के बिना रिपोर्टिंग के लिए उपयोग करते हैं।

ट्यूनिंग अनुक्रमित और सही संकुल अनुक्रमणिका चुनने निश्चित रूप से प्रदर्शन के लिए महत्वपूर्ण है।

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

Answer 2

SQL सर्वर का कौन सा संस्करण आप उपयोग कर रहे हैं? एसक्यूएल सर्वर 2005 ने टेबल को विभाजित किया है, लेकिन 2000 (या 7.0) में आपको विभाजन दृश्यों का उपयोग करने की आवश्यकता है।

इसके अलावा, एक अलग डेटाबेस में तालिका विभाजन डालने के लिए तर्क क्या था?

जब मैं अतीत (पूर्व 2005) में तालिकाओं विभाजन किया है, यह एक तारीख स्तंभ या कुछ इसी तरह से आम तौर पर है, विभिन्न विभाजन के दृश्य के साथ। पुस्तकें ऑनलाइन में एक ऐसा अनुभाग है जो इस बारे में बात करता है कि इसके आसपास और उसके आसपास के सभी नियम कैसे हैं। इसे काम करने के लिए आपको नियमों का पालन करना होगा कि इसे कैसे काम करना चाहिए।

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

एमएसडीएन में "विभाजित तालिका" देखें और आपको SQL सर्वर 2005 विभाजन तालिकाओं के साथ-साथ अधिकतम प्रदर्शन के लिए उन्हें सेट अप करने के बारे में सलाह के लिए एक और पूर्ण ट्यूटोरियल ढूंढने में सक्षम होना चाहिए।

Answer 3

आप डेटाबेस डिजाइन के मामले में के बारे में सर्वोत्तम प्रथाओं पूछ रहे हैं, या अपने नेतृत्व अपने मन बदल समझाने? :)

डिज़ाइन के संदर्भ में ... वापस पुराने समय में, लंबवत विभाजन को कभी-कभी डेटाबेस इंजन सीमाओं के आसपास काम करने की आवश्यकता होती थी, जहां तालिका में स्तंभों की संख्या 255 कॉलम की तरह एक कठिन सीमा थी। इन दिनों मुख्य लाभ प्रदर्शन के लिए पूरी तरह से हैं: एक अलग डिस्क सरणी पर शायद ही कभी इस्तेमाल किए गए कॉलम, या ब्लब्स डालते हैं। लेकिन अगर आप नियमित रूप से दोनों टेबलों से चीजें खींच रहे हैं तो यह एक नुकसान होगा। ऐसा लगता है जैसे आपकी लीड समयपूर्व अनुकूलन के मामले से पीड़ित है।

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

'तालिका 1 को चयन करें * के रूप में चुनें' के साथ कहीं भी एक नई भौतिक तालिका बनाएं और फिर लंबवत विभाजित तालिका और अपनी नई तालिका के साथ कुछ लंबा बैच चलाएं। यदि आप कहते हैं कि यह बुरा है, तो अंतर स्पष्ट होना चाहिए।

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

Answer 4

विभाजन कुछ हल्के ढंग से नहीं किया जाना चाहिए क्योंकि कई सूक्ष्म प्रदर्शन प्रभाव हो सकते हैं।

मेरा पहला सवाल यह है कि आप अलग-अलग फ़ाइल ग्रुप (अलग स्पिंडल पर) में बड़ी टेबल ऑब्जेक्ट्स रखने के लिए सरल संदर्भ दे रहे हैं या आप तालिका ऑब्जेक्ट के अंदर डेटा विभाजन का जिक्र कर रहे हैं?

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

मैं SQL सर्वर पुस्तकें ऑनलाइन में फ़ाइल समूह समूह में देखने वाली बड़ी तालिकाओं को रखने के लिए अतिरिक्त डेटाबेस का उपयोग करने के बजाय सुझाव देता हूं या त्वरित समीक्षा के लिए इस आलेख को देखता हूं: http://www.mssqltips.com/tip.asp?tip=1112।

यदि आप डेटा विभाजन (एकाधिक फ़ाइल समूहों में विभाजन सहित) में रूचि रखते हैं तो मैं किम्बर्ली ट्रिप द्वारा लेख पढ़ने की अनुशंसा करता हूं, जिसने SQL Server 2005 उस समय उपलब्ध सुधारों के बारे में एक उत्कृष्ट प्रस्तुति दी थी। शुरू करने के लिए एक अच्छी जगह यह श्वेतपत्र है: http://www.sqlskills.com/resources/Whitepapers/Partitioning%20in%20SQL%20Server%202005%20Beta%20II.htm।

Answer 5

मैं इस धारणा से असहमत हूं कि विभाजन द्वारा कुछ भी प्राप्त नहीं किया जा सकता है।

यदि विभाजन डेटा भौतिक रूप से और तार्किक रूप से गठबंधन है, तो प्रश्नों की संभावित आईओ नाटकीय रूप से कम होनी चाहिए।

उदाहरण के लिए: हमारे पास एक सारणी है जिसमें एक आईएनटी का प्रतिनिधित्व करने वाले आईएनटी के रूप में बैच फ़ील्ड है।

हम इस क्षेत्र से डेटा विभाजन और उसके बाद एक विशेष बैच के लिए एक प्रश्न को फिर से चलाने, तो हम पहले और विभाजन के बाद IO पर आंकड़े सेट चलाने के लिए और आईओ में कमी को देखने के लिए सक्षम होना चाहिए,

हैं हमारे पास प्रति विभाजन दस लाख पंक्तियां हैं और प्रत्येक विभाजन एक अलग डिवाइस पर लिखा गया है। क्वेरी गैर निबंध विभाजन को खत्म करने में सक्षम होना चाहिए।

मैंने SQL सर्वर पर बहुत से विभाजन नहीं किए हैं, लेकिन मुझे साइबेस एएसई पर विभाजन का अनुभव है, और इसे विभाजन उन्मूलन के रूप में जाना जाता है। जब मेरे पास समय होता है तो मैं SQL सर्वर 2005 मशीन पर परिदृश्य का परीक्षण करने जा रहा हूं।

Answer 6

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

हालांकि, SQL सर्वर में ओरेकल के विपरीत सीमित विभाजन क्षमता है। आप विभाजन के लिए केवल एक कॉलम चुन सकते हैं (यहां तक ​​कि एसक्यूएल 2008 में भी)। तो आपको बुद्धिमानी से एक कॉलम चुनना होगा जहां वह कॉलम आपके लगातार प्रश्नों का हिस्सा भी है। अधिकांश भाग के लिए लोगों को दिनांक कॉलम द्वारा विभाजन चुनना आसान लगता है। हालांकि, इस तरह विभाजन के लिए तार्किक लगता है, अगर आपके प्रश्नों में उस कॉलम के हिस्से के रूप में कॉलम नहीं है, तो आपको विभाजन से पर्याप्त लाभ नहीं मिलेगा (दूसरे शब्दों में, आपकी क्वेरी बिना किसी विभाजन को प्रभावित करेगी)।

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

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