ObjectRepository - သင့်အိမ်ပရောဂျက်များအတွက် .NET in-memory repository ပုံစံ

ဒေတာအားလုံးကို memory ထဲမှာ ဘာကြောင့် သိမ်းထားတာလဲ။

ဆိုက် သို့မဟုတ် နောက်ကွယ်တွင် ဒေတာကို သိမ်းဆည်းရန်၊ လူအများစု၏ ပထမဆုံးဆန္ဒမှာ SQL ဒေတာဘေ့စ်ကို ရွေးချယ်ရန်ဖြစ်သည်။ 

သို့သော် တစ်ခါတစ်ရံတွင် ဒေတာမော်ဒယ်သည် SQL အတွက် မသင့်လျော်ကြောင်း အတွေးဝင်လာသည်- ဥပမာ၊ ရှာဖွေမှု သို့မဟုတ် လူမှုရေးဂရပ်ဖ်တစ်ခု တည်ဆောက်သည့်အခါ၊ အရာဝတ္ထုများအကြား ရှုပ်ထွေးသော ဆက်ဆံရေးများကို ရှာဖွေရန် လိုအပ်သည်။ 

အဆိုးဆုံးအခြေအနေမှာ သင်အသင်းအဖွဲ့တွင်အလုပ်လုပ်ပြီး လုပ်ဖော်ကိုင်ဖက်တစ်ဦးသည် အမြန်မေးခွန်းများကို မည်သို့တည်ဆောက်ရမည်ကို မသိခြင်းပင်ဖြစ်သည်။ N+1 ပြဿနာများကို ဖြေရှင်းပြီး ပင်မစာမျက်နှာရှိ SELECT သည် ကျိုးကြောင်းဆီလျော်သော အချိန်အတိုင်းအတာတစ်ခုအတွင်း ပြီးမြောက်စေရန်အတွက် နောက်ထပ်အညွှန်းကိန်းများ တည်ဆောက်ခြင်းတို့ကို သင်အချိန်မည်မျှသုံးစွဲခဲ့သနည်း။

နောက်ထပ်လူကြိုက်များသောချဉ်းကပ်နည်းမှာ NoSQL ဖြစ်သည်။ လွန်ခဲ့သောနှစ်ပေါင်းများစွာက ဤအကြောင်းအရာနှင့်ပတ်သက်၍ ဖောင်းပွမှုများစွာရှိခဲ့သည် - ၎င်းတို့သည် MongoDB ကိုအသုံးပြု၍ အဆင်ပြေသည့်အချိန်အခါမျိုးတွင် json စာရွက်စာတမ်းပုံစံဖြင့် အဖြေများကို ပျော်ရွှင်စွာအသုံးပြုခဲ့ကြသည် (စာရွက်စာတမ်းများတွင် စက်ဝိုင်းပုံလင့်ခ်များကြောင့် ချိုင်းထောက်မည်မျှထည့်ခဲ့ရသနည်း။).

အခြားအခြားရွေးချယ်စရာနည်းလမ်းကို စမ်းသုံးကြည့်ဖို့ အကြံပြုလိုပါတယ်- ဒေတာအားလုံးကို အပလီကေးရှင်းမှတ်ဉာဏ်ထဲမှာ သိမ်းဆည်းထားဖို့ မကြိုးစားပါနဲ့၊ ၎င်းကို ကျပန်းသိမ်းဆည်းခြင်း (ဖိုင်၊ အဝေးထိန်းဒေတာဘေ့စ်) မှာ အခါအားလျော်စွာ သိမ်းဆည်းပါ။ 

Memory သည် စျေးပေါလာပြီး အသေးစားနှင့် အလတ်စားပရောဂျက်များအတွက် ဖြစ်နိုင်သည့်ဒေတာမှန်သမျှကို 1 GB မမ်မိုရီတွင် ထည့်ပေးပါမည်။ (ဥပမာ၊ ကျွန်တော်အကြိုက်ဆုံး အိမ်ပရောဂျက်က ငွေကြေးခြေရာခံကျွန်ုပ်၏အသုံးစရိတ်များ၊ လက်ကျန်စာရင်းများနှင့် ငွေပေးငွေယူမှုများ၏နေ့စဉ်စာရင်းဇယားများနှင့် မှတ်တမ်းများကို တစ်နှစ်ခွဲကြာသိမ်းဆည်းထားသောကြောင့် မှတ်ဉာဏ်ပမာဏ 45 MB သာသုံးစွဲပါသည်။)

အပြစ်တွေ:

