NoSQL साठी डेटा मॉडेल डिझाइन करण्याची वैशिष्ट्ये

परिचय

“तुम्हाला जागेवर राहण्यासाठी शक्य तितक्या वेगाने धावावे लागेल,
आणि कुठेतरी जाण्यासाठी, तुम्हाला किमान दुप्पट वेगाने धावावे लागेल!”
(c) अॅलिस इन वंडरलँड

काही वेळापूर्वी मला एक व्याख्यान द्यायला सांगितले होते विश्लेषक डेटा मॉडेल डिझाइन करण्याच्या विषयावर आमची कंपनी, कारण प्रकल्पांवर बराच वेळ बसून (कधीकधी अनेक वर्षे) आम्ही आयटी तंत्रज्ञानाच्या जगात आपल्या आजूबाजूला काय घडत आहे ते गमावून बसतो. आमच्या कंपनीमध्ये (असेच घडते) अनेक प्रकल्प NoSQL डेटाबेस वापरत नाहीत (किमान सध्या तरी), म्हणून माझ्या व्याख्यानात मी HBase चे उदाहरण वापरून त्यांच्याकडे वेगळे लक्ष दिले आणि त्यांच्यासाठी सामग्रीचे सादरीकरण करण्याचा प्रयत्न केला. ज्यांनी त्यांचा कधीही वापर केला नाही त्यांनी काम केले आहे. विशेषतः, मी अनेक वर्षांपूर्वी वाचलेले उदाहरण वापरून डेटा मॉडेल डिझाइनची काही वैशिष्ट्ये स्पष्ट केली अमनदीप खुराना यांच्या “HB ase स्कीमा डिझाइनचा परिचय” या लेखात. उदाहरणांचे विश्लेषण करताना, मुख्य कल्पना प्रेक्षकांपर्यंत चांगल्या प्रकारे पोहोचवण्यासाठी मी समान समस्येचे निराकरण करण्यासाठी अनेक पर्यायांची तुलना केली.

अलीकडे, “काहीही करण्यासारखे नाही,” मी स्वतःला प्रश्न विचारला (क्वारंटाईनमधील दीर्घ मे शनिवार व रविवार यासाठी अनुकूल आहे), सैद्धांतिक गणना सरावाशी किती जुळेल? वास्तविक, या लेखाची कल्पना अशीच जन्माला आली. अनेक दिवसांपासून NoSQL सोबत काम करणारा विकासक कदाचित त्यातून नवीन काही शिकू शकणार नाही (आणि त्यामुळे लगेच अर्धा लेख वगळू शकतो). पण त्यासाठी विश्लेषकज्यांनी अद्याप NoSQL सह जवळून काम केले नाही त्यांच्यासाठी, मला वाटते की HBase साठी डेटा मॉडेल डिझाइन करण्याच्या वैशिष्ट्यांची मूलभूत माहिती मिळविण्यासाठी ते उपयुक्त ठरेल.

उदाहरण विश्लेषण

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

चला खालील "सिंथेटिक" समस्येचा विचार करूया, ज्यासह आम्ही कार्य करणे सुरू ठेवू:

काही अमूर्त सोशल नेटवर्कच्या वापरकर्त्यांच्या मित्रांच्या यादीसाठी स्टोरेज रचना तयार करणे आवश्यक आहे. सोपे करण्यासाठी, आम्ही असे गृहीत धरू की आमचे सर्व कनेक्शन निर्देशित केले आहेत (इन्स्टाग्रामवर, लिंक्डइनवर नाही). संरचनेने आपल्याला प्रभावीपणे अनुमती दिली पाहिजे:

• वापरकर्ता A वापरकर्ता B वाचतो की नाही या प्रश्नाचे उत्तर द्या (रीडिंग पॅटर्न)
• वापरकर्ता B (डेटा बदल टेम्प्लेट) कडून वापरकर्ता A चे सदस्यत्व/सदस्यता रद्द करण्याच्या बाबतीत कनेक्शन जोडण्यास/काढण्यास परवानगी द्या

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

