NoSQL मधील डेटा, स्थिरता आणि विश्वास न गमावता कॅसॅन्ड्राच्या डोळ्यात कसे पहावे

ते म्हणतात की जीवनातील प्रत्येक गोष्ट किमान एकदा प्रयत्न करणे योग्य आहे. आणि जर तुम्हाला रिलेशनल डीबीएमएससह काम करण्याची सवय असेल, तर सराव मध्ये NoSQL शी परिचित होणे फायदेशीर आहे, सर्व प्रथम, किमान सामान्य विकासासाठी. आता, या तंत्रज्ञानाच्या जलद विकासामुळे, या विषयावर बरीच विरोधाभासी मते आणि गरम वादविवाद आहेत, जे विशेषतः स्वारस्य वाढवतात.
आपण या सर्व विवादांचे सार शोधून काढल्यास, आपण पाहू शकता की ते चुकीच्या दृष्टिकोनामुळे उद्भवतात. जे NoSQL डेटाबेस वापरतात ते नेमके कुठे आवश्यक आहेत ते समाधानी आहेत आणि त्यांना या सोल्यूशनचे सर्व फायदे मिळतात. आणि जे प्रयोगकर्ते या तंत्रज्ञानावर रामबाण उपाय म्हणून विसंबून राहतात जिथे ते अजिबात लागू होत नाही, त्यांनी लक्षणीय फायदे न मिळवता रिलेशनल डेटाबेसची ताकद गमावली आहे.

Cassandra DBMS वर आधारित उपाय अंमलात आणण्याच्या आमच्या अनुभवाविषयी मी तुम्हाला सांगेन: आम्हाला कशाचा सामना करावा लागला, आम्ही कठीण परिस्थितीतून कसे बाहेर पडलो, आम्हाला NoSQL वापरून फायदा झाला का आणि आम्हाला अतिरिक्त प्रयत्न/निधी कोठे गुंतवावे लागले. .
काही प्रकारच्या स्टोरेजमध्ये कॉल रेकॉर्ड करणारी प्रणाली तयार करणे हे प्रारंभिक कार्य आहे.

सिस्टमचे ऑपरेटिंग तत्त्व खालीलप्रमाणे आहे. इनपुटमध्ये कॉलच्या संरचनेचे वर्णन करणाऱ्या विशिष्ट संरचनेसह फायलींचा समावेश होतो. अनुप्रयोग नंतर ही रचना योग्य स्तंभांमध्ये संग्रहित असल्याची खात्री करते. भविष्यात, सेव्ह केलेले कॉल सदस्यांसाठी रहदारीच्या वापरावरील माहिती प्रदर्शित करण्यासाठी वापरले जातात (शुल्क, कॉल, शिल्लक इतिहास).

त्यांनी कॅसॅन्ड्राची निवड का केली हे अगदी स्पष्ट आहे - ती मशीन गनसारखी लिहिते, सहज स्केलेबल आणि दोष-सहिष्णु आहे.

तर, हा अनुभव आम्हाला मिळाला

होय, अयशस्वी नोड ही शोकांतिका नाही. हे कॅसॅन्ड्राच्या दोष सहिष्णुतेचे सार आहे. परंतु एक नोड जिवंत असू शकतो आणि त्याच वेळी कार्यक्षमतेत त्रास होऊ लागतो. जसे हे दिसून आले की, हे त्वरित संपूर्ण क्लस्टरच्या कार्यक्षमतेवर परिणाम करते.

ज्या ठिकाणी ओरॅकलने आपल्या मर्यादांसह तुम्हाला वाचवले तेथे कॅसॅंड्रा तुमचे रक्षण करणार नाही. आणि जर अर्जाच्या लेखकाला हे आगाऊ समजले नसेल, तर कॅसॅंड्रासाठी आलेली दुहेरी मूळपेक्षा वाईट नाही. एकदा ते आल्यानंतर, आम्ही ते टाकू.