• ဒေတာအသုံးပြုခွင့်သည် ပိုမိုလွယ်ကူလာသည် - သင်မေးမြန်းချက်များ၊ ပျင်းရိစွာတင်ခြင်း၊ ORM အင်္ဂါရပ်များနှင့် ပတ်သက်၍ စိတ်ပူစရာမလိုပါ၊ သင်သည် သာမန် C# အရာဝတ္ထုများနှင့် အလုပ်လုပ်ပါသည်။
• မတူညီသော စာတွဲများမှ ဝင်ရောက်ကြည့်ရှုခြင်းနှင့် ဆက်စပ်သော ပြဿနာမရှိပါ။
• အလွန်လျင်မြန်သည် - ကွန်ရက်တောင်းဆိုမှုများမရှိ၊ ကုဒ်ကို query ဘာသာစကားသို့ ဘာသာပြန်ခြင်းမရှိ၊ အရာဝတ္ထုများ၏ အမှတ်စဉ် (de)serialization ပြုလုပ်ရန် မလိုအပ်ပါ။
• ဒေတာကို မည်သည့်ပုံစံဖြင့် သိမ်းဆည်းနိုင်သည် - ဒစ်ခ်ပေါ်တွင် XML တွင်ဖြစ်စေ၊ SQL Server တွင်ဖြစ်စေ သို့မဟုတ် Azure Table Storage တွင်ဖြစ်စေ လက်ခံနိုင်သည်။

cons:

• အလျားလိုက် အတိုင်းအတာကို ဆုံးရှုံးသွားပြီး ရလဒ်အနေဖြင့် သုညစက်ရပ်ချိန် ဖြန့်ကျက်မှုကို လုပ်ဆောင်၍မရပါ။
• အပလီကေးရှင်းပျက်သွားပါက သင်သည် ဒေတာတစ်စိတ်တစ်ပိုင်း ဆုံးရှုံးနိုင်သည်။ (ဒါပေမယ့် ကျွန်တော်တို့ရဲ့ application က ဘယ်တော့မှ ပျက်မသွားပါဘူး၊ ဟုတ်တယ်မလား?)

ဘယ်လိုအလုပ်လုပ်သလဲ

algorithm မှာအောက်ပါအတိုင်းဖြစ်သည်။

• အစတွင်၊ ဒေတာသိမ်းဆည်းမှုနှင့်အတူ ချိတ်ဆက်မှုတစ်ခုကို တည်ဆောက်ထားပြီး ဒေတာကို တင်ဆောင်ထားသည်။
• အရာဝတ္ထုပုံစံ၊ ပင်မအညွှန်းကိန်းများနှင့် ဆက်စပ်ညွှန်းကိန်းများ (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;
}

နောက်ဆုံးအနေနှင့်၊ ဒေတာကိုရယူရန်အတွက် repository class ကိုယ်တိုင်

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

ဤခေါ်ဆိုမှုနှင့်အတူ, အရာဝတ္ထု ParentModel ဒေတာဘေ့စ်သို့စာရေးရန်အတွက် local cache နှင့် တန်းစီနှစ်ခုလုံးကို ပေါင်းထည့်ထားသည်။ ထို့ကြောင့်၊ ဤလုပ်ဆောင်ချက်သည် O(1) ကိုယူ၍ ဤအရာဝတ္တုနှင့် ချက်ချင်းလုပ်ဆောင်နိုင်သည်။

ဥပမာအားဖြင့်၊ သိုလှောင်မှုတွင် ဤအရာဝတ္ထုကို ရှာရန်နှင့် ပြန်ပေးသည့်အရာသည် တူညီသောဥပမာဖြစ်ကြောင်း စစ်ဆေးရန်-

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

ဘာဖြစ်နေတာလဲ? သတ်မှတ်သည်။ ( ) ပြန်လာသည် ဇယားအဘိဓာန်ပါရှိသည်။ ပြိုင်တူအဘိဓာန် မူလနှင့် အလယ်တန်း အညွှန်းကိန်းများ၏ အပိုလုပ်ဆောင်ချက်ကို ပံ့ပိုးပေးသည်။ ၎င်းသည် အရာဝတ္ထုအားလုံးကို လုံးဝထပ်မွမ်းမံခြင်းမပြုဘဲ Id (သို့မဟုတ် အခြားထင်သလိုအသုံးပြုသူအညွှန်းများ) ဖြင့် ရှာဖွေရန် နည်းလမ်းများ သင့်အားခွင့်ပြုထားသည်။

