গিট সংগ্রহস্থলটিকে ডাটাবেস ব্যাকএন্ড হিসাবে ব্যবহার করা হচ্ছে

Question

আমি এমন একটি প্রকল্প করছি যা স্ট্রাকচার্ড ডকুমেন্ট ডাটাবেস নিয়ে কাজ করে। আমার ক্যাটাগরিগুলির একটি গাছ রয়েছে (categories 1000 বিভাগ, প্রতিটি স্তরের) 50 বিভাগ পর্যন্ত), প্রতিটি বিভাগে কাঠামোযুক্ত নথিগুলির কয়েক হাজার (পর্যন্ত, বলতে গেলে ~ 10000) থাকে। প্রতিটি নথি হ'ল কিছু কাঠামোবদ্ধ আকারে কয়েক কিলোবাইট ডেটা (আমি YAML পছন্দ করতাম তবে এটি জেএসএন বা এক্সএমএলও হতে পারে)।

এই সিস্টেমগুলির ব্যবহারকারীরা বিভিন্ন ধরণের অপারেশন করেন:

• আইডি দ্বারা এই নথি পুনরুদ্ধার করা
• তাদের মধ্যে কিছু কাঠামোগত বৈশিষ্ট্য দ্বারা নথিগুলি অনুসন্ধান করা
• দলিল সম্পাদনা (যেমন যোগ / অপসারণ / নতুন নামকরণ / মার্জ করা); প্রতিটি সম্পাদনা অপারেশন কিছু মন্তব্য সঙ্গে একটি লেনদেন হিসাবে রেকর্ড করা উচিত
• নির্দিষ্ট ডকুমেন্টের জন্য রেকর্ডকৃত পরিবর্তনের ইতিহাস দেখা (ডকুমেন্টটি কবে, কখন এবং কেন বদলেছে, পূর্ববর্তী সংস্করণটি সহ - এবং সম্ভবত অনুরোধ করা হলে এটিতে আবার ফিরে যাওয়া সহ)

অবশ্যই, traditionalতিহ্যগত সমাধানটি এই সমস্যার জন্য কিছু প্রকারের ডকুমেন্ট ডেটাবেস (যেমন কাউচডিবি বা মঙ্গো) ব্যবহার করবে - তবে, এই সংস্করণ নিয়ন্ত্রণ (ইতিহাস) জিনিসটি আমাকে বুনো ধারণা সম্পর্কে প্ররোচিত করেছিল - কেন আমি gitসংগ্রহস্থলটিকে একটি হিসাবে ব্যবহার করব না? এই অ্যাপ্লিকেশনটির জন্য ডাটাবেস ব্যাকএন্ড?

প্রথম নজরে, এটি এর মতো সমাধান করা যেতে পারে:

• বিভাগ = ডিরেক্টরি, নথি = ফাইল
• আইডি => ডিরেক্টরি পরিবর্তন করে + একটি ওয়ার্কিং কপির একটি ফাইল পড়ার দ্বারা নথি পাওয়া যাচ্ছে
• সম্পাদনা মন্তব্য সহ দস্তাবেজগুলি সম্পাদনা করা => বিভিন্ন ব্যবহারকারী দ্বারা কমিট করা + কমিট বার্তা সংরক্ষণ করে st
• ইতিহাস => সাধারণ গিট লগ এবং পুরানো লেনদেনের পুনরুদ্ধার
• অনুসন্ধান => এটি সামান্য কৌশলযুক্ত অংশ, আমি অনুমান করি যে এটির জন্য কলামগুলির সূচীকরণের সাথে সম্পর্কিত ডেটাবেজে কোনও বিভাগের পর্যায়ক্রমিক রফতানি প্রয়োজন যা আমরা অনুসন্ধানের অনুমতি দেব

