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

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

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

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

मुझे कैसे पता चलेगा?

मैं अपना संक्षिप्त परिचय दूंगा। मैंने 2006 से 2013 तक Google में काम किया। पहले इंटर्न के रूप में, फिर वेब सर्च इन्फ्रास्ट्रक्चर में सॉफ्टवेयर इंजीनियर के रूप में। Google ने 2010 में मेटाएब का अधिग्रहण किया, और मेरी टीम ने कैफीन लॉन्च किया। मैं कुछ और करना चाहता था - और मेटावेब (सैन फ्रांसिस्को में) के लोगों के साथ काम करना शुरू कर दिया, सैन फ्रांसिस्को और माउंटेन व्यू के बीच यात्रा का समय बिताया। मैं यह जानना चाहता था कि अपनी वेब खोज को बेहतर बनाने के लिए ज्ञान ग्राफ का उपयोग कैसे किया जाए।

मेरे सामने Google पर ऐसी परियोजनाएं आई हैं। यह उल्लेखनीय है कि स्क्वायर्ड नामक परियोजना न्यूयॉर्क कार्यालय में बनाई गई थी , और नॉलेज कार्ड्स के बारे में कुछ बात हुई थी। तब व्यक्तियों / छोटी टीमों द्वारा छिटपुट प्रयास किए गए थे, लेकिन उस समय कोई स्थापित टीम श्रृंखला नहीं थी, जिसने अंततः मुझे Google छोड़ने के लिए मजबूर किया। लेकिन हम बाद में इस पर वापस आएंगे ...

मेटावेब का इतिहास

जैसा कि पहले ही उल्लेख किया गया है, Google ने 2010 में मेटाब का अधिग्रहण किया। मेटावे ने विकिपीडिया क्रॉलिंग और पार्सिंग के साथ-साथ फ्रीबेस के उपयोग से क्राउडसोर्सिंग विकी-स्टाइल एडिटिंग सिस्टम सहित कई तरीकों का उपयोग करके एक उच्च-गुणवत्ता वाला ज्ञान ग्राफ बनाया। यह सब ग्राफ के अपने ग्राफ डेटाबेस के आधार पर काम करता था - ग्राफ डेमॉन (अब गिटहब पर प्रकाशित )।

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

Google ने मानक हार्डवेयर और वितरित सॉफ़्टवेयर पर एक साम्राज्य बनाया। एक सर्वर-साइड DBMS क्रॉलिंग, इंडेक्सिंग और खोज परिणामों की सेवा करने में कभी सक्षम नहीं होगा। पहले SSTable बनाया, फिर Bigtable, जो क्षैतिज रूप से सैकड़ों या हजारों मशीनों को स्केल करता है जो डेटा की पेटाबाइट्स साझा करते हैं। मशीनों को Borg ( K8 यहाँ से आया) द्वारा आवंटित किया गया है, वे Stubby (gRPC यहाँ से आए) Borg नाम सेवा (K8 के अंदर BNC) और Google फ़ाइल सिस्टम ( GFS में डेटा संग्रहीत करते हैं, आप Hadoop FS कह सकते हैं) के माध्यम से आईपी पते को हल करते हैं। प्रक्रियाएं मर सकती हैं, मशीनें टूट सकती हैं, लेकिन एक पूरे के रूप में प्रणाली अविनाशी है और आगे भी जारी रहेगी।

ऐसे माहौल में ग्राफ्ड हो गया। एक सर्वर पर एक पूरी वेबसाइट की सेवा करने वाले डेटाबेस का विचार Google के लिए विदेशी है (मेरे सहित)। विशेष रूप से, ग्राफ्ड को चलाने के लिए 64 जीबी या अधिक मेमोरी की आवश्यकता होती है। यदि यह आपको लगता है कि यह थोड़ा है, तो याद रखें: यह 2010 है। अधिकांश Google सर्वर अधिकतम 32 जीबी से लैस थे। वास्तव में, Google को अपने वर्तमान स्वरूप में ग्राफ्ड की सेवा के लिए पर्याप्त रैम के साथ विशेष मशीनों की खरीद करनी थी।

रेखांकन प्रतिस्थापन

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

