डीबीएमएस का स्वायत्त भविष्य

आपको क्या लगता है कि बेहतर होगा कि आप PostgreSQL - DBA या ML एल्गोरिथ्म को कॉन्फ़िगर करें? और अगर दूसरा है, तो क्या यह सोचने का समय है कि जब कारें हमें बदल देती हैं तो क्या करना है। या यह उस पर नहीं आया, और महत्वपूर्ण निर्णय अभी भी लोगों द्वारा किए जाने चाहिए। संभवतः, लेन-देन स्थिरता के लिए अलगाव और आवश्यकताओं का स्तर प्रशासक के पास रहना चाहिए। लेकिन अनुक्रमित जल्द ही मशीन को स्वयं निर्धारित करने के लिए भरोसा किया जा सकता है।



हाईलीड ++ पर एंडी पावलो ने भविष्य के डीबीएमएस के बारे में बात की, जिसे आप अभी "स्पर्श" कर सकते हैं। यदि आप इस भाषण से चूक गए हैं या रूसी में जानकारी प्राप्त करना पसंद करते हैं - कट के तहत भाषण का अनुवाद है।

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



वक्ता के बारे में: एंडी पावलो कार्नेगी मेलन विश्वविद्यालय में एक एसोसिएट प्रोफेसर हैं, उनके नेतृत्व में एक "स्व-प्रबंधित" DBMS पेलोटनबीडी , साथ ही ओटरट्यून बनाता है , जो मशीन लर्निंग का उपयोग करके PostgreSQL और MySQL कॉन्फ़िगर करने में मदद करता है। एंडी और उनकी टीम अब स्व-प्रबंध डेटाबेस में सच्चे नेता हैं।

हम स्वायत्त डीबीएमएस बनाना चाहते हैं इसका कारण स्पष्ट है। इन DBMS टूल को प्रबंधित करना एक बहुत महंगी और समय लेने वाली प्रक्रिया है। संयुक्त राज्य अमेरिका में औसत DBA का वेतन लगभग 89 हजार डॉलर प्रति वर्ष है। रूबल में अनुवादित, एक वर्ष में 5.9 मिलियन रूबल प्राप्त होते हैं। यह वास्तव में बड़ी राशि है जो आप लोगों को भुगतान करते हैं ताकि आप अपने सॉफ़्टवेयर पर नज़र रख सकें। डेटाबेस का उपयोग करने की कुल लागत का लगभग 50% ऐसे प्रशासकों और संबंधित कर्मचारियों के काम के लिए भुगतान किया जाता है।

जब यह वास्तव में बड़ी परियोजनाओं की बात आती है, जैसे कि हम हाईलाड ++ पर चर्चा करते हैं और जो हजारों डेटाबेस का उपयोग करते हैं, तो उनकी संरचना की जटिलता मानवीय धारणा से परे है। हर कोई इस समस्या को सतही रूप से देखता है और सिस्टम को ट्यून करने में न्यूनतम प्रयास करके अधिकतम प्रदर्शन प्राप्त करने की कोशिश करता है।

यदि आप अधिकतम प्रदर्शन सुनिश्चित करने के लिए एप्लिकेशन और पर्यावरण स्तर पर DBMS को कॉन्फ़िगर करते हैं तो आप एक गोल राशि बचा सकते हैं।

स्व-अनुकूली डेटाबेस, 1970-1990

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

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

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



DBA को पता होना चाहिए कि उपयोगकर्ता गतिविधि में गिरावट होने पर एप्लिकेशन का उपयोग कैसे किया जाता है। उदाहरण के लिए, रविवार को अपराह्न 3:00 बजे डेटाबेस के प्रश्नों का निम्नतम स्तर है, इसलिए इस समय आप अनुक्रमित को पुनः लोड कर सकते हैं।

जैसा कि मैंने कहा, उस समय के सभी डिज़ाइन टूल ने एक ही तरह से काम किया है - यह एक बहुत पुरानी समस्या है । मेरे वैज्ञानिक पर्यवेक्षक के वैज्ञानिक पर्यवेक्षक ने 1976 में स्वचालित सूचकांक चयन के बारे में एक लेख लिखा था।