बॉक्सच्या बाहेर विनामूल्य कॅसॅन्ड्राला आयबीने जोरदार नापसंत केली: वापरकर्त्याच्या कृतींचे कोणतेही लॉगिंग नाही, अधिकारांमध्ये फरक नाही. कॉल्सची माहिती वैयक्तिक डेटा मानली जाते, याचा अर्थ असा की कोणत्याही प्रकारे विनंती/बदल करण्याचे सर्व प्रयत्न त्यानंतरच्या ऑडिटच्या शक्यतेसह लॉग इन केले जाणे आवश्यक आहे. तसेच, तुम्हाला वेगवेगळ्या वापरकर्त्यांसाठी वेगवेगळ्या स्तरांवर वेगळे अधिकार असण्याची गरज आहे याची जाणीव असणे आवश्यक आहे. एक साधा ऑपरेशन अभियंता आणि एक सुपर अॅडमिन जो संपूर्ण कीस्पेस मुक्तपणे हटवू शकतो, वेगवेगळ्या भूमिका, वेगवेगळ्या जबाबदाऱ्या आणि क्षमता आहेत. प्रवेश अधिकारांच्या अशा भिन्नतेशिवाय, डेटाचे मूल्य आणि अखंडता कोणत्याही सातत्य पातळीपेक्षा त्वरित प्रश्नात येईल.

आम्ही विचारात घेतले नाही की कॉलसाठी विविध परिस्थितींसाठी गंभीर विश्लेषणे आणि नियतकालिक सॅम्पलिंग दोन्ही आवश्यक आहेत. निवडलेले रेकॉर्ड नंतर हटवले जाणे आणि पुन्हा लिहिणे अपेक्षित असल्याने (कार्याचा भाग म्हणून, डेटाने सुरुवातीला चुकीच्या पद्धतीने आमच्या लूपमध्ये प्रवेश केला तेव्हा आम्ही डेटा अपडेट करण्याच्या प्रक्रियेस समर्थन दिले पाहिजे), कॅसॅंड्रा येथे आमची मित्र नाही. कॅसॅंड्रा पिग्गी बँकेसारखी आहे - गोष्टी ठेवणे सोयीचे आहे, परंतु आपण त्यात मोजू शकत नाही.

आम्हाला चाचणी क्षेत्रांमध्ये डेटा हस्तांतरित करताना समस्या आली (चाचणीतील 5 नोड्स विरुद्ध प्रोममध्ये 20). या प्रकरणात, डंप वापरला जाऊ शकत नाही.

Cassandra ला लिहिणाऱ्या अर्जाचा डेटा स्कीमा अपडेट करण्यात समस्या. रोलबॅकमुळे अनेक थडग्यांचे दगड निर्माण होतील, ज्यामुळे अप्रत्याशित मार्गांनी उत्पादकता कमी होऊ शकते.. कॅसॅन्ड्रा रेकॉर्डिंगसाठी अनुकूल आहे, आणि लिहिण्यापूर्वी जास्त विचार करत नाही. त्यात विद्यमान डेटा असलेले कोणतेही ऑपरेशन देखील रेकॉर्डिंग आहे. म्हणजेच, अनावश्यक हटवून, आम्ही फक्त आणखी रेकॉर्ड तयार करू आणि त्यापैकी फक्त काही समाधी दगडांनी चिन्हांकित केले जातील.

घालताना कालबाह्यता. Cassandra रेकॉर्डिंग मध्ये सुंदर आहे, पण कधी कधी येणारा प्रवाह तिला लक्षणीयरीत्या गोंधळात टाकू शकतो. असे घडते जेव्हा अनुप्रयोग काही कारणास्तव घातल्या जाऊ शकत नाहीत अशा अनेक रेकॉर्डभोवती फिरू लागतो. आणि आम्हाला एका वास्तविक DBA ची आवश्यकता असेल जो gc.log, सिस्टम आणि डीबग लॉग्सचे धीमे क्वेरी, कॉम्पॅक्शन प्रलंबित मेट्रिक्सचे निरीक्षण करेल.

एका क्लस्टरमध्ये अनेक डेटा केंद्रे. कुठून वाचायचे आणि कुठे लिहायचे?
कदाचित वाचन आणि लेखन मध्ये विभाजित? आणि असल्यास, लिहिण्यासाठी किंवा वाचण्यासाठी अर्जाच्या जवळ डीसी असावा का? आणि जर आपण चुकीची सुसंगतता पातळी निवडली तर आपण वास्तविक विभाजित मेंदूसह समाप्त होणार नाही का? बरेच प्रश्न आहेत, बर्‍याच अज्ञात सेटिंग्ज, शक्यता आहेत ज्यात तुम्हाला खरोखर टिंकर करायचे आहे.

आम्ही कसे ठरवले

