Titan添加顶点，事务吞吐量的边缘在提交事务之前随着时间的推移而下降

Question

关于将顶点/边缘插入Titan图形db 1.0;我做了批量插入。这意味着所需的子图将被添加到事务中，并且在同一个事务中插入整个子图之后它将被提交。我的问题是，Titan在反复插入顶点/边缘到同一个事务上显示出奇怪的性能（提交事务之前）。首先，整体吞吐量为每秒400个边/顶点，但根据子图的大小，每分钟将降至小于1个边/顶点！ （请注意，性能下降是通过事务添加/更新边缘/顶点，存储后端尚未涉及。）

我确实更改了事务缓存和db-cache，并且性能下降仍然存在于所有不同的场景。在我的测试场景中，性能下降只是通过频繁提交事务来停止，这会导致多线程情况下的一些不一致，并且不适用于我的应用程序。如果有人能帮助我克服这种情况，我会很感激。

到目前为止，不同场景的结果：

• 我在不同的场景有些轻微的GC活动，从顶点/边几百到顶点/边缘万元。

• 给予更多的堆空间没有改变GC活动和吞吐量落下。对于200k的顶点/边，即使4g的堆空间也不会改变整个下降;然而，从4g堆只有1g用于200k场景。

• 更改事务高速缓存不影响吞吐量下降。

• 增加数据库缓存提高在首位的插入时间，但整个再度回落。

• 更改ids.flush到false不影响吞吐量下降。

GC活动图：

CPU活动图：

对整个操作的一些信息：

之前增加边/顶点的交易，它会进行检查数据库中不存在具有相同标识符的边/顶点，如果边/顶点是全新的，它将被添加到事务中所有属性。我做了一些调查，似乎让我的一部分操作（检查边缘/顶点的存在）增加，但插入时间几乎是恒定的。

我泰坦配置：

storage.backend=cassandrathrift 
storage.hostname=127.0.0.1 
cache.db-cache = true 
cache.db-cache-clean-wait = 20 
cache.db-cache-time = 180000 
cache.db-cache-size = 0.25 
index.search.backend=solr 
index.search.solr.mode=http 
index.search.solr.http-urls=http://localhost:8983/solr/ 
schema.default=none 
index.search.solr.wait-searcher=false 
query.force-index=true 
query.batch=true 
query.fast-property=true 
cache.tx-cache-size=4000000 

关于我的问题的一些新的事实：

**似乎顶点/边让我的代码部分（当我要确保这是一个新的edge/vertex或不），以及代码的属性部分（当我想添加一些属性到顶点）是最耗时的部分，几乎所有的吞吐量下降都是由这些部分导致的。而且，如果我试图频繁地提交事务，整个吞吐量的下降将会得到解决，这在我的情况下是不可能的。 **

Answer 1

你所描述的可能是由Titan中一个负责ID Blocks allocation的机制造成的。

每个泰坦元件 - edge，vertex或property是由Titan赋予唯一的ID，在这个过程被称为ID分配 - 基本上意图的方式分配一个唯一的ID没有其他元件将给出ID，但是泰坦的其他实例可能会同时运行。 这是一个昂贵的过程，涉及多个请求到您的backend商店（例如HBase）。

默认情况下，Titan会在您创建元素时将元素ID分配给元素。这可能会成为严重的性能瓶颈。

泰坦每次分配一个block的ID - 这意味着虽然T​​itan在本地拥有更多可用ID，但它可以分配元素ID，并且元素将被快速创建，并且当元素用完ID可用时，它会通过联系后端再次。这可能会解释您遇到的突然性能下降。

你可以让泰坦分配的ID，只有当你commit a transaction，通过添加以下设置到本地泰坦配置文件：

为真时，顶点：

ids.flush=false 

由于土卫六上的源提到创建时立即为边缘分配ID。如果为false，则仅在事务提交时分配ID。