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

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

我确实更改了事务缓存和数据库缓存，在所有不同的场景中性能下降仍然存在。在我的测试场景中，只有频繁提交事务才能停止性能下降，这将导致多线程情况下的某些不一致性，对于我的应用程序来说是不可接受的。如果有人能帮助我克服这种情况，我将不胜感激

到目前为止，不同情景的结果如下：

• 我在不同的场景中有一些次要的GC活动，从数百个顶点/边到数百万个顶点/边

• 提供更多堆空间不会改变GC活动和吞吐量下降。即使200k顶点/边的4g堆空间也不会改变整个下降过程；然而，从4g堆中，只有1g用于200k场景

• 更改事务缓存不会影响吞吐量下降

• 增加db缓存可以提高插入时间，但会再次降低插入时间

• 将

  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

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

---

**似乎顶点/边获取代码的一部分（当我想确定这是否是新的边/顶点时）和代码的属性部分（当我想向顶点添加一些属性时）是最耗时的部分，几乎所有吞吐量下降都是由这些部分造成的。此外，如果我尝试频繁提交事务（在我的情况下是不可能的），那么整个吞吐量下降将得到解决**

您所描述的可能是由Titan中负责

ID块分配的机制引起的

每个Titan元素--
边
、
顶点
或
属性
都由Titan在一个称为ID分配的过程中指定一个唯一的ID，其基本目的是以一种方式分配一个唯一的ID，即不会向其他元素提供该ID，尽管Titan的其他实例可能同时运行。
这是一个昂贵的过程，涉及到对
后端
存储（例如HBase）的多个请求

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

Titan每次分配一个
ID块
——这意味着，虽然Titan在本地有更多可用ID，但它可以分配元素ID，元素将快速创建，当可用ID用完时，它会通过再次联系后端来分配更多ID。这也许可以解释你所经历的性能突然下降

通过将以下设置添加到本地Titan配置文件，仅当您提交事务时，才可以使Titan分配ID：

ids.flush=false

如《泰坦号》资料来源所述：

如果为true，则顶点和边在创建时立即指定ID。如果为false，则仅当事务提交时才分配ID

我更改了上述参数，吞吐量下降不受此参数的影响，我的问题仍然存在。您能否提供有关哪个Titan方法需要很长时间才能返回的更多信息？检查顶点存在性是否至关重要？是的，我必须先检查其存在性。不建议使用数百万条记录的事务。我使用的是10000块大小。考虑添加一个专用的线程来添加只执行提交，并使其从队列中的块读取。对队列的插入可以是多线程的。