मल्टी थ्रेडिंग डेटाबेस रीडिंग

नेटवर्क

सबसे पहले, पंक्तिबद्ध . का उपयोग करने के बाद से और राउनम वैसे भी विक्रेता-लॉक है, आपको डेटाबेस संग्रहीत दिनचर्या का उपयोग करने पर विचार करना चाहिए। यह डेटाबेस से एप्लिकेशन सर्वर तक डेटा ट्रांसमिट करने के ओवरहेड को काफी कम कर सकता है (विशेषकर यदि वे विभिन्न मशीनों पर हैं और नेटवर्क के माध्यम से जुड़े हुए हैं)।

यह देखते हुए कि आपके पास संचारित करने के लिए 80 मिलियन रिकॉर्ड हैं, यह आपके लिए सबसे अच्छा प्रदर्शन बढ़ावा हो सकता है, हालांकि यह आपके थ्रेड द्वारा किए जाने वाले काम पर निर्भर करता है।

स्पष्ट रूप से बैंडविड्थ बढ़ाने से नेटवर्किंग समस्याओं को हल करने में भी मदद मिलेगी।

डिस्क प्रदर्शन

कोड में परिवर्तन करने से पहले कार्य के दौरान हार्ड ड्राइव लोड की जांच करें, शायद यह इतना I/O (एक साथ पढ़ने वाले 10 थ्रेड) को संभाल नहीं सकता है।

SSD/RAID या क्लस्टरिंग डेटाबेस में माइग्रेट करने से समस्या हल हो सकती है। आपके द्वारा डेटाबेस तक पहुँचने के तरीके को बदलते समय उस स्थिति में नहीं होगा।

मल्टीथ्रेडिंग CPU समस्याओं को हल कर सकता है, लेकिन डेटाबेस ज्यादातर डिस्क सिस्टम पर निर्भर करते हैं।

राउनम

यदि आप इसे पंक्तिबद्ध और राउनम का उपयोग करके कार्यान्वित कर रहे हैं तो आपको कुछ समस्याओं का सामना करना पड़ सकता है।

1) राउनम प्रत्येक क्वेरी के परिणामों के लिए फ्लाई पर उत्पन्न होता है। इसलिए यदि क्वेरी में स्पष्ट सॉर्टिंग नहीं है और यह संभव है कि हर बार जब आप क्वेरी चलाते हैं तो कुछ रिकॉर्ड में अलग-अलग राउनम होते हैं।

उदाहरण के लिए आप इसे पहली बार चलाते हैं और इस तरह के परिणाम प्राप्त करते हैं:

some_column | rownum
____________|________
     A      |    1
     B      |    2
     C      |    3

फिर आप इसे दूसरी बार चलाते हैं, क्योंकि आपके पास स्पष्ट छँटाई नहीं है, dbms (किसी कारण से खुद को ज्ञात) इस तरह के परिणाम वापस करने का निर्णय लेता है:

some_column | rownum
____________|________
     C      |    1
     A      |    2
     B      |    3

2) बिंदु 1 का अर्थ यह भी है कि यदि आप rownum . पर परिणाम फ़िल्टर कर रहे हैं यह सभी . के साथ अस्थायी तालिका उत्पन्न करेगा परिणाम और फिर इसे फ़िल्टर करें

तो राउनम परिणामों को विभाजित करने के लिए एक अच्छा विकल्प नहीं है। जबकि पंक्तिबद्ध बेहतर लग रहा था, इसमें कुछ समस्याएं भी हैं।

रोविड

अगर आप ROWID विवरण देखें आप देख सकते हैं कि "पंक्तिबद्ध मान विशिष्ट रूप से डेटाबेस . में एक पंक्ति की पहचान करता है ".

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

तो उदाहरण के लिए यदि आपके पास तीन धागे हैं और प्रत्येक 1'000'000 पंक्ति प्राप्त कर रहे हैं, तो यह संभव है कि एक को 1'000'000 रिकॉर्ड और अन्य दो 1 रिकॉर्ड प्रत्येक प्राप्त होंगे। तो एक अभिभूत हो जाएगा, जबकि दो अन्य भूखे ।

आपके मामले में यह कोई बड़ी बात नहीं हो सकती है, हालांकि यह वह समस्या हो सकती है जिसका आप वर्तमान में प्राथमिक कुंजी पैटर्न के साथ सामना कर रहे हैं।

या यदि आप पहले डिस्पैचर में सभी पंक्तियों को लाते हैं और फिर उन्हें समान रूप से विभाजित करते हैं (जैसे peter.petrov ने सुझाव दिया) जो काम कर सकता है, हालांकि 80 मिलियन आईडी प्राप्त करना अभी भी बहुत कुछ लगता है, मुझे लगता है कि एक के साथ विभाजन करना बेहतर होगा sql-क्वेरी जो विखंडू के बॉर्डर लौटाती है।

या आप प्रति कार्य कम मात्रा में पंक्तियाँ देकर और जावा 7 में पेश किए गए फोर्क-जॉइन फ्रेमवर्क का उपयोग करके उस समस्या को हल कर सकते हैं, हालांकि यह होना चाहिए इस्तेमाल किया हुआ ध्यान से ।

यह भी स्पष्ट बिंदु:दोनों पंक्तिबद्ध और पंक्तिबद्ध डेटाबेस में पोर्टेबल नहीं हैं।

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

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

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