Titanグラフデータベースの使用と拡大

Question

私は、階層データ（親子関係）を保存するためのオプションを考え出しています。

ツリーはグラフであり、フォレスト（ツリーの）も技術的にグラフであるため、グラフデータベースはRDBMS espよりはるかに優れているようです。私は読み取りと書き込みの両方の操作を最適化することに懸念があるからです。

• 書き込みの最適化は、階層の変更が最小限の書き込みを必要とすることを意味します。
• 読み取りを最適化することは、特定のノードのコンシューマに最小限の読み取り操作を実行することを意味します。

私のユースケースは、次のとおりです。

• ユーザーあたりの木。ユーザー空間全体で1つのグラフを保存し、ユーザーごとに1つのグラフを使用する必要がありますか？
• パスクエリは、任意のノードから始まり、ユーザーのツリーのルートに戻ります。親ノード

から

子ノードストアリンク私のすべてのリソースは、タイタンDynamoDBのバックエンドは理想的なようで使用することができるという、AWSであるので。

私の実際の問題は、Titanの規模と管理方法を理解することです。

1. gremlinサーバーインスタンスが必要ですか？言い換えれば、私はTitanで何かをするためにgremlinサーバでEC2インスタンスを立ち上げる必要がありますか？または、Java Titan APIを使用してグラフデータを直接操作できますか？

2. 明示的にデータを分割する必要がありますか？言い換えれば、使用量が増え、データ量と操作量が増えるにつれ、より多くのグレムリンサーバーを立ち上げる必要がありますか？サーバーの数が増えると、操作を実行するためにクライアントからサーバー間で一貫したハッシュを行う必要がありますか？

3. 任意のノードからトラバーサルを開始できるように、弾性検索クラスタを設定する必要がありますか。または、この時点で十分な親関係を表現するために頂点を使用してオブジェクトとエッジを表現していますか？私は、頂点IDがユーザ空間全体で一意であることを保証することができます。一意のユーザーIDで各頂点を飾ることもできます。その場合、私は弾性検索が必要ですか？私の希望は、弾力的な検索は、自由形式またはより複雑な検索タイプのクエリであり、正確なクエリではないということです！

4. フロントエンドの数が増えるにつれて、各フロントエンドはグラフを開くことができます（ユーザー空間全体に1つのグラフ）。ユーザあたりのグラフがある場合、フロントエンドは親和性を持たないため、各ユーザに対して同じグラフを開くことができます。それは大丈夫ですか？

これに関する多くのドキュメントを見つけることができませんでした。ありがとうございました！

Answer 1

私は次でご質問にお答えしようとします：どちらのソリューションが可能です

1. 、非常にグレムリンのサーバーを選択するか、カスタマイズされた照会にカスタマイズされたデータアクセス層を有する間で決定するためにあなたのアプリケーションに依存しています他のセカンダリデータストアを介して私はカスタマイズされたデータアクセス層を好みますが、gremlinサーバーを介してすべてのgremlinクエリ要件に応答することは可能です。

2. Gremlinサーバは、アプリケーションとデータストアの間のインターフェイスに過ぎず、キャッシュメカニズムのためにメモリを消費します。データは、異なるマシン、たとえばDynamoDBマシンのクラスタに格納することができます。これは同時ユーザーの数に依存しますが、ほとんどのアプリケーションでは、垂直方向のスケーリングが十分であると思います。単一マシンのリソースを超えて並行性の高い環境でtitanを使用する場合は、別のマシンに異なるgremlin-serverを作成し、ロードバランスメカニズムを処理する必要があります。問題は、同様のクエリが同じgremlin-serverをキャッシュ効率の観点からヒットさせるようにリクエストを送信することを制御する必要があることです。

3. はい、インデックスバックエンドは単なる検索以外の複雑なクエリに役立ちます。条件付き検索や類似検索によるテキスト検索が必要な場合は、Solr/ElasticやLuceneのようなセカンダリインデックスバックエンドが便利です。これは、Luceneのようなインデクサーが、同様の検索に役立つ逆索引構造を提供できるためです。あなたの名前に "foo"を持つすべての親/子供を検索する場合は、インデックスバックエンドを使用する必要があります。年齢が40歳未満のすべての親/子供を検索する場合は、インデックスバックエンドも使用する必要があります。 バックエンドの索引付けに関する詳細は、これらのリンクからアクセスできます。 http://s3.thinkaurelius.com/docs/titan/1.0.0/indexes.htmlhttp://s3.thinkaurelius.com/docs/titan/1.0.0/index-parameters.html

4. 非常にアプリケーション全体のための1つにオープングラフの数を制限することが推奨されます。 Titanは、パフォーマンスのためにアプリケーション全体で単一のグラフインスタンスを持つように促すキャッシュメカニズムを使用しています。コミットされていないデータは単一のグラフインスタンスとトランザクションでのみ表示されるため、リアルタイムアプリケーションが必要な場合は、単一のグラフインスタンスと単一のトランザクションを使用することをお勧めします。ただし、アプリケーション全体で1つ以上のグラフインスタンスを読み取り専用トランザクションに使用することは間違いではありませんが、効率的ではありません。

   メインタイタンdocumentaion：

あなたは以下のリンクでタイタングラフデータベースについての情報をたくさん見つけることができますhttp://s3.thinkaurelius.com/docs/titan/1.0.0/

タイタンがどのように機能するかについての古いが、本当に便利なドキュメント：https://github.com/elffersj/delftswa-aurelius-titan/tree/master/SA-doc