OxiRS Cluster
Status: v0.4.0 - Released 2026-07-19 (1868 tests passing)
✨ Production Release: Production-ready with API stability guarantees and comprehensive testing.
A high-performance, distributed RDF storage system using Raft consensus for horizontal scaling and fault tolerance. Part of the OxiRS ecosystem providing a JVM-free alternative to Apache Jena + Fuseki with enhanced clustering capabilities.
Features
- Raft Consensus: Strong consistency with automated leader election and log replication
- Byzantine Fault Tolerance (opt-in): a closed-loop PBFT path behind the
bftfeature andNodeConfig.use_bft(v0.4.0) — commits are idempotent (extra commits past quorum never re-execute), a committedRdfCommandis applied to the real storage backend and returns a realRdfResponse, andprocess_requestcompletes on a genuine 2f+1 quorum via a(client_id, timestamp)-keyed commit callback (configurable timeout). Requestinguse_bfton a build compiled without thebftfeature fails loud rather than silently downgrading - Horizontal Scaling: Linear performance scaling to 1000+ nodes
- High Availability: 99.9% uptime with automatic failover
- Distributed RDF Storage: Efficient partitioning and indexing of RDF triples
- SPARQL 1.2 Support: Distributed query processing with federated queries
- Enterprise Security: TLS encryption, authentication, and access control
- Operational Excellence: Comprehensive monitoring, alerting, and management tools
- Certification Suite:
certification::CertificationSuiteruns deterministic, in-memory simulations (no real sockets) validating consistency (read-your-writes, linearizability probes, convergence), partition handling (island formation, quorum loss/recovery, split-brain prevention), Raft safety invariants (leader uniqueness, log monotonicity), and SLA bounds (read/write p99 latency, throughput floor)
Architecture
┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐
│ Node A │ │ Node B │ │ Node C │
│ (Leader) │ │ (Follower) │ │ (Follower) │
├─────────────────┤ ├─────────────────┤ ├─────────────────┤
│ Raft Consensus │◄─┤ Raft Consensus │◄─┤ Raft Consensus │
│ RDF Storage │ │ RDF Storage │ │ RDF Storage │
│ Query Engine │ │ Query Engine │ │ Query Engine │
│ Network Layer │ │ Network Layer │ │ Network Layer │
└─────────────────┘ └─────────────────┘ └─────────────────┘
Core Components
- Consensus Layer: Raft-based distributed consensus for strong consistency
- Storage Layer: Distributed RDF triple storage with efficient indexing
- Network Layer: High-performance inter-node communication
- Discovery Service: Automatic node registration and cluster membership
- Query Engine: Distributed SPARQL query processing
- Replication: Multi-master replication with conflict resolution
Quick Start
Prerequisites
- Rust 1.70+ (MSRV)
- Memory: 4GB+ recommended
- Network: Low-latency connection between nodes
Installation
Add to your Cargo.toml:
# Experimental feature
[]
= "0.3.2"
Basic Usage
use ;
async
Multi-Node Cluster Setup
oxirs-cluster is a library crate — it does not bundle a multi-node launcher
binary. Wire NodeConfig/DistributedStore into your own binary (or a test
harness), giving each node a distinct node_id and the full peer set:
// Node 1 (peers 2 and 3)
let mut n1 = new;
n1.data_dir = "./data/node1".to_string;
n1.add_peer;
n1.add_peer;
// Node 2 (peers 1 and 3)
let mut n2 = new;
n2.data_dir = "./data/node2".to_string;
n2.add_peer;
n2.add_peer;
// Node 3 (peers 1 and 2)
let mut n3 = new;
n3.data_dir = "./data/node3".to_string;
n3.add_peer;
n3.add_peer;
// Start each `DistributedStore::new(n).await?.start().await?` in its own
// process/task; Raft handles leader election among the three automatically.
Configuration
Environment Variables
OXIRS_CLUSTER_NODE_ID=node-1
OXIRS_CLUSTER_BIND_ADDR=0.0.0.0:8080
OXIRS_CLUSTER_DATA_DIR=/var/lib/oxirs
OXIRS_CLUSTER_LOG_LEVEL=info
OXIRS_CLUSTER_HEARTBEAT_INTERVAL=150ms
OXIRS_CLUSTER_ELECTION_TIMEOUT=1500ms
Configuration File (oxirs-cluster.toml)
[]
= "node-1"
= "0.0.0.0:8080"
= "/var/lib/oxirs"
[]
= "150ms"
= "1500ms"
= 10000
= 5000
[]
= 16
= 3
= "lz4"
[]
= 1000
= "30s"
= "5s"
Performance
Benchmarks
- Throughput: 10,000+ operations/second per cluster
- Latency: <100ms for read queries, <200ms for writes
- Scalability: Linear performance to 1000+ nodes
- Recovery: <30 seconds for automatic failover
Tuning
let mut config = new;
config
.add_peer
.add_peer;
let config = config
.with_discovery
.with_replication_strategy;
Raft election/heartbeat timing (election_timeout_min/_max, heartbeat_interval,
max_batch_size) defaults live in the crate-internal raft_state::RaftConfig and are not yet
exposed as NodeConfig builder methods.
Monitoring
Metrics
The cluster exposes Prometheus-compatible metrics:
oxirs_cluster_nodes_total: Total number of cluster nodesoxirs_cluster_leader_changes_total: Number of leader changesoxirs_cluster_queries_total: Total queries processedoxirs_cluster_query_duration_seconds: Query latency histogramoxirs_cluster_replication_lag_seconds: Replication lag
Health Checks
# Check cluster health
# Check node status
# Get cluster metrics
Development
Building
# Build with all features
# Run tests
# Run benchmarks
Testing
# Unit tests
# Integration tests
# Chaos engineering tests
Contributing
- Fork the repository
- Create a feature branch (
git checkout -b feature/amazing-feature) - Make your changes
- Add tests for your changes
- Ensure all tests pass (
cargo nextest run --no-fail-fast) - Run clippy (
cargo clippy --workspace --all-targets -- -D warnings) - Format your code (
cargo fmt --all) - Commit your changes (
git commit -am 'Add amazing feature') - Push to the branch (
git push origin feature/amazing-feature) - Open a Pull Request
License
This project is licensed under the Apache License, Version 2.0 - see the LICENSE file for details.
Acknowledgments
- Raft Consensus Algorithm by Diego Ongaro and John Ousterhout
- OpenRaft for Rust Raft implementation
- Apache Jena for RDF/SPARQL inspiration
- OxiGraph for RDF storage patterns
Roadmap
Post-1.0 Enhancements
- Multi-region deployment support —
region_manager,cross_dc,cross_dc_consistencymodules - Advanced conflict resolution —
conflict_resolutionmodule (CRDTs, vector clocks) - Improved monitoring dashboard —
visualization_dashboardmodule with REST API - Performance optimizations —
raft_optimization,performance_monitor, SIMD Merkle hashing - Machine learning-based query optimization —
ml_optimizationmodule (Q-learning, cost optimization) - Edge computing integration —
edge_computingmodule - Advanced security features —
security,encryption,tls,bft(Byzantine fault tolerance) modules - GraphQL federation support — cross-cluster query federation exists (
federationmodule); GraphQL-schema-level federation is a separate concern handled byoxirs-gql, not this crate
For more information, see the OxiRS documentation and TODO.md for detailed implementation progress.