user_id
मित्र_आयडी

वासिया
पेट्या

वासिया
Olya

यापुढे, स्पष्टतेसाठी आणि चांगल्या प्रकारे समजून घेण्यासाठी, मी IDs ऐवजी नावे सूचित करेन

HBase च्या बाबतीत, आम्हाला माहित आहे की:

• कार्यक्षम शोध ज्याचा परिणाम संपूर्ण टेबल स्कॅनमध्ये होत नाही केवळ की द्वारे
  • खरं तर, म्हणूनच अशा डेटाबेसेससाठी अनेकांना परिचित असलेल्या SQL क्वेरी लिहिणे ही वाईट कल्पना आहे; तांत्रिकदृष्ट्या, अर्थातच, तुम्ही त्याच Impala वरून HBase ला Joins आणि इतर लॉजिकसह SQL क्वेरी पाठवू शकता, परंतु ते किती प्रभावी होईल...

म्हणून, आम्हाला वापरकर्ता आयडी एक की म्हणून वापरण्याची सक्ती केली जाते. आणि "मित्रांचे आयडी कुठे आणि कसे साठवायचे?" या विषयावर माझा पहिला विचार. कदाचित त्यांना स्तंभांमध्ये संग्रहित करण्याची कल्पना आहे. हा सर्वात स्पष्ट आणि "भोळा" पर्याय यासारखा दिसेल (याला कॉल करूया पर्याय १ (डीफॉल्ट)पुढील संदर्भासाठी):

RowKey
स्पीकर्स

वासिया
1: पेट्या
2: ओल्या
3: दशा

पेट्या
1: माशा
2: वस्या

येथे, प्रत्येक ओळ एका नेटवर्क वापरकर्त्याशी संबंधित आहे. स्तंभांना नावे आहेत: 1, 2, ... - मित्रांच्या संख्येनुसार, आणि मित्रांचे आयडी कॉलममध्ये संग्रहित केले जातात. हे लक्षात घेणे महत्त्वाचे आहे की प्रत्येक पंक्तीमध्ये स्तंभांची संख्या भिन्न असेल. वरील आकृतीमधील उदाहरणात, एका पंक्तीमध्ये तीन स्तंभ आहेत (1, 2 आणि 3), आणि दुसऱ्यामध्ये फक्त दोन (1 आणि 2) आहेत - येथे आम्ही स्वतः दोन HBase गुणधर्म वापरले आहेत जे रिलेशनल डेटाबेसमध्ये नाहीत:

• स्तंभांची रचना गतिशीलपणे बदलण्याची क्षमता (मित्र जोडा -> स्तंभ जोडा, मित्र काढा -> स्तंभ हटवा)
• वेगवेगळ्या पंक्तींमध्ये वेगवेगळ्या स्तंभ रचना असू शकतात

कार्याच्या आवश्यकतांचे पालन करण्यासाठी आमची रचना तपासूया:

• डेटा वाचत आहे: वास्याने ओल्याचे सदस्यत्व घेतले आहे की नाही हे समजून घेण्यासाठी, आम्हाला वजा करणे आवश्यक आहे संपूर्ण ओळ RowKey = “वास्या” की द्वारे आणि स्तंभ मूल्यांद्वारे क्रमवारी लावा जोपर्यंत आपण त्यामध्ये ओल्याला “भेट” देत नाही. किंवा सर्व स्तंभांच्या मूल्यांमधून पुनरावृत्ती करा, ओल्याला “भेटले नाही” आणि उत्तर खोटे परत करा;
• डेटा संपादित करणे: मित्र जोडणे: समान कार्यासाठी आपल्याला वजा करणे देखील आवश्यक आहे संपूर्ण ओळ त्याच्या मित्रांची एकूण संख्या मोजण्यासाठी RowKey = “वास्य” की वापरून. आम्हाला नवीन मित्राचा आयडी लिहिण्याची आवश्यकता असलेल्या कॉलमची संख्या निश्चित करण्यासाठी आम्हाला मित्रांची ही संख्या आवश्यक आहे.
• डेटा बदलणे: मित्र हटवणे:
  • वजा करणे आवश्यक आहे संपूर्ण ओळ RowKey = “वास्य” की द्वारे आणि ज्या मित्राला हटवायचे आहे ते शोधण्यासाठी स्तंभांमधून क्रमवारी लावा;
  • पुढे, मित्र हटवल्यानंतर, आम्हाला सर्व डेटा एका कॉलममध्ये "शिफ्ट" करणे आवश्यक आहे जेणेकरून त्यांच्या क्रमांकामध्ये "अंतर" येऊ नये.

आता हे अल्गोरिदम कितपत फलदायी असतील याचे मूल्यांकन करूया, ज्याची आपल्याला “कंडिशनल ऍप्लिकेशन” बाजूने अंमलबजावणी करावी लागेल, वापरून ओ-प्रतीकवाद. चला आमच्या काल्पनिक सोशल नेटवर्कचा आकार n म्हणून दर्शवू. मग एका वापरकर्त्याला जास्तीत जास्त मित्र असू शकतात (n-1). आम्ही आमच्या उद्देशांसाठी याकडे (-1) आणखी दुर्लक्ष करू शकतो, कारण O-चिन्हांच्या वापराच्या चौकटीत ते बिनमहत्त्वाचे आहे.

• डेटा वाचत आहे: संपूर्ण रेषा वजा करणे आणि मर्यादेतील सर्व स्तंभांमधून पुनरावृत्ती करणे आवश्यक आहे. याचा अर्थ खर्चाचा वरचा अंदाज अंदाजे O(n) असेल
• डेटा संपादित करणे: मित्र जोडणे: मित्रांची संख्या निश्चित करण्यासाठी, तुम्हाला पंक्तीच्या सर्व स्तंभांमधून पुनरावृत्ती करणे आवश्यक आहे, आणि नंतर एक नवीन स्तंभ घाला => O(n)
• डेटा बदलणे: मित्र हटवणे:
  • जोडण्यासारखेच - तुम्हाला मर्यादा => O(n) मधील सर्व स्तंभांमधून जावे लागेल
  • स्तंभ काढून टाकल्यानंतर, आम्हाला त्यांना "हलवा" लागेल. तुम्ही हे “हेड-ऑन” अंमलात आणल्यास, मर्यादेत तुम्हाला (n-1) ऑपरेशन्सची आवश्यकता असेल. परंतु येथे आणि पुढे व्यावहारिक भागामध्ये आम्ही एक भिन्न दृष्टीकोन वापरू, जो एका निश्चित संख्येच्या ऑपरेशन्ससाठी "स्यूडो-शिफ्ट" लागू करेल - म्हणजेच, n ची पर्वा न करता, त्यावर सतत वेळ घालवला जाईल. ही स्थिर वेळ (O(2) अचूक असणे) O(n) च्या तुलनेत दुर्लक्षित केली जाऊ शकते. खालील आकृतीमध्ये दृष्टिकोन स्पष्ट केला आहे: आम्ही फक्त "अंतिम" स्तंभातील डेटा कॉपी करतो ज्यामधून आम्हाला डेटा हटवायचा आहे, आणि नंतर शेवटचा स्तंभ हटवा:
    

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

RowKey
स्पीकर्स

वासिया
1: पेट्या
2: ओल्या
3: दशा
संख्या: 3

पेट्या
1: माशा
2: वस्या

संख्या: 2

पहिल्या पर्यायाच्या तुलनेत:

• डेटा वाचत आहे: "वास्या ओल्या वाचतो का?" या प्रश्नाचे उत्तर मिळवण्यासाठी काहीही बदलले नाही => O(n)
• डेटा संपादित करणे: मित्र जोडणे: आम्ही नवीन मित्र समाविष्ट करणे सोपे केले आहे, कारण आता आम्हाला संपूर्ण ओळ वाचण्याची आणि त्याच्या स्तंभांवर पुनरावृत्ती करण्याची आवश्यकता नाही, परंतु फक्त "गणना" स्तंभ इत्यादीचे मूल्य मिळू शकते. नवीन मित्र समाविष्ट करण्यासाठी ताबडतोब स्तंभ क्रमांक निश्चित करा. यामुळे O(1) ची संगणकीय जटिलता कमी होते
• डेटा बदलणे: मित्र हटवणे: मित्राला हटवताना, डेटा एका सेलला डावीकडे "शिफ्ट" करताना आम्ही I/O ऑपरेशन्सची संख्या कमी करण्यासाठी देखील हा स्तंभ वापरू शकतो. परंतु ज्याला हटवायचे आहे ते शोधण्यासाठी स्तंभांद्वारे पुनरावृत्ती करण्याची आवश्यकता अजूनही शिल्लक आहे, म्हणून => O(n)
• दुसरीकडे, आता डेटा अद्यतनित करताना आम्हाला प्रत्येक वेळी "गणना" स्तंभ अद्यतनित करणे आवश्यक आहे, परंतु यासाठी सतत वेळ लागतो, ज्याकडे ओ-चिन्हांच्या चौकटीत दुर्लक्ष केले जाऊ शकते.

सर्वसाधारणपणे, पर्याय 2 थोडा अधिक इष्टतम वाटतो, परंतु तो "क्रांतीऐवजी उत्क्रांती" सारखा आहे. "क्रांती" करण्यासाठी आपल्याला आवश्यक असेल पर्याय 3 (col).
चला सर्वकाही "उलट" करू: आम्ही नियुक्त करू स्तंभ नाव वापरकर्ता आयडी! स्तंभात काय लिहिले जाईल ते यापुढे आमच्यासाठी महत्त्वाचे नाही, तो क्रमांक 1 असू द्या (सर्वसाधारणपणे, उपयुक्त गोष्टी तेथे संग्रहित केल्या जाऊ शकतात, उदाहरणार्थ, "कुटुंब/मित्र/इ." गट). हा दृष्टिकोन अप्रस्तुत "सामान्य माणसाला" आश्चर्यचकित करू शकतो ज्यांना NoSQL डेटाबेससह काम करण्याचा पूर्वीचा अनुभव नाही, परंतु नेमका हाच दृष्टिकोन तुम्हाला या कार्यात HBase ची क्षमता अधिक प्रभावीपणे वापरण्याची परवानगी देतो:

RowKey
स्पीकर्स

वासिया
पेट्या : १
ओल्या : १
दशा: १

पेट्या
माशा: १
वस्य : १

येथे आपल्याला एकाच वेळी अनेक फायदे मिळतात. ते समजून घेण्यासाठी, नवीन संरचनेचे विश्लेषण करू आणि संगणकीय जटिलतेचा अंदाज घेऊ:

• डेटा वाचत आहे: वास्याने ओल्याचे सदस्यत्व घेतले आहे की नाही या प्रश्नाचे उत्तर देण्यासाठी, "ओल्या" हा एक स्तंभ वाचणे पुरेसे आहे: जर ते असेल तर उत्तर खरे आहे, नसल्यास - असत्य => O(1)
• डेटा संपादित करणे: मित्र जोडणे: मित्र जोडणे: फक्त एक नवीन कॉलम जोडा “Friend ID” => O(1)
• डेटा बदलणे: मित्र हटवणे: फक्त Friend ID कॉलम => O(1) काढा

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

