database - डेटाबेस बैकएंड के रूप में गिट भंडार का उपयोग करना




git database-performance (4)

मैं एक प्रोजेक्ट कर रहा हूं जो संरचित दस्तावेज़ डेटाबेस से संबंधित है। मेरे पास श्रेणियों का एक पेड़ है (~ 1000 श्रेणियां, प्रत्येक स्तर पर ~ 50 श्रेणियों तक), प्रत्येक श्रेणी में संरचित दस्तावेज़ों के कई हजार (ऊपर, कहने, ~ 10000) शामिल हैं। प्रत्येक दस्तावेज़ कुछ संरचित रूप में डेटा के कई किलोबाइट्स है (मैं वाईएएमएल पसंद करूंगा, लेकिन यह जेएसओएन या एक्सएमएल भी हो सकता है)।

इस प्रणाली के उपयोगकर्ता कई प्रकार के संचालन करते हैं:

  • आईडी द्वारा इन दस्तावेजों को पुनः प्राप्त करना
  • उनके अंदर कुछ संरचित विशेषताओं द्वारा दस्तावेजों की खोज
  • संपादन दस्तावेज़ (यानी जोड़ना / निकालना / नामकरण / विलय करना); प्रत्येक संपादन ऑपरेशन को कुछ टिप्पणी के साथ एक लेनदेन के रूप में दर्ज किया जाना चाहिए
  • विशेष दस्तावेज के लिए दर्ज किए गए परिवर्तनों का इतिहास देखना (जिसमें यह देखना शामिल है कि दस्तावेज किसने, कब और क्यों बदल दिया, पहले संस्करण प्राप्त करना - और अनुरोध किए जाने पर शायद इस पर वापस लौटना)

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

पहली नज़र में, इसे हल किया जा सकता है:

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

क्या इस समाधान में कोई अन्य आम समस्या है? क्या किसी ने पहले से ही इस तरह के बैकएंड को लागू करने की कोशिश की है (यानी किसी भी लोकप्रिय ढांचे के लिए - RoR, node.js, Django, केकेपीएचपी)? क्या इस समाधान के प्रदर्शन या विश्वसनीयता पर कोई संभावित प्रभाव पड़ता है - यानी यह साबित हुआ है कि पारंपरिक डाटाबेस समाधान से गिट बहुत धीमी होगी या कोई स्केलेबिलिटी / विश्वसनीयता नुकसान होगा? मुझे लगता है कि ऐसे सर्वरों का समूह जो एक दूसरे के भंडार को धक्का / खींचता है वह काफी मजबूत और भरोसेमंद होना चाहिए।

असल में, मुझे बताएं कि क्या यह समाधान काम करेगा और यह क्यों करेगा या नहीं करेगा?


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

  • अलग-अलग काम करने वाली प्रतियों की आवश्यकता नहीं है (डिस्क उपयोग बदली गई फाइलों तक सीमित है)
  • समय लेने वाली प्रारंभिक कार्य (प्रति उपयोगकर्ता सत्र) की कोई ज़रूरत नहीं है

चाल गिट के GIT_INDEX_FILE पर्यावरणीय चर को गठबंधन बनाने के लिए उपकरण के साथ गठबंधन करने के लिए है:

एक समाधान रूपरेखा निम्नानुसार है (वास्तविक SHA1 हैश आदेश से छोड़े गए हैं):

# Initialize the index
# N.B. Use the commit hash since refs might changed during the session.
$ GIT_INDEX_FILE=user_index_file git reset --hard <starting_commit_hash>

#
# Change data and save it to `changed_file`
#

# Save changed data to the Git object database. Returns a SHA1 hash to the blob.
$ cat changed_file | git hash-object -t blob -w --stdin
da39a3ee5e6b4b0d3255bfef95601890afd80709

# Add the changed file (using the object hash) to the user-specific index
# N.B. When adding new files, --add is required
$ GIT_INDEX_FILE=user_index_file git update-index --cacheinfo 100644 <changed_data_hash> path/to/the/changed_file

# Write the index to the object db. Returns a SHA1 hash to the tree object
$ GIT_INDEX_FILE=user_index_file git write-tree
8ea32f8432d9d4fa9f9b2b602ec7ee6c90aa2d53

