DBA बॉट जो. अनातोली स्टॅन्सलर (Postgres.ai)

बॅकएंड डेव्हलपरला हे कसे समजते की SQL क्वेरी “प्रॉड” वर चांगले काम करेल? मोठ्या किंवा वेगाने वाढणाऱ्या कंपन्यांमध्ये, प्रत्येकाला "उत्पादन" मध्ये प्रवेश मिळत नाही. आणि प्रवेशासह, सर्व विनंत्या वेदनारहितपणे तपासल्या जाऊ शकत नाहीत आणि डेटाबेसची एक प्रत तयार करण्यासाठी अनेकदा तास लागतात. या समस्यांचे निराकरण करण्यासाठी, आम्ही एक कृत्रिम DBA तयार केला - जो. हे आधीच अनेक कंपन्यांमध्ये यशस्वीरित्या लागू केले गेले आहे आणि डझनभर विकसकांना मदत करते.

व्हिडिओ:

सर्वांना नमस्कार! माझे नाव अनातोली स्टॅन्सलर आहे. मी एका कंपनीत काम करतो postgres.ai. विकासक, DBA आणि QAs कडून Postgres च्या कामाशी संबंधित विलंब दूर करून विकास प्रक्रियेला गती देण्यासाठी आम्ही वचनबद्ध आहोत.

आमच्याकडे चांगले क्लायंट आहेत आणि आजच्या अहवालाचा काही भाग आम्ही त्यांच्यासोबत काम करताना भेटलेल्या प्रकरणांना समर्पित केला जाईल. आम्ही त्यांना गंभीर समस्या सोडवण्यास कशी मदत केली याबद्दल मी बोलेन.

जेव्हा आम्ही जटिल हाय-लोड स्थलांतर विकसित करत असतो आणि करत असतो, तेव्हा आम्ही स्वतःला प्रश्न विचारतो: “हे स्थलांतर बंद होईल का?”. आम्ही पुनरावलोकन वापरतो, आम्ही अधिक अनुभवी सहकारी, डीबीए तज्ञांचे ज्ञान वापरतो. आणि ते उडेल की नाही हे ते सांगू शकतात.

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

कोणी थेट उत्पादनावर अनुक्रमणिका बनवली आहे किंवा कोणतेही बदल केले आहेत? अगदी थोडा. आणि यामुळे डेटा गमावला किंवा डाउनटाइम होता हे तथ्य कोणासाठी घडले? मग तुम्हाला ही वेदना कळेल. बॅकअप आहेत देवाचे आभार.

पहिला दृष्टिकोन म्हणजे उत्पादनात चाचणी करणे. किंवा, जेव्हा एखादा विकसक स्थानिक मशीनवर बसतो तेव्हा त्याच्याकडे चाचणी डेटा असतो, काही प्रकारची मर्यादित निवड असते. आणि आम्ही उत्पादनासाठी रोल आउट करतो आणि आम्हाला ही परिस्थिती प्राप्त होते.

हे दुखत आहे, ते महाग आहे. न करणे बहुधा उत्तम.

आणि ते करण्याचा सर्वोत्तम मार्ग कोणता आहे?

चला स्टेजिंग घेऊ आणि तेथे उत्पादनाचा काही भाग निवडा. किंवा सर्वोत्तम, एक वास्तविक उत्पादन घेऊ, सर्व डेटा. आणि आम्ही ते स्थानिक पातळीवर विकसित केल्यानंतर, आम्ही स्टेजिंगसाठी देखील तपासू.

हे आम्हाला काही त्रुटी काढून टाकण्यास अनुमती देईल, म्हणजे त्यांना उत्पादनावर येण्यापासून प्रतिबंधित करेल.

समस्या काय आहेत?

• समस्या अशी आहे की आम्ही हे स्टेजिंग सहकार्यांसह सामायिक करतो. आणि बर्‍याचदा असे घडते की आपण काही प्रकारचे बदल करता, बेम - आणि कोणताही डेटा नाही, काम निचरा होत आहे. स्टेजिंग मल्टी-टेराबाइट होते. आणि ते पुन्हा वाढण्यासाठी तुम्हाला बराच काळ प्रतीक्षा करावी लागेल. आणि आम्ही उद्या ते अंतिम करण्याचा निर्णय घेतो. बस्स, आमचा विकास आहे.
• आणि, अर्थातच, आमचे अनेक सहकारी तेथे कार्यरत आहेत, अनेक संघ आहेत. आणि ते स्वहस्ते करावे लागेल. आणि हे गैरसोयीचे आहे.