အရာဝတ္ထုတွေကို ထည့်တဲ့အခါ ObjectRepository ၎င်းတို့၏ ဂုဏ်သတ္တိများကို ပြောင်းလဲရန် စာရင်းသွင်းမှုတစ်ခုအား ထည့်သွင်းထားသည်၊ ထို့ကြောင့် ဂုဏ်သတ္တိများ ပြောင်းလဲမှုတိုင်းသည် ဤအရာဝတ္ထုကို ရေးရန်စာရင်းသို့ ပေါင်းထည့်ခြင်းကိုလည်း ဖြစ်ပေါ်စေပါသည်။ 
ပြင်ပမှ ဂုဏ်သတ္တိများကို အပ်ဒိတ်လုပ်ခြင်းသည် POCO အရာဝတ္ထုတစ်ခုနှင့် အလုပ်လုပ်ပုံနှင့် တူသည်-

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

အောက်ပါနည်းလမ်းများဖြင့် အရာဝတ္ထုတစ်ခုကို ဖျက်နိုင်သည်-

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

၎င်းသည် အရာဝတ္တုအား ဖျက်ရေးတန်းစီသို့လည်း ထည့်သည်။

သိမ်းဆည်းခြင်းအလုပ်က ဘယ်လိုလဲ။

ObjectRepository စောင့်ကြည့်ထားသော အရာဝတ္ထုများ ပြောင်းလဲသောအခါ (ပေါင်းထည့်ခြင်း သို့မဟုတ် ဖျက်ခြင်း သို့မဟုတ် ဂုဏ်သတ္တိများ ပြောင်းလဲခြင်း) သည် ဖြစ်ရပ်တစ်ခုကို ပေါ်ပေါက်စေသည်။ ပုံစံပြောင်းထားသည်။စာရင်းသွင်းထားသည်။ သိုလှောင်မှု. အကောင်အထည်ဖော်မှုများ သိုလှောင်မှု အဖြစ်အပျက်တစ်ခုဖြစ်ပေါ်လာသောအခါ ပုံစံပြောင်းထားသည်။ အပြောင်းအလဲများကို ထည့်သွင်းရန်၊ အပ်ဒိတ်လုပ်ရန်နှင့် ဖျက်ရန်အတွက် တန်းစီ 3 ခုတွင် ထည့်သွင်းထားသည်။

အကောင်အထည်ဖော်မှုတွေလည်း ရှိတယ်။ သိုလှောင်မှု စတင်ချိန်တွင်၊ ၎င်းတို့သည် အပြောင်းအလဲများကို 5 စက္ကန့်တိုင်း သိမ်းဆည်းစေသည့် timer တစ်ခုကို ဖန်တီးသည်။ 

ထို့အပြင်၊ သိမ်းဆည်းခေါ်ဆိုမှုကို အတင်းအကြပ်ပြုလုပ်ရန် API တစ်ခုလည်း ရှိပါသည်။ ObjectRepository.Save().

သိမ်းဆည်းမှုတစ်ခုစီမတိုင်မီတွင်၊ အဓိပ္ပါယ်မဲ့လုပ်ဆောင်မှုများကို စီတန်းများမှ ဦးစွာဖယ်ရှားသည် (ဥပမာ၊ အရာဝတ္ထုတစ်ခုအား နှစ်ကြိမ်ပြောင်းလဲလိုက်သောအခါ သို့မဟုတ် အမြန်ထပ်တိုးခြင်း/အရာဝတ္ထုများကို ဖယ်ရှားလိုက်သောအခါ)၊ ထို့နောက်မှသာ ၎င်းကိုယ်တိုင် သိမ်းဆည်းမည်ဖြစ်သည်။ 

ကိစ္စရပ်တိုင်းတွင်၊ လက်ရှိအရာဝတ္တုတစ်ခုလုံးကို သိမ်းဆည်းထားပြီး၊ ထို့ကြောင့် ၎င်းတို့ကို တန်းစီသို့ထည့်သည့်အချိန်တွင်ထက် ပိုမိုသောအရာဝတ္ထုများ၏ ဗားရှင်းအသစ်များအပါအဝင် အရာဝတ္ထုများကို ၎င်းတို့ပြောင်းလဲထားသည်ထက် မတူညီသောအစီအစဥ်ဖြင့် သိမ်းဆည်းထားနိုင်သည်။

နောက်ထပ် ဘာရှိသေးလဲ။

• စာကြည့်တိုက်များအားလုံးသည် .NET Standard 2.0 ကို အခြေခံထားသည်။ မည်သည့်ခေတ်မီ .NET ပရောဂျက်တွင်မဆို အသုံးပြုနိုင်ပါသည်။
• API သည် thread လုံခြုံသည်။ ပြည်တွင်းစုဆောင်းမှုများကို အခြေခံ၍ အကောင်အထည်ဖော် ဆောင်ရွက်လျက်ရှိသည်။ ပြိုင်တူအဘိဓာန်ပွဲကိုင်တွယ်သူများတွင် သော့များရှိသည် သို့မဟုတ် ၎င်းတို့ကို မလိုအပ်ပါ။ 
  သတိရဖို့ တစ်ခုတည်းသောအရာက ဖုန်းဆက်ဖို့ပါ။ ObjectRepository.Save();
