Question

我有一个带有几个索引的图表。它们是两个具有标签限制的综合指数。（两者在不同的属性/标签上完全相同）。一个肯定似乎工作，但另一个没有。我已完成以下配置文件（）以加倍检查：

一个名为KeyOnNode：属性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：属性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：

图索引的名称必须是唯一的。构建的图索引新定义的属性键，即在其中定义的属性键与索引相同的管理事务，立即生效可用。针对已经存在的属性键构建的图索引在使用中需要执行reindex过程以确保 index包含以前添加的所有元素。直到重新索引程序已经完成，索引将无法使用。它是鼓励在与同一事务中定义图索引初始架构。
索引可能会超时从REGISTERED移动到INSTALLED的过程，在这种情况下您要使用mgmt.awaitGraphIndexStatus()。您甚至可以指定您愿意在此等待的时间。
确保您的图表上没有未结交易，或者索引状态确实不会改变，如here所述。
对你来说显然不是这种情况，但Titan中存在一个错误（通过this PR在JanusGraph中修复），这样如果你创建一个针对新创建的propertyKey的索引以及之前的错误使用propertyKey，索引将陷入REGISTERED状态
除非群集中的每个Titan / JanusGraph节点都确认索引创建，否则索引不会移动到REGISTERED。如果索引陷入INSTALLED状态，则系统中的其他节点可能无法确认索引是否存在。这可能是由于集群中另一台服务器的问题，Titan / JanusGraph用于相互通信的消息队列中的回填，或者最意外的是：存在幻像实例。每次您的服务器通过非正常的JVM关闭进程被杀死时都会发生这些情况，即kill -9服务器由于它被卡在世界垃圾收集中。如果您希望回填成为问题，this class中的注释可以提供有助于解决问题的可自定义配置选项。要检查是否存在幻像节点，请使用this function然后this function来终止虚拟实例。

Answer 2

我认为您错过了图表的配置。如果您使用后端是cassandra，则必须使用elasticsearch进行配置。如果您使用后端是hbase，则必须使用缓存进行配置。阅读下面的链接： https://docs.janusgraph.org/0.2.0/configuration.html

泰坦Db无视指数

2 个答案: