किसी भी डेटाबेस पर भारी लेनदेन को संभालने के तरीके?

Question

मेरे पास एक डेटा ट्रांसफॉर्मेशन उत्पाद है, जो डेटाबेस में एक टेबल का चयन करता है और स्रोत डेटाबेस में पंक्ति डेटाबेस को गंतव्य डेटाबेस में बदल देता है।

यह एक समय में 1000 पंक्तियों को संसाधित करके और इसे 10 धागे समानांतर करके वर्तमान उत्पाद (जावा आधारित वर्कबेंच और इंजन) में संभाला जाता है। यह दृष्टिकोण छोटे डेटा सेट पर ठीक काम करता है। इस दृष्टिकोण अभी भी काम करता है, लेकिन

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

मैंने समाधान की तलाश शुरू कर दी और मैं हार्डवेयर को "गोमांस" "स्रोत/गंतव्य डेटाबेस सर्वर मशीनों पर। इसमें शामिल है, एक नया मल्टी-कोर सीपीयू और कुछ अतिरिक्त रैम खरीदना। बाहर निकलता है, हार्डवेयर को अपग्रेड करना केवल एकमात्र चिंता नहीं थी: डेटाबेस के लिए कई सॉफ़्टवेयर लाइसेंस प्राप्त करने की आवश्यकता थी - बहु-कोर प्रोसेसर (प्रति कोर लाइसेंस) के लिए धन्यवाद।

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

1. पढ़ना डेटा

   Approach1, एक अस्थायी मध्यम (फाइल) के लिए यह बने: इस समय, मैं बहुत बड़ा भार से निपटने के लिए एक संभावित दृष्टिकोण के बारे में सोच सकता है।

2. फ़ाइल वितरित करने के लिए स्विच करने के "व्यापार-बंद चाल" को संभालने के द्वारा, एक वितरित वातावरण (सस्ता सिंगल कोर मशीन) में इसे चलाकर, लगातार फ़ाइल में डेटा को ट्रांसफॉर्म करें। (वितरित कंप्यूटिंग भाग को संभालने के लिए अपाचे हैडोप जैसे कुछ का उपयोग करना)
3. किसी गंतव्य डेटाबेस में डेटा लिखना।

यह सब कुछ मैं वास्तुशिल्प परिप्रेक्ष्य से अब के लिए आ सकता हूं। क्या आपने पहले इस स्थिति को संभाला है? यदि हां, तो आपने इसे कैसे संभाला? अपने सुझावों और सहायता की सराहना करते हैं।

Answer 1

चीजें हैं जो आप अपने डेटाबेस लाइसेंस लागत में वृद्धि के बिना कर सकता है के एक जोड़े हैं:

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

यदि आप थोक सम्मिलित करने के बजाय डालने का उपयोग कर रहे हैं तो भी एक बड़ी सुधार क्षमता है। सामान्य सम्मिलन की समस्या यह है कि यह लॉग को जानकारी लिखता है ताकि लेनदेन को रोलबैक करना संभव हो।

this मामले में मैं 6 मिनट को :)

Answer 2

यहां सोचने वाली पहली बात यह है कि यदि आपको वास्तव में इस डेटा के लिए लेनदेन की आवश्यकता है। यदि उत्तर नहीं है, तो आपके डेटाबेस उत्पाद में एक थोक सम्मिलन विकल्प होता है जो इस प्रकार के बड़े डेटाबेस सम्मिलन के लिए बनाया जाता है।

संपादित करें (टिप्पणियों के लिए आगे): मुझे लगता है कि आपके हिरण (SQL सर्वर में वैसे भी) के लिए सबसे अधिक धमाका ऑपरेशन की अवधि के लिए लक्ष्य पुनर्प्राप्ति मोड को लक्षित डेटाबेस सेट करना होगा। वास्तव में, यदि आपने ऐसा किया है, तो संभव है कि आपको कोई अन्य कोड परिवर्तन नहीं करना पड़ेगा।

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

Answer 3

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

Answer 4

फूट डालो मदद किसी 10 घंटे से लोड समय को कम करने और जीत के लिए कर रहा था!

यदि स्रोत डीबी एक बार (ईटीएल और "नियमित" लेन-देन) में दोनों नौकरियों को संभाल नहीं सकता तो यह पीड़ित नहीं बनाते हैं: एक "दर्पण" के लिए

• कॉपी स्रोत डेटा।
• "दर्पण" पर ईटीएल करें।

एनबी - जब मैं कहता हूँ "दर्पण" मैं बस एक प्रति है कि डाटा का तेजी से और कुशल नकल (एक "का मंचन" डीबी की तरह एक बिट) की अनुमति देता है मतलब - नहीं एक और बड़ा/धीमी गति से/बुरा ETL प्रक्रिया । स्रोत डीबी को लाभ पहुंचाने के लिए प्रक्रिया को अनुकूलित करने का विचार यहां है।

फिर, आप लक्षित डीबी को लाभ पहुंचाने के लिए लक्ष्य डीबी को ईटीएल अनुकूलित कर सकते हैं; क्योंकि आपने स्रोत और लक्ष्य को छेड़ा है, इसलिए ओवरल प्रक्रिया के पढ़ने/सम्मिलित हिस्सों को अनुकूलित करना आसान होगा।

आप लक्ष्य अंत में भी एक ही चीज़ कर सकते हैं (एक और "दर्पण"/स्टेजिंग डीबी का उपयोग करके)।

यह दृष्टिकोण आपके द्वारा सुझाए गए कार्यों से अलग नहीं है, लेकिन मुझे लगता है कि के दो समान डीबी के बीच डेटा की सीधी प्रतिलिपि पर उसी प्रकार प्रबंधन और सबसे कुशल दोनों के लिए सबसे आसान होगा।

इसके बाद आप कुछ अन्य सुझावों को लागू करना शुरू कर सकते हैं जिन्हें अन्य आगे बढ़ा सकते हैं।

एक आखिरी बात - आप ETL उपकरण के साथ प्रयोग कर सकता है - अगर आप

Answer 5

Oracle SQL लोडर (आयात/निर्यात) का उपयोग चला रहे हैं। एक मध्यवर्ती तालिका में डेटा आयात करें और बैकअप के रूप में मुख्य तालिका का नाम बदलने के बाद मुख्य तालिका के रूप में तालिका को अच्छी तरह से नामित करने के बाद। याद रखें कि आपको प्रत्येक आयात/अपलोड के बाद ही बाधाओं को लागू करना चाहिए।आप जावा प्रोग्राम से एसक्यूएल लोडर को कॉल कर सकते हैं।