डेल्टा: डाटा सिंक्रोनाइजेसन र एन्रिचमेन्ट प्लेटफर्म

दरमा नयाँ प्रवाहको सुरुवातको प्रत्याशामा डाटा इन्जिनियर हामीले रोचक सामग्रीको अनुवाद तयार गरेका छौं।

सिंहावलोकन

हामी एक धेरै लोकप्रिय ढाँचाको बारेमा कुरा गर्नेछौं जसद्वारा एप्लिकेसनहरूले धेरै डाटा स्टोरहरू प्रयोग गर्दछ, जहाँ प्रत्येक स्टोरलाई आफ्नै उद्देश्यका लागि प्रयोग गरिन्छ, उदाहरणका लागि, डाटाको क्यानोनिकल फारम (MySQL, आदि) भण्डारण गर्न, उन्नत खोज क्षमताहरू प्रदान गर्नुहोस् (ElasticSearch, आदि)।), क्यासिङ (Memcached, etc.) र अन्य। सामान्यतया, धेरै डाटा स्टोरहरू प्रयोग गर्दा, ती मध्ये एउटाले प्राथमिक स्टोरको रूपमा र अरूले डेरिभेटिभ स्टोरहरूको रूपमा कार्य गर्दछ। मात्र समस्या यी डाटा स्टोरहरू कसरी सिङ्क्रोनाइज गर्ने हो।

हामीले धेरै पसलहरू सिङ्क्रोनाइज गर्ने समस्या समाधान गर्ने प्रयास गर्ने विभिन्न ढाँचाहरू हेर्यौं, जस्तै डबल राइटहरू, वितरित लेनदेनहरू, आदि। यद्यपि, यी दृष्टिकोणहरूमा वास्तविक-जीवन प्रयोग, विश्वसनीयता, र मर्मतसम्भारको सन्दर्भमा महत्त्वपूर्ण सीमाहरू छन्। डाटा सिङ्क्रोनाइजेसनको अतिरिक्त, केहि अनुप्रयोगहरूले बाह्य सेवाहरू कल गरेर डाटा समृद्ध गर्न आवश्यक छ।

यी समस्याहरू समाधान गर्न डेल्टा विकसित गरिएको थियो। डेल्टा अन्ततः डेटा सिंक्रोनाइजेसन र संवर्धनको लागि एक सुसंगत, घटना-संचालित प्लेटफर्म प्रदान गर्दछ।

अवस्थित समाधानहरू

डबल प्रवेश

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

समस्याहरू:

रिकभरी प्रक्रिया प्रदर्शन गर्नु एक विशिष्ट काम हो जुन पुन: प्रयोग गर्न सकिँदैन। थप रूपमा, भण्डारण स्थानहरू बीचको डेटा पुनर्स्थापना प्रक्रिया नभएसम्म सिंक बाहिर रहन्छ। यदि दुई भन्दा बढी डाटा स्टोरहरू प्रयोग गरिन्छ भने समाधान थप जटिल हुन्छ। अन्तमा, पुनर्स्थापना प्रक्रियाले मूल डाटा स्रोतमा लोड थप्न सक्छ।

लग तालिका परिवर्तन गर्नुहोस्

जब परिवर्तनहरू तालिकाहरूको सेटमा हुन्छन् (जस्तै रेकर्ड घुसाउने, अद्यावधिक गर्ने, र मेटाउने), परिवर्तन रेकर्डहरू लग तालिकामा उही लेनदेनको भागको रूपमा थपिन्छन्। अर्को थ्रेड वा प्रक्रियाले लगातार लग तालिकाबाट घटनाहरू अनुरोध गर्दछ र तिनीहरूलाई एक वा बढी डेटा भण्डारहरूमा लेख्छ, यदि आवश्यक भएमा, सबै स्टोरहरूले रेकर्ड पुष्टि गरेपछि लग तालिकाबाट घटनाहरू हटाउँदै।

समस्याहरू:

यो ढाँचालाई पुस्तकालयको रूपमा लागू गरिनु पर्छ, र आदर्श रूपमा यसलाई प्रयोग गर्ने अनुप्रयोगको कोड परिवर्तन नगरी। पोलिग्लोट वातावरणमा, यस्तो पुस्तकालयको कार्यान्वयन कुनै पनि आवश्यक भाषामा अवस्थित हुनुपर्छ, तर भाषाहरूमा कार्यक्षमता र व्यवहारको स्थिरता सुनिश्चित गर्न धेरै गाह्रो छ।

