30 मिलियन रिकॉर्ड एक दिन, एसक्यूएल सर्वर नहीं रख सकता है, अन्य प्रकार की डेटाबेस सिस्टम की आवश्यकता है?

Question

कुछ समय पहले मैंने अपने बहु-मिलियन उपयोगकर्ता वेबसाइट के लिए, हमारे ग्राहकों के लिए उपयोगकर्ता-क्रियाओं को लॉग और रिपोर्ट करने के लिए एक नई सांख्यिकी प्रणाली को सोचा था।

डेटाबेस-डिज़ाइन एक साधारण है, जिसमें एक विदेशी आईडी (200,000 अलग-अलग आईडी), एक डेटाटाइम फ़ील्ड, एक एक्शनआईडी (30 अलग-अलग आईडी), और दो मेटा-सूचना (केवल छोटे-छोटे) वाले दो फ़ील्ड होते हैं। । अन्य तालिकाओं में कोई बाधा नहीं है। इसके अलावा हमारे पास दो फ़ील्ड हैं जिनमें प्रत्येक 4 फ़ील्ड हैं, जिन्हें छोड़ा नहीं जा सकता है, क्योंकि जब उपयोगकर्ता छोटे इंडेक्स होते हैं तो उपयोगकर्ता टाइमआउट प्राप्त कर रहे हैं। विदेशी आईडी सबसे महत्वपूर्ण क्षेत्र है, क्योंकि प्रत्येक और प्रत्येक क्वेरी में यह क्षेत्र होता है।

हमने SQL सर्वर का उपयोग करना चुना, लेकिन कार्यान्वयन के बाद एक रिलेशनल डेटाबेस एकदम सही फिट नहीं लगता है, क्योंकि हम एक दिन में 30 मिलियन रिकॉर्ड नहीं डाल सकते हैं (यह केवल सम्मिलित है, हम कोई अपडेट नहीं करते हैं) जब भी डेटाबेस पर यादृच्छिक पढ़ने के बहुत सारे कर रहे हैं; क्योंकि इंडेक्स को पर्याप्त तेज़ी से अपडेट नहीं किया जा सकता है। Ergo: हमें एक बड़ी समस्या है :-) हमने अस्थायी रूप से समस्या हल की है, फिर भी

एक रिलेशनल डेटाबेस इस समस्या के लिए उपयुक्त नहीं प्रतीत होता है!

क्या बिगटेबल जैसे डेटाबेस बेहतर विकल्प होंगे, और क्यों? या इस तरह की समस्याओं से निपटने के दौरान बेहतर विकल्प हैं?

एनबी। इस बिंदु पर हम 4 जीबी मेमोरी और विन 2003 32-बिट के साथ एक एकल 8-कोर ज़ीऑन सिस्टम का उपयोग करते हैं। जहां तक ​​मुझे पता है RAID10 एससीएसआई। सूचकांक आकार तालिका आकार के बारे में 1.5x है।

Answer 1

आप कहते हैं कि आपका सिस्टम इंडेक्स के बिना प्रति सेकंड 3000 रिकॉर्ड डालने में सक्षम है, लेकिन केवल दो अतिरिक्त गैर क्लस्टर इंडेक्स के साथ 100 है। यदि 3k/s आपके आई/ओ परमिट के अधिकतम थ्रूपुट है, तो सिद्धांत में दो इंडेक्स जोड़ना थ्रूपुट को लगभग 1000-1500/सेकंड पर कम कर देता है। इसके बजाय आप 10 गुना अधिक गिरावट देखते हैं। उचित समाधान और उत्तर 'यह निर्भर करता है' और कुछ गंभीर समस्या निवारण और बाधा पहचान को निष्पादित करना होगा। इस बात को ध्यान में रखते हुए, अगर मैं अनुमान लगाता हूं, तो मैं दो संभावित अपराधी दूंगा:

ए। अतिरिक्त गैर-क्लस्टर इंडेक्स गंदे पृष्ठों के लेखन को अधिक आवंटन क्षेत्रों में वितरित करते हैं। समाधान क्लस्टर्ड इंडेक्स और प्रत्येक गैर-क्लस्टर इंडेक्स को अपने फ़ाइल समूह में रखना होगा और तीन फ़ाइल समूह को प्रत्येक को अलग-अलग LUNs पर RAID पर रखना होगा।