এই সমাধানে অন্য কোনও সাধারণ সমস্যা আছে? কেউ কি ইতিমধ্যে এই জাতীয় ব্যাকএন্ড বাস্তবায়নের চেষ্টা করেছেন (অর্থাত্ কোনও জনপ্রিয় ফ্রেমওয়ার্কের জন্য - আরআর, নোড.জেএস, জাজানো, কেকপিএইচপি)? এই সমাধানটির কার্য সম্পাদন বা নির্ভরযোগ্যতার উপর কোনও সম্ভাব্য প্রভাব রয়েছে - অর্থাত্ এটি কি প্রমাণিত যে গিটটি প্রচলিত ডাটাবেস সমাধানগুলির চেয়ে অনেক ধীর গতিতে বা কোনও স্কেলিবিলিটি / নির্ভরযোগ্যতার ক্ষতি হতে পারে? আমি অনুমান করি যে এই জাতীয় সার্ভারগুলির একটি ক্লাস্টার যা একে অপরের সংগ্রহস্থলকে ধাক্কা দেয় / টান দেয় তা মোটামুটি দৃust় এবং নির্ভরযোগ্য হতে হবে।

মূলত, আমাকে বলুন যে এই সমাধানটি কার্যকর হবে এবং কেন এটি করবে বা করবে না?

Comments

দয়া করে youtube.com/watch?v=nPPlyjMlQ34 দেখুন

— Assaf এস

Answer 1

আমার নিজের প্রশ্নের উত্তর দেওয়া সবচেয়ে ভাল কাজ নয়, তবে শেষ পর্যন্ত আমি যে ধারণাটি ফেলেছি, আমি আমার ক্ষেত্রে যে যুক্তি দিয়ে কাজ করেছি তার সাথে ভাগ করে নিতে চাই। আমি জোর দিয়ে বলতে চাই যে এই যুক্তিটি সব ক্ষেত্রেই প্রযোজ্য নয়, তাই স্থির করার সিদ্ধান্ত নেওয়ার পক্ষে।

সাধারণত, আমার প্রথম প্রশ্নটি যে প্রশ্নটি মিস করে তা হ'ল আমি বহু-ব্যবহারকারী সিস্টেমের সাথে কাজ করছি যা সমান্তরালভাবে কাজ করে, একই সাথে আমার সার্ভারটি একটি পাতলা ক্লায়েন্টের সাথে ব্যবহার করে (অর্থাত্ কেবল একটি ওয়েব ব্রাউজার)। এইভাবে, আমি তাদের সকলের জন্য রাষ্ট্র বজায় রাখতে হবে। এর একাধিক পদ্ধতি রয়েছে তবে এগুলির সবগুলিই সংস্থানসমূহের পক্ষে খুব শক্ত বা বাস্তবায়নের পক্ষে খুব জটিল (এবং এইভাবে প্রথমে গিটে দেওয়ার জন্য সমস্ত কঠোর বাস্তবায়ন সামগ্রী লোড করার মূল উদ্দেশ্যটি হত্যা করুন):

• "ধোঁয়া" দৃষ্টিভঙ্গি: 1 ব্যবহারকারী = 1 রাজ্য = 1 সার্ভার ব্যবহারকারীর জন্য রক্ষণাবেক্ষণের একটি সম্পূর্ণ কার্য কপি। এমনকি যদি আমরা small 100K ব্যবহারকারীদের সাথে মোটামুটি ছোট ডকুমেন্ট ডাটাবেস (উদাহরণস্বরূপ, 100s MiBs) সম্পর্কে কথা বলি, তাদের সকলের জন্য সম্পূর্ণ সংগ্রহস্থল ক্লোন বজায় রাখা ডিস্কের ব্যবহারটি ছাদ দিয়ে চালিত করে (যেমন ব্যবহারকারীদের 100Mi ~ 10 TiB এর 100K) । সবচেয়ে খারাপ বিষয়, প্রতিবার 100 টি এমআইবি সংগ্রহস্থলটির ক্লোনিং করতে বেশ কয়েক সেকেন্ড সময় লাগে, এমনকি মোটামুটি কার্যকর মনিয়ারে করা হয় (যেমন গিট এবং আনপ্যাকিং-রিপ্যাকিং স্টাফ ব্যবহার না করা), এটি গ্রহণযোগ্য নয়, আইএমও। এবং আরও খারাপ - প্রতিটি মূল সম্পাদনা যা আমরা একটি প্রধান গাছের সাথে প্রয়োগ করি তা প্রতিটি ব্যবহারকারীর ভান্ডারে টানা উচিত, যা (1) রিসোর্স হোগ, (2) সাধারণ ক্ষেত্রে সমাধান না হওয়া সমস্যার সমাধান করতে পারে।

  মূলত, ডিস্ক ব্যবহারের ক্ষেত্রে এটি ও (সম্পাদনার সংখ্যা × ডেটা users ব্যবহারকারীর সংখ্যা) এর মতো খারাপ হতে পারে এবং এই জাতীয় ডিস্ক ব্যবহারের অর্থ স্বয়ংক্রিয়ভাবে বেশ উচ্চ সিপিইউ ব্যবহার।