• မတရားအညွှန်းများ (ထူးခြားမှု လိုအပ်သည်)

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

ဘယ်သူက သုံးတာလဲ။

ကိုယ်တိုင်ကိုယ်ကျ၊ ဝါသနာပါရာပရောဂျက်အားလုံးတွင် ဤချဉ်းကပ်နည်းကို စတင်အသုံးပြုရခြင်းမှာ အဆင်ပြေပြီး ဒေတာအသုံးပြုခွင့်အလွှာတစ်ခုရေးသားခြင်း သို့မဟုတ် လေးလံသောအခြေခံအဆောက်အအုံများကို အသုံးပြုခြင်းအတွက် ကြီးမားသောကုန်ကျစရိတ်မလိုအပ်သောကြောင့်ဖြစ်သည်။ ပုဂ္ဂိုလ်ရေးအရ၊ ဒေတာကို litedb သို့မဟုတ် ဖိုင်တစ်ခုတွင် သိမ်းဆည်းခြင်းသည် များသောအားဖြင့် ကျွန်ုပ်အတွက် လုံလောက်ပါသည်။ 

သို့သော် ယခင်က EscapeTeams (ယခု ပျက်သွားသော startup) သည် ယခင်က၊ဒီနေရာမှာ ပိုက်ဆံလို့ထင်ခဲ့ပေမဲ့ မဟုတ်ဘူး၊ ထပ်ပြီး ကြုံလာရတယ်။) - Azure Table Storage တွင် ဒေတာသိမ်းဆည်းရန် အသုံးပြုသည်။

အနာဂတျအတှကျအစီအစဉျမြား

ဤချဉ်းကပ်မှု၏ အဓိက အားနည်းချက်များထဲမှ တစ်ခုကို ပြင်ဆင်လိုသည် - အလျားလိုက် အတိုင်းအတာ ချဲ့ထွင်ခြင်း။ ၎င်းကိုလုပ်ဆောင်ရန်၊ ဖြန့်ဝေထားသော ငွေပေးငွေယူများ (sic!) သို့မဟုတ် မတူညီသောဖြစ်ရပ်များမှ တူညီသောဒေတာကို မပြောင်းလဲသင့်ကြောင်း စေတနာအလျောက် ဆုံးဖြတ်ချက်ချပါ သို့မဟုတ် “နောက်ဆုံးသောသူသည် မှန်သည်” ဟူသောမူအရ ၎င်းတို့ကို ပြောင်းလဲခွင့်ပြုပါ။

နည်းပညာရှုထောင့်မှကြည့်လျှင် အောက်ပါအစီအစဥ်ကို တတ်နိုင်သမျှမြင်ပါသည်။

• အရာဝတ္ထုမော်ဒယ်အစား EventLog နှင့် Snapshot ကို သိမ်းဆည်းပါ။
• အခြားဖြစ်ရပ်များကို ရှာပါ (ဆက်တင်များတွင် ဖြစ်ရပ်အားလုံး၏ အဆုံးမှတ်များကို ပေါင်းထည့်မလား? udp ရှာဖွေတွေ့ရှိမှု? master/slave?)
• EventLog ဖြစ်ရပ်များကြားတွင် RAFT ကဲ့သို့သော အများသဘောတူသော အယ်လဂိုရီသမ်တစ်ခုမှ တစ်ဆင့် ကူးယူပါ။

ကျွန်ုပ်ကို စိုးရိမ်သော နောက်ထပ်ပြဿနာတစ်ခု ရှိသေးသည် - ကက်ကိတ် ဖျက်ခြင်း သို့မဟုတ် အခြားအရာဝတ္ထုများမှ လင့်ခ်များရှိသည့် အရာဝတ္ထုများကို ဖျက်ခြင်းကိစ္စများကို ရှာဖွေတွေ့ရှိခြင်း။ 

အရင်းအမြစ်

ဤနေရာသို့ သင်ဖတ်ရှုပြီးပါက ကျန်အရာအားလုံးမှာ ကုဒ်ကိုဖတ်ရန်ဖြစ်သည်၊ ၎င်းကို GitHub တွင် ရှာတွေ့နိုင်သည်-
https://github.com/DiverOfDark/ObjectRepository

source: www.habr.com