स्व-ट्यूनिंग डेटाबेस, 1990-2000

1990 के दशक में, लोगों ने, वास्तव में, एक ही समस्या पर काम किया, केवल नाम अनुकूली से स्व-ट्यूनिंग डेटाबेस में बदल गया।

एल्गोरिदम थोड़ा बेहतर हो गया, उपकरण थोड़ा बेहतर हो गए, लेकिन उच्च स्तर पर उन्होंने पहले की तरह ही काम किया। स्व-ट्यूनिंग सिस्टम के आंदोलन में सबसे आगे एकमात्र कंपनी माइक्रोसॉफ्ट रिसर्च थी जो अपने स्वचालित प्रशासन प्रोजेक्ट के साथ थी। उन्होंने वास्तव में अद्भुत समाधान विकसित किए, और 90 के दशक के उत्तरार्ध में और 00 के शुरुआती दिनों में उन्होंने फिर से अपने डेटाबेस की स्थापना के लिए सिफारिशों का एक सेट प्रस्तुत किया।

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



2007 में, माइक्रोसॉफ्ट रिसर्च ने एक लेख प्रकाशित किया, जिसमें दस साल से अधिक के शोध का पूर्वव्यापी निर्धारण किया गया था। और यह सभी जटिल कार्यों को अच्छी तरह से कवर करता है जो पथ के हर खंड पर उत्पन्न हुए।

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

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

पिछले 15 वर्षों में, PostgreSQL में नियामकों की संख्या 5 गुना बढ़ गई है, और MySQL के लिए - 7 गुना।

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

क्लाउड डीबी, 2010–…

इसके अलावा हम खुद को 2010 के युग में पाते हैं, जिसमें हम आज तक हैं। मैं इसे क्लाउड डेटाबेस का युग कहता हूं। इस समय के दौरान, क्लाउड में बड़ी संख्या में डेटाबेस की तैनाती को स्वचालित करने के लिए बहुत काम किया गया है।

मुख्य क्लाउड प्रदाताओं को चिंता करने वाली मुख्य बात यह है कि एक किरायेदार की मेजबानी कैसे करें या एक से दूसरे में माइग्रेट करें। यह निर्धारित करने के लिए कि प्रत्येक किरायेदार को कितने संसाधनों की आवश्यकता होगी, और फिर उन्हें मशीनों के बीच वितरित करने की कोशिश करें ताकि कम से कम उत्पादकता या SLAs को न्यूनतम लागत से अधिकतम किया जा सके।

अमेज़ॅन, माइक्रोसॉफ्ट और Google इस समस्या को हल करते हैं, लेकिन मुख्य रूप से परिचालन स्तर पर। केवल हाल ही में, क्लाउड सेवा प्रदाताओं ने व्यक्तिगत डेटाबेस सिस्टम को कॉन्फ़िगर करने की आवश्यकता के बारे में सोचना शुरू किया। यह काम आम उपयोगकर्ताओं को दिखाई नहीं देता है, लेकिन यह कंपनी के उच्च स्तर को निर्धारित करता है।

स्वायत्त और गैर-स्वायत्त प्रणालियों के साथ डेटाबेस के 40 साल के शोध को सारांशित करते हुए, हम यह निष्कर्ष निकाल सकते हैं कि यह काम अभी भी पर्याप्त नहीं है।

आज हमारे पास स्वशासन की वास्तव में स्वायत्त प्रणाली क्यों नहीं हो सकती है? इसके तीन कारण हैं।



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

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

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

मुझे यकीन है कि यह बदलाव का समय क्यों है? इस सवाल का जवाब उसी के बारे में है कि डेटा या मशीन लर्निंग के सुपर-एरे लोकप्रिय क्यों हो गए हैं। उपकरण बेहतर गुणवत्ता वाले होते जा रहे हैं: उत्पादन संसाधन बढ़ रहे हैं, भंडारण क्षमता बढ़ रही है, हार्डवेयर क्षमता बढ़ रही है, जो सीखने की मशीन सीखने के मॉडल के लिए गणना में तेजी लाती है।

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

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

मैं उन परियोजनाओं के बारे में बात करना चाहता हूं जो हम वर्तमान में कार्नेगी मेलन विश्वविद्यालय में काम कर रहे हैं। उनमें, हम समस्या को दो अलग-अलग तरीकों से देखते हैं।

पहले में - ओटेरट्यून - हम डेटाबेस को ट्यून करने के तरीकों की तलाश करते हैं, उन्हें काले बक्से के रूप में मानते हैं। यही है, सिस्टम के आंतरिक भाग को नियंत्रित किए बिना और केवल प्रतिक्रिया को देखते हुए मौजूदा DBMS को ट्यून करने के तरीके।

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

आइए दोनों परियोजनाओं पर विचार करें।

OtterTune

मौजूदा सिस्टम समायोजन परियोजना जिसे हमने विकसित किया है, उसे ओटरट्यून कहा जाता है।

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



ओटेरट्यून परियोजना में मुख्य बात यह है कि पिछले ट्यूनिंग सत्रों से डेटा का उपयोग करने और बाद के सत्रों की दक्षता बढ़ाने की क्षमता है। उदाहरण के लिए, PostgreSQL कॉन्फ़िगरेशन लें, जिसमें एक एप्लिकेशन है जिसे हमने पहले कभी नहीं देखा है। लेकिन अगर इसकी कुछ विशेषताएं हैं या डेटाबेस को उसी तरह उपयोग करता है जैसे कि डेटाबेस जो हमने पहले ही अपने अनुप्रयोगों में देखा है, तो हम पहले से ही जानते हैं कि इस एप्लिकेशन को और अधिक कुशलता से कैसे कॉन्फ़िगर किया जाए।

उच्च स्तर पर, काम का एल्गोरिथ्म इस प्रकार है।

मान लीजिए कि एक लक्ष्य डेटाबेस है: PostgreSQL, MySQL या वेक्टर वाइज। आपको उसी डोमेन में नियंत्रक को स्थापित करना होगा, जो दो कार्य करेगा।



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

सिफारिशें देने से पहले, आपको दो चरण करने होंगे। सबसे पहले, आपको रनटाइम मेट्रिक्स को देखना होगा और यह पता लगाना होगा कि वास्तव में कौन से महत्वपूर्ण हैं। निम्न उदाहरण MySQL द्वारा लौटाए गए मैट्रिक्स को दर्शाता है लेकिन InnoDB पर SHOW_GLOBAL_STATUS । उनमें से सभी हमारे विश्लेषण के लिए उपयोगी नहीं हैं। यह ज्ञात है कि मशीन सीखने में बड़ी मात्रा में डेटा हमेशा अच्छा नहीं होता है। क्योंकि तब अनाज को चफ से अलग करने के लिए और भी अधिक डेटा की आवश्यकता होती है। जैसा कि इस मामले में, उन संस्थाओं से छुटकारा पाना महत्वपूर्ण है जो वास्तव में मायने नहीं रखते हैं ।



उदाहरण के लिए, दो मैट्रिक्स हैं: INNODB_BUFFER_POOL_BYTES_DATA और INNODB_BUFFER_POOL_PAGES_DATA । वास्तव में, यह एक ही मीट्रिक है, लेकिन विभिन्न इकाइयों में। आप एक सांख्यिकीय विश्लेषण कर सकते हैं, यह देख सकते हैं कि मैट्रिक्स अत्यधिक सहसंबद्ध हैं, और निष्कर्ष निकालते हैं कि दोनों का उपयोग विश्लेषण के लिए अनावश्यक है। यदि आप उनमें से एक को त्याग देते हैं, तो सीखने के कार्य का आयाम कम हो जाएगा और उत्तर प्राप्त करने का समय कम हो जाएगा।

