【问题标题】:Titan Db ignoring indexTitan Db 忽略索引
【发布时间】:2017-03-27 21:27:15
【问题描述】:

我有一个带有几个索引的图表。它们是两个带有标签限制的复合索引。 (两者在不同的属性/标签上完全相同)。 一个肯定似乎工作,但另一个没有。我已经完成了以下 profile() 以双重检查:

一个叫做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 边。

【问题讨论】:

    标签: titan gremlin tinkerpop tinkerpop3


    【解决方案1】:

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

    1. 如果您描述的这两个索引都不是在同一个事务中创建的(并且有问题的索引是在 name propertyKey 已经定义之后创建的),那么您应该按照 @987654321 发出重新索引@:

      图索引的名称必须是唯一的。建立的图索引 新定义的属性键,即定义在 与指数相同的管理交易,立即 可用的。针对已经存在的属性键构建的图索引 在使用中需要执行重新索引程序以确保 index 包含所有先前添加的元素。直到重新索引 程序已完成,索引将不可用。它是 鼓励在与 初始架构。

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

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

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

    5. 除非集群中的每个 Titan/JanusGraph 节点都确认创建了索引,否则索引不会移动到 REGISTERED。如果您的索引卡在INSTALLED 状态,则系统中的其他节点可能不会确认索引的存在。这可能是由于集群中另一台服务器的问题、Titan/JanusGraph 用于相互通信的消息队列中的回填,或者最出乎意料的是:幻像实例的存在。每次您的服务器通过非正常的 JVM 关闭进程被杀死时,都会发生这些情况,即 kill -9 服务器由于它被卡在世界垃圾收集中。如果您认为回填会成为问题,this class 中的 cmets 可以很好地了解可帮助解决问题的可自定义配置选项。要检查虚拟节点是否存在,请使用this function,然后使用this function 来终止虚拟实例。

    【讨论】:

    • 谢谢!我会尝试一些事情。您是否突然知道如何延长awaitGraphIndexStatus() 的超时时间?另外,我需要处于什么状态才能重新索引? INSTALLED 无法做到这一点
    • 第二个答案here 应该会为您回答这两个问题!祝你好运!
    • 我是想说先^
    • 感谢所有帮助。我在帖子中添加了第二次更新,因为我似乎无法在更改索引状态方面取得任何进展。我认为您是正确的,因为 name 是在其他标签限制索引中定义的属性,但仍然卡住...
    • 请注意,#4 中的错误已在 JanusGraph 中修复。使用this PR,您可以指定多个等待状态
    【解决方案2】:

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

    【讨论】:

      猜你喜欢
      • 2015-10-01
      • 2014-10-31
      • 1970-01-01
      • 2010-10-31
      • 2010-12-02
      • 2017-04-12
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多