Hacktoberfest 2026:维护者为十月标记出来的 issue,仍然开放、适合新手。 浏览 Hacktoberfest issue

[Feature] The gaph in-memory projection and and its corresponding algorithm

未关闭
#2,359 5 条评论 4 个 reaction 已指派 1 人 在 GitHub 查看

维护者通常 1 天内回复

@javeme 已经在做这个了。

开始于 2023年11月22日。

评估

这个 Issue 还没有评估数据。

描述

feature
Feature Description (功能描述)

问题描述

我司决定采用HugeGraph作为数据库,并在使用过程中需要频繁调用s-t最短路径,但是我发现最短路径算法性能在大图中很慢几乎无法使用。为了优化算法,我参考了Neo4j GDS,并在内存中实现了针对s-t边的持久化投影以重新实现了源到目标的迪杰斯特拉算法,同时还进行了一些基本的优化,包括优化的优先队列等。这些改进使得投影后的源到目标迪杰斯特拉算法的执行时间稳定在毫秒级。

我希望将我的代码贡献到HugeGraph中,以便更多用户受益于这些性能优化。

目前的问题

目前,我的代码(包括图的投影和基于投影的迪杰斯特拉算法)都存放在 hugegraph-core/src/main/java/org/apache/hugegraph/traversal 目录下。然而,我认为这不够合理,至少对于图的投影而言,因为可以优化更多的算法,应该将其放置在一个更大的包中。

提议

我希望将我的代码重新组织,并将图的投影放置在一个更合适的大包中。然而,我对于在HugeGraph中的代码组织结构并不了解,所以我需要一些建议。

具体来说,我想知道:

  1. 在HugeGraph中,应该将图在内存中持久化投影的代码放在哪个目录?
  2. 是否有任何特定的代码组织规范或命名约定我需要遵循?
  3. 是否需要对HugeGraph的核心代码进行修改以适应我的贡献?
    感谢您的指导和建议,我期待将这些性能优化的代码成功融入HugeGraph中。
主要语言
Java
星标
3.2k
派生
641
平均合并
2 天 4 小时
30 天内合并 PR
31

环境准备

从这里开始

  1. 先读完整个 Issue,再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库,在一个分支上完成修改。
  4. 提交 Pull Request,并在描述里引用这个 Issue 编号。

apache/hugegraph 的其他 Issue

查看 apache/hugegraph 的全部 Issue

相似的 Issue

更多 Java Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。