ऑब्जेक्टरिपॉजिटरी - .नेट इन-मेमरी रिपॉझिटरी पॅटर्न तुमच्या गृहप्रकल्पांसाठी

सर्व डेटा मेमरीमध्ये का साठवायचा?

वेबसाइट किंवा बॅकएंड डेटा संचयित करण्यासाठी, बहुतेक समजदार लोकांची पहिली इच्छा SQL डेटाबेस निवडण्याची असेल. 

परंतु कधीकधी असा विचार येतो की डेटा मॉडेल SQL साठी योग्य नाही: उदाहरणार्थ, शोध किंवा सामाजिक आलेख तयार करताना, आपल्याला ऑब्जेक्ट्समधील जटिल संबंध शोधण्याची आवश्यकता आहे. 

सर्वात वाईट परिस्थिती असते जेव्हा तुम्ही एखाद्या संघात काम करता आणि एखाद्या सहकाऱ्याला त्वरित प्रश्न कसे तयार करावे हे माहित नसते. तुम्ही N+1 समस्या सोडवण्यासाठी आणि अतिरिक्त अनुक्रमणिका तयार करण्यासाठी किती वेळ घालवला आहे जेणेकरून मुख्य पृष्ठावरील SELECT वाजवी वेळेत पूर्ण होईल?

आणखी एक लोकप्रिय दृष्टीकोन म्हणजे NoSQL. अनेक वर्षांपूर्वी या विषयाभोवती खूप प्रचार होता - कोणत्याही सोयीस्कर प्रसंगी त्यांनी मोंगोडीबी तैनात केले आणि json दस्तऐवजांच्या स्वरूपात उत्तरे मिळाल्याने आनंद झाला. (तसे, कागदपत्रांमधील वर्तुळाकार लिंक्समुळे तुम्हाला किती क्रॅच घालाव्या लागल्या?).

मी दुसरी, पर्यायी पद्धत वापरण्याचा सल्ला देतो - सर्व डेटा ऍप्लिकेशन मेमरीमध्ये संग्रहित करण्याचा प्रयत्न का करू नये, वेळोवेळी यादृच्छिक स्टोरेजमध्ये (फाइल, रिमोट डेटाबेस) जतन करण्याचा प्रयत्न करा? 

मेमरी स्वस्त झाली आहे आणि बहुतेक लहान आणि मध्यम आकाराच्या प्रकल्पांसाठी कोणताही संभाव्य डेटा 1 GB मेमरीमध्ये फिट होईल. (उदाहरणार्थ, माझा आवडता गृहप्रकल्प आहे आर्थिक ट्रॅकर, जे माझ्या खर्चाची, शिल्लक आणि व्यवहारांची दीड वर्षाची दैनिक आकडेवारी आणि इतिहास ठेवते, फक्त 45 MB मेमरी वापरते.)

साधक:

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

बाधक

• क्षैतिज स्केलिंग गमावले आहे, आणि परिणामी, शून्य डाउनटाइम उपयोजन केले जाऊ शकत नाही;
• अनुप्रयोग क्रॅश झाल्यास, आपण अंशतः डेटा गमावू शकता. (पण आमचा अर्ज कधीच क्रॅश होत नाही, बरोबर?)

ते कसे कार्य करते?

अल्गोरिदम खालीलप्रमाणे आहे:

• सुरुवातीला, डेटा स्टोरेजसह कनेक्शन स्थापित केले जाते आणि डेटा लोड केला जातो;
• ऑब्जेक्ट मॉडेल, प्राथमिक निर्देशांक आणि रिलेशनल इंडेक्स (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());
    }
    
    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();
    }
}

ऑब्जेक्टरिपॉजिटरी उदाहरण तयार करा:

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);

या कॉलसह, ऑब्जेक्ट पालक मॉडेल डेटाबेसमध्ये लिहिण्यासाठी स्थानिक कॅशे आणि रांग दोन्हीमध्ये जोडले जाते. म्हणून, हे ऑपरेशन 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());

हे हटवण्याच्या रांगेत ऑब्जेक्ट देखील जोडते.

बचत कशी कार्य करते?

ऑब्जेक्टरिपॉजिटरी जेव्हा निरीक्षण केलेल्या वस्तू बदलतात (एकतर जोडणे किंवा हटवणे, किंवा गुणधर्म बदलणे), घटना वाढवते मॉडेल बदललेचे सदस्यत्व घेतले ISस्टोरेज. अंमलबजावणी ISस्टोरेज जेव्हा एखादी घटना घडते मॉडेल बदलले बदल 3 रांगांमध्ये ठेवले आहेत - जोडण्यासाठी, अपडेट करण्यासाठी आणि हटवण्यासाठी.

तसेच अंमलबजावणी ISस्टोरेज प्रारंभ केल्यावर, ते एक टाइमर तयार करतात ज्यामुळे बदल दर 5 सेकंदांनी जतन केले जातात. 

याव्यतिरिक्त, सेव्ह कॉल सक्ती करण्यासाठी API आहे: 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 किंवा फाइलमध्ये डेटा संग्रहित करणे माझ्यासाठी सहसा पुरेसे असते. 

पण भूतकाळात, जेव्हा आता बंद पडलेल्या स्टार्टअप EscapeTeems (मला वाटले इथेच आहे, पैसा - पण नाही, पुन्हा अनुभव) - Azure टेबल स्टोरेजमध्ये डेटा संग्रहित करण्यासाठी वापरला जातो.

भविष्यासाठी योजना

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

तांत्रिक दृष्टिकोनातून, मला खालील योजना शक्य तितक्या दिसतात:

• ऑब्जेक्ट मॉडेलऐवजी इव्हेंटलॉग आणि स्नॅपशॉट स्टोअर करा
• इतर उदाहरणे शोधा (सेटिंग्जमध्ये सर्व घटनांचे अंतिम बिंदू जोडा? udp शोध? मास्टर/स्लेव्ह?)
• RAFT सारख्या कोणत्याही एकमत अल्गोरिदमद्वारे EventLog उदाहरणांमध्ये प्रतिकृती तयार करा.

आणखी एक समस्या आहे जी मला चिंतित करते - कॅस्केड हटवणे, किंवा इतर ऑब्जेक्ट्सच्या लिंक्स असलेल्या ऑब्जेक्ट्स हटविण्याच्या प्रकरणांचा शोध. 

स्त्रोत कोड

जर तुम्ही इथपर्यंत सर्व मार्ग वाचला असेल, तर कोड वाचणे बाकी आहे; ते GitHub वर आढळू शकते:
https://github.com/DiverOfDark/ObjectRepository

स्त्रोत: www.habr.com