एक विचार माइंडमिल्ड (IIRC) नामक परियोजना का उपयोग करना था। यह माना जाता था कि नेटवर्क उपकरण के माध्यम से दूसरे सर्वर से मेमोरी बहुत तेजी से उपलब्ध होगी। यह नियमित रूप से RPC की तुलना में तेज होना चाहिए, छद्म के लिए पर्याप्त तेजी से-इन-मेमोरी डेटाबेस द्वारा आवश्यक प्रत्यक्ष मेमोरी एक्सेस को दोहराने के लिए। लेकिन विचार बहुत दूर नहीं गया।

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

यदि आप रुचि रखते हैं, तो हाँ। मेरा स्टार्टअप, Dgraph Labs, कंपनी, और ओपन सोर्स प्रोजेक्ट Dgraph का नाम Google पर उस प्रोजेक्ट के नाम पर रखा गया है (नोट: Dgraph, Dgraph Labs का ट्रेडमार्क है; जहाँ तक मुझे पता है, Google उन नामों के साथ प्रोजेक्ट जारी नहीं करता है जो आंतरिक मेल खाते हैं)।

लगभग सभी पाठों में, जब मैं Dgraph का उल्लेख करता हूं, तो मेरा मतलब आंतरिक Google परियोजना से है, और हमारे द्वारा बनाए गए ओपन सोर्स प्रोजेक्ट से नहीं। लेकिन उस पर और बाद में।

Cerebro की कहानी: ज्ञान इंजन

रेखांकन के लिए अनजाने बुनियादी ढांचे का निर्माण

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

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

पहेली का पहला भाग सर्च इंजन है। यह सही तरीके से निर्धारित करने का एक तरीका है कि कौन से शब्द एक-दूसरे से संबंधित हैं। उदाहरण के लिए, जब आप [टॉम हैंक्स मूवीज] जैसा कोई वाक्यांश देखते हैं, तो यह आपको बता सकता है कि [टॉम] और [हैंक्स] संबंधित हैं। इसी तरह, [san francisco weather] से हम [san] और [francisco] के बीच संबंध देखते हैं। ये लोगों के लिए स्पष्ट चीजें हैं, लेकिन कारों के लिए इतना स्पष्ट नहीं है।

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

पहेली का तीसरा भाग संस्थाओं को समझ रहा है। [फ्रेंच] का मतलब बहुत कुछ हो सकता है। यह एक देश (क्षेत्र), राष्ट्रीयता (फ्रांसीसी लोगों से संबंधित), व्यंजन (भोजन से संबंधित) या भाषा हो सकती है। फिर मैंने उन संस्थाओं की सूची प्राप्त करने के लिए एक और प्रणाली लागू की जो एक शब्द या वाक्यांश के अनुरूप हो सकते हैं।

पहेली का चौथा भाग संस्थाओं के बीच संबंधों को समझना था। जब यह जाना जाता है कि शब्दों को वाक्यांशों में कैसे जोड़ा जाए, तो किस क्रम में वाक्यांशों का प्रदर्शन किया जाना चाहिए, अर्थात्, उनका व्याकरण, और वे किन संस्थाओं से मेल कर सकते हैं, आपको मशीन व्याख्या बनाने के लिए इन संस्थाओं के बीच संबंध खोजने की आवश्यकता है। उदाहरण के लिए, हम क्वेरी [फ्रेंच लेखकों द्वारा पुस्तकें] चलाते हैं, और पीओएस का कहना है कि यह [फ्रेंच लेखकों] से [किताबें] है। हमारे पास [फ्रेंच] और [लेखकों] के लिए कई इकाइयां हैं: एल्गोरिथ्म को यह निर्धारित करना चाहिए कि वे कैसे संबंधित हैं। उदाहरण के लिए, वे जन्म स्थान से संबंधित हो सकते हैं, अर्थात्, लेखक जो फ्रांस में पैदा हुए थे (हालांकि वे अंग्रेजी में लिख सकते हैं)। या यह लेखक हो सकते हैं जो फ्रांसीसी नागरिक हैं। या तो वे लेखक जो फ्रेंच बोल सकते हैं या लिख ​​सकते हैं (लेकिन एक देश के रूप में फ्रांस से संबंधित नहीं हो सकते हैं), या ऐसे लेखक जो केवल फ्रांसीसी भोजन पसंद करते हैं।

