ObjectRepository - .NET მეხსიერების საცავის ნიმუში თქვენი სახლის პროექტებისთვის

რატომ ინახება ყველა მონაცემი მეხსიერებაში?

ვებსაიტის ან სარეზერვო მონაცემების შესანახად, გონიერი ადამიანების უმეტესობის პირველი სურვილი იქნება SQL მონაცემთა ბაზის არჩევა. 

მაგრამ ზოგჯერ იბადება აზრი, რომ მონაცემთა მოდელი არ არის შესაფერისი SQL-სთვის: მაგალითად, საძიებო ან სოციალური გრაფის შექმნისას, თქვენ უნდა მოძებნოთ რთული ურთიერთობები ობიექტებს შორის. 

ყველაზე ცუდი სიტუაციაა, როცა გუნდში მუშაობ და კოლეგამ არ იცის როგორ შექმნას სწრაფი მოთხოვნები. რამდენი დრო დახარჯეთ N+1 ამოცანების გადაჭრასა და დამატებითი ინდექსების შექმნაზე, რათა მთავარ გვერდზე SELECT შესრულდეს გონივრულ დროში?

კიდევ ერთი პოპულარული მიდგომა არის NoSQL. რამდენიმე წლის წინ იყო ბევრი აჟიოტაჟი ამ თემის ირგვლივ - ნებისმიერი მოსახერხებელი შემთხვევისთვის მათ განათავსეს MongoDB და კმაყოფილი იყვნენ პასუხებით json დოკუმენტების სახით (სხვათა შორის, რამდენი ხელჯოხების ჩასმა მოგიწიათ დოკუმენტებში წრიული ბმულების გამო?).

მე გთავაზობთ სცადოთ სხვა, ალტერნატიული მეთოდი - რატომ არ სცადოთ ყველა მონაცემის შენახვა აპლიკაციის მეხსიერებაში, პერიოდულად შენახვა შემთხვევით საცავში (ფაილი, დისტანციური მონაცემთა ბაზა)? 

მეხსიერება იაფი გახდა და მცირე და საშუალო ზომის პროექტების უმეტესობისთვის ნებისმიერი შესაძლო მონაცემი ჯდება 1 გბ მეხსიერებაში. (მაგალითად, ჩემი საყვარელი სახლის პროექტია ფინანსური ტრეკერი, რომელიც ინახავს ყოველდღიურ სტატისტიკას და ისტორიას ჩემი ხარჯების, ნაშთებისა და ტრანზაქციების შესახებ წელიწადნახევრის განმავლობაში, მოიხმარს მხოლოდ 45 მბ მეხსიერებას.)

დადებითი:

• მონაცემებზე წვდომა უფრო ადვილი ხდება - თქვენ არ გჭირდებათ ფიქრი შეკითხვებზე, ზარმაცი დატვირთვაზე, ORM ფუნქციებზე, თქვენ მუშაობთ ჩვეულებრივ C# ობიექტებთან;
• არ არსებობს პრობლემები სხვადასხვა თემებიდან წვდომასთან;
• ძალიან სწრაფი - არ არის ქსელის მოთხოვნა, არ არის კოდის თარგმნა შეკითხვის ენაზე, არ არის საჭირო ობიექტების (დე)სერიალიზაცია;
• დასაშვებია მონაცემების შენახვა ნებისმიერი ფორმით - იქნება ეს XML დისკზე, თუ SQL Server-ში, თუ Azure Table Storage-ში.

Cons:

• ჰორიზონტალური მასშტაბირება დაკარგულია და შედეგად, ნულოვანი შეფერხების განლაგება შეუძლებელია;
• თუ აპლიკაცია ავარიულია, შეიძლება ნაწილობრივ დაკარგოთ მონაცემები. (მაგრამ ჩვენი აპლიკაცია არასდროს იშლება, არა?)

როგორ მუშაობს იგი?

ალგორითმი შემდეგია:

• დასაწყისში მყარდება კავშირი მონაცემთა საცავთან და იტვირთება მონაცემები;
• აგებულია ობიექტის მოდელი, პირველადი ინდექსები და რელაციური ინდექსები (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();
    }
}

შექმენით 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));

Რა მოხდა? კომპლექტი () ბრუნდება ცხრილის ლექსიკონი, რომელიც შეიცავს კონკურენტული ლექსიკონი და უზრუნველყოფს პირველადი და მეორადი ინდექსების დამატებით ფუნქციონირებას. ეს საშუალებას გაძლევთ გქონდეთ 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 წამში. 

გარდა ამისა, არსებობს 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-ში ან ფაილში, როგორც წესი, საკმარისია. 

მაგრამ წარსულში, როდესაც ახლა უკვე გაუქმებული სტარტაპი EscapeTeams (მეგონა, აქ არის ფული - მაგრამ არა, ისევ გამოცდილება) - გამოიყენება მონაცემთა შესანახად Azure Table Storage-ში.

სამომავლო გეგმები

მსურს გამოვასწორო ამ მიდგომის ერთ-ერთი მთავარი მინუსი - ჰორიზონტალური სკალირება. ამისათვის თქვენ გჭირდებათ ან განაწილებული ტრანზაქციები (sic!), ან მიიღოთ მტკიცე გადაწყვეტილება, რომ ერთი და იგივე მონაცემები სხვადასხვა ინსტანციიდან არ უნდა შეიცვალოს, ან ნება მიეცით შეცვალონ პრინციპით „ვინ არის ბოლო, მართალია“.

ტექნიკური თვალსაზრისით, მე ვხედავ, რომ შესაძლებელია შემდეგი სქემა:

• შეინახეთ EventLog და Snapshot ობიექტის მოდელის ნაცვლად
• იპოვეთ სხვა ინსტანციები (დაამატეთ ყველა ინსტანციის ბოლო წერტილები პარამეტრებს? udp აღმოჩენა? master/slave?)
• გაიმეორეთ EventLog ინსტანციებს შორის ნებისმიერი კონსენსუსის ალგორითმის საშუალებით, როგორიცაა RAFT.

ასევე არის კიდევ ერთი პრობლემა, რომელიც მაწუხებს - კასკადის წაშლა, ანუ იმ ობიექტების წაშლის შემთხვევების გამოვლენა, რომლებსაც აქვთ ბმული სხვა ობიექტებიდან. 

კოდის კოდი

თუ აქამდე წაიკითხეთ, მაშინ რჩება მხოლოდ კოდის წაკითხვა; ის შეგიძლიათ ნახოთ GitHub-ზე:
https://github.com/DiverOfDark/ObjectRepository

წყარო: www.habr.com