NoSQL मा डाटा, स्थिरता र विश्वास गुमाए बिना क्यासान्ड्राको आँखामा कसरी हेर्ने

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

म तपाईंलाई क्यासान्ड्रा DBMS मा आधारित समाधान लागू गर्ने हाम्रो अनुभवको बारेमा बताउनेछु: हामीले के सामना गर्नुपर्‍यो, हामी कसरी कठिन परिस्थितिहरूबाट बाहिर आयौं, हामीले NoSQL प्रयोग गरेर फाइदा लिन सक्यौं कि छैन र हामीले थप प्रयासहरू/कोषहरू कहाँ लगानी गर्नुपर्ने थियो। ।
प्रारम्भिक कार्य भनेको कुनै प्रकारको भण्डारणमा कलहरू रेकर्ड गर्ने प्रणाली निर्माण गर्नु हो।

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

यो एकदम स्पष्ट छ किन उनीहरूले क्यासान्ड्रा रोजे - उनी मेसिन गन जस्तो लेख्छिन्, सजिलै मापनयोग्य छ, र गल्ती-सहनशील छ।

त्यसोभए, यो अनुभवले हामीलाई दिएको छ

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

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

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

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

हामीले परीक्षण क्षेत्रहरूमा डेटा स्थानान्तरण गर्दा समस्याको सामना गर्यौं (प्रोममा 5 बनाम परीक्षणमा 20 नोडहरू)। यस अवस्थामा, डम्प प्रयोग गर्न सकिँदैन।

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

सम्मिलित गर्दा टाइमआउट। क्यासान्ड्रा रेकर्डिङमा सुन्दर छ, तर कहिलेकाहीँ आगमन प्रवाहले उनलाई महत्त्वपूर्ण रूपमा पजल गर्न सक्छ। यो तब हुन्छ जब अनुप्रयोगले धेरै रेकर्डहरू वरिपरि चक्र गर्न थाल्छ जुन कुनै कारणले सम्मिलित गर्न सकिँदैन। र हामीलाई एक वास्तविक DBA चाहिन्छ जसले gc.log, प्रणाली र डिबग लगहरू ढिलो प्रश्नहरू, कम्प्याक्शन पेन्डिङमा मेट्रिक्सको लागि निगरानी गर्नेछ।

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

हामीले कसरी निर्णय गर्यौं

नोडलाई डुब्नबाट रोक्नको लागि, हामीले SWAP असक्षम पार्यौं। र अब, यदि मेमोरीको कमी छ भने, नोड तल जानु पर्छ र ठूलो gc पजहरू सिर्जना गर्नु हुँदैन।

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

हामीले DataStax बाट समर्थन खरिद गर्यौं। बक्स गरिएको क्यासान्ड्राको विकास पहिले नै बन्द भएको छ (अन्तिम प्रतिबद्धता फेब्रुअरी 2018 मा थियो)। एकै समयमा, Datastax ले उत्कृष्ट सेवा र अवस्थित IP समाधानहरूको लागि परिमार्जित र अनुकूलित समाधानहरूको ठूलो संख्या प्रदान गर्दछ।

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

हामीले दुईवटा विकल्पहरू विचार गर्यौं। पहिलो विकल्पमा, हामी C* मा मात्र होइन, तर संग्रहित Oracle डाटाबेसमा पनि कलहरू लेख्छौं। केवल, C* को विपरीत, यो डाटाबेसले हालको महिनाका लागि मात्र कलहरू भण्डार गर्दछ (केसहरू रिचार्ज गर्नका लागि पर्याप्त कल भण्डारण गहिराइ)। यहाँ हामीले तुरुन्तै निम्न समस्या देख्यौं: यदि हामीले सिंक्रोनस रूपमा लेख्यौं भने, हामीले द्रुत प्रविष्टिसँग सम्बन्धित C* का सबै फाइदाहरू गुमाउँछौं; यदि हामीले एसिन्क्रोनस रूपमा लेख्यौं भने, त्यहाँ कुनै ग्यारेन्टी छैन कि सबै आवश्यक कलहरू Oracle मा आए। त्यहाँ एउटा प्लस थियो, तर एउटा ठूलो: सञ्चालनको लागि उही परिचित PL/SQL विकासकर्ता रहन्छ, अर्थात् हामी व्यावहारिक रूपमा "Facade" ढाँचा लागू गर्छौं। वैकल्पिक विकल्प। हामीले C* बाट कलहरू अनलोड गर्ने, Oracle मा सम्बन्धित तालिकाहरूबाट संवर्धनका लागि केही डेटा तान्ने, नतिजा प्राप्त गर्ने नमूनाहरूमा सामेल हुने र हामीलाई नतिजा दिन्छ, जुन हामीले कुनै न कुनै रूपमा प्रयोग गर्छौं (रोल ब्याक, दोहोर्याउनुहोस्, विश्लेषण गर्नुहोस्, प्रशंसा गर्नुहोस्) कार्यान्वयन गर्छौं। विपक्ष: प्रक्रिया धेरै बहु-चरण हो, र यसको अतिरिक्त, सञ्चालन कर्मचारीहरूको लागि कुनै इन्टरफेस छैन।

