DBA बोट जो। Anatoly Stansler (Postgres.ai)

एक ब्याकएन्ड विकासकर्ताले कसरी बुझ्छ कि SQL क्वेरी "prod" मा राम्रोसँग काम गर्नेछ? ठूला वा द्रुत रूपमा बढ्दो कम्पनीहरूमा, सबैलाई "उत्पादन" मा पहुँच छैन। र पहुँचको साथ, सबै अनुरोधहरू पीडारहित रूपमा जाँच गर्न सकिँदैन, र डाटाबेसको प्रतिलिपि बनाउन अक्सर घण्टा लाग्छ। यी समस्याहरू समाधान गर्न, हामीले एक कृत्रिम DBA - Joe सिर्जना गर्यौं। यो पहिले नै धेरै कम्पनीहरूमा सफलतापूर्वक लागू गरिएको छ र एक दर्जन भन्दा बढी विकासकर्ताहरूलाई मद्दत गर्दछ।

भिडियो:

नमस्ते सबै! मेरो नाम Anatoly Stansler हो। म एउटा कम्पनीमा काम गर्छु postgres.ai। हामी विकासकर्ताहरू, DBAs र QAs बाट Postgres को कामसँग सम्बन्धित ढिलाइहरू हटाएर विकास प्रक्रियालाई गति दिन प्रतिबद्ध छौं।

हामीसँग उत्कृष्ट ग्राहकहरू छन् र आज रिपोर्टको अंश हामीले उनीहरूसँग काम गर्दा भेटेका केसहरूमा समर्पित हुनेछ। हामीले उनीहरूलाई गम्भीर समस्याहरू समाधान गर्न कसरी मद्दत गर्‍यौं भन्ने बारेमा म कुरा गर्नेछु।

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

तर सायद यो राम्रो हुनेछ यदि हामीले यसलाई पूर्ण आकारको प्रतिलिपिहरूमा परीक्षण गर्न सक्छौं। र आज हामी केवल परीक्षणको लागि कुन दृष्टिकोणहरू छन् र यसलाई कसरी अझ राम्रो र कुन उपकरणहरूसँग गर्न सकिन्छ भनेर कुरा गर्नेछौं। हामी त्यस्ता दृष्टिकोणहरूको फाइदा र बेफाइदाको बारेमा पनि कुरा गर्नेछौं, र हामी यहाँ के ठीक गर्न सक्छौं।

कसले कहिल्यै उत्पादनमा सिधै अनुक्रमणिकाहरू बनाएको छ वा कुनै परिवर्तनहरू गरेको छ? अलि अलि। र कसको लागि यसले डाटा हराएको वा डाउनटाइम भएको तथ्यलाई नेतृत्व गर्‍यो? त्यसपछि यो पीडा थाहा छ। भगवानलाई धन्यवाद त्यहाँ ब्याकअपहरू छन्।

पहिलो दृष्टिकोण उत्पादन मा परीक्षण छ। वा, जब एक विकासकर्ता स्थानीय मेसिनमा बस्छ, उहाँसँग परीक्षण डेटा हुन्छ, त्यहाँ केहि प्रकारको सीमित चयन हुन्छ। र हामी उत्पादनमा रोल आउट गर्छौं, र हामीले यो अवस्था पाउँछौं।

दुख्छ, महँगो छ। यो सायद राम्रो छैन।

र यो गर्न सबै भन्दा राम्रो तरिका के हो?

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

यसले हामीलाई केही त्रुटिहरू हटाउन अनुमति दिनेछ, अर्थात् तिनीहरूलाई उत्पादनमा हुनबाट रोक्न।

समस्याहरु के के छन् ?

