ObjectRepository — .NET in-memory repository pattern за вашите домашни проекти

Защо да съхранявате всичките данни в паметта?

При съхранение на данни за сайта или бекенда, повечето разумни хора първо ще изберат SQL база данни. 

Но понякога в главата възниква мисълта, че моделът на данни не е подходящ за SQL: например, при изграждане на търсене или социална графика, е необходима търсене по сложни връзки между обектите. 

Най-лошата ситуация е, когато работите в екип и колега не знае как да изгражда бързи заявки. Колко време сте прекарали за решаване на проблеми N+1 и изграждане на допълнителни индекси, за да SELECT на главната страница да работи за разумно време?

Друг популярен подход е NoSQL. Преди няколко години имаше голям шум около тази тема - за всяка удобна възможност разгръщаха MongoDB и се радваха на отговорите под формата на json-документи (между другото, колко много "костилки" трябваше да сложите заради цикличните връзки в документите?).

Предлагам да опитате още един, алтернативен начин - защо да не опитате да съхранявате всичките данни в паметта на приложението, периодично запазвайки в произволно хранилище (файл, отдалечена база данни)? 

Паметта стана евтина, а повечето възможни данни на повечето малки и средни проекти влизат в 1 GB памет. (Например, любимият ми домашен проект - финансов трекер, който води ежедневна статистика и история на моите разходи, баланси и транзакции за година и половина, използва само 45 MB памет.)

Предимства:

• Достъпът до данните става по-лесен - не е нужно да се притеснявате за заявки, лениво зареждане, особености на ORM, работата става с обикновени C# обекти;
• Няма проблеми, свързани с достъпа от различни нишки;
• Много бързо - няма мрежови заявки, отсъства транслация на кода към език за заявки, не е нужна (де)сериализация на обекти;
• Допустимо е да се съхраняват данните под всякаква форма - било в XML на диска, било в SQL Server, било в Azure Table Storage.

Минуси:

• Загуба на хоризонтално мащабиране и следователно не може да се направи нулево време на работа при внедряване;
• Ако приложението падне - може частично да загубите данни. (Но нали нашето приложение никога не пада, нали?)

Как работи това?

Алгоритъмът е следният:

• При стартиране се установява връзка с хранилището на данни и се извършва зареждане на данните;
• Изгражда се обектен модел, основни индекси и индекси на отношения (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:Много
    public IEnumerable Children => Multiple(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(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);

При този вик обектът ParentModel се добавя както в локалния кеш, така и в опашката за запис в базата. Затова тази операция заема O(1) и можем веднага да работим с този обект.

Например, за да намерим този обект в репозитория и да се уверим, че върнатият обект е същият екземпляр:

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

Какво се случва в този случай? Set() върща TableDictionary, който съдържа ConcurrentDictionary и предоставя допълнителен функционал за основни и вторични индекси. Това позволява да имаме методи за търсене по Id (или други произволни потребителски индекси) без да е необходимо пълно преглеждане на всички обекти.

При добавяне на обекти в ObjectRepository се добавя подписка за изменения на техните свойства, така че всяка промяна на свойствата също води до добавянето на този обект в опашката за запис. 
Обновяването на свойствата отвън изглежда по същия начин, както и работата с POCO обект:

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

Обектът може да бъде премахнат по следните начини:

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

При това също се добавя обектът в опашката за изтриване.

Как работи запазването?

ObjectRepository при промяна на проследяваните обекти (както добавяне или изтриване, така и промяна на свойства) предизвиква събитие ModelChanged, на което е абониран IStorage. Реализациите IStorage при възникване на събитието ModelChanged съхраняват промените в 3 опашки — за добавяне, за обновяване и за изтриване.

Също така реализациите IStorage при инициализация създават таймер, който на всеки 5 секунди извиква запазването на промените. 

Освен това има API за принудително извикване на запазване: ObjectRepository.Save().

Преди всяко запазване първо се извършва премахване от опашките на безсмислени операции (например дубликати на събития — когато обектът е бил променян два пъти или бързо добавяне/изтриване на обекти) и едва след това самото запазване. 

Във всички случаи се запазва актуалният обект изцяло, затова е възможна ситуация, при която обектите се запазват в различен ред от този, по който са били променяни, включително могат да се запазват по-нови версии на обектите, отколкото в момента на добавяне в опашката.

Какво още има?

• Всички библиотеки са основани на .NET Standard 2.0. Могат да се използват в който и да е съвременен .NET проект.
• API е потокобезопасен. Вътрешните колекции са реализирани на база ConcurrentDictionary, обработчиците на събития имат или заключвания, или не се нуждаят от тях. 
  Единственото, което трябва да помните, е, че при приключване на приложението трябва да извикате 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

Източник: habr.com