दूसरे चरण में, हम ऐसा ही करते हैं, केवल नियामकों के संबंध में। MySQL में 500 नियामक हैं , और निश्चित रूप से, उनमें से सभी वास्तव में महत्वपूर्ण नहीं हैं, लेकिन विभिन्न अनुप्रयोगों के लिए अलग-अलग अनुप्रयोग महत्वपूर्ण हैं। यह पता लगाने के लिए एक और सांख्यिकीय विश्लेषण करना आवश्यक है कि कौन से नियामक वास्तव में लक्ष्य समारोह को प्रभावित करते हैं।



हमारे उदाहरण में, हमने पाया कि तीन INNODB_BUFFER_POOL_SIZE , FLUSH_METHOD और LOG_FILE_SIZE का प्रदर्शन पर सबसे अधिक प्रभाव है। वे एक ट्रांजेक्शनल वर्कलोड के लिए देरी के समय को कम करते हैं।

नियामकों से संबंधित अन्य दिलचस्प बिंदु हैं। स्क्रीनशॉट में TIMED_MUTEXES नाम का एक नियामक है। यदि आप MySQL के कामकाजी दस्तावेज का उल्लेख करते हैं, तो धारा 45.7 में यह इंगित किया जाएगा कि यह नियामक पुराना है। लेकिन मशीन लर्निंग एल्गोरिदम प्रलेखन को पढ़ने में सक्षम नहीं है , इसलिए इसके बारे में पता नहीं है। वह जानता है कि एक नियामक है जिसे चालू या बंद किया जा सकता है, और यह समझने में लंबा समय लगेगा कि इससे कुछ भी प्रभावित नहीं होता है। लेकिन आप पहले से गणना कर सकते हैं और पता लगा सकते हैं कि नियामक कुछ भी नहीं करता है, और इसे स्थापित करने में समय बर्बाद न करें।

विश्लेषण के बाद, डेटा हमारे कॉन्फ़िगरेशन एल्गोरिथ्म में गॉसियन प्रक्रिया मॉडल का उपयोग करके स्थानांतरित किया जाता है - बल्कि एक पुरानी विधि। आपने शायद गहरी शिक्षा के बारे में सुना है, हम कुछ ऐसा ही कर रहे हैं, लेकिन गहरे नेटवर्क के बिना। हम GPflow का उपयोग करते हैं , गेंसियन प्रक्रिया मॉडल के साथ काम करने के लिए एक पैकेज जो रूस में TensorFlow के आधार पर विकसित किया गया है। एल्गोरिथ्म एक सिफारिश जारी करता है जिसे उद्देश्य फ़ंक्शन में सुधार करना चाहिए; यह डेटा नियंत्रक के अंदर काम करने वाले इंस्टॉलेशन एजेंट को वापस स्थानांतरित कर दिया जाता है। एजेंट एक रीसेट करके परिवर्तनों को लागू करता है - दुर्भाग्य से, इसे डेटाबेस को पुनरारंभ करना होगा - और फिर प्रक्रिया फिर से दोहराती है। कुछ और रनटाइम मैट्रिक्स एकत्र किए जाते हैं, एल्गोरिथ्म में स्थानांतरित किए जाते हैं, उत्पादकता में सुधार और वृद्धि की संभावना का विश्लेषण किया जाता है, एक सिफारिश जारी की जाती है, और इसी तरह, बार-बार।



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

आइए ओटेरट्यून डेमो पर एक नज़र डालें। परियोजना की वेबसाइट पर, हम Postgres 9.6 चलाते हैं और TPC-C परीक्षण के साथ सिस्टम को लोड करते हैं। आइए आरंभिक पोस्टग्रेक्यूएल कॉन्फ़िगरेशन के साथ शुरू करें, जो उबंटू पर स्थापित होने पर तैनात किया जाता है।



