ObjectRepository — .NET iekšējā atmiņas krātuves modelis jūsu mājas projektiem

Kāpēc uzglabāt visus datus atmiņā?

Kad runa ir par mājaslapas vai aizmugurējās puses datu uzglabāšanu, vairums saprātīgu cilvēku pirmā izvēle ir SQL datubāze. 

Bet dažreiz prātā ienāk doma, ka datu modelis nav piemērots SQL: piemēram, veidojot meklēšanu vai sociālo grafiku, nepieciešama sarežģītu attiecību starp objektiem meklēšana. 

Visgrūtāk ir strādājot komandā, kad kolēģis nezina, kā veidot ātrus vaicājumus. Cik daudz laika esat pavadījis, risinot N+1 problēmas un veidojot papildus indeksus, lai SELECT galvenajā lapā izpildītos saprātīgā laikā?

Cits populārs pieejas veids ir NoSQL. Pirms dažiem gadiem ap šo tēmu bija liela ažiotāža — jebkurā izdevīgā gadījumā tika izvērsta MongoDB un priecājāmies par atbildēm json dokumentu veidā. (Starpcitu, cik daudz pagaidu risinājumu nācās ievietot dēļ cikliskām atsaucēm dokumentos?).

Es piedāvāju izmēģināt vēl vienu alternatīvu pieeju — kāpēc gan neglabāt visus datus lietojumprogrammas atmiņā, regulāri saglabājot tos nejaušā krātuvē (fails, attālināta datubāze)? 

Atmiņa ir kļuvusi lēta, un jebkuri iespējamie dati vairumam mazo un vidējo projektu iekļaujas 1 GB atmiņā. (Piemēram, mans iecienītākais mājas projekts — finanšu izsekotājs, kas veic ikdienas statistiku un manu izdevumu, bilances un darījumu vēsturi pusotru gadu, patērē tikai 45 MB atmiņas.)

Priekšrocības:

• Piekļuve datiem kļūst vienkāršāka — nav jāuztraucas par vaicājumiem, slinkajām ielādēm, ORM īpatnībām, darbs notiek ar parastajiem C# objektiem;
• Nav problēmu, kas saistītas ar piekļuvi no dažādiem pavedieniem;
• Ļoti ātri — nav tīkla vaicājumu, nav koda translācijas vaicājumu valodā, nav nepieciešama (de)serializācija objektu;
• Ir pieņemami glabāt datus jebkurā veidā — gan XML diskā, gan SQL Server, gan Azure Table Storage.

Mīnusi:

• Pazaudēta horizontālā mērogošana, līdz ar to nav iespējams veikt zero downtime deployment;
• Ja lietojumprogramma avarē — iespējams daļēji zaudēt datus. (Bet mūsu lietojumprogramma taču nekad neavarē, vai ne?)

Kā tas darbojas?

Algoritms ir šāds:

• Sākumā tiek izveidota savienojums ar datu krātuvi, un notiek datu ielāde;
• Tiek veidota objektu modeļu struktūra, primārie indeksi un attiecību indeksi (1:1, 1:Daudz);
• Tiek izveidota abonēšana uz objektu īpašību izmaiņām (INotifyPropertyChanged) un uz elementu pievienošanu vai dzēšanu kolekcijā (INotifyCollectionChanged);
• Kad abonēšana tiek aktivizēta, mainītais objekts tiek pievienots datu veikala ierakstu rindai;
• Periodiski (pēc taimeri) fona pavedienā tiek saglabātas izmaiņas datu veikalā;
• Izliekot no programmas, arī tiek saglabātas izmaiņas datu veikalā.

Koda piemērs

Pievienojam nepieciešamās atkarības

// Основная библиотека
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

Aprakstām datu modeli, kas tiks saglabāts datu veikalā

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

Tad ir objektu modelis:

public class ParentModel : ModelBase
{
    public ParentModel(ParentEntity entity)
    {
        Entity = entity;
    }
    
    public ParentModel()
    {
        Entity = new ParentEntity(Guid.NewGuid());
    }
    
    public Guid? NullableId => null;
    
    // 1:Daudz attiecību piemērs
    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;
    }
    
    // Pieejamība ar indeksu meklēšanu
    public ParentModel Parent => Single(ParentId);
    
    protected override BaseEntity Entity => _childEntity;
}

Un visfinally pats datu piekļuves klase - repozitorijs:

public class MyObjectRepository : ObjectRepositoryBase
{
    public MyObjectRepository(IStorage storage) : base(storage, NullLogger.Instance)
    {
        IsReadOnly = true; // Testiem, ļauj nesaglabāt izmaiņas datu bāzē
    
        AddType((ParentEntity x) => new ParentModel(x));
        AddType((ChildEntity x) => new ChildModel(x));
    
        // Ja tiek lietots Hangfire un nepieciešams saglabāt datu modeli Hangfire datu repozitorijā
        // this.RegisterHangfireScheme(); 
    
        Initialize();
    }
}

Izveidojam ObjectRepository instance:

var memory = new MemoryStream();
var db = new LiteDatabase(memory);
var dbStorage = new LiteDbStorage(db);
    