अर्को समस्या प्रणालीहरूमा स्कीमा परिवर्तनहरू प्राप्त गर्नमा निहित छ जसले लेनदेन स्कीमा परिवर्तनहरूलाई समर्थन गर्दैन [१][२], जस्तै MySQL। त्यसकारण, परिवर्तन गर्ने ढाँचा (उदाहरणका लागि, स्कीमा परिवर्तन) र लेनदेन रूपमा यसलाई परिवर्तन लग तालिकामा रेकर्ड गर्ने कार्यले सधैं काम गर्दैन।

वितरित लेनदेन

वितरित लेनदेनहरू धेरै विषम डाटा स्टोरहरूमा एक लेनदेन विभाजित गर्न प्रयोग गर्न सकिन्छ ताकि सञ्चालन या त प्रयोग गरिएका सबै डाटा स्टोरहरूमा प्रतिबद्ध छ, वा तिनीहरूमध्ये कुनै पनि प्रति प्रतिबद्ध छैन।

समस्याहरू:

वितरित लेनदेन विषम डाटा स्टोरहरूको लागि धेरै ठूलो समस्या हो। तिनीहरूको प्रकृति द्वारा, तिनीहरू केवल समावेश प्रणालीहरूको सबैभन्दा कम सामान्य भाजकमा भर पर्न सक्छन्। उदाहरणका लागि, XA लेनदेनहरूले कार्यान्वयनलाई रोक्छ यदि आवेदन प्रक्रिया तयारी चरणमा असफल हुन्छ। थप रूपमा, XA ले डेडलक पत्ता लगाउन वा आशावादी समवर्ती नियन्त्रण योजनाहरूलाई समर्थन गर्दैन। थप रूपमा, ElasticSearch जस्ता केही प्रणालीहरूले XA वा कुनै अन्य विषम लेनदेन मोडेललाई समर्थन गर्दैन। तसर्थ, विभिन्न डाटा भण्डारण प्रविधिहरूमा परमाणु लेखन सुनिश्चित गर्नु अनुप्रयोगहरूको लागि धेरै चुनौतीपूर्ण कार्य रहन्छ [3]।

डेल्टा

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

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

डेल्टा भन्दा पहिले, चलचित्र खोजी टोलीले चलचित्र डेटा अनुक्रमणिका गर्नु अघि धेरै माइक्रोसर्भिसेसहरूबाट डेटा तान्न आवश्यक थियो। थप रूपमा, टोलीले कुनै पनि परिवर्तन नभए पनि अन्य माइक्रोसर्भिसेसहरूबाट परिवर्तनहरू अनुरोध गरेर आवधिक रूपमा खोज अनुक्रमणिका अपडेट गर्ने प्रणाली विकास गर्नुपर्‍यो। यो प्रणाली चाँडै जटिल र कायम राख्न गाह्रो भयो।

चित्र १. डेल्टामा मतदान प्रणाली
डेल्टा प्रयोग गरेपछि, निम्न चित्रमा देखाइए अनुसार प्रणालीलाई घटना संचालित प्रणालीमा सरलीकृत गरियो। CDC (चेन्ज-डेटा-क्याप्चर) घटनाहरू डेल्टा-कनेक्टर प्रयोग गरेर कीस्टोन काफ्का विषयहरूमा पठाइन्छ। डेल्टा स्ट्रिम प्रशोधन फ्रेमवर्क (फ्लिंकमा आधारित) प्रयोग गरी निर्मित डेल्टा अनुप्रयोगले विषयबाट सीडीसी घटनाहरू प्राप्त गर्दछ, तिनीहरूलाई अन्य माइक्रोसर्भिसेसहरू कल गरेर समृद्ध बनाउँछ, र अन्तमा इलास्टिकसर्चमा खोज अनुक्रमणिकामा समृद्ध डाटा पास गर्दछ। सम्पूर्ण प्रक्रिया लगभग वास्तविक समयमा हुन्छ, त्यो हो, डेटा गोदाममा परिवर्तनहरू प्रतिबद्ध हुने बित्तिकै, खोज अनुक्रमणिकाहरू अद्यावधिक हुन्छन्।

चित्र २. डेल्टा प्रयोग गरेर डाटा पाइपलाइन
निम्न खण्डहरूमा, हामी डेल्टा-कनेक्टरको सञ्चालनको वर्णन गर्नेछौं, जसले भण्डारणमा जडान गर्दछ र सीडीसी घटनाहरूलाई यातायात तहमा प्रकाशित गर्दछ, जुन वास्तविक-समय डाटा प्रसारण पूर्वाधार हो जसले सीडीसी घटनाहरूलाई काफ्का विषयहरूमा मार्ग गर्दछ। र अन्त्यमा, हामी डेल्टा स्ट्रिम प्रशोधन ढाँचाको बारेमा कुरा गर्नेछौं, जुन अनुप्रयोग विकासकर्ताहरूले डेटा प्रशोधन र संवर्धन तर्कको लागि प्रयोग गर्न सक्छन्।