इंडेक्स ग्राफ़ सिस्टम खोजें

यह निर्धारित करने के लिए कि वस्तुओं के बीच कोई संबंध है और वे कैसे जुड़े हुए हैं, आपको एक ग्राफ़ सिस्टम की आवश्यकता है। ग्राफ्ड कभी भी Google के स्तर के पैमाने पर नहीं था, लेकिन आप स्वयं खोज का उपयोग कर सकते हैं। ज्ञान ग्राफ डेटा को ट्रिपल्स ट्राइएप्स प्रारूप में संग्रहीत किया जाता है, अर्थात, प्रत्येक तथ्य को तीन भागों द्वारा दर्शाया जाता है: विषय (निकाय), विधेय (संबंध) और ऑब्जेक्ट (अन्य इकाई)। अनुरोध [SP] → [O] या [PO] → [S] , और कभी-कभी [SO] → [P] जैसे चलते हैं।



मैंने Google खोज इंडेक्स का उपयोग किया , प्रत्येक ट्रिपल के लिए एक डॉकिड असाइन किया, और तीन इंडेक्स बनाए, जिनमें से एक S, P और O के लिए था। इसके अलावा, इंडेक्स नेस्टेबल है, इसलिए मैंने प्रत्येक एंटिटी के प्रकार (जैसे, अभिनेता, पुस्तक, व्यक्ति, और के बारे में जानकारी जोड़ी) टी। डी।)।

मैंने इस तरह की एक प्रणाली बनाई, हालांकि मैंने जॉन्स की गहराई के साथ एक समस्या देखी (जिसे नीचे समझाया गया है) और यह जटिल प्रश्नों के लिए उपयुक्त नहीं है। दरअसल, जब मेटावेब टीम के किसी व्यक्ति ने मुझसे सहकर्मियों के लिए एक प्रणाली प्रकाशित करने के लिए कहा, तो मैंने मना कर दिया।

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


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

यह परियोजना इतनी बुद्धिमानी से प्रतीत हुई कि हम (डीएच ज्ञान मानचित्र पर एक विशेषज्ञ के रूप में आंशिक रूप से शामिल थे) ने इसे "एक्स-मेन" फिल्म से उसी नाम के उपकरण के सम्मान में सेरेबेल नाम दिया।

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

ब्लू लिंक बनाम ज्ञान

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

डीएच ने इस अवसर को लंबन नामक एक अन्य परियोजना में एक सूची से दूसरी सूची में स्थानांतरित करने का प्रदर्शन किया।

सेरेब्रो ने बहुत प्रभावशाली परिणाम दिखाया, और मेटाब प्रबंधन ने इसका समर्थन किया। यहां तक ​​कि बुनियादी सुविधाओं के मामले में, यह कुशल और कार्यात्मक निकला। मैंने इसे ज्ञान इंजन (एक खोज इंजन की तरह) कहा। लेकिन Google पर, किसी ने विशेष रूप से इस विषय को संबोधित नहीं किया। वह मेरे प्रबंधक के लिए बहुत कम रुचि थी, उन्होंने मुझे एक व्यक्ति के साथ बात करने की सलाह दी, फिर दूसरे के साथ, और परिणामस्वरूप मुझे एक बहुत ही उच्च शीर्ष खोज प्रबंधक को सिस्टम प्रदर्शित करने का मौका मिला।

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

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

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

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

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

ज्वाइन-डेप्थ प्रॉब्लम

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

कहते हैं कि आप जानना चाहते हैं [SF में लोग जो सुशी खाते हैं]। सभी लोगों को कुछ डेटा सौंपे जाते हैं, जिनमें कौन किस शहर में रहता है और किस तरह का खाना खाता है।

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

दूसरा कदम पंखे की समस्या से पीड़ित है। यदि पहला कदम एक लाख परिणाम (सैन फ्रांसिस्को की जनसंख्या) देता है, तो दूसरा चरण सभी के अनुरोध पर, उनके खाने की आदतों के लिए, और फिर एक फ़िल्टर लागू करने के लिए दिया जाना चाहिए।



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