• "শুধুমাত্র সক্রিয় ব্যবহারকারী" পদ্ধতির: কেবল সক্রিয় ব্যবহারকারীদের জন্য কাজের অনুলিপি বজায় রাখুন। এইভাবে, আপনি সাধারণত কোনও ব্যবহারকারী হিসাবে একটি সম্পূর্ণ-রেপো-ক্লোন-না সঞ্চয় করেন তবে:

  • ব্যবহারকারী লগ ইন হিসাবে, আপনি সংগ্রহস্থল ক্লোন। এটি সক্রিয় ব্যবহারকারীর জন্য বেশ কয়েক সেকেন্ড এবং ডিস্ক স্পেসের 100 ডলার takes
  • ব্যবহারকারী যেমন সাইটে কাজ চালিয়ে যাচ্ছেন, তিনি প্রদত্ত ওয়ার্কিং কপির সাথে কাজ করেন।
  • ব্যবহারকারী লগ আউট করার সাথে সাথে তার সংগ্রহস্থল ক্লোনটি আবার প্রধান ভান্ডারে একটি শাখা হিসাবে অনুলিপি করা হয়, সুতরাং কেবল তার "প্রয়োগহীন পরিবর্তনগুলি" সংরক্ষণ করা হয়, যদি সেখানে কিছু থাকে যা মোটামুটি স্থান-দক্ষ।

  সুতরাং, এক্ষেত্রে ডিস্ক ব্যবহারের ফলে ও (শীর্ষস্থানীয় সম্পাদকের সংখ্যা × ডেটা active সক্রিয় ব্যবহারকারীর সংখ্যা) শীর্ষে রয়েছে যা মোট ব্যবহারকারীদের সংখ্যার তুলনায় সাধারণত ~ 100..1000 গুণ কম, তবে এটি লগ ইন / আউটটিকে আরও জটিল এবং ধীর করে তোলে makes যেমন এটি প্রতিটি লগইনে প্রতি ব্যবহারকারী শাখার ক্লোনিং করা এবং লগআউট বা সেশনের মেয়াদ শেষ হওয়ার পরে এই পরিবর্তনগুলি ফিরিয়ে আনার সাথে জড়িত (যা লেনদেনের মাধ্যমে করা উচিত => জটিলতার আরও একটি স্তর যুক্ত করে)। নিরঙ্কুশ সংখ্যায়, এটি আমার ক্ষেত্রে 10 টিআইবি ডিস্ক ব্যবহারের নিচে নেমে 10.100 গিগাবাইট, এটি গ্রহণযোগ্য হতে পারে, তবে, আবার, আমরা এখন 100 এমআইবি মোটামুটি ছোট ডাটাবেস সম্পর্কে কথা বলছি ।

• "স্পার্স চেকআউট" পদ্ধতির: সক্রিয় ব্যবহারকারীর প্রতি পূর্ণ-বর্ধিত রেপো ক্লোনটির পরিবর্তে "স্পার্স চেকআউট" তৈরি করা খুব বেশি সহায়তা করে না। এটি ডিস্ক স্পেসের ব্যবহারের 10x ডলার সাশ্রয় করতে পারে, তবে ইতিহাসের সাথে জড়িত ক্রিয়াকলাপগুলিতে অনেক বেশি সিপিইউ / ডিস্ক লোড ব্যয় করে, কোন ধরণের উদ্দেশ্যকে হত্যা করে।