नोड बुडण्यापासून रोखण्यासाठी, SWAP अक्षम केले होते. आणि आता, मेमरीची कमतरता असल्यास, नोड खाली जावे आणि मोठे gc विराम तयार करू नये.

त्यामुळे, आम्ही यापुढे डेटाबेसमधील तर्कशास्त्रावर अवलंबून राहणार नाही. ऍप्लिकेशन डेव्हलपर स्वतःला पुन्हा प्रशिक्षित करत आहेत आणि त्यांच्या स्वतःच्या कोडमध्ये सक्रियपणे खबरदारी घेण्यास सुरुवात करत आहेत. डेटा स्टोरेज आणि प्रोसेसिंगचे आदर्श स्पष्ट पृथक्करण.

आम्ही DataStax कडून समर्थन खरेदी केले. बॉक्स्ड कॅसॅन्ड्राचा विकास आधीच थांबला आहे (शेवटची कमिट फेब्रुवारी 2018 मध्ये होती). त्याच वेळी, डेटास्टॅक्स उत्कृष्ट सेवा आणि विद्यमान आयपी सोल्यूशन्ससाठी मोठ्या प्रमाणात सुधारित आणि रुपांतरित उपाय ऑफर करते.

मला हे देखील लक्षात घ्यायचे आहे की Cassandra निवड प्रश्नांसाठी फार सोयीस्कर नाही. अर्थात, वापरकर्त्यांसाठी (ट्रिफ्टच्या तुलनेत) CQL हे एक मोठे पाऊल आहे. परंतु तुमच्याकडे अशा सोयीस्कर जोडण्या, कोणत्याही फील्डद्वारे विनामूल्य फिल्टरिंग आणि क्वेरी ऑप्टिमायझेशन क्षमतांची सवय असलेले संपूर्ण विभाग असल्यास आणि हे विभाग तक्रारी आणि अपघातांचे निराकरण करण्यासाठी काम करत असतील, तर कॅसॅंड्रावरील उपाय त्यांच्यासाठी प्रतिकूल आणि मूर्खपणाचा वाटतो. आणि आम्ही आमच्या सहकाऱ्यांनी नमुने कसे बनवायचे ते ठरवू लागलो.

आम्ही दोन पर्यायांचा विचार केला. पहिल्या पर्यायामध्ये, आम्ही कॉल केवळ C* मध्येच नाही तर संग्रहित ओरॅकल डेटाबेसमध्ये देखील लिहितो. फक्त, C* च्या विपरीत, हा डेटाबेस केवळ चालू महिन्यासाठी कॉल संचयित करतो (केस रिचार्ज करण्यासाठी पुरेशी कॉल स्टोरेज खोली). येथे आम्हाला ताबडतोब खालील समस्या दिसली: जर आपण समकालिकपणे लिहिल्यास, जलद प्रवेशाशी संबंधित C* चे सर्व फायदे आपण गमावतो; जर आपण समकालिकपणे लिहिल्यास, सर्व आवश्यक कॉल ओरॅकलमध्ये आलेच याची कोणतीही हमी नाही. तेथे एक प्लस होता, परंतु एक मोठा: ऑपरेशनसाठी समान परिचित PL/SQL विकसक राहतो, म्हणजे आम्ही व्यावहारिकपणे "Facade" पॅटर्न लागू करतो. एक पर्यायी पर्याय. आम्ही एक यंत्रणा कार्यान्वित करतो जी C* वरून कॉल्स अनलोड करते, Oracle मधील संबंधित सारण्यांमधून संवर्धनासाठी काही डेटा खेचते, परिणामी नमुन्यांमध्ये सामील होते आणि आम्हाला परिणाम देते, जे आम्ही नंतर कसा तरी वापरतो (रोल बॅक, पुनरावृत्ती, विश्लेषण, प्रशंसा). बाधक: प्रक्रिया बर्‍यापैकी बहु-चरण आहे आणि त्याव्यतिरिक्त, ऑपरेशन कर्मचार्‍यांसाठी कोणताही इंटरफेस नाही.

शेवटी, आम्ही दुसऱ्या पर्यायावर स्थायिक झालो. अपाचे स्पार्कचा वापर वेगवेगळ्या जारमधून नमुना घेण्यासाठी केला गेला. यंत्रणेचे सार जावा कोडमध्ये कमी केले गेले आहे, जे निर्दिष्ट की (ग्राहक, कॉलची वेळ - विभाग की) वापरून, C* वरून डेटा तसेच इतर कोणत्याही डेटाबेसमधून समृद्धीसाठी आवश्यक डेटा काढते. त्यानंतर ते त्यांच्या मेमरीमध्ये सामील होते आणि परिणामी टेबलमध्ये निकाल प्रदर्शित करते. आम्ही स्पार्कवर एक वेब चेहरा काढला आणि तो वापरण्यायोग्य निघाला.