आणि हे सांगण्यासारखे आहे की आमच्याकडे फक्त एक प्रयत्न आहे, एक शॉट आहे, जर आम्हाला डेटाबेसमध्ये काही बदल करायचे असतील, डेटाला स्पर्श करा, रचना बदला. आणि जर काही चूक झाली असेल, स्थलांतरात त्रुटी आली असेल तर आम्ही पटकन मागे हटणार नाही.

हे मागील दृष्टिकोनापेक्षा चांगले आहे, परंतु तरीही काही प्रकारची त्रुटी उत्पादनात जाण्याची उच्च संभाव्यता आहे.

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

टेराबाइटपेक्षा मोठा डेटाबेस कोणाकडे आहे? अर्ध्याहून अधिक खोली.

आणि हे स्पष्ट आहे की प्रत्येक विकसकासाठी मशीन ठेवणे, जेव्हा इतके मोठे उत्पादन होते तेव्हा ते खूप महाग असते आणि त्याशिवाय, यास बराच वेळ लागतो.

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

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

परंतु ते हा दृष्टिकोन वापरतात कारण ते त्यांना उत्पादन विश्वसनीय ठेवण्याची परवानगी देते.

आपण येथे काय करू शकतो? चला चाचणी बेंच स्वस्त करू आणि प्रत्येक विकसकाला त्यांचे स्वतःचे चाचणी बेंच देऊ.

आणि हे शक्य आहे.

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

वास्तविक उदाहरण:

• DB - 4,5 टेराबाइट्स.

• आम्ही 30 सेकंदात स्वतंत्र प्रती मिळवू शकतो.

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

हे उत्तम आहे. येथे आपण जादू आणि समांतर विश्वाबद्दल बोलत आहोत.

आमच्या बाबतीत, हे OpenZFS प्रणाली वापरून कार्य करते.

OpenZFS ही कॉपी-ऑन-राईट फाइल सिस्टम आहे जी बॉक्सच्या बाहेर स्नॅपशॉट आणि क्लोनचे समर्थन करते. हे विश्वसनीय आणि स्केलेबल आहे. तिला व्यवस्थापित करणे खूप सोपे आहे. हे अक्षरशः दोन संघांमध्ये तैनात केले जाऊ शकते.

इतर पर्याय आहेत:

• एलव्हीएम,

• स्टोरेज (उदाहरणार्थ, शुद्ध स्टोरेज).

मी ज्या डेटाबेस लॅबबद्दल बोलत आहे ती मॉड्यूलर आहे. हे पर्याय वापरून अंमलात आणता येतात. परंतु आत्तासाठी, आम्ही OpenZFS वर लक्ष केंद्रित केले आहे, कारण विशेषत: LVM मध्ये समस्या होत्या.

हे कसे कार्य करते? प्रत्येक वेळी डेटा बदलण्याऐवजी तो ओव्हरराईट करण्याऐवजी, हा नवीन डेटा एका नवीन बिंदूपासून, नवीन स्नॅपशॉटमधून आहे असे चिन्हांकित करून आम्ही तो जतन करतो.

आणि भविष्यात, जेव्हा आम्हाला रोलबॅक करायचे असेल किंवा आम्हाला जुन्या आवृत्तीतून नवीन क्लोन बनवायचा असेल, तेव्हा आम्ही फक्त म्हणतो: "ठीक आहे, आम्हाला असे चिन्हांकित केलेले डेटाचे ब्लॉक द्या."

आणि हा वापरकर्ता अशा डेटा सेटसह कार्य करेल. तो हळूहळू त्यांना बदलेल, स्वतःचे स्नॅपशॉट बनवेल.

आणि आम्ही शाखा करू. आमच्या बाबतीत प्रत्येक डेव्हलपरला स्वतःचा क्लोन ठेवण्याची संधी असेल जो तो संपादित करतो आणि शेअर केलेला डेटा प्रत्येकामध्ये सामायिक केला जाईल.

अशी प्रणाली घरी तैनात करण्यासाठी, आपल्याला दोन समस्या सोडवणे आवश्यक आहे:

• पहिला डेटाचा स्रोत आहे, तुम्ही तो कुठून घ्याल. तुम्ही उत्पादनासह प्रतिकृती सेट करू शकता. तुम्ही कॉन्फिगर केलेले बॅकअप तुम्ही आधीच वापरू शकता, मला आशा आहे. WAL-E, WAL-G किंवा बर्मन. आणि जरी तुम्ही काही प्रकारचे क्लाउड सोल्यूशन जसे की RDS किंवा Cloud SQL वापरत असाल, तर तुम्ही लॉजिकल डंप वापरू शकता. परंतु तरीही आम्ही तुम्हाला बॅकअप वापरण्याचा सल्ला देतो, कारण या दृष्टिकोनामुळे तुम्ही फाइल्सची भौतिक रचना देखील राखून ठेवू शकता, ज्यामुळे तुम्हाला त्या समस्यांना पकडण्यासाठी उत्पादनात दिसत असलेल्या मेट्रिक्सच्या अगदी जवळ जाण्याची परवानगी मिळेल.

• दुसरे म्हणजे जिथे तुम्हाला डेटाबेस लॅब होस्ट करायची आहे. ते मेघ असू शकते, ते ऑन-प्रिमाइस असू शकते. येथे हे सांगणे महत्त्वाचे आहे की ZFS डेटा कॉम्प्रेशनचे समर्थन करते. आणि ते खूप चांगले करते.

कल्पना करा की अशा प्रत्येक क्लोनसाठी, आम्ही बेससह केलेल्या ऑपरेशन्सवर अवलंबून, काही प्रकारचे देव वाढतील. त्यासाठी देवालाही जागा लागणार आहे. परंतु आम्ही 4,5 टेराबाइट्सचा आधार घेतल्यामुळे, ZFS ते 3,5 टेराबाइट्सवर संकुचित करेल. हे सेटिंग्जवर अवलंबून बदलू शकते. आणि आमच्याकडे अजूनही देवासाठी जागा आहे.

अशी प्रणाली वेगवेगळ्या प्रकरणांसाठी वापरली जाऊ शकते.

• हे विकसक आहेत, क्वेरी प्रमाणीकरणासाठी, ऑप्टिमायझेशनसाठी डीबीए.

• आम्ही उत्पादनावर रोल आउट करण्यापूर्वी विशिष्ट स्थलांतराची चाचणी घेण्यासाठी हे QA चाचणीमध्ये वापरले जाऊ शकते. आणि आम्ही वास्तविक डेटासह QA साठी विशेष वातावरण देखील वाढवू शकतो, जिथे ते नवीन कार्यक्षमतेची चाचणी करू शकतात. आणि प्रतीक्षा तासांऐवजी काही सेकंद लागतील आणि कदाचित काही इतर प्रकरणांमध्ये जेथे पातळ प्रती वापरल्या जात नाहीत.

• आणि आणखी एक केस. जर कंपनीकडे विश्लेषण प्रणाली सेट केलेली नसेल, तर आम्ही उत्पादन बेसचा एक पातळ क्लोन वेगळा करू शकतो आणि ते दीर्घ क्वेरी किंवा विशेष निर्देशांकांना देऊ शकतो ज्याचा वापर विश्लेषणामध्ये केला जाऊ शकतो.

या दृष्टिकोनासह:

1. "प्रॉड" वर त्रुटींची कमी संभाव्यता, कारण आम्ही पूर्ण-आकाराच्या डेटावर सर्व बदलांची चाचणी केली आहे.

2. आमच्याकडे चाचणीची संस्कृती आहे, कारण आता तुम्हाला स्वतःच्या स्टँडसाठी तासनतास थांबावे लागणार नाही.

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

• कमी रिफॅक्टरिंग होईल. उत्पादनामध्ये कमी बग संपतील. आम्ही त्यांना नंतर कमी करू.

• आपण अपरिवर्तनीय बदल परत करू शकतो. हा मानक दृष्टिकोन नाही.

1. हे फायदेशीर आहे कारण आम्ही चाचणी बेंचची संसाधने सामायिक करतो.

आधीच चांगले, परंतु आणखी काय प्रवेगक केले जाऊ शकते?

अशा प्रणालीबद्दल धन्यवाद, आम्ही अशा चाचणीमध्ये प्रवेश करण्यासाठी थ्रेशोल्ड मोठ्या प्रमाणात कमी करू शकतो.

आता एक दुष्ट वर्तुळ आहे जिथे वास्तविक पूर्ण-आकाराच्या डेटामध्ये प्रवेश मिळविण्यासाठी विकासकाने तज्ञ बनले पाहिजे. अशा प्रवेशासह त्याच्यावर विश्वास ठेवला पाहिजे.

पण ती नसेल तर वाढणार कशी. परंतु जर तुमच्याकडे चाचणी डेटाचा एक छोटा संच उपलब्ध असेल तर? मग तुम्हाला कोणताही खरा अनुभव मिळणार नाही.

