ObjectRepository - अपने घर के प्रोजेक्ट के लिए .NET-इन-मेमोरी रिपॉजिटरी पैटर्न

मेमोरी में सारा डेटा क्यों स्टोर करें?

साइट को संग्रहीत करने या बैकएंड डेटा के लिए, अधिकांश समझदार लोगों की पहली इच्छा एक SQL डेटाबेस होगी।

लेकिन कभी-कभी यह विचार आता है कि डेटा मॉडल SQL के लिए उपयुक्त नहीं है: उदाहरण के लिए, खोज या सामाजिक ग्राफ़ बनाते समय, आपको ऑब्जेक्ट के बीच जटिल संबंधों की खोज करने की आवश्यकता होती है।

सबसे खराब स्थिति तब होती है जब आप एक टीम में काम करते हैं, और एक सहकर्मी त्वरित प्रश्नों का निर्माण करने में सक्षम नहीं होता है। आपने N + 1 समस्याओं को हल करने और अतिरिक्त अनुक्रमित बनाने में कितना समय बिताया ताकि मुख्य पृष्ठ पर SELECT ने उचित समय में काम किया?

एक अन्य लोकप्रिय दृष्टिकोण NoSQL है। कुछ साल पहले इस विषय के आसपास एक बड़ा प्रचार था - किसी भी अवसर के लिए, हमने MongoDB को तैनात किया और json-document के रूप में उत्तरों का आनंद लिया (वैसे, दस्तावेजों में परिपत्र लिंक के कारण कितनी बैसाखी डालनी थी?) ।

एप्लिकेशन की मेमोरी में सभी डेटा को स्टोर करने की कोशिश क्यों नहीं की जाती है, समय-समय पर इसे मनमाना स्टोरेज (फ़ाइल, रिमोट डेटाबेस) में सहेजा जाता है?

मेमोरी सस्ती हो गई है, और सबसे छोटी और मध्यम आकार की परियोजनाओं से कोई भी संभव डेटा 1 जीबी मेमोरी में फिट होगा। (उदाहरण के लिए, मेरा पसंदीदा होम प्रोजेक्ट - एक वित्तीय ट्रैकर जो दैनिक आँकड़े रखता है और मेरे खर्चों, शेष राशि, और डेढ़ साल के लेन-देन का इतिहास केवल 45 एमबी मेमोरी का उपभोग करता है।)

पेशेवरों:

• डेटा तक पहुंच आसान होती जा रही है - साधारण सी # ऑब्जेक्ट के साथ काम करने, प्रश्नों के बारे में चिंता करने की ज़रूरत नहीं, आलसी लोडिंग, ओआरएम फीचर्स;
• विभिन्न थ्रेड्स से पहुंच से जुड़ी कोई समस्या नहीं है;
• बहुत तेज - कोई नेटवर्क अनुरोध, क्वेरी भाषा में कोई कोड अनुवाद, वस्तुओं का क्रमिक (डी) नहीं;
• यह किसी भी रूप में डेटा को स्टोर करने की अनुमति है - कम से कम XML में डिस्क पर, कम से कम SQL सर्वर में, कम से कम एज़्योर टेबल स्टोरेज में।

विपक्ष:

• क्षैतिज स्केलिंग खो गया है, और परिणामस्वरूप, शून्य डाउनटाइम परिनियोजन नहीं किया जा सकता है;
• यदि एप्लिकेशन क्रैश हो जाता है, तो आप आंशिक रूप से डेटा खो सकते हैं। (लेकिन हमारा एप्लिकेशन कभी क्रैश नहीं होता है, है ना?)

यह कैसे काम करता है?

एल्गोरिथ्म इस प्रकार है:

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

कोड उदाहरण

