履歴関係を保持するグラフデータベース
次の問題のモデリングを開始します。
グラフを形成するネットワークで相互作用する多くのクライアント（数百万）がいます。私のビジネス問題の最も細かい単位で、各実現には3つの属性があります。
「現実的な」最悪のシナリオでは、ノードが一意のメッシュを構成し、他のノードとの関係が100を超えますが、悪化します。これらの関係は多くの場合双方向であり、いずれかの可能な値で分割する必要があります。 3つの属性（つまり、クライアントが操作するリージョン）。これにより、次のサイジングにつながります。
2 directions * 6 regions * 100 nodes = 1200 edges per node
悪くなる。要件の1つは、ユーザーがいずれかのノードの過去のスコアを確認したい場合に備えて、このデータベースに過去5年間の月ごとの履歴を含める必要があることです。つまり、ノードごとに1か月あたり1つのエントリも考慮する必要があります。 、私に次のサイジングを与えます：
2 directions * 6 regions * 100 nodes * 60 months = 72000 edges per node
この問題を解決するためにグラフデータベースを使用する傾向がありますが、問題は、現在のグラフ技術を使用してこれを実行できるかどうかです。
履歴データの問題は実際には非常に一般的です。ビジネス関連のデータは多くの場合、時間に関連しています。
Snaphsotアプローチ
これを処理する1つの方法は、スナップショットを取ることです。これは、@ CandleOrangeによって提案されたソリューションです。しかし、それはまたあなたの仮定のようです：サイジングでは、月ごとに各組み合わせの発生が異なると予想します（スナップショットアプローチと完全に同等です）。しかし、あなたはそれをデータベースに保存することを考えています。
例として、1つの主要なビジネスソフトウェアパッケージがこの方法で売上高を管理します。毎月、顧客カテゴリ、製品グループ、および地域の組み合わせごとに、その月の売上高を合計します。このようにして、何百万もの基礎となるトランザクションを読み取る必要なく、基準に従って、任意の期間の売上高を生成できます。
実際、ここではデータと履歴データに違いはありません。ビジネスの観点からは、月は管理されるデータの不可欠な部分です。また、1年間の売上高を前年と比較することもよくありますが、1か月の売上高を前月、または今年の第1四半期と過去2年間の第1四半期と比較することもよくあります。
有効期限アプローチ（時間依存のバージョン管理）
ただし、スナップショットアプローチは常にニーズに適しているわけではありません。多くの場合、データは時間に依存することがあります。たとえば、セールスマンXは、3月1日から8月18日までの地域と、8月19日から今日までの別の地域を担当できます。それで、8月の間彼のためにどの地域を維持しますか？他のものほど正確なものはありません。
グラフの関係の場合、イベントは悪化します。すべてのデータとすべての関係に時間依存の側面があるからです。例を挙げましょう。マネージャーAは、1月20日から9月20日まで部門Xを担当しています。従業員Bは昨年から1月22日まで部門Xに割り当てられ、従業員Cは会社に入社してここにいるため、その部門に割り当てられています。では、マネージャAは誰を管理するのでしょうか。それは完全に日付に依存します。
さて、時間依存のアプローチとスナップショットを比較すると、データベースのサイズはどうなりますか？スナップショットについては、毎月、関連するすべての値を複製する必要があります。したがって、この例の3人と1つの部門の場合、1年で36件のレコードがあります。そして、あなたはまだ完全な真実を保持することができません。時間依存のアプローチの場合、生データは3つのレコードであり、変更が発生した場合にのみ追加データがあるため、全体で6つのレコードになります。
時間に依存するデータのバージョン管理 は、したがって、現実世界を非常に正確に表しており、宇宙に精通しています。ただし、クエリのデザインがはるかに複雑になります。
完全なクエリの悪夢を回避するために、デフォルトで各オブジェクトの現在のバージョン（たとえば、有効期限の最後が空）で作業し、重要なデータを変更するたびに時間制限のあるクローン（有効期限の開始日と終了日を設定）を作成できます。次に、これらのクローンとその有効期限にアクセスする必要がある、時間に依存するいくつかのクエリについてのみ、それらの有効期限にアクセスします。
データベースシステムによるサポート
ほとんどのデータベースシステムでは、時間に依存する側面に注意する必要があります。データ要素の時間依存性は最初から特定する必要があり、ケースバイケースの設計作業は困難です。
しかし、すでに述べたように、これは一般的な課題です。幸いなことに、いくつかのサポートがあります：
私はかつて、データベースの履歴の問題を単にコピーするだけで解決しました。
データベースのコピーを毎週1週間作成しました。 1か月間、毎週。毎年、毎月。そして、毎年のバックアップを保持しました。すべてを簡単なスクリプトで行いました。履歴の問題を解決し、サイズを適切に保ち、データベースをクリーンに保ちました。もちろん、これには制限がありますが、履歴の要件を解決する簡単な方法なので、本当に必要のないものを過剰に設計する前に考慮してください。
DBコピーアプローチの優れている点は、巨大ではない（年間66回+ 1回）以外に、すべてが、その値があったときにリンクされていたものにリンクされていることです。欠点は次のとおりです。損失があるため（一時的な値が失われる可能性があります）、分離されます（現在と過去を結合するクエリを実行できません）。 他のアプローチ 、