Titan Db忽略索引

Question

我有一张有几个指数的图表。这是两个带有标签约束的综合指数。(在不同的属性/标签上两者完全相同)。其中一种看起来确实有效，但另一种则不起作用。我做了下面的配置文件()来加倍检查：

一个名为KeyOnNode：property uid和label 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和label 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状态，并且仍然处于超时状态。我检查过没有公开的交易。有人有主意吗？图运行在一个服务器上，有~100 K顶点和~130 k边。

Answer 1

所以这里有几件事情可以发生：

1. 如果您描述的这两个索引都不是在同一个事务中创建的(并且问题索引是在name propertyKey定义之后创建的)，那么您应该按照土卫六博士发出一个重新索引： 图形索引的名称必须是唯一的。根据新定义的属性键(即在与索引相同的管理事务中定义的属性键)构建的图形索引立即可用。根据已经使用的属性键生成的图形索引需要执行重新索引过程，以确保索引包含以前添加的所有元素。在重新索引过程完成之前，索引将不可用。鼓励在与初始模式相同的事务中定义图形索引。
2. 索引可能会超时从REGISTERED迁移到INSTALLED所需的进程，在这种情况下，您希望使用mgmt.awaitGraphIndexStatus()。您甚至可以指定您愿意在这里等待的时间。
3. 确保您的图形上没有打开的事务，否则索引状态确实不会改变，正如这里所描述的那样。
4. 显然不是这样，但是Titan中有一个bug (通过JanusGraph通过这个公关修复)，如果您针对新创建的propertyKey以及以前使用的propertyKey创建索引，索引将陷入REGISTERED状态。
5. 索引不会移动到REGISTERED，除非集群中的每个Titan/JanusGraph节点都确认创建了索引。如果您的索引处于INSTALLED状态，则系统中的其他节点有可能不承认索引的存在。这可能是由于集群中的另一台服务器出现了问题，Titan/JanusGraph用来相互交谈的消息队列的回填，或者最出乎意料的是:幻影实例的存在。每次您的服务器通过非正常的JVM关闭进程被杀死时，都会发生这种情况，例如，由于服务器被困在世界垃圾收集中，所以kill -9服务器。如果您希望回填是问题，那么这个类中的注释可以很好地洞察可自定义的配置选项，这些配置选项可能有助于解决问题。若要检查幻影节点的存在，请使用这一功能，然后使用这一功能来杀死幻影实例。

Answer 2

我想你错过了图形的配置。如果使用后端为cassandra，则必须使用elasticsearch进行配置。如果使用后端是hbase，则必须配置缓存。在下面的链接中阅读更多内容：https://docs.janusgraph.org/0.2.0/configuration.html