• समस्या यो हो कि हामीले यो स्टेजिङ सहकर्मीहरूसँग साझा गर्छौं। र धेरै पटक यो हुन्छ कि तपाइँ केहि प्रकारको परिवर्तन गर्नुहुन्छ, बाम - र त्यहाँ कुनै डाटा छैन, काम नाली तल छ। स्टेजिङ बहु-टेराबाइट थियो। र यो फेरि उठ्नको लागि तपाईले लामो समय पर्खनु पर्छ। अनि भोलि टुंग्याउने निर्णय गर्छौं। त्यो हो, हामीसँग विकास छ।
• र, अवश्य पनि, हामीसँग त्यहाँ काम गर्ने धेरै सहकर्मीहरू छन्, धेरै टोलीहरू। र यो म्यानुअल रूपमा गर्नुपर्छ। र यो असुविधाजनक छ।

र यो भन्न लायक छ कि हामीसँग केवल एक प्रयास छ, एक शट, यदि हामी डाटाबेसमा केहि परिवर्तन गर्न चाहन्छौं, डाटा छुनुहोस्, संरचना परिवर्तन गर्नुहोस्। र यदि केहि गलत भयो भने, माइग्रेसनमा त्रुटि भयो भने, हामी तुरुन्तै फिर्ता हुने छैनौं।

यो अघिल्लो दृष्टिकोण भन्दा राम्रो छ, तर त्यहाँ अझै पनि उच्च सम्भावना छ कि केहि प्रकारको त्रुटि उत्पादनमा जानेछ।

हामीलाई प्रत्येक विकासकर्तालाई परीक्षण बेन्च, पूर्ण आकारको प्रतिलिपि दिनबाट के रोक्छ? मलाई लाग्छ यो स्पष्ट छ कि बाटोमा के हुन्छ।

कोसँग टेराबाइट भन्दा ठूलो डाटाबेस छ? आधाभन्दा बढी कोठा।

र यो स्पष्ट छ कि प्रत्येक विकासकर्ताको लागि मेशिनहरू राख्न, जब त्यहाँ यति ठूलो उत्पादन छ, धेरै महँगो छ, र साथै, यो धेरै समय लाग्छ।

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

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

तर तिनीहरूले यो दृष्टिकोण प्रयोग गर्छन् किनभने यसले तिनीहरूलाई उत्पादन विश्वसनीय राख्न अनुमति दिन्छ।

हामी यहाँ के गर्न सक्छौं? परीक्षण बेन्चहरू सस्तो बनाउनुहोस् र प्रत्येक विकासकर्तालाई आफ्नै परीक्षण बेन्च दिनुहोस्।

र यो सम्भव छ।

र यस दृष्टिकोणमा, जब हामी प्रत्येक विकासकर्ताको लागि पातलो क्लोनहरू बनाउँछौं, हामी यसलाई एउटा मेसिनमा साझेदारी गर्न सक्छौं। उदाहरणका लागि, यदि तपाईंसँग 10TB डाटाबेस छ र 10 विकासकर्ताहरूलाई दिन चाहनुहुन्छ भने, तपाईंसँग XNUMX x XNUMXTB डाटाबेसहरू हुनु आवश्यक छैन। तपाइँलाई एउटा मेसिन प्रयोग गरी प्रत्येक विकासकर्ताको लागि पातलो पृथक प्रतिलिपिहरू बनाउनको लागि केवल एउटा मेसिन चाहिन्छ। म तपाइँलाई यो कसरी काम गर्दछ केहि समय पछि बताउनेछु।

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

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

• हामी 30 सेकेन्डमा स्वतन्त्र प्रतिलिपिहरू प्राप्त गर्न सक्छौं।

तपाईंले परीक्षण स्ट्यान्डको लागि पर्खनु पर्दैन र यो कति ठूलो छ भन्नेमा भर पर्छ। तपाईं यसलाई सेकेन्डमा प्राप्त गर्न सक्नुहुन्छ। यो पूर्णतया पृथक वातावरण हुनेछ, तर जो आपसमा डाटा साझा गर्दछ।

