ObjectRepository - तपाईंको गृह परियोजनाहरूको लागि NET इन-मेमोरी रिपोजिटरी ढाँचा

किन मेमोरीमा सबै डाटा भण्डारण गर्ने?

वेबसाइट वा ब्याकइन्ड डाटा भण्डारण गर्न, धेरै समझदार व्यक्तिहरूको पहिलो इच्छा SQL डाटाबेस छनौट गर्न हुनेछ। 

तर कहिलेकाँही यो विचार दिमागमा आउँछ कि डाटा मोडेल SQL को लागी उपयुक्त छैन: उदाहरण को लागी, खोज वा सामाजिक ग्राफ निर्माण गर्दा, तपाईले वस्तुहरु बीच जटिल सम्बन्धहरु को लागी खोजी गर्न आवश्यक छ। 

सबैभन्दा खराब अवस्था हो जब तपाइँ एक टोलीमा काम गर्नुहुन्छ र एक सहकर्मीलाई थाहा छैन कि कसरी द्रुत प्रश्नहरू निर्माण गर्ने। तपाईंले N+1 समस्याहरू समाधान गर्न र थप अनुक्रमणिकाहरू निर्माण गर्न कति समय खर्च गर्नुभयो ताकि मुख्य पृष्ठमा रहेको SELECT उचित समयमा पूरा होस्?

अर्को लोकप्रिय दृष्टिकोण NoSQL हो। धेरै वर्ष पहिले यस विषयको वरिपरि धेरै प्रचार थियो - कुनै पनि सुविधाजनक अवसरको लागि तिनीहरूले MongoDB तैनात गरे र json कागजातहरूको रूपमा जवाफहरूसँग खुसी थिए। (वैसे, कागजातहरूमा गोलाकार लिङ्कहरूको कारणले तपाईंले कतिवटा बैसाखीहरू सम्मिलित गर्नुपर्‍यो?).

म अर्को, वैकल्पिक विधि प्रयास गर्ने सुझाव दिन्छु - किन सबै डाटालाई एप्लिकेसन मेमोरीमा भण्डारण गर्ने प्रयास नगर्ने, आवधिक रूपमा यसलाई अनियमित भण्डारण (फाइल, रिमोट डाटाबेस) मा बचत गर्ने? 

मेमोरी सस्तो भएको छ, र धेरैजसो साना र मध्यम आकारका परियोजनाहरूको लागि कुनै पनि सम्भावित डेटा 1 GB मेमोरीमा फिट हुनेछ। (उदाहरणका लागि, मेरो मनपर्ने गृह परियोजना हो वित्तीय ट्रयाकर, जसले दैनिक तथ्याङ्क र मेरो खर्च, ब्यालेन्स, र लेनदेनको डेढ वर्षको इतिहास राख्छ, केवल 45 MB मेमोरी खपत गर्दछ।)

प्रो:

• डाटामा पहुँच सजिलो हुन्छ - तपाईंले प्रश्नहरू, अल्छी लोडिङ, ORM सुविधाहरूको बारेमा चिन्ता लिनु पर्दैन, तपाईंले साधारण C# वस्तुहरूसँग काम गर्नुहुन्छ;
• विभिन्न थ्रेडहरूबाट पहुँचसँग सम्बन्धित कुनै समस्याहरू छैनन्;
• धेरै छिटो - कुनै नेटवर्क अनुरोध छैन, कुनै क्वेरी भाषामा कोडको अनुवाद छैन, वस्तुहरूको (de) क्रमबद्धताको आवश्यकता छैन;
• यो कुनै पनि रूपमा डाटा भण्डारण गर्न स्वीकार्य छ - यो डिस्कमा XML मा, वा SQL सर्भरमा, वा Azure तालिका भण्डारणमा।

Cons:

• तेर्सो स्केलिंग हराएको छ, र नतिजाको रूपमा, शून्य डाउनटाइम डिप्लोइमेन्ट गर्न सकिँदैन;
• यदि अनुप्रयोग क्र्यास भयो भने, तपाईंले आंशिक रूपमा डाटा गुमाउन सक्नुहुन्छ। (तर हाम्रो अनुप्रयोग कहिल्यै क्र्यास हुँदैन, हैन?)

यसले कसरी काम गर्छ?

एल्गोरिदम निम्नानुसार छ:

• सुरुमा, डाटा भण्डारणसँग जडान स्थापित हुन्छ, र डाटा लोड हुन्छ;
• एक वस्तु मोडेल, प्राथमिक अनुक्रमणिकाहरू, र रिलेशनल अनुक्रमणिकाहरू (१:१, १:धेरै) बनाइएका छन्;
• वस्तु गुणहरूमा परिवर्तनहरू (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());
    }
    
    public Guid? NullableId => null;
    
    // Пример связи 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();

यदि परियोजनाले HangFire प्रयोग गर्नेछ

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

नयाँ वस्तु सम्मिलित गर्दै:

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

यो कल संग, वस्तु अभिभावक मोडेल डाटाबेसमा लेख्नका लागि स्थानीय क्यास र लाइन दुवैमा थपिएको छ। त्यसकारण, यो अपरेशनले O(1) लिन्छ, र यो वस्तु तुरुन्तै काम गर्न सकिन्छ।

उदाहरणका लागि, भण्डारमा यो वस्तु फेला पार्न र फिर्ता गरिएको वस्तु एउटै उदाहरण हो भनेर प्रमाणित गर्न:

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

