Skip to content

Latest commit

 

History

2 Commits

Folders and files

NameName
Last commit message
Last commit date
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

This project investigates how to achieve high-throughput concurrent reads and writes across nested data structures without incurring heavy global lock contention. Concepts & Key Takeaways

Sharded Concurrency with DashMap: Avoids standard Mutex<HashMap> global lock bottlenecks by sharding the map across multiple internal locks.

Recursive / Nested Data Models: Implements table-in-table support using atomic reference counting (Arc<DashMap<...>>) inside a custom Value enum.

Zero-Copy Concurrent Views: Shared inner maps can be updated or read concurrently across spawned tokio tasks without requiring expensive deep clones.

Idiomatic Type Coercion: Leverages Rust's From trait implementations and custom accessor methods (as_i64, as_str, as_map) for safe type casting.

Data Architecture

The core data structure relies on a top-level shared store containing strongly-typed Value variants: Plaintext

Store (Arc<DashMap<String, Value>>) ├── "count" ──> Value::Int(42) ├── "greeting" ──> Value::Str("hello") └── "my_table" ──> Value::Map( Arc<DashMap<String, Value>> ) ├── "key1" ──> Value::Int(100) └── "key2" ──> Value::Str("value")

Rust

pub enum Value { Map(Arc<DashMap<String, Value>>), Str(String), Int(i64), }

Async Concurrency Pattern

The project demonstrates non-blocking multi-reader / multi-writer interactions running concurrently on the Tokio async runtime:

Writers: Spawned tasks dynamically swap or insert nested table instances with minimal overhead using Arc::clone.

Readers: Concurrent tasks read top-level keys and safely iterate over nested maps without blocking parallel execution paths.

Performance Verification

The implementation includes an integrated multi-threaded stress test simulating a high-throughput load (90% Reads / 10% Writes) across 10 concurrent async workers (1,000 total operations). Running the Test Bash

cargo test test_thousand_queries_performance -- --nocapture

Benchmark Metrics Plaintext

=========== PERF RESULT =========== Time taken for 1,000 queries: ~250µs - 350µs Average time per query: ~250ns - 350ns

Note: Microsecond-level latencies validate that sharded map operations remain extremely cheap under high read contention, avoiding task starvation on the thread pool.

About

super fast key value pair store

Resources

Stars

0 stars

Watchers

0 watching

Forks

Releases

Packages

Contributors

Languages