CDC (परिवर्तन-डेटा-क्याप्चर)

हामीले डेल्टा-कनेक्टर नामक CDC सेवा विकास गरेका छौं, जसले वास्तविक समयमा डाटा स्टोरबाट प्रतिबद्ध परिवर्तनहरू खिच्न सक्छ र तिनीहरूलाई स्ट्रिममा लेख्न सक्छ। वास्तविक-समय परिवर्तनहरू लेनदेन लग र भण्डारण डम्पहरूबाट लिइन्छ। डम्पहरू प्रयोग गरिन्छ किनभने लेनदेन लगहरू सामान्यतया परिवर्तनहरूको सम्पूर्ण इतिहास भण्डार गर्दैनन्। परिवर्तनहरू सामान्यतया डेल्टा घटनाहरूको रूपमा क्रमबद्ध हुन्छन्, त्यसैले प्राप्तकर्ताले परिवर्तन कहाँबाट आउँछ भनेर चिन्ता लिनु पर्दैन।

डेल्टा-कनेक्टरले धेरै अतिरिक्त सुविधाहरू समर्थन गर्दछ जस्तै:

• काफ्का विगतको अनुकूलन आउटपुट डाटा लेख्ने क्षमता।
• सबै तालिकाहरू, एक विशेष तालिका, वा विशिष्ट प्राथमिक कुञ्जीहरूको लागि कुनै पनि समयमा म्यानुअल डम्पहरू सक्रिय गर्ने क्षमता।
• डम्पहरू टुक्राहरूमा पुन: प्राप्त गर्न सकिन्छ, त्यसैले असफलताको अवस्थामा फेरि सुरु गर्न आवश्यक छैन।
• त्यहाँ टेबलहरूमा तालाहरू राख्न आवश्यक छैन, जुन हाम्रो सेवाद्वारा डाटाबेस लेख्ने ट्राफिकलाई कहिल्यै रोकिएको छैन भन्ने सुनिश्चित गर्न धेरै महत्त्वपूर्ण छ।
• AWS उपलब्धता क्षेत्रहरूमा अनावश्यक उदाहरणहरूको कारण उच्च उपलब्धता।

हामी हाल MySQL र Postgres समर्थन गर्दछौं, AWS RDS र Aurora मा तैनाती सहित। हामी क्यासान्ड्रा (बहु-मास्टर) लाई पनि समर्थन गर्दछौं। तपाईं यहाँ डेल्टा-कनेक्टर बारे थप विवरणहरू फेला पार्न सक्नुहुन्छ ब्लग पोष्ट.

काफ्का र यातायात तह

डेल्टाको घटना यातायात तह प्लेटफर्मको सन्देश सेवामा बनाइएको छ keystone.

ऐतिहासिक रूपमा, Netflix मा पोस्टिङ दीर्घायुको सट्टा पहुँचको लागि अनुकूलित गरिएको छ (तल हेर्नुहोस्)। अघिल्लो लेख)। ट्रेड-अफ विभिन्न किनारा परिदृश्यहरूमा सम्भावित ब्रोकर डेटा असंगति थियो। उदाहरण को लागी, अशुद्ध नेता चुनाव सम्भावित नक्कल वा हराएको घटनाहरू प्राप्तकर्ताको लागि जिम्मेवार छ।

डेल्टासँग, हामीले व्युत्पन्न स्टोरहरूमा CDC घटनाहरूको डेलिभरी सुनिश्चित गर्न बलियो स्थायित्व ग्यारेन्टीहरू चाहन्थ्यौं। यस उद्देश्यका लागि, हामीले विशेष रूपमा डिजाइन गरिएको काफ्का क्लस्टरलाई प्रथम श्रेणीको वस्तुको रूपमा प्रस्ताव गरेका छौं। तपाईं तलको तालिकामा केही ब्रोकर सेटिङहरू हेर्न सक्नुहुन्छ:

कीस्टोन काफ्का क्लस्टरहरूमा, अशुद्ध नेता चुनाव सामान्यतया प्रकाशक पहुँच सुनिश्चित गर्न समावेश। यदि एक असङ्क्रमित प्रतिकृति नेताको रूपमा चुनिएमा यसले सन्देश गुमाउन सक्छ। नयाँ उच्च उपलब्धता काफ्का क्लस्टरको लागि, विकल्प अशुद्ध नेता चुनाव सन्देश गुमाउनबाट जोगाउन बन्द गरियो।

