You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+5-2Lines changed: 5 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -4,8 +4,9 @@
4
4
- native support for (e)utxo and account based chains
5
5
- native tokens/asset support
6
6
- 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)
7
8
- 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 :
9
10
- BTC
10
11
- 4 hours with 0.4TB disk space and 8GB RAM
11
12
- ETH
@@ -342,7 +343,9 @@ The same api is accessible through http endpoints at http://127.0.0.1:3033/swagg
342
343
343
344
**Why sharding?**
344
345
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
346
349
- BTrees do not have good write throughput when they grow very large (eg. billions of entries).
347
350
- Evenly distributed range sharding with round‑robin merge at query time fixes this problem.
0 commit comments