使用OrientDB扩展时的性能问题

我们正试图在分布式模式下扩展OrientDB,但面临性能瓶颈。

数据模型和处理方法:

Vertices 属于 two types 到处都是 10 to 15 properties 在他们身上 edges 属于 只有 3 properties 在他们身上。服务使用来自的子图消息 16 kafka threads 并行执行读取/更新/创建操作 concurrently

我们正在使用 Graph API (orient graph的蓝图实现)。目前要处理一个子图,我们使用一个图 transactional graph pool 250 instances 与数据库远程连接。在处理完更新/创建 transaction is committed only once .

性能瓶颈

我们目前只能处理 15K 16 threads 和 OrientDB v2.2.35 以分布式模式运行。

1. 当在单线程上处理子图消息时,大约需要10ms(大约35次读取、15次更新和20次创建操作),但是当并发处理到20-45ms时,它会呈指数级增长。

2. https://github.com/orientechnologies/orientdb/issues/8427 B、 试过了 OrientDB 2.2.35 standalone OrientDB及其并发调用 20-45ms 处理子图。鉴于,在 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

向上插入以创建边

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