Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

[Roadmap] Incremental Rust modernization for HugeGraph core modules

Đang mở
  • Có gì không ổn?
#3,110 4 bình luận 3 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
25/100
Loại issue
Tái cấu trúc
Độ rõ ràng
Cần làm rõ
Mức độ hoạt động
Ít trao đổi
Công nghệ
java, rust
Lĩnh vực
backend, databases, distributed-systems

Hướng nghiên cứu

Đây là một roadmap cấp cha thay vì một tác vụ code cụ thể và không nêu điểm vào của file hoặc test nào. Hãy bắt đầu bằng việc đọc hướng dẫn đóng góp và checklist, sau đó chọn một ứng viên có phạm vi giới hạn, chẳng hạn như các ranh giới liên khả năng tương tác, differential fixtures hoặc benchmarks. Được xem là hoàn tất khi có một Issue con đã được phê duyệt và xác định phạm vi, cùng owner hoặc mentor, các tiêu chí về khả năng tương thích và test, benchmarks, cũng như các yêu cầu về rollout hoặc rollback.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

feature help wanted improvement

Goal

Explore an incremental Rust implementation for selected HugeGraph Server, HStore, and PD components, especially performance- or memory-sensitive paths where Rust can provide measurable safety and efficiency benefits.

This is a parent tracking issue, not a commitment to rewrite the whole server. The current implementation remains the compatibility baseline, and Java/Rust components may coexist behind stable process, protocol, or storage boundaries.

Roadmap at a glance

Toolchain foundations
        │
        v
┌─ This repository ─────────────────┐
│  Server core -> HStore -> PD      │
└───────────────────────────────────┘
        │
        v
Computer kernels -> Vermeer/OLAP

Each arrow is a review gate, not an automatic rewrite.

Proposed priority

  1. Server core
    • Begin with bounded leaf components, memory management, codecs, or performance-sensitive data structures rather than the whole request path.
    • Preserve REST/Gremlin behavior, authentication, observability, and plugin contracts.
  2. HStore
    • Evaluate storage/replication paths only after workload baselines, on-disk and wire compatibility, failure recovery, and rolling-upgrade requirements are explicit.
  3. PD
    • Evaluate scheduling and metadata components after their distributed-system invariants and compatibility contract are covered by repeatable tests.

The sequence may change based on benchmark evidence and maintainer consensus.

Delivery model

proposal/RFC -> isolated component -> differential/fault tests
             -> benchmark -> opt-in deployment -> staged adoption

Planning guardrails (required)

Before implementation starts, each child issue must define:

  • scope, owner/mentor, and non-goals;
  • API, protocol, storage-format, and operational compatibility;
  • differential, concurrency, fault-injection, and upgrade/rollback tests;
  • reproducible latency, throughput, memory, and recovery benchmarks;
  • security/dependency checks and supported platforms;
  • observability, deployment, coexistence, migration, and rollback plans;
  • explicit acceptance criteria and user/operator/contributor documentation.

No large rewrite PR should start before its design and acceptance criteria are reviewed. Correctness, recoverability, and compatibility take precedence over headline benchmark numbers. Small, reviewable PRs and stable interoperability boundaries are required; an unplanned rewrite PR may be closed or asked to return to the RFC/design stage.

Candidate work items

  • Select the first small server-side proof of concept
  • Document stable Java/Rust interoperability boundaries
  • Build shared differential and compatibility test fixtures
  • Establish representative OLTP and storage workload baselines
  • Define CI, packaging, security, and release conventions
  • Define rolling-upgrade and rollback requirements before HStore/PD work
  • Split approved work into newcomer-friendly child issues

This checklist will link to concrete child issues as proposals are accepted.

Project-wide roadmap

  • Toolchain: apache/hugegraph-toolchain#748
  • Server / HStore / PD (this issue): apache/hugegraph#3110
  • Computer / Vermeer: apache/hugegraph-computer#355
  • Documentation hub: apache/hugegraph-doc#462

How to participate

Interested in open source, Rust, databases, distributed systems, storage engines, or infrastructure? Comment with the area you want to work on and any relevant experience. RFC review, failure-model analysis, benchmarks, tests, and documentation are all valuable.

First-time contributors can start with the HugeGraph contribution guide and the repository's good first issue / help wanted tasks.

Ngôn ngữ chính
Java
Star
3.2k
Fork
640
Merge trung bình
1 ngày 10 giờ
Pull request đã merge (30 ngày)
89

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của apache/hugegraph

Tất cả issue của apache/hugegraph

Issue tương tự

Thêm issue về Java

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.