• "শ্রমিক পুল" পদ্ধতির: সক্রিয় ব্যক্তির জন্য প্রতিবার পূর্ণ-বিকাশযুক্ত ক্লোনগুলি করার পরিবর্তে, আমরা "শ্রমিক" ক্লোনগুলির একটি পুল রাখতে পারি, এটি ব্যবহারের জন্য প্রস্তুত। এইভাবে, যখনই ব্যবহারকারীগণ লগ ইন করেন, তখন তিনি একজন "কর্মী" দখল করেন, সেখানে তার মূল শাখাটি তার শাখাটি টেনে আনেন এবং লগ আউট করার সাথে সাথে তিনি "কর্মী" কে মুক্তি দেন, যা চালাক গিট হার্ড রিসেট করে আবার ঠিক হয়ে যায় to একটি প্রধান রেপো ক্লোন, অন্য কোনও ব্যবহারকারী লগ ইন করার জন্য প্রস্তুত disc আরও জটিলতা।

এটি বলেছিলেন, নোট করুন যে আমি ইচ্ছাকৃতভাবে মোট ছোট ছোট ডাটাবেস এবং ব্যবহারকারীর সংখ্যা গণনা করেছি: 100 কে ব্যবহারকারী, 1 কে সক্রিয় ব্যবহারকারী, 100 এমআইবি সম্পূর্ণ ডাটাবেস + সম্পাদনার ইতিহাস, 10 টি এমআইবি ওয়ার্কিং কপি। আপনি যদি আরও বিশিষ্ট ভিড়-উত্সাহী প্রকল্পগুলি দেখতে চান তবে সেখানে অনেক বেশি সংখ্যক সংখ্যা রয়েছে:

│              │ 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 │

স্পষ্টতই, পরিমাণে ডেটা / ক্রিয়াকলাপের জন্য, এই পদ্ধতিকে সম্পূর্ণ অগ্রহণযোগ্য হবে।

সাধারণত, এটি কাজ করত, যদি কেউ "ঘন" ক্লায়েন্ট হিসাবে ওয়েব ব্রাউজার ব্যবহার করতে পারে, যেমন গিট অপারেশন জারি করে এবং সার্ভারের পাশে নয়, ক্লায়েন্টের পক্ষে পুরোপুরি পুরো চেকআউট সংরক্ষণ করে।

এছাড়াও অন্যান্য পয়েন্টগুলি আমি মিস করেছি, তবে প্রথমটির তুলনায় এগুলি খুব খারাপ নয়:

• "ঘন" ব্যবহারকারীর সম্পাদনার স্থিতিটি সাধারণত ওআরএম, যেমন অ্যাক্টিভেকর্ড, হাইবারনেট, ডেটা ম্যাপার, টাওয়ার ইত্যাদির ক্ষেত্রে বিতর্কিত is
• আমি যতটা অনুসন্ধান করেছি, জনপ্রিয় ফ্রেমওয়ার্ক থেকে গিটের জন্য এই পদ্ধতির জন্য শূন্য বিদ্যমান ফ্রি কোডবেস রয়েছে।
• কমপক্ষে একটি পরিষেবা রয়েছে যা কোনওরকমভাবে দক্ষতার সাথে পরিচালনা করতে পারে - এটি অবশ্যই গিথুব - তবে হায়, তাদের কোডবেস বন্ধ উত্স এবং আমি দৃ strongly়ভাবে সন্দেহ করি যে তারা অভ্যন্তরীণ গিট সার্ভার / রেপো স্টোরেজ কৌশল ব্যবহার করে না, অর্থাৎ তারা মূলত প্রয়োগ করা হয়েছে বিকল্প "বিগ ডেটা" গিট

সুতরাং, বটম লাইন : এটা হল সম্ভব, কিন্তু অধিকাংশ বর্তমান usecases জন্য এটি সন্তোষজনক সমাধান কাছাকাছি কোনো জায়গায় হবে না। আপনার নিজের ডকুমেন্ট-সম্পাদনা-ইতিহাস-থেকে-এসকিউএল বাস্তবায়ন রোলিং বা বিদ্যমান যে কোনও নথির ডাটাবেস ব্যবহার করার চেষ্টা করা সম্ভবত একটি ভাল বিকল্প হতে পারে।

Comments