//   Install-Package OutCode.EscapeTeams.ObjectRepository    //  ,      //  ,   . Install-Package OutCode.EscapeTeams.ObjectRepository.File Install-Package OutCode.EscapeTeams.ObjectRepository.LiteDb Install-Package OutCode.EscapeTeams.ObjectRepository.AzureTableStorage    //  -       Hangfire // Install-Package OutCode.EscapeTeams.ObjectRepository.Hangfire 

 public class ParentEntity : BaseEntity {  public ParentEntity(Guid id) => Id = id; }  public class ChildEntity : BaseEntity {  public ChildEntity(Guid id) => Id = id;  public Guid ParentId { get; set; }  public string Value { get; set; } } 

 public class ParentModel : ModelBase {  public ParentModel(ParentEntity entity)  {    Entity = entity;  }    public ParentModel()  {    Entity = new ParentEntity(Guid.NewGuid());  }    //   1:Many  public IEnumerable<ChildModel> Children => Multiple<ChildModel>(x => x.ParentId);    protected override BaseEntity Entity { get; } }  public class ChildModel : ModelBase {  private ChildEntity _childEntity;    public ChildModel(ChildEntity entity)  {    _childEntity = entity;  }    public ChildModel()  {    _childEntity = new ChildEntity(Guid.NewGuid());  }    public Guid ParentId  {    get => _childEntity.ParentId;    set => UpdateProperty(() => _childEntity.ParentId, value);  }    public string Value  {    get => _childEntity.Value;    set => UpdateProperty(() => _childEntity.Value, value);  }    //       public ParentModel Parent => Single<ParentModel>(ParentId);    protected override BaseEntity Entity => _childEntity; } 

 public class MyObjectRepository : ObjectRepositoryBase {  public MyObjectRepository(IStorage storage) : base(storage, NullLogger.Instance)  {    IsReadOnly = true; //  ,            AddType((ParentEntity x) => new ParentModel(x));    AddType((ChildEntity x) => new ChildModel(x));      //   Hangfire       Hangfire  ObjectRepository    // this.RegisterHangfireScheme();      Initialize();  } } 

ObjectRepository की एक आवृत्ति बनाएँ:

 var memory = new MemoryStream(); var db = new LiteDatabase(memory); var dbStorage = new LiteDbStorage(db);  var repository = new MyObjectRepository(dbStorage); await repository.WaitForInitialize(); 

 public void ConfigureServices(IServiceCollection services, ObjectRepository objectRepository) {  services.AddHangfire(s => s.UseHangfireStorage(objectRepository)); } 

एक नई वस्तु डालें:

 var newParent = new ParentModel() repository.Add(newParent); 

इस कॉल में, ParentModel ऑब्जेक्ट को स्थानीय कैश और डेटाबेस में राइट कतार में जोड़ा जाता है । इसलिए, यह ऑपरेशन O (1) लेता है, और आप तुरंत इस ऑब्जेक्ट के साथ काम कर सकते हैं।

उदाहरण के लिए, रिपॉजिटरी में इस ऑब्जेक्ट को खोजने के लिए और सुनिश्चित करें कि लौटी हुई वस्तु एक ही उदाहरण है:

 var parents = repository.Set<ParentModel>(); var myParent = parents.Find(newParent.Id); Assert.IsTrue(ReferenceEquals(myParent, newParent)); 

इससे क्या होता है? सेट करें <ParentModel> () एक टेबल-बर्ड <ParentModel> देता है , जिसमें समवर्ती छायाकारक <ParentModel, ParentModel> होता है और प्राथमिक और द्वितीयक अनुक्रमणिकाओं के लिए अतिरिक्त कार्यक्षमता प्रदान करता है। यह आपको सभी वस्तुओं की पूरी तरह से गणना किए बिना ईद (या अन्य मनमाना कस्टम अनुक्रमित) द्वारा खोज करने की विधियाँ प्रदान करने की अनुमति देता है।

जब ऑब्जेक्ट्स को ObjectRepository में जोड़ा जाता है, तो उनके गुणों को बदलने के लिए एक सब्सक्रिप्शन जोड़ा जाता है, इसलिए गुणों में किसी भी परिवर्तन के कारण भी इस ऑब्जेक्ट को लेखन कतार में जोड़ा जाता है।
बाहर से संपत्तियों को अपडेट करना एक POCO ऑब्जेक्ट के साथ काम करने के समान है:

 myParent.Children.First().Property = "Updated value"; 

आप निम्न तरीकों से किसी ऑब्जेक्ट को हटा सकते हैं:

 repository.Remove(myParent); repository.RemoveRange(otherParents); repository.Remove<ParentModel>(x => !x.Children.Any()); 

यह ऑब्जेक्ट को हटाए गए कतार में भी जोड़ता है।

संरक्षण कैसे काम करता है?

ट्रैक किए गए ऑब्जेक्ट को बदलते समय ऑब्जेक्ट रिपॉजिटरी (दोनों को जोड़ना या हटाना या गुणों को बदलना) ModelChanged इवेंट को उठाता है, जिसे IStorage ने सब्सक्राइब किया है । जब एक ModelChanged घटना होती है , तो IStorage के कार्यान्वयन , 3 कतारों में परिवर्तनों को जोड़ते हैं - जोड़ते हैं, अद्यतन करते हैं, और हटाते हैं।

इसके अलावा, इनिशियोरशन इनिशियलाइज़ेशन के दौरान एक टाइमर बनाते हैं जो हर 5 सेकंड में परिवर्तन को सहेजने का कारण बनता है।

इसके अलावा, सेव कॉल को बाध्य करने के लिए एक एपीआई है: ObjectRepository.Save () ।

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

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

और क्या है?

• सभी पुस्तकालय .NET मानक 2.0 पर आधारित हैं। इसका उपयोग किसी भी आधुनिक .NET प्रोजेक्ट में किया जा सकता है।
• एपीआई धागा सुरक्षित है। आंतरिक संग्रह समवर्ती छायांकन पर आधारित होते हैं, घटना संचालकों के पास या तो ताले होते हैं या उनकी आवश्यकता नहीं होती है।
  याद रखने वाली एकमात्र वस्तु ObjectRepository.Save () है;
• कस्टम अनुक्रमित (विशिष्टता की आवश्यकता है):

 repository.Set<ChildModel>().AddIndex(x => x.Value); repository.Set<ChildModel>().Find(x => x.Value, "myValue"); 

इसका उपयोग कौन कर रहा है?

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

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

भविष्य की योजना

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

तकनीकी दृष्टिकोण से, मुझे निम्नलिखित योजना संभव है:

• इवेंट मॉडल की जगह EventLog और Snapshot को स्टोर करें
• अन्य उदाहरणों का पता लगाएं (सभी उदाहरणों के अंतिम बिंदुओं को जोड़ें? उडप खोज? सेटिंग्स के लिए मास्टर / दास?
• किसी भी आम सहमति एल्गोरिदम, जैसे RAFT के माध्यम से EventLog उदाहरणों के बीच पुनरावृत्ति करें।

एक और समस्या यह भी है कि मुझे परेशान करता है - डिलीट करने का कैस्केडिंग, या अन्य ऑब्जेक्ट्स से संदर्भित ऑब्जेक्ट्स को हटाने के मामलों का पता लगाना।

स्रोत कोड

यदि आप यहाँ तक पढ़ते हैं - तो केवल कोड को पढ़ना शेष है, यह हो सकता है
गितुब पर पाया ।