हामीले पनि बढायौं प्रतिकृति कारक 2 देखि 3 सम्म र न्यूनतम इन्सिंक प्रतिकृतिहरू 1 देखि 2. यस क्लस्टरमा लेख्ने प्रकाशकहरूलाई अन्य सबैबाट एक्स चाहिन्छ, 2 मध्ये 3 प्रतिकृतिहरूमा प्रकाशकले पठाएको सबैभन्दा हालको सन्देशहरू छन् भन्ने सुनिश्चित गर्दै।

जब ब्रोकर उदाहरण समाप्त हुन्छ, नयाँ उदाहरणले पुरानोलाई प्रतिस्थापन गर्दछ। जे होस्, नयाँ ब्रोकरले असङ्क्रमित प्रतिकृतिहरू समात्न आवश्यक हुनेछ, जसमा धेरै घण्टा लाग्न सक्छ। यस परिदृश्यको लागि रिकभरी समय कम गर्न, हामीले स्थानीय ब्रोकर डिस्कहरूको सट्टा ब्लक डाटा भण्डारण (अमेजन इलास्टिक ब्लक स्टोर) प्रयोग गर्न थाल्यौं। जब एउटा नयाँ उदाहरणले समाप्त गरिएको ब्रोकर उदाहरणलाई प्रतिस्थापन गर्दछ, यसले समाप्त गरिएको उदाहरणसँग भएको EBS भोल्युम संलग्न गर्दछ र नयाँ सन्देशहरू प्राप्त गर्न थाल्छ। यो प्रक्रियाले ब्याकलग क्लियरेन्स समयलाई घण्टाबाट मिनेटमा घटाउँछ किनभने नयाँ उदाहरण अब खाली अवस्थाबाट नक्कल गर्न आवश्यक छैन। समग्रमा, छुट्टै भण्डारण र ब्रोकर जीवनचक्रहरूले ब्रोकर स्विचिङको प्रभावलाई उल्लेखनीय रूपमा कम गर्छ।

थप डाटा डेलिभरी ग्यारेन्टी बढाउनको लागि, हामीले प्रयोग गर्यौं सन्देश ट्र्याकिङ प्रणाली चरम परिस्थितिहरूमा कुनै सन्देश हराएको पत्ता लगाउन (उदाहरणका लागि, विभाजन नेतामा घडी डिसिंक्रोनाइजेसन)।

स्ट्रिम प्रशोधन फ्रेमवर्क

डेल्टाको प्रशोधन तह Netflix SPaaS प्लेटफर्मको शीर्षमा बनाइएको छ, जसले नेटफ्लिक्स इकोसिस्टमसँग Apache Flink एकीकरण प्रदान गर्दछ। प्लेटफर्मले प्रयोगकर्ता इन्टरफेस प्रदान गर्दछ जसले हाम्रो Titus कन्टेनर व्यवस्थापन प्लेटफर्मको शीर्षमा Flink कार्यहरू र Flink क्लस्टरहरूको अर्केस्ट्रेसनको तैनाती व्यवस्थापन गर्दछ। इन्टरफेसले कार्य कन्फिगरेसनहरू पनि प्रबन्ध गर्दछ र प्रयोगकर्ताहरूलाई Flink कार्यहरू पुन: कम्पाइल नगरीकन गतिशील रूपमा कन्फिगरेसन परिवर्तनहरू गर्न अनुमति दिन्छ।

डेल्टाले प्रयोग गर्ने Flink र SPaaS मा आधारित स्ट्रिम प्रोसेसिङ फ्रेमवर्क प्रदान गर्दछ एनोटेसनमा आधारित DSL (डोमेन विशिष्ट भाषा) प्राविधिक विवरणहरू सार गर्न। उदाहरणका लागि, बाह्य सेवाहरू कल गरेर घटनाहरू समृद्ध हुने चरण परिभाषित गर्न, प्रयोगकर्ताहरूले निम्न DSL लेख्न आवश्यक छ, र फ्रेमवर्कले यसको आधारमा मोडेल सिर्जना गर्नेछ, जुन Flink द्वारा कार्यान्वयन गरिनेछ।

चित्र 3. डेल्टामा DSL मा संवर्धनको उदाहरण