या वर्तुळातून बाहेर कसे पडायचे? प्रथम इंटरफेस म्हणून, कोणत्याही स्तराच्या विकासकांसाठी सोयीस्कर, आम्ही स्लॅक बॉट निवडला. पण तो इतर कोणताही इंटरफेस असू शकतो.

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

आणि स्लॅक आम्हाला बॉक्सच्या बाहेर सहकार्याची संधी देते. हे फक्त एक चॅनेल असल्याने, तुम्ही अशा विनंतीसाठी थ्रेडमध्येच या विनंतीवर चर्चा सुरू करू शकता, तुमच्या सहकाऱ्यांना, कंपनीत असलेल्या DBA ला पिंग करू शकता.

पण, अर्थातच, समस्या आहेत. हे वास्तविक जग असल्यामुळे आणि आम्ही एकाच वेळी अनेक क्लोन होस्ट करणारा सर्व्हर वापरत आहोत, आम्हाला क्लोनसाठी उपलब्ध मेमरी आणि CPU पॉवरचे प्रमाण संकुचित करावे लागेल.

परंतु या चाचण्या प्रशंसनीय होण्यासाठी, आपल्याला या समस्येचे निराकरण करणे आवश्यक आहे.

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

उत्पादनाप्रमाणेच हार्डवेअर असणे छान होईल, परंतु ते वेगळे असू शकते.

पोस्टग्रेस मेमरीसह कसे कार्य करते ते लक्षात ठेवूया. आमच्याकडे दोन कॅशे आहेत. फाइल सिस्टममधील एक आणि एक मूळ पोस्टग्रेस, म्हणजे सामायिक बफर कॅशे.

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

आणि दुसरा कॅशे सर्व उपलब्ध जागा वापरतो.

आणि जेव्हा आपण एका मशीनवर अनेक क्लोन बनवतो तेव्हा असे दिसून येते की आपण हळूहळू मेमरी भरतो. आणि चांगल्या प्रकारे, शेअर्ड बफर कॅशे मशीनवर उपलब्ध असलेल्या एकूण मेमरीच्या 25% आहे.

आणि असे दिसून आले की जर आपण हे पॅरामीटर बदलले नाही, तर आपण एका मशीनवर फक्त 4 उदाहरणे चालवू शकू, म्हणजे अशा सर्व पातळ क्लोनपैकी 4. आणि हे नक्कीच वाईट आहे, कारण आपल्याला त्यापैकी बरेच काही हवे आहे.

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

उदाहरणार्थ, आमच्याकडे उत्पादनावर मोठी कॅशे असल्यास, पोस्टग्रेस इंडेक्स वापरण्यास प्राधान्य देईल. आणि नसेल तर SeqScan असेल. आणि आमच्या योजना जुळल्या नाहीत तर काय फायदा होईल?

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

Effective_cache_size म्हणजे आमच्याकडे उपलब्ध असलेल्या कॅशेची अंदाजे रक्कम, म्हणजे बफर कॅशे आणि फाइल सिस्टम कॅशेची बेरीज. हे कॉन्फिगरेशनद्वारे सेट केले आहे. आणि ही मेमरी वाटप केलेली नाही.

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

परंतु याचा वेळेवर परिणाम होऊ शकतो. आणि आम्ही वेळेनुसार क्वेरी ऑप्टिमाइझ करतो, परंतु हे महत्वाचे आहे की वेळ अनेक घटकांवर अवलंबून असते:

• हे सध्या उत्पादनावर असलेल्या लोडवर अवलंबून आहे.

• हे मशीनच्या स्वतःच्या वैशिष्ट्यांवर अवलंबून असते.

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

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

जो विशेषत: कसे ऑप्टिमाइझ केले आहे ते पाहू या.

चला प्रत्यक्ष व्यवस्थेकडून विनंती करूया. या प्रकरणात, डेटाबेस 1 टेराबाइट आहे. आणि आम्हाला 10 पेक्षा जास्त लाईक्स मिळालेल्या ताज्या पोस्टची संख्या मोजायची आहे.

आम्ही चॅनेलला संदेश लिहित आहोत, आमच्यासाठी क्लोन तैनात केला आहे. आणि आम्ही पाहू की अशी विनंती 2,5 मिनिटांत पूर्ण होईल. ही पहिली गोष्ट आपल्या लक्षात येते.

बी जो तुम्हाला योजना आणि मेट्रिक्सवर आधारित स्वयंचलित शिफारसी दर्शवेल.

