Hacktoberfest 2026:メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

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

オープン
#2,359 コメント 5 件 リアクション 4 件 担当者 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
平均マージ
1日 9時間
マージ済み PR(30日)
74

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

apache/hugegraph のほかの issue

apache/hugegraph の issue をすべて見る

似ている issue

Java の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。