धेरै राम्रो। यहाँ हामी जादू र एक समानान्तर ब्रह्माण्ड बारेमा कुरा गर्दै छन्।

हाम्रो अवस्थामा, यो OpenZFS प्रणाली प्रयोग गरेर काम गर्दछ।

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

त्यहाँ अन्य विकल्पहरू छन्:

• lvm,

• भण्डारण (उदाहरणका लागि, शुद्ध भण्डारण)।

मैले कुरा गरिरहेको डाटाबेस ल्याब मोड्युलर हो। यी विकल्पहरू प्रयोग गरेर लागू गर्न सकिन्छ। तर अहिलेको लागि, हामीले OpenZFS मा ध्यान केन्द्रित गरेका छौं, किनकि LVM सँग विशेष समस्याहरू थिए।

यसले कसरी काम गर्छ? प्रत्येक पटक डाटालाई हामीले परिवर्तन गर्दा ओभरराइट गर्नुको सट्टा, हामी यो नयाँ डाटा समयको नयाँ बिन्दुबाट, नयाँ स्न्यापसट हो भनेर चिन्ह लगाएर बचत गर्छौं।

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

र यो प्रयोगकर्ता यस्तो डाटा सेट संग काम गर्नेछ। उसले बिस्तारै तिनीहरूलाई परिवर्तन गर्नेछ, आफ्नै स्न्यापसटहरू बनाउँछ।

र हामी शाखा गर्नेछौं। हाम्रो मामलामा प्रत्येक विकासकर्तासँग उसले सम्पादन गर्ने आफ्नै क्लोन पाउने अवसर हुनेछ, र साझा गरिएको डाटा सबैको बीचमा साझा गरिनेछ।

घरमा यस्तो प्रणाली लागू गर्न, तपाईंले दुई समस्याहरू समाधान गर्न आवश्यक छ:

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

• दोस्रो हो जहाँ तपाइँ डाटाबेस ल्याब होस्ट गर्न चाहानुहुन्छ। यो क्लाउड हुन सक्छ, यो अन-प्रिमाइस हुन सक्छ। यो यहाँ भन्न महत्त्वपूर्ण छ कि ZFS डाटा कम्प्रेसन समर्थन गर्दछ। र यो एकदम राम्रो गर्छ।

कल्पना गर्नुहोस् कि प्रत्येक त्यस्ता क्लोनको लागि, हामीले आधारसँग गर्ने कार्यहरूमा निर्भर गर्दै, कुनै प्रकारको dev बढ्नेछ। यसका लागि देवलाई पनि ठाउँ चाहिन्छ। तर हामीले 4,5 टेराबाइटको आधार लिएको कारणले, ZFS ले यसलाई 3,5 टेराबाइटमा कम्प्रेस गर्नेछ। यो सेटिङहरूको आधारमा फरक हुन सक्छ। र हामीसँग अझै पनि देवको लागि ठाउँ छ।

यस्तो प्रणाली विभिन्न अवस्थामा प्रयोग गर्न सकिन्छ।

• यी विकासकर्ताहरू हुन्, क्वेरी प्रमाणीकरणका लागि DBAs, अनुकूलनका लागि।

• यसलाई हामीले उत्पादनमा रोल आउट गर्नु अघि कुनै विशेष माइग्रेसन परीक्षण गर्न QA परीक्षणमा प्रयोग गर्न सकिन्छ। र हामी वास्तविक डेटाको साथ QA को लागि विशेष वातावरणहरू पनि उठाउन सक्छौं, जहाँ तिनीहरूले नयाँ कार्यक्षमता परीक्षण गर्न सक्छन्। र यसले पर्खाइको घन्टाको सट्टा सेकेन्ड लिन सक्छ, र केहि अन्य अवस्थामा जहाँ पातलो प्रतिलिपिहरू प्रयोग नगरिएको हुन सक्छ।

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

यो दृष्टिकोण संग:

1. "उत्पादन" मा त्रुटिहरूको कम सम्भावना, किनभने हामीले पूर्ण-आकार डेटामा सबै परिवर्तनहरू परीक्षण गर्यौं।

2. हामीसँग परीक्षण गर्ने संस्कृति छ, किनकि अब तपाईले आफ्नो स्ट्यान्डको लागि घण्टा कुर्नु पर्दैन।

3. र त्यहाँ कुनै अवरोध छैन, परीक्षणहरू बीच कुनै पर्खाइ छैन। तपाईं वास्तवमा गएर जाँच गर्न सक्नुहुन्छ। र यो यस तरिकाले राम्रो हुनेछ जब हामी विकासको गति बढाउँछौं।

• त्यहाँ कम रिफ्याक्टरिंग हुनेछ। थोरै बगहरू उत्पादनमा समाप्त हुनेछन्। हामी तिनीहरूलाई पछि कम रिफ्याक्टर गर्नेछौं।

• हामी अपरिवर्तनीय परिवर्तनहरू उल्टाउन सक्छौं। यो मानक दृष्टिकोण होइन।

1. यो फाइदाजनक छ किनभने हामी परीक्षण बेन्चहरूको स्रोत साझा गर्छौं।

पहिले नै राम्रो छ, तर अरू के छिटो हुन सक्छ?

यस्तो प्रणालीको लागि धन्यवाद, हामी यस्तो परीक्षणमा प्रवेश गर्नको लागि थ्रेसहोल्डलाई धेरै कम गर्न सक्छौं।

अब त्यहाँ एक दुष्ट सर्कल छ, जब एक विकासकर्ता, वास्तविक पूर्ण-आकारको डेटामा पहुँच प्राप्त गर्न, एक विशेषज्ञ बन्नु पर्छ। उसलाई यस्तो पहुँचको साथ विश्वास गर्नुपर्छ।

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

यो घेराबाट कसरी बाहिर निस्कने ? पहिलो इन्टरफेसको रूपमा, कुनै पनि स्तरका विकासकर्ताहरूको लागि सुविधाजनक, हामीले Slack bot रोज्यौं। तर यो कुनै पनि अन्य इन्टरफेस हुन सक्छ।

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

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

तर त्यहाँ, अवश्य पनि, समस्याहरू छन्। किनभने यो वास्तविक संसार हो, र हामी एकै पटक धेरै क्लोनहरू होस्ट गर्ने सर्भर प्रयोग गर्दैछौं, हामीले क्लोनहरूमा उपलब्ध मेमोरी र CPU पावरको मात्रा कम्प्रेस गर्नुपर्छ।

तर यी परीक्षणहरू प्रशंसनीय हुनको लागि, तपाईंले कुनै न कुनै रूपमा यो समस्या समाधान गर्न आवश्यक छ।

यो स्पष्ट छ कि महत्त्वपूर्ण बिन्दु एउटै डाटा हो। तर हामीसँग पहिले नै छ। र हामी समान कन्फिगरेसन प्राप्त गर्न चाहन्छौं। र हामी यस्तो लगभग समान कन्फिगरेसन दिन सक्छौं।

उत्पादनमा जस्तै समान हार्डवेयर हुनु राम्रो हुनेछ, तर यो फरक हुन सक्छ।

याद गरौं कसरी Postgres मेमोरी संग काम गर्दछ। हामीसँग दुईवटा क्याचहरू छन्। एउटा फाइल प्रणालीबाट र एउटा नेटिभ पोस्टग्रेस, अर्थात् साझा बफर क्यास।

तपाईंले कन्फिगरेसनमा निर्दिष्ट गर्नुभएको साइजको आधारमा पोस्टग्रेस सुरु हुँदा साझा बफर क्यास आवंटित हुन्छ भन्ने कुरा नोट गर्न महत्त्वपूर्ण छ।

र दोस्रो क्यास सबै उपलब्ध ठाउँ प्रयोग गर्दछ।

र जब हामी एक मेसिनमा धेरै क्लोनहरू बनाउँछौं, यो बाहिर जान्छ कि हामी बिस्तारै मेमोरी भर्छौं। र राम्रो तरिकाले, साझा बफर क्यास मेसिनमा उपलब्ध मेमोरीको कुल रकमको 25% हो।

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

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

उदाहरणका लागि, यदि हामीसँग उत्पादनमा ठूलो क्यास छ भने, पोस्टग्रेसले अनुक्रमणिका प्रयोग गर्न रुचाउनेछ। र यदि होइन भने, त्यहाँ SeqScan हुनेछ। र यदि हाम्रो योजनाहरू मिलेन भने के बिन्दु हुनेछ?

तर यहाँ हामी निष्कर्षमा पुग्छौं कि वास्तवमा Postgres मा योजना योजना मा साझा बफर मा निर्दिष्ट निर्दिष्ट आकार मा निर्भर गर्दैन, यो प्रभावकारी_cache_size मा निर्भर गर्दछ।

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

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

तर यसले समयलाई असर गर्न सक्छ। र हामी समय अनुसार प्रश्नहरू अनुकूलन गर्छौं, तर यो महत्त्वपूर्ण छ कि समय धेरै कारकहरूमा निर्भर गर्दछ:

• यो हाल उत्पादनमा रहेको लोडमा निर्भर गर्दछ।

• यो मेशिन को विशेषताहरु मा निर्भर गर्दछ।

र यो एक अप्रत्यक्ष प्यारामिटर हो, तर वास्तवमा हामी परिणाम प्राप्त गर्नको लागि यो क्वेरीले पढ्ने डाटाको मात्रा द्वारा ठ्याक्कै अनुकूलन गर्न सक्छौं।

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

जो विशेष रूपमा अप्टिमाइज गरिएको छ भनेर हेरौं।

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

हामी च्यानललाई सन्देश लेख्दै छौं, हाम्रो लागि क्लोन तैनाथ गरिएको छ। र हामी देख्नेछौं कि यस्तो अनुरोध 2,5 मिनेटमा पूरा हुनेछ। यो हामीले याद गरेको पहिलो कुरा हो।

B Joe ले तपाईंलाई योजना र मेट्रिक्समा आधारित स्वचालित सिफारिसहरू देखाउनेछ।

हामी हेर्नेछौं कि क्वेरीले अपेक्षाकृत सानो संख्यामा पङ्क्तिहरू प्राप्त गर्न धेरै डाटा प्रक्रिया गर्दछ। र केहि प्रकारको विशेष अनुक्रमणिका आवश्यक छ, किनकि हामीले देख्यौं कि क्वेरीमा धेरै फिल्टर गरिएका पङ्क्तिहरू छन्।

के भयो त्यसलाई नजिकबाट हेरौं। वास्तवमा, हामीले देख्यौं कि हामीले फाइल क्यास वा डिस्कबाट पनि लगभग डेढ गीगाबाइट डाटा पढेका छौं। र यो राम्रो छैन, किनकि हामीले केवल 142 लाइनहरू पाएका छौं।

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

र यो योजनामा ​​भएको तथ्यको कारणले गर्दा क्वेरीमा सर्तहरू र सूचकांकमा रहेका सर्तहरू आंशिक रूपमा मेल खाँदैन।

अनुक्रमणिकालाई अझ सटीक बनाउने प्रयास गरौं र त्यस पछि क्वेरी कार्यान्वयन कसरी परिवर्तन हुन्छ हेर्नुहोस्।

अनुक्रमणिकाको निर्माणले धेरै समय लियो, तर अब हामी क्वेरी जाँच गर्छौं र देख्छौं कि 2,5 मिनेटको सट्टा समय मात्र 156 मिलिसेकेन्ड हो, जुन पर्याप्त छ। र हामी केवल 6 मेगाबाइट डाटा पढ्छौं।

