2010-06-29 4 views
5

कारण मैं इस सवाल से पूछ रहा हूं क्योंकि हम एक SQL सर्वर डेटाबेस से डेटा के एक एलओटी (कई जीबी) डेटा को प्रोसेसिंग के लिए .NET ऐप में पढ़ने की योजना बना रहे हैं। मैं जानना चाहता हूं कि हमारे नेटवर्क यातायात पर असर का आकलन करने के लिए प्रत्येक रिकॉर्ड के लिए कितना स्पेस ओवरहेड गणना करना है।SQL सर्वर डेटा को नेटवर्क के माध्यम से भेजे जाने पर किस प्रारूप में क्रमबद्ध किया गया है?

उदा। एक रिकॉर्ड में 5 पूर्णांक होते हैं (जो डेटा के 4 * 5 = 20 बाइट बनाता है)। प्रति रिकॉर्ड शारीरिक रूप से कितने बाइट स्थानांतरित होते हैं? क्या एक सटीक सूत्र या अंगूठे का नियम है?

+0

दरअसल, यदि आप 5 int स्थानांतरित करते हैं, तो आपको हमेशा हस्तांतरित 80 9 2 बाइट मिलेगा। SQL सर्वर 8K के पृष्ठों में व्यवस्थित है - आपको कभी भी 8K ब्लॉक से कम नहीं मिलेगा। –

+0

@marc_s: क्या आप आईओ और मेमोरी के बारे में सोच रहे हैं? – gbn

+0

@ जीबीएन: वह - प्लस यदि आपके पास दुर्भाग्यपूर्ण लेआउट होता है, तो आप अपने 8 के पेज के 4100 बाइट्स का उपयोग कर सकते हैं, और इस प्रकार आपके पास लगभग 50% "स्लैक"/रिक्त स्थान होगा जो प्रत्येक कॉल के साथ आता है। –

उत्तर

10

SQL सर्वर TDS protocol का उपयोग करता है। और MSDN

स्पष्ट रूप से, मैं इसके बारे में चिंता नहीं करता। जीबीएस डेटा में कोई फर्क नहीं पड़ता दुर्भाग्य से यह कैसे किया गया है

+0

धन्यवाद, "टैब्यूलर डेटा स्ट्रीम प्रोटोकॉल विशिष्टता" के लिए एमएसडीएन लिंक वास्तव में सहायक है (भले ही यह 154 पृष्ठों के साथ काफी संपूर्ण है!) – Manu

4

मुझे वास्तविक प्रारूप के बारे में कोई जानकारी नहीं है, लेकिन मैं एक अनुभवजन्य दृष्टिकोण का सुझाव दूंगा और Wireshark को हुक कर दूंगा और डेटा को माप सकता हूं।

+0

यह एक सहायक टिप्पणी है, उत्तर नहीं। – Manu

+0

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

4

पीटर एम ने कहा, इसका परीक्षण करें।

वास्तविक वास्तविक गणना नहीं है जो आप कर सकते हैं जो आपको काम करने के लिए पर्याप्त जानकारी देगा।

वास्तविकता यह है कि विचार करने के लिए बहुत सारे चर हैं। उदाहरण के लिए:

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

प्रश्न में दो मशीनों के बीच उपकरण के अन्य टुकड़े क्या हैं? फिर, हार्डवेयर, ओएस आदि के आधार पर, आप जंगली रूप से अलग-अलग संख्या देख सकते हैं। ट्रेंडनेट से $ 100 8 पोर्ट 1 जीबी अप्रबंधित स्विच $ 5000 1 जीबी सिस्को प्रबंधित स्विच की तुलना में पूरी तरह से अलग थ्रूपुट होने जा रहा है।

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

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

अगला, हार्ड ड्राइव को ध्यान में रखना होगा। यह ध्यान में रखते हुए डेटा की एक बड़ी मात्रा है, फिर विभिन्न हार्ड ड्राइव की पढ़ने और लिखने की गति का असर होगा। निश्चित रूप से नेटवर्क वास्तव में 90% दक्षता पर चलने में सक्षम हो सकता है, लेकिन यदि आप बड़ी मात्रा में डेटा की बात कर रहे हैं, तो हार्ड ड्राइव स्वयं को बनाए रखने में सक्षम नहीं हो सकती है और इसलिए इसे 25% दक्षता या उससे कम करने का कारण बनता है।

प्वाइंट है, आपको इसका परीक्षण करना होगा और दिन के अंत में, SQL सर्वर का प्रोटोकॉल आपके निष्कर्षों के लिए असत्य होगा। और केवल एक परीक्षण नहीं चलाएं, वास्तविक विश्व परीक्षणों के लॉट चलाएं। तभी आप औसत के साथ आ सकेंगे; जो कि उस समय जो भी हो रहा है उसके आधार पर अभी भी बंद हो सकता है, लेकिन आपको 10% के भीतर प्रवेश करने में सक्षम होना चाहिए।

+0

अंतिम नोट आप इस पोस्ट को देखना चाहते हैं: http://www.codinghorror.com/ ब्लॉग/2005/07/गीगाबिट-ईथरनेट-एंड-बैक-ऑफ-द-लिफाफा-कैलकुलेशन.html – NotMe

0

मेरे अवलोकनों से, मानक एसक्यूएल कमांड बहुत सारे दौर-यात्रा का कारण बनता है। तो बहुत सारे डेटा को स्थानांतरित करने के लिए यह मदद करता है अगर आप इसे एक टेबल अपलोड करने के रूप में पुन: स्थापित कर सकते हैं। फिर आप थोक प्रतिलिपि ऑपरेशन का उपयोग कर सकते हैं, जो कि अधिक कुशल है। देखें: Bulk Copy Operations in SQL Server (ADO.NET) और bcp Utility

+0

थोक प्रतिलिपि ऑपरेशंस केवल प्रासंगिक होते हैं जब SQL सर्वर को लिखते हैं, जब डेटा से पढ़ते समय – Manu

+0

@Manu: हाँ। लेखन करते समय प्रदर्शन में अंतर बहुत बड़ा है। लेकिन मैंने पढ़ने के दौरान भी काफी गति देखा है। मुझे लगता है कि यह आपके परिदृश्य पर निर्भर करता है। –

0

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

कुल मिलाकर, यदि आप कभी भी एक प्रश्न पूछने के लिए आते हैं, तो इसका मतलब है कि आप इसे गलत कर रहे हैं।

संबंधित मुद्दे