डेटाबेस बैकएंड के रूप में git रिपॉजिटरी का उपयोग करना

Question

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

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

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

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

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

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

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

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

Comments

कृपया youtube.com/watch?v=nPPlyjMlQ34

— Assaf S.

Answer 1

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

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

• "ब्लंट" दृष्टिकोण: 1 उपयोगकर्ता = 1 राज्य = 1 रिपॉजिटरी की पूरी कार्यशील प्रतिलिपि जो सर्वर उपयोगकर्ता के लिए रखता है। यहां तक ​​कि अगर हम उपयोगकर्ताओं के ~ 100K के साथ काफी छोटे दस्तावेज़ डेटाबेस (उदाहरण के लिए, 100s MiB) के बारे में बात कर रहे हैं, तो उन सभी के लिए पूर्ण रिपॉजिटरी क्लोन बनाए रखने से डिस्क उपयोग छत के माध्यम से होता है (यानी 100KiB के उपयोगकर्ताओं की 100KB / 10 TiB) । क्या और भी बुरा है, हर बार 100 MiB रिपॉजिटरी की क्लोनिंग करने में कई सेकंड का समय लगता है, भले ही वह काफी प्रभावी मैनर में किया गया हो (जैसे कि git और अनपैकिंग-रिपैकिंग सामान द्वारा उपयोग नहीं किया गया), जो कि गैर स्वीकार्य है, IMO। और इससे भी बदतर - प्रत्येक संपादित जो हम एक मुख्य पेड़ पर लागू करते हैं, उसे प्रत्येक उपयोगकर्ता के भंडार पर खींचा जाना चाहिए, जो (1) संसाधन हॉग है, (2) सामान्य मामले में अनसुलझे संपादन संघर्ष का कारण बन सकता है।

  मूल रूप से, यह डिस्क उपयोग के संदर्भ में ओ (संपादन × डेटा × उपयोगकर्ताओं की संख्या) जितना ही खराब हो सकता है, और इस तरह के डिस्क उपयोग का स्वचालित रूप से बहुत उच्च सीपीयू उपयोग होता है।

• "केवल सक्रिय उपयोगकर्ता" दृष्टिकोण: केवल सक्रिय उपयोगकर्ताओं के लिए काम की प्रतिलिपि बनाए रखें। इस तरह, आप आम तौर पर पूर्ण-प्रति-क्लोन-प्रति-उपयोगकर्ता संग्रहीत नहीं करते हैं, लेकिन:

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

  इस प्रकार, इस मामले में डिस्क का उपयोग O पर चोटियों (सक्रिय उपयोगकर्ताओं की संख्या × डेटा × संख्या) है, जो आमतौर पर कुल उपयोगकर्ताओं की संख्या की तुलना में ~ 100..1000 गुना कम है, लेकिन यह लॉग इन / आउट अधिक जटिल और धीमी बनाता है , क्योंकि इसमें हर लॉगिन पर एक प्रति-उपयोगकर्ता शाखा का क्लोनिंग शामिल है और लॉगआउट या सत्र समाप्ति (जो कि ट्रांसेक्शनल => जटिलता की एक और परत जोड़ता है) पर इन परिवर्तनों को वापस खींचना चाहिए। पूर्ण संख्या में, यह मेरे मामले में 10..100 GiBs तक डिस्क उपयोग के 10 TiBs को गिराता है, जो स्वीकार्य हो सकता है, लेकिन, फिर भी, अब हम 100 MiBs के काफी छोटे डेटाबेस के बारे में बात कर रहे हैं ।

• "स्पार्स चेकआउट" दृष्टिकोण: सक्रिय उपयोगकर्ता प्रति पूर्ण-विकसित रेपो क्लोन के बजाय "स्पार्स चेकआउट" बनाना बहुत मदद नहीं करता है। यह डिस्क स्पेस उपयोग के ~ 10x को बचा सकता है, लेकिन इतिहास से जुड़े संचालन पर बहुत अधिक सीपीयू / डिस्क लोड की कीमत पर, जो उद्देश्य को मारता है।

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

उस ने कहा, ध्यान दें कि मैंने जानबूझकर काफी छोटे डेटाबेस और उपयोगकर्ता आधार की संख्या की गणना की: 100K उपयोगकर्ता, 1K सक्रिय उपयोगकर्ता, 100 MiBs कुल डेटाबेस + संपादन का इतिहास, 10 MiBs की कार्यशील प्रतिलिपि। यदि आप अधिक प्रमुख क्राउड-सोर्सिंग परियोजनाओं को देखेंगे, तो वहां बहुत अधिक संख्या में हैं:

│              │ Users │ Active users │ DB+edits │ DB only │
├──────────────┼───────┼──────────────┼──────────┼─────────┤
│ MusicBrainz  │  1.2M │     1K/week  │   30 GiB │  20 GiB │
│ en.wikipedia │ 21.5M │   133K/month │    3 TiB │  44 GiB │
│ OSM          │  1.7M │    21K/month │  726 GiB │ 480 GiB │