र अब हामी अनुक्रमणिका स्क्यान मात्र प्रयोग गर्दछौं।

अर्को महत्त्वपूर्ण कथा यो हो कि हामी योजनालाई अझ बुझ्ने तरिकामा प्रस्तुत गर्न चाहन्छौं। हामीले फ्लेम ग्राफहरू प्रयोग गरेर भिजुअलाइजेशन लागू गरेका छौं।

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

यहाँ हामी एक अर्कासँग विशिष्ट नोडहरू तुलना गर्न सक्छौं। र यो स्पष्ट हुनेछ कि ती मध्ये कुनले बढी वा कम लिन्छ, जुन सामान्यतया अन्य रेन्डरिङ विधिहरूमा गर्न गाह्रो हुन्छ।

अवश्य पनि, सबैलाई थाहा छ explain.depesz.com। यस भिजुअलाइजेशनको राम्रो विशेषता यो हो कि हामीले पाठ योजना बचत गर्छौं र केहि आधारभूत प्यारामिटरहरूलाई तालिकामा राख्छौं ताकि हामी क्रमबद्ध गर्न सकौं।

र विकासकर्ताहरू जसले यस विषयमा अहिलेसम्म जान सकेका छैनन् उनीहरूले पनि explain.depesz.com को प्रयोग गर्छन्, किनभने कुन मेट्रिक्स महत्त्वपूर्ण छन् र कुन होइनन् भनेर पत्ता लगाउन उनीहरूलाई सजिलो हुन्छ।

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

सहयोग

र, मैले भनेझैं, स्ल्याकले हामीलाई सहयोग गर्ने अवसर दिन्छ। उदाहरणका लागि, यदि हामीले अप्टिमाइज कसरी गर्ने भन्ने स्पष्ट नभएको जटिल प्रश्न भेट्टायौं भने, हामी हाम्रा सहकर्मीहरूसँग Slack मा रहेको थ्रेडमा यस मुद्दालाई स्पष्ट गर्न सक्छौं।

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

यो नोट गर्न पनि महत्त्वपूर्ण छ कि समाधान आफैंमा क्रान्तिकारी छैन, किनकि त्यहाँ डेल्फिक्स छ, तर यो एक उद्यम समाधान हो। यो पूर्ण रूपमा बन्द छ, यो धेरै महँगो छ। हामी विशेष गरी Postgres मा विशेषज्ञ छौं। यी सबै खुला स्रोत उत्पादनहरू हुन्। हामीसँग सामेल हुनुहोस्!

म यहीँ अन्त्य गर्छु। धन्यवाद!

तपाईंका प्रश्नहरू

नमस्ते! रिपोर्ट को लागी धन्यवाद! धेरै चाखलाग्दो, विशेष गरी मेरो लागि, किनकि मैले केहि समय अघि उही समस्याको बारेमा समाधान गरें। र त्यसैले मसँग धेरै प्रश्नहरू छन्। आशा छ कि म यसको कम्तिमा अंश प्राप्त गर्नेछु।

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

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

हो, मसँग एउटा नेस्टेड प्रश्न छ। त्यो हो, तपाइँ यी मोड्युलहरूको जीवन चक्र कसरी सुनिश्चित गर्नुहुन्छ? हामीसँग यो समस्या र पूरै छुट्टै कथा छ। यो कसरी हुन्छ?

प्रत्येक क्लोनको लागि केही ttl छ। सामान्यतया, हामीसँग निश्चित ttl छ।

के, गोप्य छैन भने?

1 घण्टा, अर्थात् निष्क्रिय - 1 घण्टा। यदि यो प्रयोग गरिएन भने, हामी यसलाई पिट्छौं। तर यहाँ कुनै आश्चर्य छैन, किनकि हामी सेकेन्डमा क्लोन उठाउन सक्छौं। र यदि तपाईंलाई यो फेरि आवश्यक छ भने, कृपया।

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