औद्योगिक चाचणी डेटा अद्यतनित करण्याच्या समस्येचे निराकरण करताना, आम्ही पुन्हा अनेक उपायांचा विचार केला. Sstloader द्वारे हस्तांतरण आणि चाचणी झोनमधील क्लस्टरला दोन भागांमध्ये विभाजित करण्याचा पर्याय, ज्यापैकी प्रत्येक पर्यायीपणे प्रचारात्मक असलेल्या समान क्लस्टरचा आहे, अशा प्रकारे त्याद्वारे समर्थित आहे. चाचणी अद्यतनित करताना, त्यांची अदलाबदल करण्याची योजना आखण्यात आली होती: चाचणीमध्ये काम केलेला भाग साफ केला जातो आणि उत्पादनात प्रवेश केला जातो आणि दुसरा स्वतंत्रपणे डेटासह कार्य करण्यास सुरवात करतो. तथापि, पुन्हा विचार केल्यावर, आम्ही अधिक तर्कशुद्धपणे डेटाचे मूल्यांकन केले जे हस्तांतरित करण्यासारखे होते आणि लक्षात आले की कॉल स्वतःच चाचण्यांसाठी एक विसंगत घटक आहेत, आवश्यक असल्यास त्वरीत व्युत्पन्न केले जातात आणि हा प्रमोशनल डेटा संच आहे ज्याला हस्तांतरित करण्यासाठी कोणतेही मूल्य नाही. चाचणी अशा अनेक स्टोरेज ऑब्जेक्ट्स आहेत ज्या हलवण्यासारख्या आहेत, परंतु हे अक्षरशः काही टेबल्स आहेत, आणि फार जड नाहीत. म्हणून आम्ही एक उपाय म्हणून, स्पार्क पुन्हा बचावासाठी आला, ज्याच्या मदतीने आम्ही लिहिले आणि टेबल, प्रोम-चाचणी दरम्यान डेटा हस्तांतरित करण्यासाठी स्क्रिप्ट सक्रियपणे वापरण्यास सुरुवात केली.

आमचे सध्याचे तैनाती धोरण आम्हाला रोलबॅकशिवाय काम करण्याची परवानगी देते. प्रोमोच्या आधी, एक अनिवार्य चाचणी चालविली जाते, जिथे चूक करणे इतके महाग नसते. अयशस्वी झाल्यास, तुम्ही नेहमी केसस्पेस टाकू शकता आणि सुरुवातीपासून संपूर्ण योजना रोल करू शकता.

कॅसॅन्ड्राची सतत उपलब्धता सुनिश्चित करण्यासाठी, तुम्हाला केवळ त्यालाच नव्हे तर डीबीएची आवश्यकता आहे. ऍप्लिकेशनसह काम करणार्‍या प्रत्येकाला सध्याची परिस्थिती कुठे आणि कशी पहावी आणि वेळेवर समस्यांचे निदान कसे करावे हे समजून घेणे आवश्यक आहे. हे करण्यासाठी, आम्ही सक्रियपणे DataStax OpsCenter (कार्यभारांचे प्रशासन आणि देखरेख), कॅसॅंड्रा ड्रायव्हर सिस्टम मेट्रिक्स (C* वर लिहिण्यासाठी टाइमआउट्सची संख्या, C* वरून वाचण्यासाठी टाइमआउट्सची संख्या, कमाल विलंब इ.) वापरतो, ऑपरेशनचे निरीक्षण करतो. कॅसॅंड्रासोबत काम करत आहे.

जेव्हा आम्ही मागील प्रश्नाचा विचार केला, तेव्हा आम्हाला कळले की आमचा मुख्य धोका कुठे असू शकतो. हे डेटा डिस्प्ले फॉर्म आहेत जे अनेक स्वतंत्र क्वेरींपासून स्टोरेजपर्यंत डेटा प्रदर्शित करतात. अशाप्रकारे आपल्याला खूप विसंगत माहिती मिळू शकते. परंतु ही समस्या तितकीच संबंधित असेल जर आम्ही फक्त एका डेटा सेंटरसह काम केले. त्यामुळे येथे सर्वात वाजवी गोष्ट म्हणजे, अर्थातच, थर्ड-पार्टी अॅप्लिकेशनवरील डेटा वाचण्यासाठी बॅच फंक्शन तयार करणे, ज्यामुळे डेटा एकाच कालावधीत प्राप्त होईल याची खात्री होईल. कार्यक्षमतेच्या दृष्टीने वाचन आणि लेखन या विभागणीसाठी, येथे आम्हाला या जोखमीमुळे थांबवले गेले आहे की DCs दरम्यान काही कनेक्शन गमावल्यास, आम्ही एकमेकांशी पूर्णपणे विसंगत असलेल्या दोन क्लस्टरसह समाप्त होऊ शकतो.

परिणामी, आतासाठी EACH_QUORUM लिहिण्यासाठी सातत्य पातळीवर थांबले, वाचनासाठी - LOCAL_QUORUM

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

ऑपरेशनल समर्थन आणि पुढील विकासाच्या संभाव्यतेच्या दृष्टिकोनातून परिणामी समाधानाचे मूल्यांकन करण्यासाठी, आम्ही असा विकास कोठे लागू केला जाऊ शकतो याचा विचार करण्याचे ठरविले.

थेट बॅट, नंतर “सोयीस्कर असेल तेव्हा पैसे द्या” (आम्ही C* मध्ये माहिती लोड करतो, स्पार्क स्क्रिप्ट वापरून गणना करतो), क्षेत्रानुसार एकत्रीकरणासह दाव्यांची गणना, भूमिका संचयित करणे आणि भूमिकेच्या आधारावर वापरकर्त्याच्या प्रवेश अधिकारांची गणना करणे यासारख्या प्रोग्रामसाठी डेटा स्कोअरिंग मॅट्रिक्स.

जसे आपण पाहू शकता, भांडार विस्तृत आणि वैविध्यपूर्ण आहे. आणि जर आम्ही NoSQL च्या समर्थक/विरोधकांचा कॅम्प निवडला, तर आम्ही समर्थकांमध्ये सामील होऊ, कारण आम्हाला आमचे फायदे मिळाले आहेत, आणि आम्हाला अपेक्षा आहे.

अगदी बॉक्सच्या बाहेर असलेला कॅसॅंड्रा पर्याय रिअल टाइममध्ये क्षैतिज स्केलिंगला अनुमती देतो, सिस्टममधील डेटा वाढविण्याच्या समस्येचे पूर्णपणे वेदनारहित निराकरण करतो. आम्ही एका वेगळ्या सर्किटमध्ये कॉल एग्रीगेट्सची गणना करण्यासाठी एक अतिशय उच्च-लोड यंत्रणा हलवू शकलो आणि डेटाबेसमध्येच कस्टम जॉब्स आणि ऑब्जेक्ट्स लिहिण्याच्या चुकीच्या प्रथेपासून मुक्त होऊन, अॅप्लिकेशन स्कीमा आणि लॉजिक वेगळे करू शकलो. आम्हाला निवडण्याची आणि कॉन्फिगर करण्याची, वेग वाढवण्याची संधी मिळाली, आम्ही कोणत्या DC वर गणना करू आणि कोणत्यावर आम्ही डेटा रेकॉर्ड करू, आम्ही वैयक्तिक नोड्स आणि संपूर्णपणे DC दोन्ही क्रॅश होण्यापासून स्वतःचा विमा उतरवला.

आमच्या आर्किटेक्चरला नवीन प्रकल्पांवर लागू करणे आणि आधीच काही अनुभव असल्याने, मी वर वर्णन केलेल्या बारकावे त्वरित लक्षात घेऊ इच्छितो आणि काही चुका टाळू इच्छितो, काही तीक्ष्ण कोपरे गुळगुळीत करू इच्छितो जे सुरुवातीला टाळता येत नाहीत.

उदाहरणार्थ, Cassandra च्या अपडेट्सचा वेळेवर मागोवा ठेवाकारण आम्हाला मिळालेल्या काही समस्या आधीच ज्ञात आणि निश्चित केल्या होत्या.