एक वितरित प्रणाली में प्रसारण अच्छा काम नहीं करता है। इस समस्या को Google के जेफ डीन ने अपने भाषण "बड़ी ऑनलाइन सेवाओं में तेजी से प्रतिक्रिया प्राप्त करने" ( वीडियो , स्लाइड ) के द्वारा सबसे अच्छी तरह से समझाया है। कुल देरी हमेशा सबसे धीमी घटक की देरी से अधिक होती है। अलग-अलग कंप्यूटरों पर छोटी चमक में देरी होती है, और क्वेरी में कई कंप्यूटरों के शामिल होने से नाटकीय रूप से देरी की संभावना बढ़ जाती है।

50% मामलों में 1 एमएस से अधिक की देरी के साथ एक सर्वर पर विचार करें, और 1% मामलों में 1 से अधिक एस। यदि अनुरोध केवल एक ऐसे सर्वर पर जाता है, तो प्रतिक्रियाओं का केवल 1% एक सेकंड से अधिक है। लेकिन अगर अनुरोध ऐसे सैकड़ों सर्वर पर जाता है, तो 63% प्रतिक्रियाएं एक सेकंड से अधिक होती हैं।

इस प्रकार, एक अनुरोध के प्रसारण में देरी बहुत बढ़ जाती है। अब सोचो, और अगर आपको दो, तीन या अधिक संघों की आवश्यकता है? वास्तविक समय में निष्पादित करना बहुत धीमा है।

अनुरोध प्रसारण के समय फैन की तैनाती की समस्या सबसे अधिक गैर-देशी डीबी ग्राफ में होती है, जिसमें जेनस ग्राफ , ट्विटर फ्लॉकडीबी और फेसबुक टीएओ शामिल हैं ।

वितरित संघ एक जटिल समस्या है। नेटिव ग्राफ़ डेटाबेस एक सर्वर (स्टैंड-अलोन डेटाबेस) के भीतर एक सार्वभौमिक डेटा सेट को संग्रहीत करके और अन्य सर्वरों को एक्सेस किए बिना सभी जॉइन का प्रदर्शन करके इस समस्या से बचने की अनुमति देता है। उदाहरण के लिए, Neo4j ऐसा करता है।

डग्राफ: अनियंत्रित गहराई के साथ यूनियनों

सेरेब्रो पर काम पूरा करने और एक ग्राफ प्रबंधन प्रणाली के निर्माण का अनुभव होने के बाद, मैंने डग्राफ परियोजना में भाग लिया, जो तीन तकनीकी परियोजना प्रबंधकों में से एक बन गई। हमने अभिनव अवधारणाएं लागू कीं जो संघ की गहराई की समस्या को हल करती हैं।

विशेष रूप से, Dgraph ग्राफ़ डेटा को अलग करता है ताकि प्रत्येक जुड़ाव पूरी तरह से एक मशीन द्वारा किया जा सके। subject-predicate-object (SPO) subject-predicate-object लौटते हुए, प्रत्येक Dgraph उदाहरण में इस उदाहरण में प्रत्येक विधेय के लिए संबंधित सभी विषय और वस्तुएं होती हैं। कई विधेयकों को एक उदाहरण में संग्रहीत किया जाता है, प्रत्येक को पूरी तरह से संग्रहीत किया जाता है।

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


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

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

प्लाज्मा के माध्यम से सभी वनबॉक्स ब्लॉकों को मिलाकर

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

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

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

उदाहरण के लिए, [SF में घटनाएँ] घटनाओं को दिखा सकती हैं, और [SF में मौसम] मौसम दिखा सकती हैं। लेकिन अगर [SF में घटनाओं] ने यह समझा कि अब बारिश हो रही है, तो हम "घर के अंदर" या "बाहर" के अनुसार घटनाओं को फ़िल्टर या सॉर्ट कर सकते हैं ( भारी बारिश में फुटबॉल की बजाय सिनेमा जाना बेहतर हो सकता है) )।

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

लीपफ्रॉग मैनेजमेंट

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

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

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

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

