Titan Db 忽略索引

Question

我有一个带有几个索引的图表。它们是两个带有标签限制的复合指数。 (两者在不同的属性/标签上完全相同)。
一个似乎确实有效，但另一个无效。我已经完成了以下 profile() 以进行双重检查:

一个叫KeyOnNode :属性(property)uid和标签 node :

gremlin> g.V().hasLabel("node").has("uid", "xxxxxxxx").profile().cap(...)
==>Traversal Metrics
Step                                                               Count  Traversers       Time (ms)    % Dur
=============================================================================================================
TitanGraphStep([~label.eq(node), uid.eq(dammit_...                     1           1           2.565    96.84
  optimization                                                                                 1.383
  backend-query                                                        1                       0.231
SideEffectCapStep([~metrics])                                          1           1           0.083     3.16
                                            >TOTAL                     -           -           2.648        -

以上是完全可以接受的并且运行良好。我假设魔线是 backend-query .

另一个叫 NameOnSuperNode : 属性(property) name和标签 supernode :

gremlin> g.V().hasLabel("supernode").has("name", "xxxxxxxx").profile().cap(...)
==>Traversal Metrics
Step                                                               Count  Traversers       Time (ms)    % Dur
=============================================================================================================
TitanGraphStep([~label.eq(supernode), name.eq(n...                     1           1        5763.163   100.00
  optimization                                                                                 2.261
  scan                                                                                         0.000
SideEffectCapStep([~metrics])                                          1           1           0.073     0.00
                                            >TOTAL                     -           -        5763.236        -

这里的查询花费了大量的时间，我们有一个 scan线。我最初想知道索引是否没有通过管理系统提交，但以下似乎工作正常:

gremlin> m = graphT.openManagement(); 
==>com.thinkaurelius.titan.graphdb.database.management.ManagementSystem@73c1c105
gremlin> index = m.getGraphIndex("NameOnSuperNode")
==>NameOnSuperNode
gremlin> index.getFieldKeys()
==>name
gremlin> import static com.thinkaurelius.titan.graphdb.types.TypeDefinitionCategory.*
==>null
gremlin> sv = m.getSchemaVertex(index)
==>NameOnSuperNode
gremlin> rel = sv.getRelated(INDEX_SCHEMA_CONSTRAINT, Direction.OUT)
==>com.thinkaurelius.titan.graphdb.types.SchemaSource$Entry@26b2b8e2
gremlin> sse = rel.iterator().next()
==>com.thinkaurelius.titan.graphdb.types.SchemaSource$Entry@2d39a135
gremlin> sse.getSchemaType()
==>supernode

我现在不能只是重置数据库。任何确定问题可能是什么的帮助都会很棒，我在这里碰壁了。
这是我需要重新索引的迹象吗？

信息:Titan DB 1.1 (TP 3.1.1)

干杯

更新:我发现有问题的索引不在 REGISTERED 中状态:

gremlin> :> m = graphT.openManagement(); index = m.getGraphIndex("NameOnSuperNode"); pkey = index.getFieldKeys()[0]; index.getIndexStatus(pkey)
==>INSTALLED

我如何才能注册？我试过 m.updateIndex(index, SchemaAction.REGISTER_INDEX).get(); m.commit(); graphT.tx().commit();但它似乎没有做任何事情

更新 2:我已经尝试重新索引索引，以便使用以下内容重新索引:

gremlin> m = graphT.openManagement(); 
index = m.getGraphIndex("NameOnSuperNode") ; 
import static com.thinkaurelius.titan.graphdb.types.TypeDefinitionCategory.*; 
import com.thinkaurelius.titan.graphdb.database.management.ManagementSystem; 
m.updateIndex(index, SchemaAction.REGISTER_INDEX).get();
ManagementSystem.awaitGraphIndexStatus(graphT, "NameOnSuperNode").status(SchemaStatus.REGISTERED).timeout(20, java.time.temporal.ChronoUnit.MINUTES).call();
m.commit();
graphT.tx().commit()

但这不起作用。我的索引还在 INSTALLED状态，我仍然超时。我检查过没有未结交易。有人有想法吗？仅供引用，该图在单个服务器上运行，具有 ~100K 顶点和 ~130k 边。

Answer 1

因此，这里可能会发生一些事情:

如果您描述的这两个索引不是在同一个事务中创建的(并且有问题的索引是在 name propertyKey 已经定义之后创建的)，那么您应该根据 Titan docs 发出重新索引。 :

The name of a graph index must be unique. Graph indexes built against newly defined property keys, i.e. property keys that are defined in the same management transaction as the index, are immediately available. Graph indexes built against property keys that are already in use require the execution of a reindex procedure to ensure that the index contains all previously added elements. Until the reindex procedure has completed, the index will not be available. It is encouraged to define graph indexes in the same transaction as the initial schema.

索引可能会使从 REGISTERED 移动的过程超时。至 INSTALLED ，在这种情况下，您要使用 mgmt.awaitGraphIndexStatus() .您甚至可以在此处指定您愿意等待的时间。

确保图表上没有未结交易，否则索引状态确实不会改变，如 here 所述.

这显然不适合您，但是 Titan 中存在一个错误(通过 this PR 在 JanusGraph 中修复)，如果您针对新创建的 propertyKey 以及以前使用的 propertyKey 创建索引，则索引将卡住在 REGISTERED状态

索引不会移动到 REGISTERED除非集群中的每个 Titan/JanusGraph 节点都确认索引创建。如果您的索引卡在 INSTALLED 中状态，系统中的其他节点有可能不承认索引的存在。这可能是由于集群中的另一台服务器出现问题，回填 Titan/JanusGraph 用来相互交谈的消息队列，或者最出乎意料的是:幻影实例的存在。每次您的服务器通过非正常的 JVM 关闭过程(即 kill -9)被杀死时，都会发生这些情况。服务器因为它被困在世界垃圾收集中。如果您认为回填是问题所在，请查看 this class 中的评论提供对可能有助于解决问题的可定制配置选项的深入了解。要检查虚节点是否存在，请使用 this function然后 this function杀死幻影实例。