बी। गैर-क्लस्टर इंडेक्स की कम चयनकता पढ़ने और लिखने (मुख्य संघर्ष के साथ-साथ %lockres% conflicts) के बीच उच्च विवाद पैदा करती है जिसके परिणामस्वरूप दोनों प्रविष्टियों और चयनों के लिए लंबे समय तक लॉक प्रतीक्षा समय होता है। संभावित समाधान read committed snapshot mode के साथ SNAPSHOTs का उपयोग करेंगे, लेकिन version store (यानी tempdb में) IO के लॉट जोड़ने के खतरे के बारे में मुझे चेतावनी देना चाहिए जो पहले से ही उच्च आईओ तनाव के तहत हो सकता है। एक दूसरा समाधान रिपोर्टिंग के लिए database snapshots का उपयोग कर रहा है, वे कम आईओ तनाव का कारण बनते हैं और उन्हें बेहतर नियंत्रित किया जा सकता है (कोई tempdb संस्करण स्टोर शामिल नहीं है), लेकिन रिपोर्टिंग रीयल-टाइम डेटा पर नहीं है।

मुझे विश्वास है कि बी) संभावित कारण के रूप में, लेकिन मुझे फिर से उचित जांच और उचित रूट केस विश्लेषण की आवश्यकता पर जोर देना चाहिए।

'RAID10' एक बहुत सटीक वर्णन नहीं है।

• RAID 0 भाग में कितने स्पिंडल हैं? क्या वे कम धारीदार हैं?
• कितने एलयूएनएस?
• डेटाबेस लॉग कहां स्थित है?
• डेटाबेस कहां स्थित है?
• कितने विभाजन?
• tempdb कहां स्थित है?

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

Answer 2

आप पर्याप्त जानकारी प्रदान नहीं कर रहे हैं; मुझे यकीन नहीं है कि आप क्यों कहते हैं कि एक रिलेशनल डेटाबेस खराब फिट जैसा लगता है, इस तथ्य के अलावा कि अब आप प्रदर्शन समस्याओं का सामना कर रहे हैं। आरडीबीएमएस किस प्रकार की मशीन चल रहा है? यह देखते हुए कि आपके पास विदेशी आईडी है, ऐसा लगता है कि एक रिलेशनल डेटाबेस बिल्कुल है जिसे यहां कहा जाता है। एसक्यूएल सर्वर प्रति दिन 30 मिलियन आवेषणों को संभालने में सक्षम होना चाहिए, यह मानते हुए कि यह पर्याप्त हार्डवेयर पर चल रहा है।

Answer 3

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

क्या आपने SQL सर्वर में अनुक्रमित दृश्यों की तरह कुछ देखा है? वे मुख्य तालिका से अनुक्रमण को हटाने का एक अच्छा तरीका हैं, और इसे भौतिक दृश्य में ले जाएं।

Answer 4

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

हालांकि, मुझे आश्चर्य है कि आपको सभी 30 मिमी रिकॉर्ड स्टोर करना होगा या नहीं? क्या कुछ पूर्व-समेकित डेटा स्टोर करना बेहतर नहीं होगा?

Answer 5

आप तालिका को partitioned one बनाने का प्रयास कर सकते हैं। इस तरह इंडेक्स अपडेट पंक्तियों के छोटे सेट को प्रभावित करेगा। शायद दैनिक विभाजन पर्याप्त होगा। यदि नहीं, तो घंटे के अनुसार विभाजन का प्रयास करें!

Answer 6

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

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

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

Answer 7

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

Answer 8

आप यह नहीं कहते कि आवेषण कैसे प्रबंधित होते हैं। क्या वे बैच किए गए हैं या प्रत्येक आंकड़े अलग से लिखे गए हैं? क्योंकि एक ही ऑपरेशन में एक हजार पंक्तियों को डालने से शायद एक हज़ार अलग-अलग परिचालनों में एक पंक्ति को डालने से अधिक प्रभावी होगा। आप अभी भी कम या कम वास्तविक समय रिपोर्टिंग प्रदान करने के लिए पर्याप्त रूप से पर्याप्त रूप से सम्मिलित कर सकते हैं;)