Titan DB的一些问题

使用熟悉一点的系统来测试TitanDB，HBASE+ES，记录下来一些小tips。

1、首先TitanDB支持的Hadoop只有1.2.1，所以Hbase自然也只能取到0.98，虽然官网上提供了titan-1.0-hadoop2，但是并不好用，向hbase存数据时会报错，原因是因为hadoop1的configure格式和hadoop2的不同，创建的config hbase和hadoop没法用，只能退回到上述版本。（ES包是1.5.1，建议使用1.5.2避免奇怪的错误）

2、使用gremlin按照官方文档上的方法进行添加索引(参照官方文档第8节)

mgmt = graph.openManagement()
name = mgmt.getPropertyKey('name')
age = mgmt.getPropertyKey('age')
mgmt.buildIndex('byNameComposite', Vertex.class).addKey(name).buildCompositeIndex()
mgmt.buildIndex('byNameAndAgeComposite', Vertex.class).addKey(name).addKey(age).buildCompositeIndex()
mgmt.commit()
//Wait for the index to become available
mgmt.awaitGraphIndexStatus(graph, 'byNameComposite').call()
mgmt.awaitGraphIndexStatus(graph, 'byNameAndAgeComposite').call()
//Reindex the existing data
mgmt = graph.openManagement()
mgmt.updateIndex(mgmt.getGraphIndex("byNameComposite"), SchemaAction.REINDEX).get()
mgmt.updateIndex(mgmt.getGraphIndex("byNameAndAgeComposite"), SchemaAction.REINDEX).get()
mgmt.commit()

　在执行完mgmt.commit()之后，第一个事物会关闭，一定要重新开一个management才能使用updateIndex。这和0.5.1版本不同

3、JAVA API在添加索引这里有个问题，titan建索引大致是这样：

　　（1）创建一个空索引，将其状态设置为registered（mgmt.buildIndex('byNameComposite', Vertex.class).addKey(name).buildCompositeIndex()）

　　（2）修改索引状态，将其状态设置为install（mgmt.awaitGraphIndexStatus(graph, 'byNameComposite').call()）

　　（3）将表中现有数据reindex（mgmt.updateIndex(mgmt.getGraphIndex("byNameComposite"), SchemaAction.REINDEX).get()）

　　JAVA API中没有找到将索引状态转化为install的方法，还在摸索。但是使用gremlin创建的索引在java使用查询时是可以正确使用的。

　　这个titan由于活跃度较低，用eclipse import mvn project的方式导入出了各种各样的错误，最后只能用最原始的办法：下载源码包，然后将所有依赖包加进来，虽然还有编译错误，但是至少不影响代码阅读了，找到了Titanfactory.open方法，发现如下：

    public static TitanGraph open(ReadConfiguration configuration) {
        return new StandardTitanGraph(new GraphDatabaseConfiguration(configuration));
    }

　　找到StandardTitanGraph的openManagement方法

    public TitanManagement openManagement() {
        return new ManagementSystem(this,backend.getGlobalSystemConfig(),backend.getSystemMgmtLog(), mgmtLogger, schemaCache);
    }

　　好吧，原来是TitanManagement的子类，找到ManagementSystem类，查看其源码发现：

    public static GraphIndexStatusWatcher awaitGraphIndexStatus(TitanGraph g, String graphIndexName) {
        return new GraphIndexStatusWatcher(g, graphIndexName);
    }

　　原来还是个静态方法，在gremlin中使用的个mgmt.awaitGraphIndexStatus来更改index状态，而在api中是调用静态方法ManagementSystem.awaitGraphIndexStatus(g, indexname)来更改的。。

　　不过感觉有点奇怪，我使用updateindex方法更改其状态，titan竟然是把这个更改放在了触发器里而不是直接更改，按理说在不commit的时候是不会涉及到修改底层数据的，为什么要做成触发而且写在log类里？

　　现在一套走下来没什么问题了，Titan+HBASE+ES的代码如下（scala）：

    val g = TitanFactory.open(conf)
    var mgmt = g.openManagement
    val name = mgmt getPropertyKey "movieId"
    var index = mgmt.buildIndex("movie2WIndex666", classOf[Vertex]).addKey(name).buildCompositeIndex
    mgmt.updateIndex(index, SchemaAction.REGISTER_INDEX)
    mgmt.commit
    val ms = ManagementSystem.awaitGraphIndexStatus(g, "movie2WIndex666").call
    println(ms.getTargetStatus)
    mgmt = g.openManagement
    index = mgmt.getGraphIndex("movie2WIndex666")
    println(index.getIndexStatus(name))
    mgmt.updateIndex(index,  SchemaAction.REINDEX).get
    mgmt.commit
    val res = g.traversal().V().has("movieId",12345).out()
    println(res)
    g.close　　

4、这个和HBASE连接使用的时get方法，每次get一条数据，所以在没索引的前提下1秒只能检索100条左右的数据，测试时18万条的数据做一遍g.V().has(XX)需要34分钟左右，建立好索引的话查询一条只需要200ms左右。

　　建立索引时也是做一遍scan（这里是逐条get），所以百万级的数据对一个属性做CompositeIndex需要好几个小时- -mix索引和更大规模的数据集总感觉有点不对劲。

5、由于上述原因，hbase的连接超时要设置的很长，目前我设置的为180000秒，配置文件如下。

<property>
 <name>hbase.rootdir</name>
 <value>hdfs://cloud12:9000/hbase</value>
</property>
<property>
 <name>hbase.cluster.distributed</name>
 <value>true</value>
</property>
 <property>
 <name>hbase.master</name>
 <value>cloud12:60000</value>
 </property>
 <property>
 <name>hbase.zookeeper.property.dataDir</name>
 <value>/home/Titan/hbase/zookeeperDir</value>
 </property>
 <property>
 <name>hbase.zookeeper.quorum</name>
 <value>192.168.12.148</value>
 </property>
 <property>
 <name>hbase.regionserver.lease.period</name>
 <value>180000000</value>
 </property>
 <property>
 <name>hbase.rpc.timeout</name>
 <value>180000000</value>
 </property>