3
空のデータベースでも、Titan 1.0でインデックスを作成するのに数分かかります。時間は正確だと思われ、不必要な遅延があることを示唆しています。タイタンインデックスの更新に時間がかかりすぎる
私の質問はですタイタンが再インデックスにかかる時間を短縮する方法は？概念的には、作業が行われていないので、時間は最小限でなければなりません。確かに4分ではありません。
（NBは私が以前に単にタイタンがタイムアウトせずに完全な遅延を待たせた溶液に指摘されているこれは間違った解決策である - 私は完全に遅れを解消したい。）
私はコード最初からセットアップするデータベースを使用している：
graph = ... a local cassandra instance ...
graph.tx().rollback()
// 1. Check if the index already exists
mgmt = graph.openManagement()
i = mgmt.getGraphIndex('byIdent')
if(! i) {
// 1a. If the index does not exist, add it
idKey = mgmt.getPropertyKey('ident')
idKey = idKey ? idKey : mgmt.makePropertyKey('ident').dataType(String.class).make()
mgmt.buildIndex('byIdent', Vertex.class).addKey(idKey).buildCompositeIndex()
mgmt.commit()
graph.tx().commit()
mgmt = graph.openManagement()
idKey = mgmt.getPropertyKey('ident')
idx = mgmt.getGraphIndex('byIdent')
// 1b. Wait for index availability
if (idx.getIndexStatus(idKey).equals(SchemaStatus.INSTALLED)) {
mgmt.awaitGraphIndexStatus(graph, 'byIdent').status(SchemaStatus.REGISTERED).call()
}
// 1c. Now reindex, even though the DB is usually empty.
mgmt.updateIndex(mgmt.getGraphIndex('byIdent'), SchemaAction.REINDEX).get()
mgmt.commit()
mgmt.awaitGraphIndexStatus(graph, 'byIdent').status(SchemaStatus.ENABLED).call()
} else { mgmt.commit() }
updateIndex...REINDEX呼び出しのように見えるそのタイムアウトまでブロックします。これは既知の問題なのですか？私は何か間違っているのですか？
EDIT：REINDEXを無効にすることは、実際にはインデックスがアクティブにならないため修正されていません。私は今、次を参照してください。
WARN com.thinkaurelius.titan.graphdb.transaction.StandardTitanTx - Query requires iterating over all vertices [(myindexedkey = somevalue)]. For better performance, use indexes
[インデックス状態はAmazon DynamoDBバックエンドのTitanでENABLEDに変更されない可能性があります]（http://stackoverflow.com/questions/35088574/index-state-never-change-to-enabled-on-titan-with -amazon-dynamodb-backend） –
プロパティキーとインデックスを初めて作成するときなど、既存のデータがない場合は、 'REINDEX'への呼び出しを削除します。 –
@JasonPluradそれは、ほとんどの私の使用のための良い戦略です。インデックスの作成時にデータベースが非常に小さい場合はどうなりますか？言っておきますが、私はほとんどゼロではない頂点を持っていればどうでしょうか？私は再インデックスを作成し、この一見無意味な遅延を招かなければならない（私は少なくともプルリクエストを提出するまで）？ –