डेटाबेसमध्ये प्रवेश करताना कार्यक्षमता ऑप्टिमाइझ करण्याच्या आणि I/O ऑपरेशन्स कमी करण्याच्या मार्गावर तुम्ही गोंधळून जाऊ शकता आणि थोडे पुढे जाऊ शकता. जर आपण संपूर्ण संबंध माहिती थेट रो कीमध्येच संग्रहित केली तर? म्हणजेच userID.friendID सारखी की संमिश्र बनवायची? या प्रकरणात, आम्हाला ओळीचे स्तंभ अजिबात वाचण्याची गरज नाही (पर्याय ४(पंक्ती)):

RowKey
स्पीकर्स

वस्या.पेट्या
पेट्या : १

वस्या.ओल्या
ओल्या : १

वस्या.दशा
दशा: १

पेट्या.माशा
माशा: १

पेट्या.वस्या
वस्य : १

साहजिकच, अशा संरचनेतील सर्व डेटा हाताळणीच्या परिस्थितीचे मूल्यांकन, मागील आवृत्तीप्रमाणे, O(1) असेल. पर्याय 3 मधील फरक केवळ डेटाबेसमधील I/O ऑपरेशन्सच्या कार्यक्षमतेमध्ये असेल.

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

RowKey
स्पीकर्स

dc084ef00e94aef49be885f9b01f51c01918fa783851db0dc1f72f83d33a5994
पेट्या : १

dc084ef00e94aef49be885f9b01f51c0f06b7714b5ba522c3cf51328b66fe28a
ओल्या : १

dc084ef00e94aef49be885f9b01f51c00d2c2e5d69df6b238754f650d56c896a
दशा: १

1918fa783851db0dc1f72f83d33a59949ee3309645bd2c0775899fca14f311e1
माशा: १

1918fa783851db0dc1f72f83d33a5994dc084ef00e94aef49be885f9b01f51c0
वस्य : १

साहजिकच, आम्ही विचार करत असलेल्या परिस्थितींमध्ये अशा संरचनेसह कार्य करण्याची अल्गोरिदमिक जटिलता पर्याय 4 सारखीच असेल - म्हणजेच O(1).
एकूण, एका सारणीमध्ये संगणकीय जटिलतेचे आमचे सर्व अंदाज सारांशित करूया:

मित्र जोडत आहे
मित्राची तपासणी करत आहे
मित्राला काढून टाकत आहे

पर्याय १ (डीफॉल्ट)
O (n)
O (n)
O (n)

पर्याय २ (गणना)
ओ (1)
O (n)
O (n)

पर्याय 3 (स्तंभ)
ओ (1)
ओ (1)
ओ (1)

पर्याय ४ (पंक्ती)
ओ (1)
ओ (1)
ओ (1)

पर्याय 5 (हॅश)
ओ (1)
ओ (1)
ओ (1)

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

प्रयोगाची तयारी

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

• एक नवीन मित्र जोडत आहे
• वापरकर्ता A हा वापरकर्ता B चा मित्र आहे का ते तपासत आहे
• एका मित्राला काढून टाकत आहे

अशाप्रकारे, प्रारंभिक विधानात नमूद केलेल्या आवश्यकता लक्षात घेऊन, पडताळणी परिस्थिती खालीलप्रमाणे उद्भवते:

• डेटा रेकॉर्डिंग. यादृच्छिकपणे आकार n चे प्रारंभिक नेटवर्क तयार करा. “वास्तविक जग” जवळ जाण्यासाठी, प्रत्येक वापरकर्त्याच्या मित्रांची संख्या देखील एक यादृच्छिक चल आहे. आमचा “कंडिशनल ऍप्लिकेशन” सर्व जनरेट केलेला डेटा HBase वर लिहितो तो वेळ मोजा. नंतर परिणामी वेळ जोडलेल्या मित्रांच्या एकूण संख्येने विभाजित करा - अशा प्रकारे आम्हाला एका "व्यवसाय ऑपरेशन" साठी सरासरी वेळ मिळेल.
• डेटा वाचत आहे. प्रत्येक वापरकर्त्यासाठी, "व्यक्तिमत्त्वे" ची एक सूची तयार करा ज्यासाठी वापरकर्त्याने त्यांची सदस्यता घेतली आहे की नाही याचे उत्तर तुम्हाला मिळणे आवश्यक आहे. यादीची लांबी = अंदाजे वापरकर्त्याच्या मित्रांची संख्या, आणि तपासलेल्या मित्रांपैकी अर्ध्यासाठी उत्तर "होय" आणि उरलेल्या अर्ध्यासाठी - "नाही" असे असावे. तपासणी अशा क्रमाने केली जाते की उत्तरे “होय” आणि “नाही” पर्यायी आहेत (म्हणजे प्रत्येक दुसर्‍या प्रकरणात आपल्याला पर्याय 1 आणि 2 साठी ओळीच्या सर्व स्तंभांमधून जावे लागेल). एकूण स्क्रीनिंग वेळ प्रत्येक विषयासाठी सरासरी स्क्रीनिंग वेळ मिळविण्यासाठी चाचणी केलेल्या मित्रांच्या संख्येने विभागला जातो.
• डेटा हटवत आहे. वापरकर्त्याकडून सर्व मित्रांना काढून टाका. शिवाय, हटवण्याचा क्रम यादृच्छिक आहे (म्हणजे, आम्ही डेटा रेकॉर्ड करण्यासाठी वापरली जाणारी मूळ सूची "शफल" करतो). एकूण चेक वेळ नंतर काढलेल्या मित्रांच्या संख्येने भागून प्रत्येक चेकची सरासरी वेळ प्राप्त केली जाते.

प्रत्येक 5 डेटा मॉडेल पर्यायांसाठी आणि सोशल नेटवर्कच्या वेगवेगळ्या आकारांसाठी परिस्थिती कशी वाढते हे पाहण्यासाठी ते चालवणे आवश्यक आहे. एका n मध्ये, नेटवर्कमधील कनेक्शन आणि तपासण्यासाठी वापरकर्त्यांची यादी, अर्थातच, सर्व 5 पर्यायांसाठी समान असणे आवश्यक आहे.
अधिक चांगल्या प्रकारे समजून घेण्यासाठी, खाली n= 5 साठी व्युत्पन्न केलेल्या डेटाचे उदाहरण दिले आहे. लिखित "जनरेटर" आउटपुट म्हणून तीन आयडी शब्दकोश तयार करतो:

• पहिले समाविष्ट करण्यासाठी आहे
• दुसरा तपासण्यासाठी आहे
• तिसरा - हटवण्यासाठी

{0: [1], 1: [4, 5, 3, 2, 1], 2: [1, 2], 3: [2, 4, 1, 5, 3], 4: [2, 1]} # всего 15 друзей

{0: [1, 10800], 1: [5, 10800, 2, 10801, 4, 10802], 2: [1, 10800], 3: [3, 10800, 1, 10801, 5, 10802], 4: [2, 10800]} # всего 18 проверяемых субъектов

{0: [1], 1: [1, 3, 2, 5, 4], 2: [1, 2], 3: [4, 1, 2, 3, 5], 4: [1, 2]} # всего 15 друзей

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

हा प्रयोग Windows 10 वर चालणार्‍या लॅपटॉपवर करण्यात आला, जिथे एका डॉकर कंटेनरमध्ये HBase चालू होते आणि दुसर्‍या कंटेनरमध्ये Jupyter Notebook सह Python चालू होते. डॉकरला 2 CPU कोर आणि 2 GB RAM वाटप करण्यात आली. चाचणी डेटा व्युत्पन्न करण्यासाठी आणि वेळ मोजण्यासाठी “सशर्त अनुप्रयोग” आणि “पाइपिंग” चे अनुकरण यासारखे सर्व तर्क, पायथनमध्ये लिहिले गेले होते. HBase सोबत काम करण्यासाठी लायब्ररीचा वापर करण्यात आला हॅपीबेस, पर्याय 5 साठी हॅश (MD5) ची गणना करण्यासाठी - hashlib

