चमक, ग्लस्टर या मोगाइलएफएस ?? वीडियो स्टोरेज, एन्कोडिंग और स्ट्रीमिंग

Question

इतने सारे विकल्प और उन सभी का परीक्षण करने के लिए बहुत कम समय ... मुझे आश्चर्य है कि किसी को वीडियो स्ट्रीमिंग और स्टोरेज/एन्कोडिंग के लिए वितरित फ़ाइल सिस्टम के साथ अनुभव है।

मेरे पास बहुत सारी बड़ी वीडियो फ़ाइलें (50GB से 250GB) हैं जिन्हें मुझे कहीं स्टोर करने की आवश्यकता है, उन्हें एमपी 4 में एन्कोड करने और उन्हें कई एडोब एफएमएस सर्वर से स्ट्रीम करने में सक्षम होना चाहिए। इन सभी को संभालने का एकमात्र तरीका एक वितरित फ़ाइल सिस्टम के साथ है, लेकिन अब सवाल कौन सा है ??

मेरे शोध अब तक मुझसे कहता है:

• आलोक: परिपक्व साबित समाधान, बड़ी कंपनियों के एक बहुत द्वारा इस्तेमाल किया,> 10G फाइलों के साथ सबसे अच्छा एक कर्नेल ड्राइवर है।
• ग्लस्टर: नया, कम परिपक्व, FUSE आधारित जिसका मतलब है इंस्टॉल करना आसान है लेकिन शायद FUSE ओवरहेड के कारण धीमा हो सकता है। बड़ी संख्या में छोटी फाइलों को संभालने के लिए बेहतर ~ 1 जीबी
• मोगाइलफ़ेस: केवल छोटी फ़ाइलों ~ एमबी के लिए लगता है, उपयोग के लिए HTTP का उपयोग करता है ?? भविष्य में बाध्यकारी संभव FUSE।

अब तक लस्टर विजेता लगता है लेकिन मैं अपने विशेष एप्लिकेशन के लिए वास्तविक अनुभव सुनना चाहता हूं।

इसके अलावा हडोप, रेडहाट जीएफएस, कोडा और विंडोज़ डीएफएस ध्वनि विकल्पों के रूप में ध्वनि का स्वागत है। अगर किसी के पास बेंचमार्क हैं तो कृपया साझा करें।

कुछ वास्तविक अनुभव के बाद इस मैं क्या सीखा है है:

• चमक:
  • प्रदर्शन: आश्चर्यजनक तेजी से! मैं जोर दे सकता हूं कि लस्टर पर कई धाराओं की सेवा कर सकता है और यह कि एन्कोडिंग गति Luster के माध्यम से फ़ाइलों तक पहुंच से प्रभावित नहीं होती है।
  • POXIS संगतता: बहुत अच्छा! चमक का उपयोग करने के लिए अनुप्रयोगों को संशोधित करने की आवश्यकता नहीं है।
  • प्रतिकृति, लोड संतुलन और विफलता: बहुत बुरा! प्रतिकृति लोड हमें संतुलित करने और विफल होने के लिए हमें वर्चुअल आईपी और डीआरडीबी जैसे अन्य सॉफ़्टवेयर पर भरोसा करने की आवश्यकता है।
  • स्थापना: सबसे खराब! केवल प्राणियों द्वारा स्थापित करने के लिए असंभव है। इसे काम करने के लिए कर्नेल, चमक पैच और tweaks के एक बहुत ही विशिष्ट संयोजन की आवश्यकता है। और वर्तमान चमक पैच आमतौर पर पुराने कर्नेल के साथ काम करते हैं जो नए हार्डवेयर/सॉफ्टवेयर के साथ असंगत हैं।
