2

SQL/NoSQL のバックグラウンドから来て、グラフ DB で最も単純な演習を (効率的に) モデル化するのは非常に難しいと感じています。

さまざまなテクノロジーには制限とベスト プラクティスがありますが、モデルを作成する際に使用している考え方が正しいかどうか確信が持てません。正しい慣行。

私が試した最初の演習は、グラフ DB 内のファイル共有ディレクトリ全体 (サブフォルダーとファイル) を表すことです。たとえば、含めたい属性とクエリのいくつかは次のとおりです。

  • フォルダの階層構造
  • 現在のノードでの総サイズ
  • ファイル/フォルダーの作成者に基づいて検索できること
  • ファイルの種類で検索できること

これは私に次の質問をもたらします

  1. エッジにいつ、どの属性を使用する必要があるか。検索したいものだけ？関係だけ？

  2. X より大きいファイルの検索など、グラフ機能を拡張する必要がありますか? そのような変更が大きな影響を与えないように、モデルの将来の機能/柔軟性をどのように最大化しようとしますか?

現在、InfiniteGraph と TitanDB を調査しています。

4

1 に答える 1

0

1）フォルダー階層のエッジを説明するために私が考えることができる唯一の属性は、それが包含または包含関係であるかどうかです。

（すべてのエッジをどちらか一方と見なすことにした場合でも、それは必要ありません。あなたの場合、ほとんどの場合、検索して集約サイズを返すために子孫に問い合わせているようです）。

これは、ネットワークや、エッジが異なるタイプである可能性がある階層よりもはるかに単純です。誰が誰を管理するかだけでなく、誰が誰をサポートし、誰を指導し、誰に嫌がらせをするかなどを追跡する組織図を考えてみてください。

2）あなたが言及した2つのデータベースには詳しくありませんが、Neo4Jはノードプロパティのインデックスを許可しているため、file_sizeにインデックスを追加しても大きな影響はありません. また、「スキーマレス」であるため、その場で属性を追加でき、さまざまなノードに異なる属性を含めることができます。

于 2014-03-31T00:15:37.463 に答える