2

OrientDB をパーシスタンス レイヤーとして使用するアプリケーションがあり、大きな成功を収めています。監査証跡の実装を検討しているときに岐路に立たされました。

IMO 監査は、次の 4 つのコア プロパティで構成する必要があります。

  • タイムスタンプ(アクションが発生した時間)
  • アクター(アクションを実行するエンティティ)
  • ターゲット(操作対象のエンティティ)
  • アクション(これは、要件に応じて、事前および事後状態、説明などの多くのサブパーツで構成できます。)

一方では、さまざまなエンティティ間のこのタイプの関係は、グラフ データベースに最適です。一方で (やはり IMO) グラフ データベースは、時間に関しては、素晴らしく装備されていないか、操作が簡単ではありません。

私は今、2つのアイデアの間で引き裂かれています:

時系列を作成する

基本的には、セグメント化された頂点ノードの時間を表すカスケード時系列をデータベースに作成するという考え方です。

ここに画像の説明を入力

すべてのアクション可能なプロパティAuditを含む頂点を作成し、と最も近い時間頂点ノードの間、と の間、との間の関係を作成します。EdgeAuditAuditActorAuditTarget

ここに画像の説明を入力

まっすぐな関係を築く

時系列は、考慮する必要があるレベルの複雑さを追加します。監査を 3 つのルート基準で検索する必要があると仮定します。、および時間Actor_ 時間はほぼ常に要件であるため、時系列は魅力的なソリューションになります。過去 30 日間のすべてを入手してくださいTargetAudit

しかし、ジョンAuditActor. おそらく、時間の関係を無視して、EdgetoActorTargetタイムスタンプを使用して監査を作成することもできます。

ここに画像の説明を入力

または、タイムスタンプも のプロパティである可能性がありEdgeます。

時系列には本当に利点がありますか、それとも不必要な複雑さを追加しているだけですか? グラフ データベースでのイベントの監査に関して、既に受け入れられているより良い方法はありますか?

4

1 に答える 1