# Create a commit from the tree. Returns a SHA1 hash to the commit object
# N.B. Parent commit should the same commit as in the first phase.
$ echo "User X updated their data" | git commit-tree <new_tree_hash> -p <starting_commit_hash>
3f8c225835e64314f5da40e6a568ff894886b952

# Create a ref to the new commit
git update-ref refs/heads/users/user_x_change_y <new_commit_hash>

आपके डेटा के आधार पर आप master को नए रेफर्स को मर्ज करने के लिए क्रॉन जॉब का उपयोग कर सकते हैं लेकिन संघर्ष समाधान तर्कसंगत रूप से सबसे कठिन हिस्सा है।

इसे आसान बनाने के विचार स्वागत हैं।


मेरे 2 पेन्स लायक थोड़ी देर लग रही है लेकिन ...... मेरी ऊष्मायन परियोजनाओं में से एक में मुझे भी इसी तरह की आवश्यकता थी। आपके समान, मेरी मुख्य आवश्यकताएं जहां दस्तावेज़ डेटाबेस के साथ एक दस्तावेज़ डेटाबेस (मेरे मामले में xml)। यह एक बहु-उपयोगकर्ता प्रणाली के लिए बहुत सहयोगी उपयोग मामलों के साथ था। मेरी वरीयता उपलब्ध ओपनसोर्स समाधानों का उपयोग करना था जो अधिकांश प्रमुख आवश्यकताओं का समर्थन करते थे।

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

अभी भी प्रगति पर काम करते हैं (... और थोड़ा उपेक्षित) morphed संस्करण बस यह है।

  • अग्रभाग पर: (userfacing) पहले स्तर के भंडारण के लिए डेटाबेस का उपयोग करें (उपयोगकर्ता अनुप्रयोगों के साथ इंटरफेसिंग)
  • बैकएंड पर, डेटाबेस में डेटा ऑब्जेक्ट्स के वर्जनिंग करने के लिए वर्जन कंट्रोल सिस्टम (वीसीएस) (जैसे गिट) का उपयोग करें

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

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

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

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

उपरोक्त कॉकटेल में, यह वही है जो मैं वर्तमान में बना रहा हूं

  • वीसीएस के लिए गिट का उपयोग करना (प्रारंभ में केवल पुराने संस्करणों के उपयोग के कारण अच्छे पुराने सीवीएस माना जाता है या 2 संस्करण के बीच डेल्टा)
  • mysql का उपयोग (मेरे डेटा की अत्यधिक संरचित प्रकृति के कारण, सख्त एक्सएमएल स्कीमा के साथ एक्सएमएल)
  • MongoDB के साथ घूमना (नोएसक्यूएल डेटाबेस का प्रयास करने के लिए, जो गिट में उपयोग की जाने वाली देशी डेटाबेस संरचना से निकटता से मेल खाता है)

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

यदि आपको यह अभी तक मिल गया है, तो मुझे उपरोक्त आपके मामले पर लागू हो सकता है, और यह मानते हुए कि यह आपके पिछले व्यापक प्रदर्शन विश्लेषण में कुछ पहलू तक कैसे पहुंच जाएगा


मैंने libgit2 शीर्ष पर रूबी लाइब्रेरी लागू की जो इसे लागू करने और अन्वेषण करने में बहुत आसान बनाता है। कुछ स्पष्ट सीमाएं हैं, लेकिन यह एक बहुत ही मुक्त प्रणाली है क्योंकि आपको पूर्ण गिट टूलचेन मिलता है।

दस्तावेज़ीकरण में प्रदर्शन, ट्रेडऑफ इत्यादि के बारे में कुछ विचार शामिल हैं।


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

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

1) आपने "सर्वरों के क्लस्टर का उल्लेख किया जो एक-दूसरे को धक्का / खींचते हैं" - मैंने थोड़ी देर के लिए इसके बारे में सोचा है और फिर भी मुझे यकीन नहीं है। आप एक परमाणु ऑपरेशन के रूप में कई repos धक्का / खींच नहीं सकते हैं। मुझे आश्चर्य है कि समवर्ती काम के दौरान कुछ विलय गड़बड़ी की संभावना हो सकती है।

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





document-database