0

Cassandra で Rexster/TITAN 0.4 を使用しています。頂点キーは、以下の標準インデックスを使用してインデックス付けされます。g.makeKey("ドメイン").dataType(String.class).indexed("standard", Vertex.class).make(); パフォーマンスとスケーラビリティのために一意性を使用していません。グラフには約 10M の頂点があります。

私の要件は、各頂点を反復処理し、重複があるかどうかを特定してから削除することです。既に存在するインデックスから直接、ソートされた頂点のリストを取得する方法はありますか? 「ダイレクト インデックス クエリ」に似たインデックス (標準の TITAN インデックス) に対する直接クエリ。頂点全体を小さなバッチに分割し、個別に処理できるようにします。

不可能な場合、これを達成するための最良の方法は何ですか。グラフ内の重複を見つけて削除するためだけに、Titan-Hadoop または同様のソリューションを使用したくありません。

以下のクエリを実行して、ソートされた順序で 1000 個の頂点を取得したいと考えています。

gremlin> g.V.has('domain').domain.order[0..1000]

WARN  com.thinkaurelius.titan.graphdb.transaction.StandardTitanTx  - Query requires iterating over all vertice
s [(domain <> null)]. For better performance, use indexes

しかし、このクエリは 'domain'で作成された標準のインデックスを使用しておらず、実行に失敗し、メモリ不足の例外が発生します。グラフには最大 10M の頂点があります。

この特定のケースでグレムリンにインデックスを使用させるにはどうすればよいですか?

4

1 に答える 1

1

答えは、前の質問のコメントで提供したものと同じです。

  1. 問題により多くのメモリを投入します (つまり-Xmx、コンソールまたはクエリを実行しているアプリケーションを増やす) - これは短期的な解決策です。
  2. titan-hadoop を使用します。
  3. 何らかの方法でグラフまたはクエリを再構築して、インデックスを使用できるようにします。これは、挿入時のパフォーマンスの一部を放棄し、一意性ロックを使用することを意味する可能性があります。おそらく、ソース データの重複を削除する必要はありません。おそらく、トラバーサル時に Gremlin クエリでそれらを重複排除できるでしょう。ポイントは、あなたが創造的である必要があるということです。

titan-hadoop を使用することに消極的であり、「グラフ内の重複を検索/削除するためだけに」使用したくないにもかかわらず、それはまさにそれが得意とするユースケースです。すべての頂点を繰り返す必要があるバッチ プロセスがあり、割り当てたメモリに収まらず、titan-hadoop を使用したくない場合。これは、「釘とハンマーはあるが、ハンマーで釘を打ちたくない」と言っているようなものです。:)

この特定のケースでグレムリンにインデックスを使用させるにはどうすればよいですか?

グレムリンでこれを行う方法はありません。理論的には、Cassandra から直接 (Titan をバイパスして) 読み取り、バイナリ結果をデコードし、何らかの方法で反復して削除する方法があるかもしれませんが、私にはわかりません。理解できたとしても、Titan の奥深くを掘り下げてインデックス データを読み取る方法を確認するのに何時間もかかることになりますが、Titan をコアとしてアップグレードするたびに壊れる可能性が高いハックです。予期しない方法で Titan を回避しているため、開発者はいつでもその道を閉じる可能性があります。

最良の選択肢は、titan-hadoop を使用して問題を解決することです。グラフが完全に静的で、もはや成長していない場合を除き、titan-hadoop が避けられないポイントに到達します。1 億以上のエッジがある場合、グラフが正しく成長していることをどのように確認しますか? データに関するグローバルな統計をどのように収集しますか? コードのバグからデータベースに入った不良データをどのように修復しますか? グラフが特定のスケールに達し、titan-hadoop が現時点で唯一の友達になると、これらすべてが問題になります。

于 2015-05-21T10:56:29.293 に答える