तुलनेने कमी संख्येने पंक्ती मिळविण्यासाठी क्वेरी खूप जास्त डेटावर प्रक्रिया करते हे आपण पाहू. आणि काही प्रकारचे विशेष निर्देशांक आवश्यक आहे, कारण आमच्या लक्षात आले की क्वेरीमध्ये बर्याच फिल्टर केलेल्या पंक्ती आहेत.

काय झाले ते जवळून पाहूया. खरंच, आम्ही पाहतो की आम्ही फाईल कॅशे किंवा डिस्कवरून जवळपास दीड गीगाबाइट डेटा वाचला आहे. आणि हे चांगले नाही, कारण आम्हाला फक्त 142 ओळी मिळाल्या.

आणि, असे दिसते की, आमच्याकडे येथे अनुक्रमणिका स्कॅन आहे आणि त्वरीत काम केले पाहिजे, परंतु आम्ही बर्याच ओळी फिल्टर केल्या (आम्हाला त्या मोजायच्या होत्या), विनंती हळूहळू पूर्ण झाली.

आणि हे या योजनेत घडले कारण क्वेरीमधील अटी आणि निर्देशांकातील अटी अंशतः जुळत नाहीत.

चला अनुक्रमणिका अधिक अचूक करण्याचा प्रयत्न करूया आणि त्यानंतर क्वेरी अंमलबजावणी कशी बदलते ते पाहू.

इंडेक्स तयार होण्यास बराच वेळ लागला, परंतु आता आम्ही क्वेरी तपासतो आणि पाहतो की 2,5 मिनिटांऐवजी फक्त 156 मिलीसेकंद आहे, जे पुरेसे आहे. आणि आम्ही फक्त 6 मेगाबाइट डेटा वाचतो.

आणि आता आम्ही फक्त इंडेक्स स्कॅन वापरतो.

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

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

येथे आपण विशिष्ट नोड्सची एकमेकांशी तुलना करू शकतो. आणि हे स्पष्ट होईल की त्यापैकी कोणते कमी किंवा जास्त घेते, जे सहसा इतर प्रस्तुतीकरण पद्धतींमध्ये करणे कठीण असते.

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

आणि ज्या विकसकांनी अद्याप या विषयाचा अभ्यास केलेला नाही ते देखील explain.depesz.com वापरतात, कारण कोणते मेट्रिक्स महत्त्वाचे आहेत आणि कोणते नाहीत हे शोधणे त्यांच्यासाठी सोपे आहे.

व्हिज्युअलायझेशनसाठी एक नवीन दृष्टीकोन आहे - हे आहे explain.dalibo.com. ते ट्री व्हिज्युअलायझेशन करतात, परंतु नोड्सची एकमेकांशी तुलना करणे खूप कठीण आहे. येथे तुम्ही रचना चांगल्या प्रकारे समजू शकता, तथापि, जर मोठी विनंती असेल, तर तुम्हाला पुढे मागे स्क्रोल करणे आवश्यक आहे, परंतु एक पर्याय देखील आहे.

सहयोग

आणि, मी म्हटल्याप्रमाणे, स्लॅक आम्हाला सहयोग करण्याची संधी देते. उदाहरणार्थ, ऑप्टिमाइझ कसे करायचे हे स्पष्ट नसलेली गुंतागुंतीची क्वेरी आम्हाला आढळल्यास, आम्ही स्लॅक मधील एका थ्रेडमध्ये आमच्या सहकाऱ्यांसोबत ही समस्या स्पष्ट करू शकतो.

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

हे लक्षात घेणे देखील महत्त्वाचे आहे की समाधान स्वतः क्रांतिकारक नाही, कारण डेल्फिक्स आहे, परंतु ते एक एंटरप्राइझ समाधान आहे. ते पूर्णपणे बंद आहे, ते खूप महाग आहे. आम्ही विशेषतः पोस्टग्रेसमध्ये तज्ञ आहोत. ही सर्व मुक्त स्रोत उत्पादने आहेत. आमच्यात सामील व्हा!

इथेच माझा शेवट होतो. धन्यवाद!

प्रश्न

नमस्कार! अहवालाबद्दल धन्यवाद! खूप मनोरंजक, विशेषतः माझ्यासाठी, कारण मी काही काळापूर्वी त्याच समस्येचे निराकरण केले होते. आणि म्हणून माझ्या मनात अनेक प्रश्न आहेत. मला तरी त्यातला काही भाग मिळेल अशी आशा आहे.