विशिष्ट लॅपटॉपची संगणकीय शक्ती लक्षात घेऊन, n = 10, 30, … साठी लॉन्च प्रायोगिकरित्या निवडले गेले. 170 – जेव्हा पूर्ण चाचणी चक्राचा एकूण कार्यकाळ (सर्व पर्यायांसाठी सर्व परिस्थिती) एका चहाच्या पार्टीदरम्यान (सरासरी 15 मिनिटे) अगदी कमी-अधिक वाजवी आणि योग्य होता.

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

प्रयोग परिणाम

पहिली चाचणी म्हणजे मित्रांची यादी भरण्यात घालवलेला वेळ कसा बदलतो. परिणाम खालील आलेखामध्ये आहे.

पर्याय 3-5, अपेक्षेप्रमाणे, जवळजवळ स्थिर "व्यवसाय व्यवहार" वेळ दर्शवितात, जो नेटवर्क आकाराच्या वाढीवर आणि कार्यप्रदर्शनातील अभेद्य फरकावर अवलंबून नाही.
पर्याय 2 देखील स्थिर, परंतु किंचित वाईट कामगिरी दर्शवतो, पर्याय 2-3 च्या तुलनेत जवळजवळ 5 पट. आणि हे आनंदी होऊ शकत नाही, कारण ते सिद्धांताशी संबंधित आहे - या आवृत्तीमध्ये HBase मधील I/O ऑपरेशन्सची संख्या 2 पट जास्त आहे. हे अप्रत्यक्ष पुरावे म्हणून काम करू शकते की आमची चाचणी खंडपीठ, तत्त्वतः, चांगली अचूकता प्रदान करते.
पर्याय 1 देखील, अपेक्षेप्रमाणे, सर्वात मंद आहे आणि नेटवर्कच्या आकारात एकमेकांना जोडण्यासाठी घालवलेल्या वेळेत एक रेषीय वाढ दर्शवतो.
आता दुसऱ्या परीक्षेचा निकाल पाहू.

पर्याय 3-5 पुन्हा अपेक्षेप्रमाणे वागतात - सतत वेळ, नेटवर्कच्या आकारापेक्षा स्वतंत्र. पर्याय 1 आणि 2 नेटवर्क आकार आणि समान कार्यप्रदर्शन म्हणून वेळेत एक रेषीय वाढ दर्शवतात. शिवाय, पर्याय 2 थोडा हळू निघतो - वरवर पाहता अतिरिक्त "गणना" स्तंभाचे प्रूफरीड आणि प्रक्रिया करण्याच्या गरजेमुळे, जे n वाढते तसे अधिक लक्षणीय होते. पण तरीही मी कोणतेही निष्कर्ष काढण्यापासून परावृत्त करेन, कारण या तुलनेची अचूकता तुलनेने कमी आहे. याव्यतिरिक्त, हे गुणोत्तर (कोणता पर्याय, 1 किंवा 2, वेगवान आहे) रन मधून रनमध्ये बदलले (अवलंबित्वाचे स्वरूप आणि "मान आणि मान" राखत असताना).

बरं, शेवटचा आलेख काढण्याच्या चाचणीचा परिणाम आहे.

पुन्हा, येथे कोणतेही आश्चर्य नाही. पर्याय 3-5 सतत वेळेत काढण्याचे कार्य करतात.
शिवाय, मनोरंजकपणे, मागील परिस्थितींप्रमाणे पर्याय 4 आणि 5, पर्याय 3 पेक्षा लक्षणीयरीत्या किंचित खराब कामगिरी दर्शवतात. वरवर पाहता, स्तंभ हटविण्याच्या ऑपरेशनपेक्षा पंक्ती हटविण्याचे ऑपरेशन अधिक महाग आहे, जे सामान्यतः तर्कसंगत आहे.