সম্ভবত পার্টিতে কিছুটা দেরি হয়েছিল, তবে আমার এটির অনুরূপ প্রয়োজন ছিল এবং আসলে গিট-রুটে নেমে গেলাম। গিট ইন্টার্নালগুলি দিয়ে কিছুটা খনন করার পরে, আমি এটির কাজ করার একটি উপায় খুঁজে পেয়েছি। ধারণাটি একটি খালি সংগ্রহস্থল নিয়ে কাজ করা। কিছু ত্রুটি আছে, কিন্তু আমি এটি কার্যক্ষম বলে মনে করি। আমি একটি পোস্টে সমস্ত কিছু লিখেছি যা আপনি যাচাই করতে চাইতে পারেন (যদি কিছু হয় তবে স্বার্থের জন্য): kenneth-truyers.net/2016/10/13/git-nosql-database

— কেনেথ

আমার এটি না করার আরেকটি কারণ হল ক্যোয়ারী ক্ষমতা। দস্তাবেজগুলি প্রায়শই সূচী দস্তাবেজগুলি সংরক্ষণ করে যাতে সেগুলির মধ্যে অনুসন্ধান করা সহজ হয়। এই গিট সঙ্গে সরাসরি এগিয়ে হবে না।

— ফ্রাঙ্কিহলিউড

Answer 2

সত্যিই একটি আকর্ষণীয় পদ্ধতির। আমি বলব যে আপনার যদি ডেটা সঞ্চয় করার প্রয়োজন হয় তবে একটি উত্স কোড সংগ্রহস্থল নয়, একটি ডাটাবেস ব্যবহার করুন, যা খুব নির্দিষ্ট কাজের জন্য তৈরি করা হয়েছে। আপনি যদি বাক্সের বাইরে গিট ব্যবহার করতে পারেন, তবে এটি ঠিক আছে, তবে আপনাকে সম্ভবত এটির উপরে একটি নথি সংগ্রহস্থল স্তর তৈরি করতে হবে। সুতরাং আপনি এটি একটি ট্র্যাডিশনাল ডাটাবেসের উপর পাশাপাশি তৈরি করতে পারে, ডান? এবং যদি এটি অন্তর্নির্মিত সংস্করণ নিয়ন্ত্রণে আপনার আগ্রহী হয় তবে কেন কেবল ওপেন সোর্স ডকুমেন্টের সংগ্রহস্থল সরঞ্জাম ব্যবহার করবেন না ? থেকে পছন্দ করে নিন প্রচুর আছে।

ঠিক আছে, আপনি যদি যাইহোক গিট ব্যাকএন্ডে যাওয়ার সিদ্ধান্ত নিয়ে থাকেন, তবে আপনি যদি বর্ণিত হিসাবে এটি প্রয়োগ করেন তবে মূলত এটি আপনার প্রয়োজনীয়তার জন্য কাজ করবে। কিন্তু:

1) আপনি "সার্ভারের ক্লাস্টারকে উল্লেখ করেছেন যা একে অপরকে ধাক্কা দেয় / টানায়" - আমি এটি সম্পর্কে কিছুক্ষণ ভেবেছি এবং এখনও আমি নিশ্চিত নই। পারমাণবিক ক্রিয়াকলাপ হিসাবে আপনি বেশ কয়েকটি স্টোর পুশ / টানতে পারবেন না। আমি অবাক হই যে যদি একযোগে কাজ করার সময় কিছু সংশ্লেষ জড়িত হওয়ার সম্ভাবনা থাকে।

2) হতে পারে আপনার এটির প্রয়োজন নেই, তবে আপনি যে তালিকাভুক্ত করেছেন না এমন কোনও দস্তাবেজ সংগ্রহস্থলের একটি সুস্পষ্ট কার্যকারিতা হ'ল অ্যাক্সেস নিয়ন্ত্রণ। আপনি সাবমডিউলগুলির মাধ্যমে কয়েকটি পাথ (= বিভাগ) এ অ্যাক্সেস সম্ভবত সীমাবদ্ধ করতে পারেন তবে সম্ভবত আপনি নথির স্তরে সহজেই অ্যাক্সেস দিতে পারবেন না।

Answer 3

আমার 2 পেন্স মূল্য। কিছুটা আকাঙ্ক্ষা তবে ...... আমার একটি ইনকিউবেশন প্রকল্পে আমার একই রকম প্রয়োজন ছিল। আপনার অনুরূপ, আমার মূল প্রয়োজনীয়তা যেখানে ডকুমেন্ট ভার্সন সহ একটি ডকুমেন্ট ডাটাবেস (আমার ক্ষেত্রে এক্সএমএল)। এটি অনেকগুলি সহযোগিতার ব্যবহারের ক্ষেত্রে একটি বহু-ব্যবহারকারী সিস্টেমের জন্য ছিল। আমার পছন্দটি ছিল উপলব্ধ ওপেনসোর্স সমাধানগুলি ব্যবহার করা যা মূলত প্রয়োজনীয়তাগুলির বেশিরভাগ সমর্থন করে।

