时间戳

首页 > 解决方案 > 使用 OrientDB 扩展时的性能问题

orientdb - 使用 OrientDB 扩展时的性能问题

问题描述

我们正在尝试以分布式模式扩展 OrientDB，但面临性能瓶颈。

我们的用例

数据模型和处理方法：

我们有子图消息，我们正在从 kafka 读取并持久化/附加到数据库中的图。子图消息可以在图中保存/更新多个顶点/边。这些顶点/边可能存在或不存在于数据库中，因此我们必须首先查询数据库它们是否存在。如果它们存在，我们必须检查是否有任何属性被更改，并且必须相应地执行更新操作。Verticesare of two typesand have around 10 to 15 propertiesthem，而edgesare of two typesand have only 3 propertieson them。服务并行消费子图消息16 kafka threads并执行读取/更新/创建操作concurrently。

我们正在使用Graph API（方向图的蓝图实现）。目前为了处理一个子图，我们使用transactional graph池中的一个图实例。远程与数据库连接的pool有。250 instances在处理完所有更新/创建所需的操作之后transaction is committed only once。

性能瓶颈

我们目前只能在分布式模式下15K每分钟处理大约子图消息16 threads并运行。OrientDB v2.2.35

  1. 并发性造成的性能损失：在单线程上处理子图消息时，大约需要 10 毫秒（大约 35 次读取、15 次更新和 20 次创建操作），但并发处理时它会以指数方式增加至 20-45 毫秒。

  2. 横向扩展 orient 数据库：A. 由于此错误，无法在分布式模式下运行 OrientDB v3.0.3：https ://github.com/orientechnologies/orientdb/issues/8427 B. 尝试使用OrientDB 2.2.35它。但是对于standaloneOrientDB 和并发调用，它需要20-45ms处理子图。然而，平均需要 2 个服务器节点都作为主节点运行distributed mode。100-110 ms虽然除了要花更多的时间writeQurom ，majority但有什么可以做的，以减少它。

  3. 边创建缓慢：我们注意到边创建是使用 Graph API 的繁重操作，因为它需要引用两个顶点，因此还涉及读取这些顶点以在活动事务中获取引用。

到目前为止我们已经尝试过的事情：

调优图 API

  1. 查找indexes顶点和边
  2. 声明massive insertion intent在写入方面有所改进，但在读取方面性能受到影响，因为它禁用了本地缓存。
  3. 使用定义明确schema的 .
  4. 切换off data validation：没有明显改善
  5. 禁用client level cache虽然会减少 JVM 消耗，但对性能很重要
  6. 禁用transactional logs: 没有明显改善。

调优分布式数据库集群：

  1. 使用Master-Replica模型没有明显改善。
  2. Load balancing：对数据库的并发调用和负载平衡策略设置为ROUND_ROBIN获得大量并发修改异常，从而导致重试次数增加。
  3. 开箱即用，sharding但由于其无法维护唯一索引的限制，无法在我们的用例中使用它。

Upsert 创建边缘

  1. 我们尝试使用带有边缘的 upsert，但它似乎已损坏，此时需要修复。（https://github.com/orientechnologies/orientdb/issues/8424）。

标签： orientdborientdb2.2

解决方案

推荐阅读