जाहिर है, डेटा / गतिविधि की मात्रा के लिए, यह दृष्टिकोण पूरी तरह से अस्वीकार्य होगा।

आमतौर पर, यह काम किया होता, अगर कोई वेब ब्राउज़र को "मोटी" क्लाइंट के रूप में उपयोग कर सकता है, अर्थात गिट संचालन जारी करना और क्लाइंट की तरफ से पूरी तरह से चेकआउट करना, सर्वर के पक्ष में नहीं।

अन्य बिंदु भी हैं जिन्हें मैंने याद किया है, लेकिन वे पहले वाले की तुलना में खराब नहीं हैं:

• "मोटी" उपयोगकर्ता के संपादन की स्थिति का बहुत ही पैटर्न सामान्य ORM के संदर्भ में विवादास्पद है, जैसे कि ActiveRecord, Hibernate, DataMapper, Tower, आदि।
• जितना मैंने खोजा है, लोकप्रिय फ्रेमवर्क से उस दृष्टिकोण को करने के लिए शून्य मौजूदा मुफ्त कोडबेस है।
• कम से कम एक सेवा है जो किसी भी तरह से उस कुशलता से करने का प्रबंधन करती है - वह स्पष्ट रूप से गिटब है - लेकिन, अफसोस, उनका कोडबेस बंद स्रोत है और मुझे दृढ़ता से संदेह है कि वे अंदर सामान्य git सर्वर / रेपो स्टोरेज तकनीकों का उपयोग नहीं करते हैं, अर्थात मूल रूप से कार्यान्वित वैकल्पिक "बड़ा डेटा" गिट।

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

Comments

शायद पार्टी के लिए थोड़ा देर हो गई, लेकिन मुझे इसके लिए एक समान आवश्यकता थी और वास्तव में गिट-रूट से नीचे चला गया। गिट इंटर्नल्स के साथ कुछ खुदाई के बाद, मुझे इसे काम करने का एक तरीका मिला। विचार एक नंगे भंडार के साथ काम करना है। कुछ कमियां हैं, लेकिन मुझे यह काम करने योग्य लगता है। मैंने एक पोस्ट में सब कुछ लिखा है जिसे आप जांचना चाहते हैं (यदि कुछ भी, ब्याज के लिए) कर सकते हैं: kenneth-truyers.net/2016/10/10/13/git-nosql-database

— केनेथ

मेरे लिए ऐसा नहीं करने का एक अन्य कारण क्वेरी क्षमताएं हैं। दस्तावेज़ भंडार अक्सर दस्तावेज़ों को अनुक्रमित करते हैं, जिससे उनके भीतर खोज करना आसान हो जाता है। यह सीधे गिट के साथ नहीं होगा।

— फ्रेंकहॉलिवुड

Answer 2

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

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

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

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

Answer 3

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

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

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

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

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

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

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

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

ऊपर कॉकटेल की, यहाँ मैं वर्तमान में शराब पी रहा हूँ

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

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

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

Answer 4

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

प्रलेखन में प्रदर्शन, ट्रेडऑफ़ आदि के बारे में कुछ विचार शामिल हैं।

Answer 5

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

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

ट्रिक Git के GIT_INDEX_FILEपर्यावरण वैरिएबल को संयोजित करने के लिए टूल के साथ है जिससे Git मैन्युअल रूप से बनाता है:

• git हैश-ऑब्जेक्ट
• git अपडेट-इंडेक्स
• git लिखना-पेड़
• कमिट-ट्री

एक समाधान की रूपरेखा इस प्रकार है (वास्तविक 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लेकिन संघर्ष का समाधान यकीनन यहां सबसे कठिन हिस्सा है।

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

Comments

यह आम तौर पर एक दृष्टिकोण है जो कहीं नहीं जाता है, जब तक कि आप मैन्युअल संघर्ष समाधान के लिए लेनदेन और यूआई की पूर्ण विकसित अवधारणा नहीं चाहते हैं। संघर्षों के लिए सामान्य विचार यह है कि उपयोगकर्ता इसे सही तरीके से हल करने के लिए (यानी "क्षमा करें, आपके द्वारा संपादित किए जा रहे दस्तावेज़ को किसी और व्यक्ति ने संपादित किया है -> कृपया उसके संपादन और आपके संपादन देखें और उन्हें मर्ज करें")। जब आप दो उपयोगकर्ताओं को सफलतापूर्वक करने की अनुमति देते हैं और फिर एक async cronjob में पता लगाते हैं कि चीजें दक्षिण में चली गईं, तो सामान को हल करने के लिए आम तौर पर कोई भी उपलब्ध नहीं है।

— ग्राकेट ऑक्ट