• MogileFS:
  • प्रदर्शन: छोटे फ़ाइलों के लिए अच्छा है, लेकिन बड़ी फ़ाइलों को माध्यम के लिए प्रयोग करने योग्य नहीं। यह अधिकतर HTTP ओवरहेड के कारण है क्योंकि सभी फाइलें HTTP अनुरोधों के माध्यम से भेजती/प्राप्त होती हैं जो बेस 64 में सभी डेटा एन्कोड करते हैं, प्रत्येक फ़ाइल में 33% ओवरहेड जोड़ते हैं।
  • POXIX संगतता मौजूद नहीं है। सभी अनुप्रयोगों को mogilefs का उपयोग करने के लिए संशोधित करने की आवश्यकता है जो स्ट्रीमिंग/एन्कोडिंग के लिए बेकार है क्योंकि अधिकांश स्ट्रीमिंग सर्वर और एन्कोडिंग टूल MogileFS प्रोटोकॉल को नहीं समझते हैं।
  • बॉक्स और लोड संतुलन से प्रतिकृति और विफलता एप्लिकेशन में एक समय में एक से अधिक ट्रैकर तक पहुंचकर लागू किया जा सकता है।
  • स्थापना अपेक्षाकृत आसान है और अधिकांश वितरण में संकुल का उपयोग करने के लिए तैयार है। मुझे मिली एकमात्र कठिनाई विफलता के एकल बिंदु को खत्म करने के लिए डेटाबेस मास्टर-गुलाम सेट कर रही थी।
    • Gluster:
  • प्रदर्शन: स्ट्रीमिंग के लिए बहुत बुरा। मैं 10 जीबीपीएस नेटवर्क में कुछ एमबीपीएस से अधिक तक नहीं पहुंच सकता। भारी लिखने पर ग्राहक और सर्वर सीपीयू skyrockets। एन्कोडिंग कार्यों के लिए क्योंकि सीपीयू नेटवर्क और आई/ओ से पहले संतृप्त है।
  • POXIS: लगभग संगत। मेरे द्वारा उपयोग किए जाने वाले टूल डिस्क में सामान्य फ़ोल्डर के रूप में ग्लस्टर माउंट तक पहुंच सकते हैं लेकिन कुछ किनारे के मामलों में चीजें समस्याएं उत्पन्न होती हैं। ग्लस्टर मेलिंग सूचियों और देखें, आप देखेंगे कि बहुत सी समस्याएं हैं।
  • प्रतिकृति, विफलता और लोड संतुलन: सबसे अच्छा! अगर वे वास्तव में काम किया। ग्लस्टर बहुत नया है और इसमें बहुत सारी बग और प्रदर्शन समस्याएं हैं।
  • स्थापना बहुत आसान है। प्रबंधन कमांड लाइन अद्भुत है और प्रतिलिपि बनाई गई है, कई सर्वरों के बीच धारीदार और वितरित वॉल्यूम कोई आसान नहीं हो सकता है।

अंतिम निष्कर्ष:

दुर्भाग्य से निष्कर्ष "कोई भी चांदी की गोली" है।

वर्तमान में हमारे पास स्टोरेज और ट्रांसकोडिंग के लिए एक प्रतिकृति मात्रा में Gluster3.2 में हमारी मीडिया फ़ाइलें हैं। जब तक आपके पास बहुत सारे सर्वर नहीं होते हैं, तब तक भू-प्रतिकृति और पट्टी वॉल्यूम से बचें चीजें ठीक काम करती हैं।

जब हम मीडिया फ़ाइलों को स्ट्रीम करने जा रहे हैं तो हम उन्हें एक चमक मात्रा में कॉपी करते हैं जिसे डीआर: डीबी के माध्यम से दूसरी चमक मात्रा में दोहराया जाता है। Wowza सर्वर तब चमक फ़ाइलों से मीडिया फ़ाइलों को पढ़ा।

और अंत में हम अपने वेब अनुप्रयोग सर्वर में थंबनेल की सेवा के लिए मोगाइलएफएस का उपयोग करते हैं।

Answer 1

नामित सिस्टम से सबसे उपयुक्त MoglieFS है।

लेकिन शायद आप किसी भी विशेष प्रणाली को w/आउट कर सकते हैं। आप 4 AdobeFMS सर्वर है कहते हैं:

{video0.exmple.com,video1.exmple.com,video2.exmple.com,video3.exmple.com}. 

