[Question] Want OLTP multi-process design doc

[SkrDrag]

Feature Description (功能描述)

那个pr #2312 里的设计文档无法查看

[DanGuge]

WIP，这两天会更新到wiki中

[SkrDrag]

WIP，这两天会更新到wiki中

感谢！

[DanGuge]

https://github.com/hugegraph/hugegraph/wiki/OLTP-multi%E2%80%90thread-Design-Doc

[SkrDrag]

”目前在Kout和Kneighbor中完成了并行执行的实现，主要通过KoutRecords和KneighborRecords自带的并发控制完成控制“
您好啊，我想请问一下这个自带的并发控制，是将任务提交到阻塞队列中，按顺序调度吗。具体是个什么并发控制方法啊

[DanGuge]

• 这个并发执行只会发生在以BFS的搜索策略中
  • 在BFS中每一层的节点对应的边的遍历是独立的，所以它们才可以并行执行
  • 假设在搜索中设定寻找深度为depth的邻居，那么在每一层都会先对该层的节点的边进行收集，假设该层有k个节点，那么就可以有k个可以遍历的边的迭代器iterator<Edge>，这几个iterator是可以并发搜索的，最终会进行depth-1次的并发执行
• 这里的并发控制，主要指容器线程安全，比如节点c为上一层另外两个节点a和b的邻边，同时设置了nearest为True，需要找最近的路径，其实a->c和b->c都符合
  • 在串行的执行中，先遍历了a节点，那么c节点就会作为a的后继节点，而b->c这个会因为已经搜索过c标记为visited，就跳过
  • 在并行的执行中，我们需要保证c只会出现在a或者b的后继，而不是两个都保留，所以在记录搜索过了的时候，依赖了KoutRecords和KneighborRecords中的安全容器来实现

[SkrDrag]

感谢您的耐心解答啊。我还想问的是一层有K个节点，有K个可以遍历的边的迭代器iterator，这几个任务提交到consumer之后，任务数大于线程池中的数量时。任务是阻塞在队列中吗？对于任务调度的方式是否有能优化的空间啊？
或者是说对于OLTP算法的多线程并行优化，您觉得哪里存在问题和优化的空间呢？ 感谢您的赐教！

[DanGuge]

hugegraph的consumer是对java的ThreadPoolExecutor进行了一层封装，本质都是使用ThreadPoolExecutor的接口的，所以当任务大于线程池中的数量时，是会被阻塞住的，对于任务调度的话，主要取决于具体的应用场景和需求，可以看看以下部分：

1. 调整线程池的大小，hugegraph中默认的线程池中线程数量依赖于可使用的CPU数量；
2. 调整队列类型，hugegraph中使用的是有界队列（ArrayBlockingQueue），最大值设置为 num_threads * QUEUE_WORKER_SIZE(1000)，这个也可以手动调整；
3. 可以制定一些调度策略，比如给任务添加优先级等，满足重要任务优先调度，同时设置有界队列来防止资源耗尽

• 具体代码：https://github.com/apache/incubator-hugegraph/blob/master/hugegraph-server/hugegraph-core/src/main/java/org/apache/hugegraph/job/algorithm/Consumers.java#L59

[SkrDrag]

感谢您的解答和建议！

[simon824]

Is there any test report on how much performance has been improved?