泰坦Db无视指数

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

所以这里有一些事情可以发生:

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

   图索引的名称必须是唯一的.针对新定义的属性键构建的图索引,即在与索引相同的管理事务中定义的属性键,可立即使用.针对已在使用的属性键构建的图索引需要执行reindex过程以确保索引包含所有先前添加的元素.在reindex过程完成之前,索引将不可用.建议在与初始模式相同的事务中定义图索引.

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

3. 确保有你的图形或索引状态的确会不会改变没有打开的事务,如所描述这里.

4. 这显然不是你的情况,但是Titan中存在一个错误(通过此PR在JanusGraph中修复),这样如果你针对新创建的propertyKey以及之前使用的propertyKey创建索引,索引将陷入困境的REGISTERED状态

5. REGISTERED除非群集中的每个Titan/JanusGraph节点都确认索引创建,否则索引不会移动到.如果索引陷入INSTALLED状态,系统中的其他节点可能无法确认索引是否存在.这可能是由于集群中另一台服务器的问题,Titan/JanusGraph用于相互通信的消息队列中的回填,或者最意外的是:存在幻像实例.每次你的服务器被非正常的JVM关闭进程杀死时都会发生这些情况,即kill -9服务器由于它被卡在世界垃圾收集中.如果您希望回填成为问题,则此类中的注释可提供对可自定义配置选项的深入了解,这些选项可能有助于解决问题.要检查是否存在幻像节点,请使用此函数然后使用此函数来终止幻像实例.