मला आश्चर्य वाटते की आपण या वातावरणासाठी जागा कशी मोजता? तंत्रज्ञानाचा अर्थ असा आहे की विशिष्ट परिस्थितीत, तुमचे क्लोन कमाल आकारात वाढू शकतात. साधारणपणे सांगायचे तर, जर तुमच्याकडे दहा टेराबाइट डेटाबेस आणि 10 क्लोन असतील, तर प्रत्येक क्लोनचे वजन 10 अद्वितीय डेटा असेल अशा परिस्थितीचे अनुकरण करणे सोपे आहे. तुम्ही या जागेची, म्हणजे त्या डेल्टाची गणना कशी कराल ज्याबद्दल तुम्ही बोललात, ज्यामध्ये हे क्लोन राहतील?

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

होय, मला एक प्रश्न आहे. म्हणजेच, तुम्ही या मॉड्यूल्सचे जीवन चक्र कसे सुनिश्चित कराल? आमच्याकडे ही समस्या आणि एक संपूर्ण वेगळी कथा आहे. हे कसे घडते?

प्रत्येक क्लोनसाठी काही ttl आहे. मुळात, आमच्याकडे एक निश्चित ttl आहे.

काय, एक गुप्त नाही तर?

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

मला तंत्रज्ञानाच्या निवडीमध्ये देखील स्वारस्य आहे, कारण, उदाहरणार्थ, आम्ही एका किंवा दुसर्या कारणास्तव समांतरपणे अनेक पद्धती वापरतो. ZFS का? तुम्ही LVM का वापरला नाही? तुम्ही LVM सह समस्या असल्याचे नमूद केले आहे. काय समस्या होत्या? माझ्या मते, कार्यक्षमतेच्या बाबतीत, स्टोरेजसह सर्वात इष्टतम पर्याय आहे.

ZFS ची मुख्य समस्या काय आहे? तुम्ही एकाच होस्टवर चालणे आवश्यक आहे, म्हणजे सर्व उदाहरणे एकाच OS मध्ये राहतील. आणि स्टोरेजच्या बाबतीत, आपण भिन्न उपकरणे कनेक्ट करू शकता. आणि अडथळे फक्त ते ब्लॉक्स आहेत जे स्टोरेज सिस्टमवर आहेत. आणि तंत्रज्ञानाच्या निवडीचा प्रश्न मनोरंजक आहे. LVM का नाही?

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

निकोलाई समोखवालोव्ह: मी आणखी टिप्पणी करू शकतो? माझे नाव निकोले आहे, आम्ही अनातोलीसह एकत्र काम करतो. मी सहमत आहे की स्टोरेज उत्तम आहे. आणि आमच्या काही ग्राहकांकडे प्युअर स्टोरेज इ.

अॅनाटोलीने अचूकपणे नोंदवले की आम्ही मॉड्यूलरिटीवर लक्ष केंद्रित केले आहे. आणि भविष्यात, आपण एक इंटरफेस लागू करू शकता - स्नॅपशॉट घ्या, क्लोन बनवा, क्लोन नष्ट करा. हे सर्व सोपे आहे. आणि स्टोरेज थंड आहे, ते असल्यास.

परंतु ZFS प्रत्येकासाठी उपलब्ध आहे. DelPhix आधीच पुरेसे आहे, त्यांच्याकडे 300 क्लायंट आहेत. यापैकी, फॉर्च्युन 100 चे 50 क्लायंट आहेत, म्हणजेच ते NASA इ.चे लक्ष्य आहेत. प्रत्येकाला हे तंत्रज्ञान मिळण्याची वेळ आली आहे. आणि म्हणूनच आमच्याकडे ओपन सोर्स कोअर आहे. आमच्याकडे एक इंटरफेस भाग आहे जो मुक्त स्रोत नाही. हेच व्यासपीठ आम्ही दाखवणार आहोत. परंतु ते प्रत्येकासाठी उपलब्ध असावे अशी आमची इच्छा आहे. आम्ही एक क्रांती करू इच्छितो जेणेकरून सर्व परीक्षक लॅपटॉपवर अंदाज करणे थांबवतील. आपण SELECT लिहावे आणि लगेच पहा की ते हळू आहे. त्याबद्दल DBA ची वाट पाहणे थांबवा. येथे मुख्य ध्येय आहे. आणि मला वाटते की आपण सर्व याकडे येऊ. आणि आम्ही ही गोष्ट प्रत्येकासाठी बनवतो. म्हणून ZFS, कारण ते सर्वत्र उपलब्ध असेल. समस्या सोडवल्याबद्दल आणि ओपन सोर्स परवाना इत्यादीसाठी समुदायाचे आभार*

