Azure Table Storage से 100 मिलियन पंक्तियों को डाउनलोड करने के लिए कैसे करें

Question

मुझे Azure Table Storage से डेटा की लगभग 100 मिलियन पंक्तियों को डाउनलोड करने का कार्य सौंपा गया है। यहां गति की महत्वपूर्ण बात है।

हम जिस प्रक्रिया का उपयोग कर रहे हैं वह एज़ूर टेबल स्टोरेज से 10,000 पंक्तियों को डाउनलोड कर रहा है। एसक्यूएल सर्वर के स्थानीय उदाहरण में उन्हें संसाधित करें। पंक्तियों को संसाधित करते समय यह Azure तालिका से एक समय में 100 पंक्तियों को हटा देता है। इस प्रक्रिया को एक समय में 10,000 पंक्तियों को डाउनलोड करने के लिए 8 धागे होने के लिए थ्रेड किया गया है।

इसकी एकमात्र समस्या यह है कि हमारी गणना के अनुसार। हमारे द्वारा संग्रहीत लगभग 100 मिलियन पंक्तियों को डाउनलोड और संसाधित करने में लगभग 40 दिन लगेंगे। क्या कोई इस कार्य को पूरा करने के लिए एक तेज़ तरीका जानता है?

एक साइड प्रश्न: डाउनलोड प्रक्रिया के दौरान Azure वापस XML भेज देगा कि इसमें कोई डेटा नहीं है। यह एक त्रुटि वापस नहीं भेजता है। लेकिन यह भेजता है:

<?xml version="1.0" encoding="utf-8" standalone="yes"?> 
<feed xml:base="azure-url/" xmlns:d="http://schemas.microsoft.com/ado/2007/08/dataservices" xmlns:m="http://schemas.microsoft.com/ado/2007/08/dataservices/metadata" xmlns="http://www.w3.org/2005/Atom"> 
    <title type="text">CommandLogTable</title> 
    <id>azure-url/CommandLogTable</id> 
    <updated>2010-07-12T19:50:55Z</updated> 
    <link rel="self" title="CommandLogTable" href="CommandLogTable" /> 
</feed> 
0 

क्या किसी और को यह समस्या है और इसके लिए कोई फिक्स है?

Answer 1

Disabling Nagling के सुझावों के अतिरिक्त, improving performance of Azure Table Storage पर एक बहुत अच्छी पोस्ट है। दरअसल एडीओ.NET Deserialization की गति में सुधार Sqwarea के लिए 10x स्पीड-अप प्रदान किया गया (Lokad.Cloud ढांचे के साथ निर्मित बड़े पैमाने पर ऑनलाइन मल्टीप्लेयर गेम)।

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

एक बार में SQLite डेटाबेस में 10 लाख रिकॉर्ड डालने (लेनदेन के भीतर, जहां प्रत्येक रिकॉर्ड को 2 फ़ील्ड द्वारा अनुक्रमित किया गया था और प्रोटोबफ के माध्यम से मनमाने ढंग से स्कीमा-कम डेटा क्रमबद्ध किया गया था) औसत पर केवल 200 सेकंड लेता था। परिणामस्वरूप फ़ाइल अपलोड/डाउनलोड करना - औसत पर लगभग 15 सेकंड। रैंडम इंडेक्स द्वारा पढ़ता है - तात्कालिक (बशर्ते फ़ाइल को स्थानीय स्टोरेज में कैश किया गया हो और ईटीएजी मेल खा रहा हो)।

Answer 2

अधिकतर, आपका सीमित कारक नेटवर्क बैंडविड्थ है, प्रसंस्करण नहीं कर रहा है। यदि ऐसा है, तो आपकी एकमात्र असली आशा विस्तारित करना है: अधिक मशीनें डेटा डाउनलोड करने के लिए अधिक थ्रेड चला रही हैं।

बीटीडब्ल्यू, Azure कुछ "निर्यात" तंत्र का खुलासा नहीं करता है जो सभी पंक्तियों को मैन्युअल रूप से डाउनलोड करने की आवश्यकता को हटा देगा?

Answer 3

आपके पक्ष प्रश्न के अनुसार, मुझे उम्मीद है कि आपको "निरंतर टोकन" मिल रहा है। यदि आप .NET स्टोरेज क्लाइंट लाइब्रेरी का उपयोग कर रहे हैं, तो अपनी क्वेरी में .AsTableServiceQuery() जोड़ने का प्रयास करें।

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

Answer 4

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

आगे: एक ऑप्टिमाइज़ेशन तैनात किया गया है (नागल का एल्गोरिदम) जो वास्तव में छोटे पढ़ने के लिए चीजों को धीमा कर सकता है (जैसे आपका 1 के डेटा पढ़ता है)। यहां एक blog post about disabling Nagling है, जो संभावित रूप से आपके पढ़ने को तेज़ी से बढ़ा सकता है, खासकर यदि आप बिना किसी इंटरनेट विलंबता के एज़ूर सेवा में सीधे चल रहे हैं।

Answer 5

यहां बड़ा कारक यह है कि डेटा विभाजन में कैसे फैलता है। एक क्वेरी जो विभाजन सीमाओं को फैलाती है, प्रत्येक सीमा पर वापस आती है, जिसके लिए पुनः सबमिट की आवश्यकता होती है - भले ही प्रश्न में विभाजन 0 पंक्तियां हों। यदि डेटा 1 विभाजन = 1 पंक्ति है, तो यह धीमा हो जाएगा, लेकिन आप थ्रेड गिनती को 8 से ऊपर बढ़ा सकते हैं। यदि डेटा एन विभाजन = एम पंक्तियों में है, तो नीचे दिए गए विचार आपको तेज कर सकते हैं।

मान लीजिए कि आपके पास कई विभाजन हैं और प्रत्येक पंक्तियों के साथ प्रत्येक, जितना संभव हो सके उतने धागे को स्पिन करना होगा (यदि आप .NET PLINQ या समानांतर हैं। फॉरएच (विभाजन) या QueueWorkItem()) और एक पंक्ति को सभी पंक्तियों, प्रक्रिया, एसक्यूएल पर पोस्ट करने के लिए अपने विभाजन को स्कैन करें, & लौटने से पहले हटाएं।

शामिल लेटेंसी (एमएस के 10) और एकाधिक दौर यात्राएं, यहां तक ​​कि w/8 धागे भी आप जितना व्यस्त हो उतना व्यस्त नहीं हैं। साथ ही, आप यह नहीं बताते कि आप किस वीएम का उपयोग कर रहे हैं लेकिन आप विभिन्न आकारों को प्रोफाइल करना चाहेंगे।

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

Answer 6

अमेज़ॅन द्वारा समर्थित, आपके डेटा को प्राप्त करने का सबसे तेज़ तरीका, लेकिन अभी तक एज़ूर नहीं है, उन्हें एक यूएसबी डिस्क (यहां तक ​​कि एक यूएसबी स्टिक) भी भेजना है, उन्हें डेटा में डिस्क डालना है और इसे वापस भेजना है।

एक और विकल्प ऐपफैब्रिक सर्विस बस का उपयोग करने के लिए किसी अन्य सिस्टम को डेटा को प्राप्त करने के लिए, इसे एक बार में डाउनलोड करने की प्रतीक्षा करने के बजाय उपयोग करने के लिए है।