ধাওয়াটি কাটাতে, আমি এমন কোনও পণ্য খুঁজে পেলাম না যা উভয়ই সরবরাহ করেছিল, যথেষ্ট পরিমাণে স্কেলযোগ্য (ব্যবহারকারীর সংখ্যা, ব্যবহারের পরিমাণ, স্টোরেজ এবং গণনা সংস্থান) ising (সম্ভাব্য) সমাধানগুলি এর মধ্যে কারুকার্য করতে পারে। আমি আরও গিট বিকল্পের সাথে কথা বলার সাথে সাথে একক ব্যবহারকারীর দৃষ্টিকোণ থেকে বহু (মিলি) ব্যবহারকারীর দৃষ্টিকোণে সরানো একটি সুস্পষ্ট চ্যালেঞ্জ হয়ে দাঁড়িয়েছে। দুর্ভাগ্যক্রমে, আমি আপনার মতো যথেষ্ট পারফরম্যান্স বিশ্লেষণ করতে পেলাম না। (.. অলস / প্রারম্ভিক তাড়াতাড়ি .... সংস্করণ 2, মন্ত্রের জন্য) আপনাকে পাওয়ার! যাইহোক, আমার পক্ষপাতদুষ্ট ধারণাটি পরের (এখনও পক্ষপাতদুষ্ট) বিকল্পের দিকে ঝাপিয়ে পড়েছে: সরঞ্জামগুলির একটি জাল-আপ যা তাদের পৃথক ক্ষেত্র, ডাটাবেস এবং সংস্করণ নিয়ন্ত্রণে সেরা are

এখনও কাজ চলাকালীন (... এবং কিছুটা অবহেলিত) মোর্ফড সংস্করণটি কেবল এটি।

• অগ্রভাগে: (ইউজারফেসিং) প্রথম স্তরের স্টোরেজ (ব্যবহারকারী অ্যাপ্লিকেশনগুলির সাথে ইন্টারফেসিং) এর জন্য একটি ডাটাবেস ব্যবহার করুন
• ব্যাকএন্ডে, ডাটাবেসে ডেটা অবজেক্টের সংস্করণ সম্পাদনের জন্য একটি সংস্করণ নিয়ন্ত্রণ ব্যবস্থা (ভিসিএস) (গিটের মতো) ব্যবহার করুন

সংক্ষেপে এটি কিছু সংহত আঠালো সহ ডেটাবেজে একটি সংস্করণ নিয়ন্ত্রণ প্লাগইন যুক্ত করার পরিমাণ, যা আপনার বিকাশ করতে হতে পারে তবে এটি অনেক সহজ হতে পারে।

এটি কীভাবে (অনুমিত) কাজ করবে তা হ'ল প্রাথমিক মাল্টি-ইউজার ইন্টারফেস ডেটা এক্সচেঞ্জগুলি ডাটাবেসের মাধ্যমে। ডিবিএমএস সমস্ত মজাদার এবং জটিল ইস্যু যেমন মাল্টি-ইউজার, কনক্যুরঞ্জি ই, পারমাণবিক ক্রিয়াকলাপ পরিচালনা করবে kend ব্যাকএন্ডে ভিসিএস একক ডেটা অবজেক্টের সংস্করণ নিয়ন্ত্রণ সম্পাদন করবে (কোনও চুক্তি বা মাল্টি-ব্যবহারকারী সমস্যা নয়)। ডাটাবেসে প্রতিটি কার্যকর লেনদেনের জন্য, সংস্করণ নিয়ন্ত্রণ কেবল ডেটা রেকর্ডে সঞ্চালিত হয় যা কার্যকরভাবে পরিবর্তিত হত।