शुभेच्छा! अहवालाबद्दल धन्यवाद! माझे नाव मॅक्सिम आहे. आम्ही समान समस्या हाताळल्या आहेत. त्यांनी स्वतःहून निर्णय घेतला. तुम्ही या क्लोनमध्ये संसाधने कशी सामायिक कराल? प्रत्येक क्लोन कोणत्याही वेळी स्वतःचे कार्य करू शकतो: कोणी एका गोष्टीची चाचणी घेतो, दुसरी दुसरी, कोणीतरी अनुक्रमणिका तयार करतो, कोणाला भारी काम असते. आणि जर तुम्ही अजूनही CPU ने भागू शकत असाल, तर IO द्वारे, तुम्ही कसे विभाजित कराल? हा पहिला प्रश्न आहे.

आणि दुसरा प्रश्न स्टँडच्या असमानतेबद्दल आहे. समजा माझ्याकडे येथे ZFS आहे आणि सर्व काही छान आहे, परंतु उत्पादनावरील क्लायंटमध्ये ZFS नाही, परंतु ext4, उदाहरणार्थ. या प्रकरणात कसे?

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

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

माझे दोन प्रश्न आहेत. ही खूप मस्त सामग्री आहे. अशी काही प्रकरणे आहेत जिथे उत्पादन डेटा गंभीर आहे, जसे की क्रेडिट कार्ड नंबर? आधीच काहीतरी तयार आहे किंवा ते स्वतंत्र कार्य आहे? आणि दुसरा प्रश्न - MySQL साठी असे काही आहे का?

डेटा बद्दल. आम्ही करत नाही तोपर्यंत आम्ही obfuscation करू. परंतु जर तुम्ही नेमका जो उपयोजित केला, जर तुम्ही विकसकांना प्रवेश दिला नाही, तर डेटामध्ये प्रवेश नाही. का? कारण जो डेटा दाखवत नाही. हे फक्त मेट्रिक्स, योजना दाखवते आणि तेच. हे हेतुपुरस्सर केले गेले, कारण ही आमच्या क्लायंटच्या गरजांपैकी एक आहे. त्यांना सर्वांना प्रवेश न देता ऑप्टिमाइझ करण्यात सक्षम व्हायचे होते.

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

परंतु प्रणाली विस्तारण्यायोग्य असल्याने, ती MySQL साठी देखील वापरली जाऊ शकते. आणि अशी उदाहरणे आहेत. यांडेक्समध्ये एक समान गोष्ट आहे, परंतु ते कोठेही प्रकाशित करत नाहीत. ते Yandex.Metrica मध्ये ते वापरतात. आणि MySQL बद्दल फक्त एक कथा आहे. पण तंत्रज्ञान समान आहेत, ZFS.

अहवालाबद्दल धन्यवाद! मलाही काही प्रश्न आहेत. तुम्ही नमूद केले आहे की क्लोनिंगचा वापर विश्लेषणासाठी केला जाऊ शकतो, उदाहरणार्थ तेथे अतिरिक्त निर्देशांक तयार करण्यासाठी. ते कसे कार्य करते याबद्दल थोडे अधिक सांगू शकाल का?

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

विश्लेषणानुसार, कोणतीही विशिष्ट प्रकरणे नाहीत, कारण आम्ही अद्याप ते वापरलेले नाही, परंतु अशी संधी आहे. जर आपण निर्देशांकांबद्दल बोलत आहोत, तर कल्पना करा की एक क्वेरी शेकडो लाखो रेकॉर्ड असलेल्या टेबलचा पाठलाग करत आहे आणि एक कॉलम जो सहसा उत्पादनामध्ये अनुक्रमित केला जात नाही. आणि आम्हाला तेथे काही डेटाची गणना करायची आहे. जर ही विनंती prod वर पाठवली गेली, तर ती prod वर सोपी असण्याची शक्यता आहे, कारण विनंतीवर एका मिनिटासाठी प्रक्रिया केली जाईल.

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

प्रत्येक वेळी निर्देशांक तयार होईल?

तुम्ही ते बनवू शकता जेणेकरून आम्ही डेटाला स्पर्श करू, स्नॅपशॉट बनवू, त्यानंतर आम्ही या स्नॅपशॉटमधून पुनर्प्राप्त करू आणि नवीन विनंत्या करू. म्हणजेच, आपण ते बनवू शकता जेणेकरून आपण आधीच चिकटलेल्या निर्देशांकांसह नवीन क्लोन वाढवू शकता.

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