सबसे पहले, टीपीसी-सी परीक्षण को पांच मिनट के लिए चलाएं, आवश्यक रनटाइम मेट्रिक्स इकट्ठा करें, उन्हें ओटेरट्यून सेवा पर अपलोड करें, सिफारिशें प्राप्त करें, परिवर्तन लागू करें, और फिर प्रक्रिया को दोहराएं। हम बाद में इस पर वापस आएंगे। डेटाबेस सिस्टम एक कंप्यूटर पर चलता है, दूसरे पर Tensor Flow सेवा, और यहाँ डेटा लोड करता है।



पांच मिनट बाद, हम पृष्ठ को ताज़ा करते हैं ( इस क्षण के परिणामों का एक प्रदर्शन शुरू होता है)। जब हमने पहली बार शुरुआत की, PostgreSQL के लिए डिफ़ॉल्ट कॉन्फ़िगरेशन में, प्रति सेकंड 623 लेनदेन थे। फिर, सिफारिश प्राप्त करने और एक बार परिवर्तनों को लागू करने के बाद, लेनदेन की संख्या बढ़कर 2300 प्रति सेकंड हो गई । यह पहचानने योग्य है कि यह प्रदर्शन पहले ही कई बार लॉन्च किया जा चुका है, इसलिए सिस्टम में पहले से एकत्रित डेटा का एक सेट है। यही कारण है कि समाधान इतना तेज है। यदि सिस्टम में पहले से एकत्रित डेटा नहीं होता तो क्या होता? यह एल्गोरिथ्म एक प्रकार का चरण-दर-चरण फ़ंक्शन है, और धीरे-धीरे यह इस स्तर तक पहुंच जाएगा।



कुछ समय और पांच पुनरावृत्तियों के बाद, सबसे अच्छा परिणाम 2600 था। हम प्रति सेकंड 600 लेनदेन से चले गए, और 2600 के मूल्य तक पहुंचने में सक्षम थे। एक छोटी सी गिरावट दिखाई दी क्योंकि एल्गोरिदम ने अच्छे परिणाम के बाद नियामकों को समायोजित करने के एक अलग तरीके की कोशिश करने का फैसला किया। परिणाम एक मार्जिन था, इसलिए प्रदर्शन में बड़ी गिरावट नहीं हुई। एक नकारात्मक परिणाम प्राप्त करने के बाद, एल्गोरिथ्म पुन: कॉन्फ़िगर हो गया और विनियमन के अन्य तरीकों की तलाश करने लगा।

हम निष्कर्ष निकालते हैं कि आपको काम में एक खराब रणनीति शुरू करने से डरना नहीं चाहिए, क्योंकि एल्गोरिथ्म समाधान स्थान का पता लगाएगा और एसएलए समझौते की शर्तों को प्राप्त करने के लिए विभिन्न कॉन्फ़िगरेशन पर प्रयास करेगा। यद्यपि आप हमेशा सेवा को कॉन्फ़िगर कर सकते हैं ताकि एल्गोरिथ्म केवल सुधार के समाधान का चयन करे। और समय के साथ, आपको सभी सर्वोत्तम और सर्वोत्तम परिणाम प्राप्त होंगे।

अब हमारी बातचीत के विषय पर वापस। मैं आपको सिगमॉड में प्रकाशित एक लेख से मौजूदा परिणामों के बारे में बताऊंगा। हमने थ्रूपुट को बढ़ाने के लिए ओटीसीट्र्यून का उपयोग करके टीपीसी-सी के लिए MySQL और PostgreSQL को कॉन्फ़िगर किया है।