पर्याय 1 आणि 2, अपेक्षेप्रमाणे, वेळेत एक रेषीय वाढ दर्शवतात. त्याच वेळी, पर्याय 2 हा पर्याय 1 पेक्षा सातत्याने धीमा आहे - काउंट कॉलम "देखभाल" करण्यासाठी अतिरिक्त I/O ऑपरेशनमुळे.

प्रयोगाचे सामान्य निष्कर्ष:

• पर्याय 3-5 अधिक कार्यक्षमता दाखवतात कारण ते HBase चा लाभ घेतात; शिवाय, त्यांचे कार्यप्रदर्शन एकमेकांच्या तुलनेत स्थिरतेनुसार भिन्न असते आणि नेटवर्कच्या आकारावर अवलंबून नसते.
• पर्याय 4 आणि 5 मधील फरक नोंदवला गेला नाही. परंतु याचा अर्थ असा नाही की पर्याय 5 वापरला जाऊ नये. चाचणी खंडपीठाच्या कार्यक्षमतेची वैशिष्ट्ये लक्षात घेऊन वापरलेल्या प्रायोगिक परिस्थितीने ते शोधू दिले नाही अशी शक्यता आहे.
• डेटासह "व्यवसाय ऑपरेशन्स" करण्यासाठी आवश्यक असलेल्या वेळेतील वाढीचे स्वरूप सामान्यतः सर्व पर्यायांसाठी पूर्वी प्राप्त केलेल्या सैद्धांतिक गणनांची पुष्टी करते.

एपिलोग

केलेले ढोबळ प्रयोग हे पूर्ण सत्य मानू नयेत. असे बरेच घटक आहेत जे विचारात घेतले गेले नाहीत आणि परिणाम विकृत केले (हे चढउतार विशेषतः लहान नेटवर्क आकारासह आलेखामध्ये दृश्यमान आहेत). उदाहरणार्थ, काटकसरीचा वेग, जो हॅपीबेसद्वारे वापरला जातो, मी पायथनमध्ये लिहिलेले तर्कशास्त्र लागू करण्याची मात्रा आणि पद्धत (मी असा दावा करू शकत नाही की कोड सर्व घटकांच्या क्षमतांचा वापर चांगल्या आणि प्रभावीपणे केला गेला आहे), कदाचित HBase कॅशिंगची वैशिष्ट्ये, माझ्या लॅपटॉपवरील Windows 10 ची पार्श्वभूमी क्रियाकलाप इ. सर्वसाधारणपणे, आम्ही असे गृहीत धरू शकतो की सर्व सैद्धांतिक गणनांनी प्रायोगिकपणे त्यांची वैधता दर्शविली आहे. बरं, किंवा कमीतकमी अशा "हेड-ऑन अटॅक" सह त्यांचे खंडन करणे शक्य नव्हते.

शेवटी, HBase मध्ये डेटा मॉडेल डिझाइन करण्यास सुरुवात करणाऱ्या प्रत्येकासाठी शिफारसी: रिलेशनल डेटाबेससह काम करण्याच्या मागील अनुभवाचा सारांश आणि "आदेश" लक्षात ठेवा:

• डिझाइन करताना, आम्ही डोमेन मॉडेलवरून नव्हे तर डेटा मॅनिपुलेशनच्या कार्य आणि नमुन्यांपासून पुढे जातो
• कार्यक्षम प्रवेश (संपूर्ण टेबल स्कॅनशिवाय) – फक्त की द्वारे
• सामान्यीकरण
• वेगवेगळ्या पंक्तींमध्ये वेगवेगळे स्तंभ असू शकतात
• स्पीकर्सची डायनॅमिक रचना

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