OrientDB をパーシスタンス レイヤーとして使用するアプリケーションがあり、大きな成功を収めています。監査証跡の実装を検討しているときに岐路に立たされました。
IMO 監査は、次の 4 つのコア プロパティで構成する必要があります。
- タイムスタンプ(アクションが発生した時間)
- アクター(アクションを実行するエンティティ)
- ターゲット(操作対象のエンティティ)
- アクション(これは、要件に応じて、事前および事後状態、説明などの多くのサブパーツで構成できます。)
一方では、さまざまなエンティティ間のこのタイプの関係は、グラフ データベースに最適です。一方で (やはり IMO) グラフ データベースは、時間に関しては、素晴らしく装備されていないか、操作が簡単ではありません。
私は今、2つのアイデアの間で引き裂かれています:
時系列を作成する
基本的には、セグメント化された頂点ノードの時間を表すカスケード時系列をデータベースに作成するという考え方です。
すべてのアクション可能なプロパティAudit
を含む頂点を作成し、と最も近い時間頂点ノードの間、と の間、との間の関係を作成します。Edge
Audit
Audit
Actor
Audit
Target
まっすぐな関係を築く
時系列は、考慮する必要があるレベルの複雑さを追加します。監査を 3 つのルート基準で検索する必要があると仮定します。、および時間。Actor
_ 時間はほぼ常に要件であるため、時系列は魅力的なソリューションになります。過去 30 日間のすべてを入手してください。Target
Audit
しかし、ジョンAudit
がActor
. おそらく、時間の関係を無視して、Edge
toActor
とTarget
タイムスタンプを使用して監査を作成することもできます。
または、タイムスタンプも のプロパティである可能性がありEdge
ます。
時系列には本当に利点がありますか、それとも不必要な複雑さを追加しているだけですか? グラフ データベースでのイベントの監査に関して、既に受け入れられているより良い方法はありますか?