Ubuntu पर पहली स्थापना के दौरान डिफ़ॉल्ट रूप से इन DBMSs के विन्यास की तुलना करें। इसके बाद, कुछ ओपन सोर्स कॉन्फिगरेशन स्क्रिप्ट्स चलाएं, जो आपको पर्ककोना और कुछ अन्य कंसल्टिंग पोस्टग्रेक्सेल के साथ काम करने वाली फर्मों से मिल सकती हैं। ये स्क्रिप्ट हेयुरिस्टिक प्रक्रियाओं का उपयोग करती हैं, जैसे कि नियम कि आपको अपने हार्डवेयर के लिए एक निश्चित बफर आकार निर्धारित करना चाहिए। हमारे पास अमेज़ॅन आरडीएस से एक कॉन्फ़िगरेशन भी है, जिसमें पहले से ही आपके द्वारा काम कर रहे उपकरणों के लिए अमेज़ॅन प्रीसेट हैं। फिर मैन्युअल रूप से महंगे डीबीए स्थापित करने के परिणाम के साथ इसकी तुलना करें, लेकिन इस शर्त के साथ कि उनके पास 20 मिनट हैं और वे किसी भी पैरामीटर को सेट करने की क्षमता चाहते हैं। और अंतिम चरण ओटेरट्यून को लॉन्च करना है।



MySQL के लिए, आप देख सकते हैं कि डिफ़ॉल्ट कॉन्फ़िगरेशन बहुत पीछे है, स्क्रिप्ट थोड़ी बेहतर काम करती हैं, आरडीएस थोड़ा बेहतर है। इस मामले में, डेटाबेस व्यवस्थापक द्वारा सबसे अच्छा परिणाम दिखाया गया था - फेसबुक से अग्रणी MySQL व्यवस्थापक।

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

यह उदाहरण दिखाता है कि हम कैसे रूढ़िवादी होने की कोशिश करते हैं कि अंतिम निर्णय व्यक्ति द्वारा किया जाना चाहिए। क्योंकि डेटाबेस के कुछ ऐसे पहलू हैं जिनके बारे में ML एल्गोरिथ्म को जानकारी नहीं है।

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

मुख्य निष्कर्ष यह है कि ओटेरट्यून सेवा ऐसे एल्गोरिदम और मशीन सीखने का उपयोग करती है जो हम बहुत ही महंगे डीबीए की तुलना में एक ही या बेहतर प्रदर्शन प्राप्त कर सकते हैं। और यह न केवल डेटाबेस के एक उदाहरण पर लागू होता है, हम कार्य को दसियों हज़ारों प्रतियों में स्केल कर सकते हैं, क्योंकि यह सिर्फ सॉफ्टवेयर है, बस डेटा है।

peloton

दूसरी परियोजना जिसके बारे में मैं बात करना चाहूंगा उसे पेलोटन कहा जाता है। यह एक पूरी तरह से नया डेटा सिस्टम है जिसे हम कार्नेगी मेलन में खरोंच से बनाते हैं। हम इसे एक स्व-प्रबंध DBMS कहते हैं।

यह विचार करना है कि यदि आप संपूर्ण सॉफ़्टवेयर स्टैक को नियंत्रित करते हैं तो बेहतर के लिए क्या परिवर्तन किए जा सकते हैं। ओटेरट्यून की तुलना में सेटिंग्स को बेहतर कैसे बनाया जा सकता है, सिस्टम के प्रत्येक टुकड़े के बारे में ज्ञान के कारण, पूरे कार्यक्रम चक्र के बारे में।



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

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

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

एक स्व-प्रबंध DBMS का मूल विचार एक कार के विचार के समान है जो स्वत: नियंत्रण के साथ है।

एक मानव रहित वाहन अपने सामने दिखता है और यह देख सकता है कि सड़क पर इसके सामने क्या स्थित है, यह भविष्यवाणी कर सकता है कि अपने गंतव्य तक कैसे पहुंचा जाए। एक स्टैंड-अलोन डेटाबेस सिस्टम उसी तरह से काम करता है। आपको भविष्य को देखने में सक्षम होना चाहिए और यह निष्कर्ष निकालना चाहिए कि एक सप्ताह या एक घंटे में कार्यभार कैसा दिखेगा। फिर हम इस अनुमानित डेटा को नियोजन घटक को पास करते हैं - हम इसे मस्तिष्क कहते हैं - टेन्सर फ्लो पर।

