2009-12-04 12 views
5

मैंने कभी यह कोशिश नहीं की है - इसलिए मुझे नहीं पता कि मैं स्मृति समस्याओं में भाग लेगा या नहीं।SQL सर्वर और SqlDataReader - ट्रिलियन रिकॉर्ड्स - मेमोरी

लेकिन क्या एक एसक्लडाटा रीडर एक ट्रिलियन रिकॉर्ड पढ़ सकता है? यह सब सही स्ट्रीम किया गया है? एसक्यूएल/टीडीएस प्रोटोकॉल कवर के तहत क्या कर रहा है, मैं थोड़ा हरा हूं।

अद्यतन ट्रिलियन का अनुवाद बहुत बड़ी संख्या में करें। मुझे शायद 1 अरब या 100 मिलियन की तरह कुछ कहना चाहिए था।

+4

क्या आप ट्रिलियन रिकॉर्ड पढ़ने की योजना बना रहे हैं? या यह सिर्फ ब्याज के लिए है? – gbn

उत्तर

10

हाँ, यह स्ट्रीम करेगा ... लेकिन मुझे नहीं लगता कि आपको वास्तव में ऐसा करने का प्रयास करना चाहिए।

यदि आप प्रति सेकंड एक लाख रिकॉर्ड पढ़ सकते हैं (जो मुझे असंभव लगता है) तो आपको अभी भी ट्रिलियन रिकॉर्ड पढ़ने के लिए 12 दिन की आवश्यकता होगी ... यह आधे रास्ते से हारने का जोखिम उठाने के लिए बहुत सारे काम है।

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

+0

तो मेरा मूल प्रश्न यह होगा कि ADO.NET और SQL सर्वर के लिए सबसे अच्छी बैचिंग रणनीति क्या है ... तो एक समय में 1000 रिकॉर्ड से निपटने का सबसे अच्छा तरीका क्या है। मान लें कि आप MapReduce प्रकार की गतिविधि कर रहे हैं। मुझे एहसास है कि इस के लिए अन्य टूल्स हैं (ओपन एंड कमर्शियल) लेकिन अगर आप जिस कंपनी के लिए काम कर रहे हैं, तो आप उन्हें इस्तेमाल नहीं करने देंगे ... वे मुझे अच्छा नहीं करते हैं। (विचारों को उधार लेने की कोशिश करने के अलावा) – BuddyJoe

+0

12 दिनों +1 के बारे में अच्छी बात। शायद मैंने बहुत अधिक संख्या में उठाया। – BuddyJoe

+0

ईमानदार होने के लिए, सर्वश्रेष्ठ बैचिंग रणनीति कार्य की सटीक प्रकृति पर निर्भर करेगी। क्या आप विश्वसनीय रूप से इसे बैच में विभाजित कर सकते हैं भले ही प्रश्न बाद की तारीख में चल रहे हों? क्या आप इसे समय से पहले बैचों में विभाजित कर सकते हैं, और विभिन्न कंप्यूटरों को अलग-अलग बैच दे सकते हैं? क्या इस डेटा को और कुछ लिख रहा है? क्या उचित इंडेक्स हैं? असल में यह आपके डेटा को एक क्वेरी करने योग्य और कुशल रूप में विभाजित करने का एक तरीका काम करने का एक मामला है। –

1

हां - इसमें कुछ समय लग सकता है (जब तक आपका एसक्यूएल स्नैपशॉट या कुछ भी लेने की कोशिश कर मूर्खतापूर्ण कुछ नहीं कर रहा हो), लेकिन यदि आपका सर्वर इसे स्ट्रीम कर सकता है, तो SqlDataReader में स्मृति उपयोग नहीं होना चाहिए मुसीबत।

13

कुछ विवरण हैं।

  • SqlDataReader सामान्य रूप से स्मृति में एक पूरी पंक्ति पढ़ेगा और इसे कैश करेगा। इसमें किसी भी बीएलओबी फ़ील्ड शामिल हैं, ताकि आप स्मृति में कई 2 जीबी फ़ील्ड कैश कर सकें (एक्सएमएल, वर्बिनरी (MAX), वर्चर (MAX), एनवीएआरएआरएआर (MAX))। यदि ऐसे क्षेत्र चिंता का विषय हैं तो आपको CommandBehavior.SequentialAccess से ExecuteReader में पास करना होगा और SqlClient विशिष्ट प्रकारों की स्ट्रीमिंग क्षमताओं का उपयोग करना होगा जैसे SqlBytes.Stream

  • SqlDataReader पूरा होने तक एक कनेक्शन व्यस्त है। यह लेनदेन संबंधी समस्याएं पैदा करता है क्योंकि आप उसी ट्रांससिटॉन में डेटाबेस में किसी भी प्रसंस्करण में सक्षम नहीं होंगे, क्योंकि कनेक्शन व्यस्त है। एक अलग कनेक्शन खोलने की कोशिश कर रहे हैं और उसी लेनदेन में नामांकन विफल हो जाएगा, क्योंकि लूप बैक वितरित ट्रांससिटन्स प्रतिबंधित हैं। लोटियन MARS का उपयोग करना है। आप कनेक्शन पर MultipleActiveResultSets=True सेट करके ऐसा करते हैं। यह आपको पर कनेक्शन पर कमांड जारी करने की अनुमति देता है जबकि डेटा रीडर अभी भी सक्रिय है (सामान्य fetch-process-fetch लूप)। क्रिश्चियन क्लेनमैन के साथ बहुत अच्छी देखभाल के लिंक को पढ़ें, सुनिश्चित करें कि आप एमएआरएस और लेनदेन के आसपास के मुद्दों और प्रतिबंधों को समझते हैं, वे काफी सूक्ष्म और काउंटर अंतर्ज्ञानी हैं।

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

  • लेनदेन का आकार। एक लेनदेन पर एक ट्रिलियन रिकॉर्ड प्रसंस्करण करना कभी काम नहीं करेगा। लॉग को संपूर्ण लेनदेन को समायोजित करने के लिए बढ़ना होगा और वीएलएफ को छोटा और पुन: उपयोग नहीं करेगा, जिसके परिणामस्वरूप विशाल लॉग वृद्धि होगी।

  • रिकवरी समय। यदि 999 बिलियन रिकॉर्ड में प्रसंस्करण विफल हो जाता है तो उसे सभी कामों को रोलबैक करना होगा, इसलिए यह रोलबैक के लिए एक और '12' दिन लेगा।

+0

बहुत अच्छी जानकारी। +1 यदि डेटा को केवल अंततः संगत होने की आवश्यकता है तो सिस्टम में लेन-देन क्या भूमिका निभाता है? एक बार में 1000 या 10000 बैच प्रक्रिया का उचित तरीका क्या है? (जॉन स्कीट को टिप्पणियां देखें) – BuddyJoe

+0

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