येथे आणखी एक समस्या आहे. जर तुम्ही क्लाउड सोल्यूशन वापरत असाल, तर तिथे फक्त लॉजिकल डंप उपलब्ध आहेत, कारण Google, Amazon तुम्हाला फिजिकल कॉपी घेण्याची परवानगी देत ​​​​नाहीत. एक समस्या असेल.

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

माझा प्रश्न थोडा वेगळा आहे. हे बहु-स्तरित डेटाबेसच्या जवळ आहे, जेथे अनेक स्तर आहेत. उदाहरणार्थ, आम्ही दहा-टेराबाइट प्रतिमा अद्यतन सेट केले आहे, आम्ही प्रतिकृती करत आहोत. आणि आम्ही विशेषतः डेटाबेससाठी हे समाधान वापरतो. प्रतिकृती प्रगतीपथावर आहे, डेटा अद्यतनित केला जात आहे. येथे 100 कर्मचारी समांतर कार्यरत आहेत, जे सतत हे वेगवेगळे शॉट्स सुरू करत आहेत. काय करायचं? कोणताही संघर्ष नाही याची खात्री कशी करायची, त्यांनी एक लाँच केले आणि नंतर फाइल सिस्टम बदलली आणि ही सर्व चित्रे गेली?

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

असे दिसून आले की अद्यतन अतिरिक्त स्तर म्हणून होईल आणि या स्तरावर आधारित सर्व नवीन चित्रे आधीच जातील, बरोबर?

मागील प्रतिकृतींमधील मागील स्तरांवरून.

मागील स्तर पडतील, परंतु ते जुन्या लेयरचा संदर्भ घेतील आणि अपडेटमध्ये प्राप्त झालेल्या शेवटच्या लेयरमधून ते नवीन प्रतिमा घेतील का?

सर्वसाधारणपणे, होय.

मग परिणाम म्हणून आपल्याकडे अंजीर पर्यंत थर असतील. आणि कालांतराने ते संकुचित करणे आवश्यक आहे?

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

नमस्कार, अहवालाबद्दल धन्यवाद! जो बद्दल प्रश्न. तुम्ही म्हणालात की ग्राहक प्रत्येकाला डेटामध्ये प्रवेश देऊ इच्छित नाही. काटेकोरपणे सांगायचे तर, जर एखाद्या व्यक्तीला स्पष्टीकरण विश्लेषणाचा निकाल लागला तर तो डेटा पाहू शकतो.

असे आहे. उदाहरणार्थ, आम्ही असे लिहू शकतो: "सेलेक्ट फ्रॉम व्हेअर ईमेल = त्याकडे". म्हणजेच, आपल्याला डेटा स्वतः दिसणार नाही, परंतु आपण काही अप्रत्यक्ष चिन्हे पाहू शकतो. हे समजून घेतले पाहिजे. पण दुसरीकडे, हे सर्व तेथे आहे. आमच्याकडे लॉग ऑडिट आहे, आमच्याकडे इतर सहकाऱ्यांचे नियंत्रण आहे जे विकासक काय करत आहेत ते देखील पाहतात. आणि जर कोणी असे करण्याचा प्रयत्न केला तर सुरक्षा सेवा त्यांच्याकडे येईल आणि या समस्येवर काम करेल.

शुभ दुपार अहवालाबद्दल धन्यवाद! माझा एक छोटा प्रश्न आहे. जर कंपनी स्लॅक वापरत नसेल, तर त्यावर आता काही बंधनकारक आहे का, किंवा डेव्हलपरना डेटाबेसेसशी चाचणी ऍप्लिकेशन कनेक्ट करण्यासाठी उदाहरणे तैनात करणे शक्य आहे का?

आता स्लॅकची लिंक आहे, म्हणजे दुसरा कोणताही मेसेंजर नाही, पण मला इतर मेसेंजर्ससाठीही सपोर्ट करायचा आहे. तुम्ही काय करू शकता? तुम्ही Joe शिवाय DB Lab तैनात करू शकता, REST API च्या मदतीने किंवा आमच्या प्लॅटफॉर्मच्या मदतीने जाऊन क्लोन तयार करू शकता आणि PSQL शी कनेक्ट करू शकता. परंतु आपण आपल्या विकसकांना डेटामध्ये प्रवेश देण्यास तयार असल्यास हे केले जाऊ शकते, कारण यापुढे कोणतीही स्क्रीन नसेल.

मला या थराची गरज नाही, पण मला अशी संधी हवी आहे.

मग होय, ते केले जाऊ शकते.

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