var repository = new MyObjectRepository(dbStorage);
await repository.WaitForInitialize();

Ja projektā tiks izmantots HangFire

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

Jauna objekta pievienošana:

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

Šajā izsaukumā objekts ParentModel tiek pievienots gan lokālajam kešatmiņai, gan ieraksta rindai datubāzē. Tāpēc šī operācija aizņem O(1), un ar šo objektu var uzreiz strādāt.

Piemēram, lai atrastu šo objektu repozitorijā un pārliecinātos, ka atgrieztais objekts ir tas pats eksemplārs:

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

Kas notiek šajā gadījumā? Set<ParentModel>() atgriež TableDictionary<ParentModel>, kas satur iekšā ConcurrentDictionary<ParentModel, ParentModel> un piedāvā papildu funkcionalitāti primārajiem un sekundārajiem indeksi. Tas ļauj izmantot metodes meklēšanai pēc Id (vai citiem lietotāja indeksiem) bez visu objektu pilnīgas pārskatīšanas.

Pievienojot objektus ObjectRepository tiek pievienota paraksts uz to īpašību izmaiņām, tāpēc jebkura īpašību izmaiņa arī rezultē objekta pievienošanā ieraksta rindai. 
Pārveidojot īpašības no ārpuses, tas izskatās tāpat kā strādājot ar POCO objektu:

myParent.Children.First().Property = "Atjaunotā vērtība";

Objektu var izdzēst šādos veidos:

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

Šajā gadījumā notiek arī objekta pievienošana izdzēšanas rindai.

Kā darbojas saglabāšana?

ObjectRepository ja izsekojamo objektu izmaiņas (kā pievienošana vai izdzēšana, tāpat kā īpašību izmaiņas) izsauc notikumu ModelChanged, uz kuru ir parakstījies IStorage. Realizācijas IStorage notikuma rašanās gadījumā ModelChanged uzkrāj izmaiņas 3 rindās — pievienošanai, atjaunināšanai un izdzēšanai.

Tāpat realizācijas IStorage savas inicializācijas laikā izveido taimeri, kas ik pēc 5 sekundēm izsauc izmaiņu saglabāšanu. 

Turklāt pastāv API piespiedu saglabāšanas izsaukšanai: ObjectRepository.Save().

Pirms katras saglabāšanas vispirms notiek bezjēdzīgu operāciju izņemšana no rindām (piemēram, notikumu dublikāti — kad objekts tika mainīts divreiz vai ātra pievienošana/izdzēšana), un tikai pēc tam pati saglabāšana. 

Visos gadījumos tiek saglabāts aktuālais objekts pilnībā, tāpēc var rasties situācija, kad objekti tiek saglabāti citā secībā, nekā mainījās, tajā skaitā var tikt saglabātas jaunākas objektu versijas, nekā brīdī, kad tās tika pievienotas rindai.

Kas vēl ir?

• Visas bibliotēkas balstās uz .NET Standard 2.0. To var izmantot jebkurā mūsdienu .NET projektā.
• API ir plūstošs. Iekšējās kolekcijas ir balstītas uz ConcurrentDictionary, un notikumu apstrādātājiem ir vai nu bloķēšana, vai arī tas nav nepieciešams. 
  Vienīgais, kas jāatceras — pirms lietojuma beigšanas ir jāvēršas pie ObjectRepository.Save();
• Patvaļīgie indeksi (prasa unikālumu):

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

Kas to lieto?

Personīgi es sāku izmantot šo pieeju visos hobija projektos, jo tas ir ērti un neprasa lielus izdevumus datu piekļuves slāņa rakstīšanai vai smagas infrastruktūras izveidošanai. Man parasti pietiek ar datu glabāšanu litedb vai failā. 

Bet pagātnē, kad ar komandu veidojām tagad jau neeksistējošo startapu EscapeTeams (domāju, nu lūk, nauda — bet nē, atkal pieredze) — izmantojām Azure Table Storage datu glabāšanai.

Nākotnes plāni

Gribu novērst vienu no galvenajiem šī pieejas trūkumiem — horizontālo mērogošanu. Tam nepieciešamas vai nu izplatītas transakcijas (sic!), vai jāpieņem grūts lēmums, ka vienādi dati no dažādiem instancēm nedrīkst mainīties, vai rezultātā pieļaut mainīšanu pēc principa 'kurš pēdējais, tas taisnība'.

No tehniskā viedokļa redzu iespējamu sekojošo shēmu:

• Glabāt nevis objektu modeli, bet gan EventLog un Snapshot
• Atrast citas instances (iekļaut visās instance iestatījumos gala punktus? udp atklāšana? master/slave?)
• Repliku veikt starp instancēm ar jebkuru no konsensa algoritmiem, piemēram, RAFT.

Tāpat pastāv vēl viena problēma, kas mani uztrauc — tas ir kaskādes dzēšana, vai objektu, uz kuriem ir atsauces no citiem objektiem, dzēšanas gadījumu noteikšana. 

Atslēgas kods

Ja jūs esat izlasījis līdz šim — tad tālāk paliek tikai lasīt kodu, to var atrast GitHub:
https://github.com/DiverOfDark/ObjectRepository

Avots: habr.com