के हुन्छ? सेट () फर्काउँछ तालिका शब्दकोश, जसमा समावेश छ समवर्ती शब्दकोश र प्राथमिक र माध्यमिक अनुक्रमणिका को अतिरिक्त कार्यक्षमता प्रदान गर्दछ। यसले तपाइँलाई आईडी (वा अन्य स्वेच्छाचारी प्रयोगकर्ता अनुक्रमणिकाहरू) द्वारा खोजी गर्नका लागि सबै वस्तुहरूमा पूर्ण रूपमा दोहोर्याउन अनुमति दिन्छ।

वस्तुहरू थप्दा वस्तु भण्डार तिनीहरूको गुणहरू परिवर्तन गर्न सदस्यता थपिएको छ, त्यसैले गुणहरूमा कुनै पनि परिवर्तनले यो वस्तुलाई लेख्ने लाममा थपिने परिणाम दिन्छ। 
बाहिरबाट गुणहरू अद्यावधिक गर्दा POCO वस्तुसँग काम गर्ने जस्तै देखिन्छ:

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

तपाइँ निम्न तरिकामा वस्तु मेटाउन सक्नुहुन्छ:

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

यसले वस्तुलाई मेटाउने लाममा पनि थप्छ।

बचत कसरी काम गर्छ?

वस्तु भण्डार जब अनुगमन गरिएका वस्तुहरू परिवर्तन हुन्छन् (या त थप्ने वा मेटाउने, वा गुणहरू परिवर्तन गर्दै), घटना बढाउँछ मोडेल परिवर्तन भयोसदस्यता लिए भण्डारण। कार्यान्वयनहरू भण्डारण जब घटना हुन्छ मोडेल परिवर्तन भयो परिवर्तनहरू 3 लामहरूमा राखिन्छन् - थप्न, अद्यावधिक गर्न, र मेटाउनको लागि।

कार्यान्वयन पनि भण्डारण प्रारम्भमा, तिनीहरूले एक टाइमर सिर्जना गर्दछ जसले प्रत्येक 5 सेकेन्डमा परिवर्तनहरू बचत हुने गर्दछ। 

थप रूपमा, त्यहाँ बचत कल बल गर्नको लागि एपीआई छ: ObjectRepository.Save().

प्रत्येक बचत गर्नु अघि, अर्थहीन कार्यहरू पहिले लामहरूबाट हटाइन्छ (उदाहरणका लागि, नक्कल घटनाहरू - जब वस्तु दुई पटक परिवर्तन गरिएको थियो वा द्रुत रूपमा थपिएको/हटाइएको वस्तुहरू), र त्यसपछि मात्र बचत गर्नुहोस्। 

सबै अवस्थामा, सम्पूर्ण हालको वस्तु बचत गरिएको छ, त्यसैले यो सम्भव छ कि वस्तुहरू परिवर्तन गरिएको भन्दा फरक क्रममा बचत गरिएको छ, वस्तुहरूको नयाँ संस्करणहरू समावेश गर्दा तिनीहरू लाममा थपिएको थियो।

अरू के छ त्यहाँ?

• सबै पुस्तकालयहरू .NET मानक 2.0 मा आधारित छन्। कुनै पनि आधुनिक .NET परियोजनामा ​​प्रयोग गर्न सकिन्छ।
• API थ्रेड सुरक्षित छ। आन्तरिक सङ्कलनको आधारमा कार्यान्वयन गरिन्छ समवर्ती शब्दकोश, घटना ह्यान्डलरहरूसँग या त तालाहरू छन् वा तिनीहरूलाई आवश्यक पर्दैन। 
  सम्झन लायकको मात्र कुरा कल गर्नु हो ObjectRepository.Save();
• स्वैच्छिक अनुक्रमणिकाहरू (विशिष्टता चाहिन्छ):

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

कसले प्रयोग गर्छ?

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

तर विगतमा, जब अहिले निष्क्रिय स्टार्टअप EscapeTeams (मैले सोचें कि यो यहाँ छ, पैसा - तर होइन, फेरि अनुभव गर्नुहोस्) - Azure Table Storage मा डाटा भण्डारण गर्न प्रयोग गरिन्छ।

भविष्यको लागि योजनाहरू

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

प्राविधिक दृष्टिकोणबाट, म निम्न योजनालाई सम्भव देख्छु:

• वस्तु मोडेलको सट्टा EventLog र स्न्यापसट भण्डार गर्नुहोस्
• अन्य उदाहरणहरू फेला पार्नुहोस् (सेटिङहरूमा सबै उदाहरणहरूको अन्तिम बिन्दुहरू थप्नुहोस्? udp खोज? मास्टर/दास?)
• RAFT जस्ता कुनै पनि सहमति एल्गोरिदम मार्फत EventLog उदाहरणहरू बीच नक्कल गर्नुहोस्।

त्यहाँ अर्को समस्या पनि छ जसले मलाई चिन्तित बनाउँछ - क्यास्केड मेटाउने, वा अन्य वस्तुहरूबाट लिङ्क भएका वस्तुहरू मेटाउने घटनाहरूको पत्ता लगाउने। 

स्रोत कोड

यदि तपाईंले यहाँ सम्म सबै तरिका पढ्नुभयो भने, त्यसपछि बाँकी सबै कोड पढ्नु हो; यो GitHub मा फेला पार्न सकिन्छ:
https://github.com/DiverOfDark/ObjectRepository

स्रोत: www.habr.com