अन्तमा, हामी दोस्रो विकल्पमा बस्यौं। Apache Spark विभिन्न जारबाट नमूना गर्न प्रयोग गरिएको थियो। मेकानिजमको सारलाई जाभा कोडमा घटाइएको छ, जसले निर्दिष्ट कुञ्जीहरू (सदस्यकर्ता, कलको समय - सेक्सन कुञ्जीहरू) प्रयोग गरेर C* बाट डाटा बाहिर निकाल्छ, साथै अन्य कुनै पनि डाटाबेसबाट संवर्धनको लागि आवश्यक डाटा। जस पछि यो तिनीहरूलाई यसको मेमोरीमा सामेल हुन्छ र परिणाम तालिकामा परिणाम प्रदर्शन गर्दछ। हामीले स्पार्कमा वेब अनुहार कोर्यौं र यो धेरै प्रयोगयोग्य भयो।

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

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

क्यासान्ड्राको निरन्तर उपलब्धता सुनिश्चित गर्न, तपाईलाई डीबीए चाहिन्छ र उहाँ मात्र होइन। एप्लिकेसनसँग काम गर्ने सबैले वर्तमान अवस्थालाई कहाँ र कसरी हेर्ने र समयमै समस्याहरूको निदान कसरी गर्ने भन्ने कुरा बुझ्नुपर्छ। यो गर्नका लागि, हामी सक्रिय रूपमा DataStax OpsCenter (कार्यभारको प्रशासन र अनुगमन), क्यासान्ड्रा ड्राइभर प्रणाली मेट्रिक्स (C* मा लेख्नको लागि टाइमआउटको संख्या, C* बाट पढ्नको लागि टाइमआउटको संख्या, अधिकतम विलम्बता, आदि) को प्रयोग गर्दछौं, सञ्चालन निगरानी गर्दछौं। क्यासान्ड्रासँग काम गर्दै आफैंको आवेदन।

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

फलस्वरूप, अहिलेको लागि EACH_QUORUM लेख्नको लागि स्थिरता स्तरमा रोकियो, पढ्नको लागि - LOCAL_QUORUM

संक्षिप्त छाप र निष्कर्ष

परिचालन समर्थन र थप विकासको सम्भावनाको दृष्टिकोणबाट नतिजा समाधानको मूल्याङ्कन गर्न, हामीले यस्तो विकासलाई अरू कहाँ लागू गर्न सकिन्छ भनेर सोच्ने निर्णय गर्‍यौं।

ब्याटको ठीक बाहिर, त्यसपछि "सुविधाजनक हुँदा भुक्तान गर्नुहोस्" (हामी C* मा जानकारी लोड गर्छौं, स्पार्क स्क्रिप्टहरू प्रयोग गरेर गणना) जस्ता कार्यक्रमहरूको लागि डेटा स्कोरिङ, क्षेत्रद्वारा एकत्रित दावीहरूको लागि लेखा, भूमिका भण्डारण र भूमिकाको आधारमा प्रयोगकर्ता पहुँच अधिकार गणना। म्याट्रिक्स।

तपाईं देख्न सक्नुहुन्छ, प्रदर्शनी फराकिलो र विविध छ। र यदि हामीले NoSQL का समर्थक/विपक्षीहरूको शिविर रोज्यौं भने, हामी समर्थकहरूमा सामेल हुनेछौं, किनकि हामीले हाम्रा फाइदाहरू प्राप्त गरेका थियौं, र हामीले अपेक्षा गरेको ठाउँमा।

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

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

उदाहरणका लागि, समयमै क्यासान्ड्राको अपडेटहरूको ट्र्याक राख्नुहोस्किनभने हामीले पाएका धेरै समस्याहरू पहिले नै ज्ञात र समाधान भइसकेका थिए।

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

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

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

खराब छैन तुरुन्तै TTL संलग्न गर्न र पुरानो डाटा सफा गर्न प्रदान गर्नुहोस्।

Cassandra बाट डाटा डाउनलोड गर्दा अनुप्रयोग तर्कले FETCH सिद्धान्तमा काम गर्नुपर्छ, ताकि सबै पङ्क्तिहरू मेमोरीमा एकैचोटि लोड हुँदैनन्, तर ब्याचहरूमा चयन गरिन्छन्।

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

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

जीवनको छ महिना पछि क्यासान्ड्रालाई के हुन्छ? सामान्यतया, त्यहाँ कुनै अनसुलझे समस्याहरू छैनन्। हामीले कुनै पनि गम्भीर दुर्घटना वा डेटा हराउन अनुमति दिएनौं। हो, हामीले केही समस्याहरूको क्षतिपूर्तिको बारेमा सोच्नुपरेको थियो जुन पहिले उत्पन्न भएको थिएन, तर अन्तमा यसले हाम्रो वास्तुकला समाधानलाई ठूलो रूपमा क्लाउड गरेन। यदि तपाइँ चाहानुहुन्छ र केहि नयाँ प्रयास गर्न डराउनुहुन्न, र एकै समयमा धेरै निराश हुन चाहनुहुन्न, त्यसपछि केहि पनि नि: शुल्क छैन भन्ने तथ्यको लागि तयार हुनुहोस्। तपाईंले पुरानो विरासत समाधानमा भन्दा बढी बुझ्नु, कागजातहरू खोल्न र तपाईंको आफ्नै व्यक्तिगत रेक भेला गर्नुपर्नेछ, र कुनै पनि सिद्धान्तले तपाईंलाई कुन रेकले तपाईंलाई पर्खिरहेको छ भनेर पहिले नै बताउँदैन।

स्रोत: www.habr.com