यह प्रक्रिया Google डीप माइंड प्रोजेक्ट के हिस्से के रूप में लंदन से अल्फा गो के काम को अंजाम देती है, शीर्ष स्तर पर यह सभी एक समान परिदृश्य में काम करती है: मोंटे कार्लो पेड़ की खोज करता है, खोज का परिणाम विभिन्न क्रियाएं हैं जो वांछित लक्ष्य को प्राप्त करने के लिए किया जाना चाहिए।

निम्नलिखित एल्गोरिथ्म लगभग ऑपरेशन योजना को निर्धारित करता है:

• स्रोत डेटा आवश्यक क्रियाओं का एक सेट है, उदाहरण के लिए, एक इंडेक्स को हटाना, एक इंडेक्स, ऊर्ध्वाधर और क्षैतिज स्केलिंग, और इसी तरह जोड़ना।
• क्रियाओं का एक क्रम उत्पन्न होता है, जो अंततः अधिकतम उद्देश्य फ़ंक्शन की उपलब्धि की ओर जाता है।
• पहले को छोड़कर सभी मानदंड खारिज कर दिए गए हैं, और परिवर्तन लागू किए गए हैं।
• सिस्टम परिणामी प्रभाव को देखता है, फिर प्रक्रिया बार-बार दोहराती है।

एक मानवरहित कार के रूपक का लगातार सहारा न लें, लेकिन यह है कि वे कैसे काम करते हैं। इसे नियोजन क्षितिज कहा जाता है।

सड़क पर क्षितिज को देखने के बाद, हमने अपने आप को पहुंचने के लिए एक काल्पनिक बिंदु निर्धारित किया है, और फिर हम क्षितिज पर इस बिंदु तक पहुंचने के लिए क्रियाओं के क्रम की योजना बनाना शुरू करते हैं: तेजी, धीमा, बाएं मुड़ें, दाएं मुड़ें, आदि। फिर हम मानसिक रूप से पहले एक को छोड़कर सभी कार्यों को त्याग देते हैं, जिसे करने की आवश्यकता है, इसे निष्पादित करें, और फिर प्रक्रिया को फिर से दोहराएं। यूएवी ऐसे एल्गोरिदम को प्रति सेकंड 30 बार चलाते हैं। डेटाबेस के लिए, यह प्रक्रिया थोड़ी धीमी है, लेकिन विचार समान है।

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

ऑटोमोबाइल के साथ समानता में, PostgreSQL पर एक स्वायत्त DBMS की तुलना मानवरहित वैगन के साथ की जा सकती है। ट्रक सड़क के सामने कुत्ते को पहचानने और उसके चारों ओर जाने में सक्षम होगा, लेकिन यह नहीं कि अगर वह सीधे कार के सामने सड़क पर भाग गया। फिर एक टक्कर अपरिहार्य है, क्योंकि ट्रक पर्याप्त रूप से चलने योग्य नहीं है। हमने खरोंच से एक प्रणाली बनाने का निर्णय लिया ताकि परिवर्तनों को जल्द से जल्द लागू किया जा सके और यह पता लगाया जा सके कि सही विन्यास क्या है।

अब हमने पहली समस्या को हल कर लिया है और स्वचालित चयन और कार्यभार की भविष्यवाणी के लिए गहन सीखने और शास्त्रीय रैखिक प्रतिगमन के संयोजन पर एक लेख प्रकाशित किया है।

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

वैसे, मैं एक प्रसिद्ध डेटाबेस कंपनी के बारे में एक मनोरंजक कहानी बताऊंगा। इस कंपनी के पास एक स्वचालित सूचकांक चयन उपकरण था, और उपकरण में एक समस्या थी। एक क्लाइंट ने लगातार सभी इंडेक्स को रद्द कर दिया जो उपकरण ने सिफारिश की और लागू किया। यह रद्दीकरण इतनी बार हुआ कि उपकरण लटका रहा। उन्हें नहीं पता था कि व्यवहार की आगे की रणनीति क्या होनी चाहिए, क्योंकि किसी व्यक्ति को पेश किए गए किसी भी समाधान को नकारात्मक मूल्यांकन मिला। जब डेवलपर्स ने ग्राहक की ओर रुख किया और पूछा: "आप सूचकांकों पर सभी सिफारिशों और सुझावों को क्यों रद्द करते हैं?", ग्राहक ने जवाब दिया कि उसे बस उनके नाम पसंद नहीं थे। लोग मूर्ख हैं, लेकिन आपको उनसे निपटना होगा। और इस समस्या के लिए मेरे पास भी कोई हल नहीं है।