ইন্টারফেসিং আঠালো হিসাবে, এটি ডাটাবেস এবং ভিসিএসের মধ্যে একটি সাধারণ ইন্টারফেসিং ফাংশন আকারে হবে। ডিজাইনের শর্তাবলী হিসাবে, সহজ পদ্ধতির একটি ইভেন্ট চালিত ইন্টারফেস হবে, ডাটাবেস থেকে ডেটা আপডেটের সাথে সংস্করণ নিয়ন্ত্রণ পদ্ধতিগুলি ট্রিগার করা হবে (ইঙ্গিত: মাইকিকিএল ধরে নেওয়া , ট্রিগার এবং সিস_এক্সেকের ব্যবহার) ব্লা ব্লাহ ...) বাস্তবায়নের জটিলতার শর্তাবলী, এটি সহজ এবং কার্যকর (উদাহরণস্বরূপ স্ক্রিপ্টিং) থেকে জটিল এবং দুর্দান্ত (কিছু প্রোগ্রামযুক্ত সংযোজক ইন্টারফেস) পর্যন্ত থাকবে। এটির উপর নির্ভর করে আপনি কতটা পাগল হতে চান এবং আপনি কত ঘামের মূলধন ব্যয় করতে ইচ্ছুক তার উপর নির্ভর করে। আমি সাধারণ স্ক্রিপ্টিং যাদু করা উচিত মনে করি। এবং শেষ ফলাফলটি অ্যাক্সেস করতে, বিভিন্ন ডেটা সংস্করণ, একটি সহজ বিকল্প হ'ল ভিসিএসে সংস্করণ ট্যাগ / আইডি / হ্যাশ দ্বারা উল্লিখিত ডেটা সহ ডাটাবেসের একটি ক্লোন (আরও বেশি ডাটাবেস কাঠামোর ক্লোন) তৈরি করা। আবার এই বিটটি একটি ইন্টারফেসের একটি সাধারণ ক্যোয়ারী / অনুবাদ / মানচিত্রের কাজ হবে।

এখনও মোকাবেলা করার জন্য কিছু চ্যালেঞ্জ এবং অজানা রয়েছে, তবে আমি মনে করি এর প্রভাব এবং এর বেশিরভাগের প্রাসঙ্গিকতা মূলত আপনার আবেদনের প্রয়োজনীয়তা এবং ব্যবহারের ক্ষেত্রে নির্ভর করবে। কিছু কেবল ইস্যু না হয়ে শেষ হতে পারে। কিছু বিষয়গুলির মধ্যে উচ্চ-ফ্রিকোয়েন্সি ডেটা আপডেটের ক্রিয়াকলাপের জন্য অ্যাপ্লিকেশনটির জন্য 2 কী মডিউল, ডাটাবেস এবং ভিসিএসের মধ্যে পারফরম্যান্স ম্যাচিং, ডেটা হিসাবে গিট সাইডে রিসোর্সেস (স্টোরেজ এবং প্রসেসিং পাওয়ার) সময়ের সাথে সাথে স্কেলিং অন্তর্ভুক্ত রয়েছে বৃদ্ধি: স্থির, সূক্ষ্ম বা শেষ পর্যন্ত মালভূমি

উপরের ককটেলগুলির মধ্যে, আমি বর্তমানে এটি তৈরি করছি

• ভিসিএসের জন্য গিট ব্যবহার করা (2 সংস্করণের মধ্যে কেবল চেঞ্জসেট বা ডেল্টাস ব্যবহারের কারণে প্রাথমিকভাবে ভাল পুরানো সিভিএস হিসাবে বিবেচিত)
• মাইএসকিএল ব্যবহার করে (আমার তথ্যের উচ্চ কাঠামোগত প্রকৃতির কারণে, এক্সএমএল কঠোর এক্সএমএল স্কিমার সাহায্যে)
• মোংগোডিবি (টোপ ব্যবহার করা নেটিভ ডাটাবেস কাঠামোর সাথে একত্রে মিলিত একটি নোএসকিউএল ডাটাবেস চেষ্টা করার জন্য) সাথে টোয়িং করা