ZFS को मुख्य समस्या के हो? तथ्य यो हो कि तपाईंले एउटै होस्टमा चल्नु पर्छ, अर्थात् सबै उदाहरणहरू एउटै OS भित्र रहनेछन्। र भण्डारण को मामला मा, तपाईं विभिन्न उपकरण जडान गर्न सक्नुहुन्छ। र अवरोध केवल ती ब्लकहरू हुन् जुन भण्डारण प्रणालीमा छन्। र प्रविधिहरूको छनोटको प्रश्न रोचक छ। किन LVM छैन?

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

निकोलाई Samokhvalov: म थप टिप्पणी गर्न सक्छु? मेरो नाम निकोले हो, हामी अनातोली संग सँगै काम गर्छौं। म सहमत छु कि भण्डारण उत्कृष्ट छ। र हाम्रा केही ग्राहकहरूसँग शुद्ध भण्डारण आदि छ।

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

तर ZFS सबैका लागि उपलब्ध छ। DelPhix पहिले नै पर्याप्त छ, तिनीहरूसँग 300 ग्राहकहरू छन्। यी मध्ये, fortune 100 का 50 ग्राहकहरू छन्, अर्थात् तिनीहरू NASA, आदिमा लक्षित छन्। यो प्रविधि सबैले प्राप्त गर्ने समय हो। र यसैले हामीसँग खुला स्रोत कोर छ। हामीसँग एक इन्टरफेस भाग छ जुन खुला स्रोत होइन। यो हामी देखाउने प्लेटफर्म हो। तर हामी यसलाई सबैको पहुँचमा राख्न चाहन्छौं। हामी एक क्रान्ति गर्न चाहन्छौं ताकि सबै परीक्षकहरूले ल्यापटपमा अनुमान गर्न बन्द गर्नुहोस्। हामीले SELECT लेख्नुपर्छ र तुरुन्तै यो ढिलो भएको देख्नुपर्छ। यसको बारेमा तपाइँलाई बताउनको लागि DBA को लागि पर्खनुहोस्। यहाँ मुख्य लक्ष्य छ। र मलाई लाग्छ कि हामी सबै यसमा आउनेछौं। र हामी सबैको लागि यो चीज बनाउँछौं। त्यसैले ZFS, किनकि यो सबै ठाउँमा उपलब्ध हुनेछ। समस्याहरू समाधान गर्न र खुला स्रोत इजाजतपत्र भएकोमा समुदायलाई धन्यवाद।*

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

र दोस्रो प्रश्न स्ट्यान्डको असमानताको बारेमा हो। मानौं मसँग यहाँ ZFS छ र सबै कुरा राम्रो छ, तर उत्पादनमा ग्राहकसँग ZFS छैन, तर ext4, उदाहरणका लागि। यस मामला मा कसरी?

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

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

मसँग दुईवटा प्रश्न छन्। यो धेरै राम्रो सामान हो। के त्यहाँ उत्पादन डाटा महत्वपूर्ण छ, जस्तै क्रेडिट कार्ड नम्बरहरू छन्? त्यहाँ पहिले नै केहि तयार छ वा यो एक अलग कार्य हो? र दोस्रो प्रश्न - MySQL को लागी यस्तो केहि छ?

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

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

तर प्रणाली एक्स्टेन्सिबल भएकोले, यो MySQL को लागि पनि प्रयोग गर्न सकिन्छ। र त्यस्ता उदाहरणहरू छन्। Yandex सँग समान कुरा छ, तर तिनीहरूले यसलाई कहीं पनि प्रकाशित गर्दैनन्। तिनीहरूले यसलाई Yandex.Metrica भित्र प्रयोग गर्छन्। र MySQL को बारेमा मात्र एउटा कथा छ। तर प्रविधिहरू समान छन्, ZFS।

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