एक स्वायत्त DBMS डिजाइन करना

स्वायत्त डेटाबेस सिस्टम बनाने के दो अलग-अलग तरीकों को देखते हुए, अब बात करते हैं कि DBMS को कैसे डिज़ाइन किया जाए ताकि यह स्वायत्त हो।

आइए हम तीन विषयों पर ध्यान दें:

• नियामकों को कैसे समायोजित करें,
• आंतरिक मीट्रिक कैसे एकत्रित करें,
• कार्यों को कैसे डिज़ाइन करें।

एक बार फिर, मुख्य बिंदुओं पर वापस: डेटाबेस सिस्टम को बेहतर निर्णय लेने के लिए मशीन लर्निंग एल्गोरिदम को सही जानकारी प्रदान करनी चाहिए। प्रतिक्रियाओं को प्राप्त करने की गति को बढ़ाने के लिए हमारे द्वारा प्रसारित बेकार डेटा की मात्रा को कम किया जाना चाहिए।

मैंने पहले ही कहा है कि किसी भी नियामक को स्वायत्त घटकों में मूल्य निर्णय लेने के लिए एक व्यक्ति की आवश्यकता होती है जिसे निषिद्ध माना जाना चाहिए। PG_SETTINGSएल्गोरिथ्म को इस नियामक तक पहुंचने से रोकने के लिए सेटिंग्स या किसी अन्य कॉन्फ़िगरेशन फ़ाइल में इस पैरामीटर को चिह्नित करना आवश्यक है ।

फ़ाइल पथ, अलगाव स्तर, लेनदेन स्थिरता आवश्यकताओं आदि जैसे मापदंडों के संबंध में। निर्णय मनुष्य द्वारा किए जाने चाहिए, एल्गोरिथम द्वारा नहीं।

, , , , .

, , , .

:

• . , , .
• . , , -1 0, .
• , . , . 64- , 0 2 ⁶⁴ . , .

, . , 10 , , 10 . , .

- , . , , . , , , .

, , , . , . , , , — . , .

, , , . , .

, , . , : , , , , . - Oracle, , .



, , .

, , . , , , . - , , , . : PostgreSQL , .



, , , .

- , , , . , , . RocksDB, MyRocks MySQL.

RocksDB . , . , , , . RocksDB, .



, , , , . MyRocks . — : ROCKSDB_BITES_READ, ROCKSDB_BITES_WRITTEN . , , . , . , .

, , , .

, , open source. , .

, , . MySQL , . , . 5 , 10 , , . 5 , — .

, . — PostgreSQL .

— . , . , , , , .

. , — SLA. , .

, . , . , . , .



, - , . , , - , . , , , — , -, , .

, , , .

, . , , , , 5- . downtime, .

, , , , , . , , , , .

Oracle autonomous database

Oracle . 2017 Oracle , . , Oracle, , « , Oracle 20 ».



. , , , , , . CIDR , . , : «, , , . , , , Oracle ?» , — .

, , , Oracle. , .

, — , , , - .

— , . , , , 2000- . , Oracle , . , : , — - .

, . , , .

— . , . : JOIN. . . , . .

Oracle. Microsoft 2017 SQL Server, . IBM DB2 00- , «LEO» — . , 1970-, Ingres. , JOIN, , . .

, , .

, , . , , . , , .

, , — , , , . , , , . , , .., .

HighLoad++ , HighLoad++ Siberia . , 39 , , highload- - .

HighLoad++ , . , UseData Conf — 16 , . , .