Skip to content
This repository was archived by the owner on Jan 27, 2026. It is now read-only.

Commit fc2a376

Browse files
committed
redme skip ci
1 parent 3de5b7d commit fc2a376

1 file changed

Lines changed: 5 additions & 2 deletions

File tree

README.md

Lines changed: 5 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -4,8 +4,9 @@
44
- native support for (e)utxo and account based chains
55
- native tokens/asset support
66
- multiple db engines abstraction (some chains perform better with LSM Trees, some with BTrees)
7+
- new sharding with simpler mount-point-per-shard model (because RAID0 helps only for sequential writes)
78
- balance pre-aggregations at indexing time for both utxo and account chains
8-
- indexing throughput on average with PCIe5 NVMe SSD without RAID0 :
9+
- indexing throughput on average with PCIe5 NVMe SSD :
910
- BTC
1011
- 4 hours with 0.4TB disk space and 8GB RAM
1112
- ETH
@@ -342,7 +343,9 @@ The same api is accessible through http endpoints at http://127.0.0.1:3033/swagg
342343

343344
**Why sharding?**
344345

345-
- At times of starting, RocksDB `v10.1.3` was at 50% of performance for my use case compared to `v10.7.5` due to various optimizations like parallel compression.
346+
- disk IO is ALWAYS the bottlenec
347+
- sharding (by addres in blockchains) allows for concurrent R/W to multiple ssds
348+
- write throughtput scales linearly with # of ssds
346349
- BTrees do not have good write throughput when they grow very large (eg. billions of entries).
347350
- Evenly distributed range sharding with round‑robin merge at query time fixes this problem.
348351
- If we split 2 billion addresses into 8 shards

0 commit comments

Comments
 (0)