কিছু মজাদার তথ্য - গিটটি স্টোরেজ অনুকূলকরণের জন্য পরিষ্কার জিনিস দেয় যেমন সংকোচন, এবং কেবলমাত্র বস্তুর পুনর্বিবেচনার মধ্যে ডেল্টাসের সঞ্চয় - হ্যাঁ, গিট কেবলমাত্র ডেটা অবজেক্টের পুনর্বিবেচনার মধ্যে পরিবর্তনসেট বা ডেল্টাস সংরক্ষণ করে, এটি প্রযোজ্য কোথায় (এটি জানে কখন এবং কিভাবে) . রেফারেন্স: গিট ইন্টারনালদের সাহসের গভীরে প্যাকফাইলস - গিটের অবজেক্ট স্টোরেজ (কনটেন্ট-অ্যাড্রেসিয়েবল ফাইল সিস্টেম) এর পর্যালোচনা, এমন মংসোডিবি-র নোএসকিউএল ডাটাবেসের সাথে স্ট্রাইকিং মিল (কনসেপ্টের দৃষ্টিভঙ্গি থেকে) দেখায়। আবার, ঘামের মূলধন ব্যয় করে, এটি 2 সংহত করার জন্য আরও কার্যকর আকর্ষণীয় সম্ভাবনা এবং পারফরম্যান্স টুইটগুলি সরবরাহ করতে পারে

আপনি যদি এতদূর পেলেন তবে উপরেরটি আপনার ক্ষেত্রে প্রযোজ্য কিনা এবং আমাকে ধরে নিই, এটি আপনার শেষ বিস্তৃত পারফরম্যান্স বিশ্লেষণের কিছু দিককে কীভাবে বর্ধন করবে?

Answer 4

আমি একটি রুবি লাইব্রেরি প্রয়োগ করেছি libgit2যার উপরে এটি কার্যকর এবং অন্বেষণ করা বেশ সহজ করে তোলে। কিছু সুস্পষ্ট সীমাবদ্ধতা আছে, তবে আপনি পুরো গিট টুলচেন পাওয়ার পরে এটি একটি সুন্দর মুক্ত ব্যবস্থাও।

ডকুমেন্টেশনে পারফরম্যান্স, ট্রেড অফস ইত্যাদি সম্পর্কে কিছু ধারণা অন্তর্ভুক্ত রয়েছে includes

Answer 5

যেমন আপনি উল্লেখ করেছেন, মাল্টি-ব্যবহারকারীর কেসটি হ্যান্ডেল করার জন্য কিছুটা কৌশলযুক্ত। এর একটি সম্ভাব্য সমাধান হ'ল ব্যবহারকারী-নির্দিষ্ট গিট ইনডেক্স ফাইলগুলি ব্যবহার করা যার ফলস্বরূপ

• আলাদা ওয়ার্কিং কপিগুলির প্রয়োজন নেই (ডিস্কের ব্যবহার পরিবর্তিত ফাইলগুলির মধ্যে সীমাবদ্ধ)
• সময় গ্রহণকারী প্রস্তুতিমূলক কাজের প্রয়োজন নেই (প্রতি ব্যবহারকারী সেশন)

কৌশলটি হ'ল গিটের 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তবে বিরোধের সমাধানটি এখানে তীব্রতম অংশ।

এটি আরও সহজ করার আইডিয়াগুলি স্বাগত।

Comments

ম্যানুয়াল দ্বন্দ্বের সমাধানের জন্য আপনি লেনদেন এবং ইউআই-এর একটি সম্পূর্ণ বিকাশ ধারণা না চাইলে এটি সাধারণত এমন একটি পন্থা। বিরোধের জন্য সাধারণ ধারণাটি হ'ল ব্যবহারকারীকে প্রতিশ্রুতিবদ্ধ অবস্থায় ঠিক সমাধান করা (যেমন "দুঃখিত, আপনি যে নথিটি সম্পাদনা করছেন অন্য কেউ সম্পাদনা করেছেন -> দয়া করে তার সম্পাদনাগুলি এবং আপনার সম্পাদনাগুলি দেখুন এবং সেগুলিকে মার্জ করুন")। আপনি যখন দু'জন ব্যবহারকারীকে সাফল্যের সাথে প্রতিশ্রুতিবদ্ধ করতে এবং তারপরে কোনও অ্যাসিঙ্ক ক্রোনজবগুলিতে সন্ধান করেন যে জিনিসগুলি দক্ষিণে চলে গেছে তখন সাধারণত জিনিসগুলি সমাধান করার জন্য কারও উপস্থিত থাকে না।

— গ্রেগেট