र म तुरुन्तै स्ट्यान्डहरूको समानता, योजनाहरूको समानताको बारेमा दोस्रो प्रश्न सोध्नेछु। योजना पनि Postgres द्वारा सङ्कलन तथ्याङ्क मा निर्भर गर्दछ। तपाईं यो समस्या कसरी समाधान गर्नुहुन्छ?

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

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

प्रत्येक पटक सूचकांक सिर्जना हुनेछ?

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

तथ्याङ्कको बारेमा प्रश्नको रूपमा, यदि हामीले ब्याकअपबाट पुनर्स्थापना गर्छौं, यदि हामीले प्रतिकृति गर्छौं भने, हाम्रो तथ्याङ्कहरू ठ्याक्कै उस्तै हुनेछन्। किनभने हामीसँग सम्पूर्ण भौतिक डेटा संरचना छ, अर्थात्, हामी सबै तथ्याङ्क मेट्रिक्सको साथमा जस्तै डाटा ल्याउनेछौं।

यहाँ अर्को समस्या छ। यदि तपाइँ क्लाउड समाधान प्रयोग गर्नुहुन्छ भने, त्यहाँ केवल तार्किक डम्पहरू उपलब्ध छन्, किनभने Google, Amazon ले तपाईंलाई भौतिक प्रतिलिपि लिन अनुमति दिँदैन। समस्या हुनेछ।

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

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

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

यो जान्छ कि अपडेट एक अतिरिक्त तहको रूपमा लिइनेछ, र सबै नयाँ तस्विरहरू पहिले नै जानेछन्, यो तहको आधारमा, सही?

अघिल्लो तहहरूबाट जुन अघिल्लो प्रतिकृतिहरूबाट थिए।

अघिल्लो तहहरू झर्नेछन्, तर तिनीहरूले पुरानो तहलाई सन्दर्भ गर्नेछन्, र तिनीहरूले अद्यावधिकमा प्राप्त भएको अन्तिम तहबाट नयाँ छविहरू लिनेछन्?

सामान्य मा, हो।

त्यसपछि नतिजाको रूपमा हामीसँग तहहरूको फिग सम्म हुनेछ। र समय संग तिनीहरू संकुचित गर्न आवश्यक हुनेछ?

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

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

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

शुभ दिउँसो रिपोर्ट को लागी धन्यवाद! मसँग छोटो प्रश्न छ। यदि कम्पनीले स्ल्याक प्रयोग गर्दैन भने, के यसमा अब कुनै बाध्यकारी छ, वा विकासकर्ताहरूले डाटाबेसमा परीक्षण अनुप्रयोग जडान गर्न उदाहरणहरू प्रयोग गर्न सम्भव छ?

अब त्यहाँ स्ल्याकको लिङ्क छ, अर्थात् त्यहाँ कुनै अन्य मेसेन्जर छैन, तर म वास्तवमै अन्य मेसेन्जरहरूको लागि पनि समर्थन गर्न चाहन्छु। तिमी के गर्न सक्छाै? तपाईं जो बिना DB ल्याब प्रयोग गर्न सक्नुहुन्छ, REST API को मद्दतमा वा हाम्रो प्लेटफर्मको मद्दतमा जानुहोस् र क्लोनहरू सिर्जना गर्नुहोस् र PSQL सँग जडान गर्नुहोस्। तर यो गर्न सकिन्छ यदि तपाईं आफ्नो विकासकर्ताहरूलाई डाटामा पहुँच दिन तयार हुनुहुन्छ भने, किनकि त्यहाँ अब कुनै स्क्रिन हुनेछैन।

मलाई यो तह चाहिँदैन, तर मलाई यस्तो अवसर चाहिन्छ।

त्यसपछि हो, यो गर्न सकिन्छ।

स्रोत: www.habr.com