कुछ महीनों बाद, मई 2013 में, मैंने Google को Dgraph / Plasma पर लगभग दो वर्षों तक काम करने के बाद छोड़ दिया।

अंतभाषण

• कुछ साल बाद, अनुभाग "इंटरनेट खोज इन्फ्रास्ट्रक्चर" का नाम बदलकर "इंटरनेट सर्च इन्फ्रास्ट्रक्चर एंड नॉलेज ग्राफ" रखा गया था, और जिस नेता को मैंने एक बार सेरेबोर दिखाया था वह दिशा "नॉलेज ग्राफ" का नेतृत्व करते हुए बताता है कि वे कैसे सरल को बदलने का इरादा रखते हैं। नीले ज्ञान लिंक उपयोगकर्ता के सवालों के जवाब देने के लिए जितनी बार संभव हो सके।
  
• जब सेरेब्रो पर काम करने वाली शंघाई टीम इसे उत्पादन में लगाने के करीब थी, तो परियोजना उनसे ली गई और न्यूयॉर्क डिवीजन को दी गई। अंत में, इसे नॉलेज स्ट्रिप के रूप में लॉन्च किया गया था। यदि आप [ टॉम हैंक्स मूवीज ] की तलाश कर रहे हैं, तो आप इसे सबसे ऊपर देखेंगे। पहले लॉन्च के बाद से इसमें थोड़ा सुधार हुआ है, लेकिन अभी भी फ़िल्टरिंग और सॉर्टिंग के स्तर का समर्थन नहीं करता है जो कि सेरेब्रो में रखी गई थी।
  
• सभी तीन तकनीकी प्रबंधक जिन्होंने डग्राफ पर काम किया था (स्वयं सहित) अंततः Google को छोड़ दिया। जहां तक ​​मुझे पता है, बाकी अब माइक्रोसॉफ्ट और लिंक्डइन पर काम कर रहे हैं।
  
• मैं Google पर दो प्रमोशन पाने में कामयाब रहा, और मुझे एक तीसरा मिलने वाला था जब मैंने कंपनी को एक वरिष्ठ सॉफ्टवेयर इंजीनियर (सीनियर सॉफ्टवेयर इंजीनियर) के रूप में छोड़ दिया।
  
• कुछ खंडित अफवाहों को देखते हुए, टीएस का वर्तमान संस्करण वास्तव में सेरेब्रो ग्राफ सिस्टम के डिजाइन के बहुत करीब है, और प्रत्येक विषय, विधेय और ऑब्जेक्ट का एक सूचकांक है। इसलिए, वह अभी भी एकीकरण की गहराई की समस्या से ग्रस्त है।
  
• प्लाज्मा को फिर से लिखा गया है और इसका नाम बदल दिया गया है, लेकिन यह टीएस के लिए वास्तविक समय ग्राफ अनुक्रमण प्रणाली के रूप में काम करना जारी रखता है। साथ में, वे Google पर सभी संरचित डेटा को पोस्ट और प्रोसेस करना जारी रखते हैं, जिसमें नॉलेज ग्राफ भी शामिल है।
  
• कई स्थानों पर गहरी यूनियन बनाने में Google की अक्षमता दिखाई देती है। उदाहरण के लिए, हम अभी भी वनबॉक्स ब्लॉकों के बीच डेटा के आदान-प्रदान को नहीं देखते हैं: [एशिया में अधिकांश बारिश से शहरों] शहरों की सूची नहीं देते हैं, हालांकि सभी डेटा ज्ञान कॉलम में हैं (इसके बजाय, वेब पेज खोज परिणामों में उद्धृत है); [एसएफ में घटनाएँ] मौसम द्वारा फ़िल्टर नहीं की जा सकती हैं; [अमेरिकी राष्ट्रपतियों] परिणाम अन्य तथ्यों द्वारा हल नहीं किए जाते हैं, फ़िल्टर किए जाते हैं या विस्तारित होते हैं: उनके बच्चे या स्कूल जहां उन्होंने अध्ययन किया। मेरा मानना ​​है कि यह फ्रीबेस सपोर्ट बंद करने का एक कारण था।

डग्राफ: फीनिक्स बर्ड

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

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

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