आप सरल योजना का उपयोग कर उन 4 सर्वर के बीच अपने सभी वीडियो वितरित कर सकते हैं, जैसे

/* 
    * pseudo code 
    */ 

    $server_id = get_server_id(filename); 
    ... 
    ... 
    int function get_server_id(filename) 
    { 
     return hash(filename) mod 4; 
    } 

आप वीडियो सांकेतिक शब्दों में बदलना करने के बाद, अपने अनुप्रयोग होगा

$server_id = get_server_id(file_name) 
copy file_name to /mnt/$server_id/ 

ग्राहक http://videoN.example.com/filename.mp4 जैसे कुछ का उपयोग करके वीडियो एक्सेस करेंगे, जहां एन को get_server_id() का उपयोग करके फ़ाइल नाम से गणना की जाती है।

चमक/ग्लस्टर वास्तव में वह नहीं है जिसे आप ढूंढना चाहते हैं।चमक एफएस अधिक परिपक्व है, लेकिन डेवलपर्स आपको ऐसे एफएस पर "कैश" के रूप में फाइलों का इलाज करने के लिए कहते हैं, यानी वे किसी भी समय खो सकते हैं।

चमक/ग्लस्टर को एचपीसी में उपयोग के लिए लक्षित किया जाता है ताकि बड़ी मात्रा में डेटा डब्ल्यू/आउट एकल स्टोरेज सर्वर के लिए तेज बोतल-गर्दन होने की अनुमति मिल सके। उन प्रणालियों के लिए एक और बिंदु यह है कि वे पॉज़िक्स-शिकायत हैं। एचपीसी/वैज्ञानिक अनुसंधान वातावरण में आमतौर पर आपके ऐप्स को फिर से लिखने के लिए कमर करने का समय नहीं होता क्योंकि आपने नया ठंडा और तेज़ एफएस स्थापित किया था।

Answer 2

हडोप फाइल सिस्टम (एचडीएफएस) देखें। इसका ध्यान बहुत बड़ी फाइलों और समांतर कार्य कंप्यूटिंग (मानचित्र/कम करने के साथ) पर है, इसमें उच्च विलंबता है लेकिन बहुत अधिक थ्रूपुट है। वर्तमान में इस तरह के बड़े इंस्टॉलेशन पर फेसबुक और amazon.com

Answer 3

MogileFS इस तरह की चीज़ के लिए बहुत अच्छा है। क्लाइंट लाइब्रेरी गुणवत्ता में थोड़ी भिन्न होती है, लेकिन मुझे आश्चर्य होगा कि अगर बड़ी संख्या में आईएसएच स्केल उत्पादन साइटें एक्सेस करने के लिए किसी भी भाषा का उपयोग नहीं कर रही हैं।

HTTP वास्तव में इस सामग्री के लिए एक अच्छा प्रोटोकॉल है। फीचर समृद्ध और कुशल HTTP क्लाइंट नहीं है?

Answer 4

मानचित्र-कमी 90/10 के लिखने/पढ़ने के अनुपात में मदद नहीं करता है! निरंतर फ़ाइल आकार एक अच्छी बात है और फाइलें छोटी हैं। तो, मोगाइलएफएस लस्टर/ग्लस्टर के रूप में अच्छा विकल्प लगता है - कैश की स्थिति उचित नहीं है।

Answer 5

ग्लस्टरफ़ेस ने स्वयं को इस तिथि तक बहुत सुधार किया है। वे अब बड़ी फाइलों के लिए "दानेदार लॉकिंग" प्रदान कर रहे हैं। यहां देखें: http://www.gluster.org/community/documentation/index.php/WhatsNew3.3 यह भी काफी निर्भर वीडियो फ्रेम दर है जिसके लिए आपको भी काम करना चाहिए। यदि आप 4K तक नहीं पहुंचेंगे, तो ग्लस्टर स्टोरेज समस्याओं को हल कर सकता है। यदि गति की भारी मांग है, इसलिए इन्फिनिबैंड खेलने के लिए आ सकता है।