ObjectRepository - ホーム プロジェクト用の .NET メモリ内リポジトリ パターン

なぜすべてのデータをメモリに保存するのでしょうか?

Web サイトやバックエンドのデータを保存するために、ほとんどの良識ある人が最初に望むのは、SQL データベースを選択することでしょう。 

しかし、データ モデルが SQL に適していないという考えが頭に浮かぶことがあります。たとえば、検索やソーシャル グラフを構築する場合、オブジェクト間の複雑な関係を検索する必要があります。 

最悪の状況は、チームで作業していて、同僚が簡単なクエリの作成方法を知らない場合です。 メイン ページの SELECT が適切な時間内に完了するように、N+1 の問題を解決し、追加のインデックスを構築するのにどのくらいの時間を費やしましたか?

もう XNUMX つの一般的なアプローチは NoSQL です。 数年前、このトピックに関しては多くの誇大宣伝がありました - 都合の良い機会に備えて、彼らは MongoDB をデプロイし、json ドキュメントの形式で答えに満足していました (ところで、文書内に循環リンクがあるため、松葉杖を何本挿入する必要がありましたか?).

別の代替方法を試してみることをお勧めします。すべてのデータをアプリケーション メモリに保存し、定期的にランダム ストレージ (ファイル、リモート データベース) に保存してみてはいかがでしょうか。 

メモリは安価になり、ほとんどの中小規模のプロジェクトで使用可能なデータはすべて 1 GB のメモリに収まります。 (たとえば、私のお気に入りのホームプロジェクトは 財務トラッカーは、45 年半にわたる支出、残高、取引の毎日の統計と履歴を保持しており、消費するメモリはわずか XNUMX MB です。)

長所：

• データへのアクセスが容易になります。クエリ、遅延読み込み、ORM 機能について心配する必要はなく、通常の C# オブジェクトを操作できます。
• 異なるスレッドからのアクセスに関連する問題はありません。
• 非常に高速 - ネットワーク リクエスト、コードのクエリ言語への変換、オブジェクトの (逆) シリアル化は必要ありません。
• データは、ディスク上の XML、SQL Server、Azure Table Storage など、あらゆる形式で保存できます。

短所：

• 水平方向のスケーリングが失われ、その結果、ゼロ ダウンタイムの展開を行うことができなくなります。
• アプリケーションがクラッシュすると、データが部分的に失われる可能性があります。 (でも、アプリケーションがクラッシュすることはありませんよね?)

それはどのように動作しますか？

アルゴリズムは次のとおりです。

• 最初に、データ ストレージとの接続が確立され、データがロードされます。
• オブジェクト モデル、プライマリ インデックス、およびリレーショナル インデックス (1:1、1:Many) が構築されます。
• サブスクリプションは、オブジェクト プロパティの変更 (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 (またはその他の任意のユーザー インデックス) によって検索するメソッドを使用できるようになります。

オブジェクトを追加するときは、 オブジェクトリポジトリ サブスクリプションはプロパティを変更するために追加されるため、プロパティが変更されると、このオブジェクトも書き込みキューに追加されます。 
外部からプロパティを更新することは、POCO オブジェクトを操作することと同じように見えます。

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

次の方法でオブジェクトを削除できます。

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

これにより、オブジェクトも削除キューに追加されます。

保存はどのように機能しますか?

オブジェクトリポジトリ 監視対象のオブジェクトが変更されると (追加または削除、またはプロパティの変更のいずれか)、イベントが発生します。 モデルが変更されました購読しました Iストレージ。 実装 Iストレージ イベントが発生したとき モデルが変更されました 変更は、追加、更新、削除の 3 つのキューに入れられます。

実装も Iストレージ 初期化時に、5 秒ごとに変更を保存するタイマーを作成します。 

さらに、保存呼び出しを強制する API もあります。 ObjectRepository.Save().

各保存の前に、無意味な操作 (たとえば、オブジェクトが XNUMX 回変更されたときや、オブジェクトがすぐに追加/削除されたときの重複イベントなど) がキューから削除され、その後、保存自体が削除されます。 

いずれの場合も、現在のオブジェクト全体が保存されるため、キューに追加された時点よりも新しいバージョンのオブジェクトも含め、オブジェクトが変更された順序とは異なる順序で保存される可能性があります。

他には何があるの？

• すべてのライブラリは .NET Standard 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 にデータを保存するために使用されます。

将来の計画

このアプローチの主な欠点の XNUMX つである水平スケーリングを修正したいと思います。 これを行うには、分散トランザクション (原文どおり!) を使用するか、異なるインスタンスからの同じデータを変更すべきではないという強い意志の決定を下すか、「最後に残った者が正しい」という原則に従ってデータを変更させるかのいずれかが必要です。

技術的な観点から、私は次のスキームが可能であると考えています。

• オブジェクトモデルの代わりにイベントログとスナップショットを保存
• 他のインスタンスを検索します (すべてのインスタンスのエンドポイントを設定に追加しますか? udp 検出? マスター/スレーブ?)
• RAFT などのコンセンサス アルゴリズムを介して EventLog インスタンス間でレプリケートします。

もう XNUMX つ気になる問題があります。カスケード削除、つまり他のオブジェクトからのリンクを持つオブジェクトが削除されるケースの検出です。 

ソースコード

ここまで読んだら、あとはコードを読むだけです。コードは GitHub にあります。
https://github.com/DiverOfDark/ObjectRepository

出所： habr.com