डेटाबेस स्वतः आणि स्पार्क दोन्ही एकाच नोड्सवर ठेवू नका (किंवा अनुमत स्त्रोत वापराच्या प्रमाणात काटेकोरपणे विभाजित करा), कारण स्पार्क अपेक्षेपेक्षा जास्त ओपी खाऊ शकते आणि आम्हाला आमच्या यादीतून समस्या क्रमांक 1 पटकन मिळेल.

प्रकल्प चाचणी टप्प्यावर देखरेख आणि ऑपरेशनल क्षमता सुधारणे. सुरुवातीला, आमच्या सोल्यूशनच्या सर्व संभाव्य ग्राहकांना शक्य तितके विचारात घ्या, कारण डेटाबेस संरचना शेवटी यावर अवलंबून असेल.

संभाव्य ऑप्टिमायझेशनसाठी परिणामी सर्किट अनेक वेळा फिरवा. कोणते फील्ड अनुक्रमित केले जाऊ शकतात ते निवडा. सर्वात योग्य आणि चांगल्या प्रकारे विचारात घेण्यासाठी आम्ही कोणती अतिरिक्त टेबले बनवायची आहेत हे समजून घ्या आणि नंतर विनंती केल्यावर आवश्यक माहिती प्रदान करा (उदाहरणार्थ, हे गृहीत धरून की आम्ही समान डेटा वेगवेगळ्या सारण्यांमध्ये संग्रहित करू शकतो, त्यानुसार भिन्न ब्रेकडाउन लक्षात घेऊन भिन्न निकष, आम्ही वाचलेल्या विनंत्यांसाठी CPU वेळ लक्षणीयरीत्या वाचवू शकतो).

वाईट नाही TTL संलग्न करण्यासाठी आणि कालबाह्य डेटा साफ करण्यासाठी त्वरित प्रदान करा.

Cassandra वरून डेटा डाउनलोड करताना ऍप्लिकेशन लॉजिकने FETCH तत्त्वावर कार्य केले पाहिजे, जेणेकरून सर्व पंक्ती एकाच वेळी मेमरीमध्ये लोड केल्या जाणार नाहीत, परंतु बॅचमध्ये निवडल्या जातील.

वर्णन केलेल्या सोल्युशनमध्ये प्रकल्प हस्तांतरित करण्यापूर्वी सल्ला दिला जातो क्रॅश चाचण्यांची मालिका आयोजित करून सिस्टमची दोष सहनशीलता तपासा, जसे की एका डेटा सेंटरमधील डेटा गमावणे, विशिष्ट कालावधीत खराब झालेले डेटा पुनर्संचयित करणे, डेटा केंद्रांमधील नेटवर्क ड्रॉपआउट. अशा चाचण्या केवळ प्रस्तावित आर्किटेक्चरच्या साधक आणि बाधकांचे मूल्यांकन करण्यास अनुमती देत ​​​​नाही, परंतु ते आयोजित करणार्‍या अभियंत्यांसाठी चांगला सराव देखील प्रदान करतील आणि उत्पादनामध्ये सिस्टम बिघाड पुनरुत्पादित केल्यास प्राप्त केलेले कौशल्य अनावश्यक होणार नाही.

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

सहा महिन्यांच्या आयुष्यानंतर कॅसॅन्ड्राचे काय होते? सर्वसाधारणपणे, कोणत्याही निराकरण न झालेल्या समस्या नाहीत. आम्ही कोणतेही गंभीर अपघात किंवा डेटा गमावण्याची परवानगी दिली नाही. होय, पूर्वी उद्भवलेल्या काही समस्यांची पूर्तता करण्याबद्दल आम्हाला विचार करावा लागला, परंतु शेवटी यामुळे आमच्या वास्तुशास्त्रीय समाधानास मोठ्या प्रमाणात ढग नाही. जर तुम्हाला काहीतरी नवीन करण्याचा प्रयत्न करण्याची इच्छा असेल आणि घाबरत नसेल आणि त्याच वेळी खूप निराश होऊ इच्छित नसेल तर काहीही विनामूल्य नाही या वस्तुस्थितीसाठी सज्ज व्हा. तुम्हाला जुन्या लेगसी सोल्यूशनपेक्षा अधिक समजून घेणे, दस्तऐवजांचा अभ्यास करणे आणि स्वतःचे वैयक्तिक रेक एकत्र करणे आवश्यक आहे आणि कोणता रेक तुमची वाट पाहत आहे हे कोणताही सिद्धांत तुम्हाला आगाऊ सांगणार नाही.

स्त्रोत: www.habr.com