प्रशोधन ढाँचाले सिकाइ कर्भलाई मात्र कम गर्दैन, तर सामान्य परिचालन समस्याहरू समाधान गर्न डुप्लिकेशन, योजनाबद्धता, र लचिलोपन र लचिलोपन जस्ता साझा स्ट्रिम प्रशोधन सुविधाहरू पनि प्रदान गर्दछ।

डेल्टा स्ट्रिम प्रशोधन फ्रेमवर्कमा दुई मुख्य मोड्युलहरू, DSL र API मोड्युल र रनटाइम मोड्युलहरू हुन्छन्। DSL र API मोड्युलले DSL र UDF (User-Defined-Function) API हरू प्रदान गर्दछ ताकि प्रयोगकर्ताहरूले आफ्नै प्रशोधन तर्क (जस्तै फिल्टरिङ वा रूपान्तरणहरू) लेख्न सक्छन्। रनटाइम मोड्युलले DSL पार्सरको कार्यान्वयन प्रदान गर्दछ जसले DAG मोडेलहरूमा प्रशोधन चरणहरूको आन्तरिक प्रतिनिधित्व निर्माण गर्दछ। कार्यान्वयन कम्पोनेन्टले वास्तविक Flink कथनहरू प्रारम्भ गर्न र अन्ततः Flink अनुप्रयोग चलाउन DAG मोडेलहरूको व्याख्या गर्दछ। फ्रेमवर्कको वास्तुकला निम्न चित्रमा चित्रण गरिएको छ।

चित्र ४. डेल्टा स्ट्रिम प्रोसेसिङ फ्रेमवर्क आर्किटेक्चर

यो दृष्टिकोण धेरै फाइदाहरू छन्:

• प्रयोगकर्ताहरूले Flink वा SPaaS ढाँचाको विशिष्टताहरूमा ध्यान नदिई आफ्नो व्यापार तर्कमा ध्यान केन्द्रित गर्न सक्छन्।
• अप्टिमाइजेसन प्रयोगकर्ताहरूलाई पारदर्शी हुने तरिकामा गर्न सकिन्छ, र प्रयोगकर्ता कोड (UDF) मा कुनै पनि परिवर्तनको आवश्यकता बिना त्रुटिहरू समाधान गर्न सकिन्छ।
• डेल्टा अनुप्रयोग अनुभव प्रयोगकर्ताहरूका लागि सरलीकृत गरिएको छ किनभने प्लेटफर्मले बक्स बाहिर लचिलोपन र लचिलोपन प्रदान गर्दछ र अलर्टहरूको लागि प्रयोग गर्न सकिने विभिन्न विस्तृत मेट्रिक्स सङ्कलन गर्दछ।

उत्पादन प्रयोग

डेल्टा एक वर्ष भन्दा बढि उत्पादनमा छ र धेरै नेटफ्लिक्स स्टुडियो अनुप्रयोगहरूमा मुख्य भूमिका खेल्छ। उनले टोलीहरूलाई खोज अनुक्रमणिका, डेटा भण्डारण, र घटना-संचालित कार्यप्रवाह जस्ता प्रयोगका केसहरू लागू गर्न मद्दत गरिन्। तल डेल्टा प्लेटफर्मको उच्च-स्तर वास्तुकलाको एक सिंहावलोकन छ।

चित्र 5. डेल्टाको उच्च-स्तरीय वास्तुकला।

स्वीकार

नेटफ्लिक्समा डेल्टाको निर्माण र विकासमा संलग्न भएका निम्न व्यक्तिहरूलाई हामी धन्यवाद दिन चाहन्छौं: एलेन वाङ, चार्ल्स झाओ, जेबिन यून, जोश स्नाइडर, कस्तुरी चटर्जी, मार्क चो, ओलोफ जोहानसन, पियुष गोयल, प्रशान्त रामदास, रघुराम ओन्टी। श्रीनिवासन, सन्दीप गुप्ता, स्टिभन वु, थरंगा गामाथिगे, युन वाङ र झेन्झोङ जु।

स्रोतहरू

1. dev.mysql.com/doc/refman/5.7/en/implicit-commit.html
2. dev.mysql.com/doc/refman/5.7/en/cannot-roll-back.html
3. मार्टिन क्लेपम्यान, एलिस्टेयर आर बेरेसफोर्ड, बोर्ज स्विंगेन: अनलाइन घटना प्रशोधन। कम्युन। ACM ६२(५): ४३–४९ (२०१९)। DOI: doi.org/10.1145/3312527

नि: शुल्क वेबिनारको लागि साइन अप गर्नुहोस्: "अमेजन रेडशिफ्ट भण्डारणको लागि डाटा निर्माण उपकरण।"

स्रोत: www.habr.com