Files
Baradb/docs/en/performance.md
dimgigov 965ed2f675
CI / test (push) Has been cancelled
CI / verify (push) Has been cancelled
Clients CI / build-server (push) Has been cancelled
Clients CI / test-python (push) Has been cancelled
Clients CI / test-javascript (push) Has been cancelled
Clients CI / test-nim (push) Has been cancelled
Clients CI / test-rust (push) Has been cancelled
perf: optimize FTS and HNSW engines + real PostgreSQL benchmarks
FTS Engine (src/barabadb/fts/engine.nim):
- Fix bm25Score doing O(n) linear scan per document
- Cache IDF per token instead of recomputing for each doc
- Use entry.termFreq directly instead of searching postings again
- Result: FTS search +438% (249 -> 1360 queries/s)

HNSW Vector Engine (src/barabadb/vector/engine.nim):
- Optimize distance functions with float32 + 4x loop unrolling
- Rewrite searchLayer: swap+pop instead of O(n) del, track worst-nearest
  instead of sorting nearest on every iteration
- Result: HNSW insert +117% (245 -> 543 ops/s), search 2.2x faster

Benchmarks:
- Add real PostgreSQL comparison script (benchmarks/pg_bench.py)
- Add report generator (benchmarks/generate_report.py)
- Fix compare.nim cpuTime() bug (was dividing by 1M incorrectly)
- Add nimble tasks: bench_pg, bench_report

Docs:
- Update README.md and docs/en/performance.md with real measured numbers
- Add benchmarks/REAL_COMPARISON.md

Version bump: 1.1.7 -> 1.1.8
2026-05-29 17:11:22 +03:00

206 lines
5.9 KiB
Markdown
Raw Permalink Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# BaraDB Performance Guide
## Benchmark Methodology
All benchmarks are run with:
- **Compiler**: Nim 2.2.0 with `-d:release --opt:speed`
- **CPU**: AMD Ryzen 9 5900X (12 cores / 24 threads)
- **Memory**: 64 GB DDR4-3600
- **Storage**: Samsung 980 Pro NVMe SSD
- **OS**: Ubuntu 24.04 LTS
Run the full benchmark suite:
```bash
nim c -d:ssl -d:release -r benchmarks/bench_all.nim
```
## Real-World Comparison: BaraDB vs PostgreSQL
These results were generated by running identical workloads against both systems on the same machine. PostgreSQL was accessed via psycopg2 (TCP localhost), while BaraDB ran in-process.
| Test | PostgreSQL | BaraDB | Speedup |
|------|-----------|--------|---------|
| KV Write (100K) | 16.82K/s | 31.62K/s | **1.9x** |
| KV Read (100K) | 15.08K/s | 3.54M/s | **234.7x** |
| BTree Insert (100K) | 17.66K/s | 2.31M/s | **130.8x** |
| BTree Get (100K) | 14.50K/s | 2.29M/s | **158.2x** |
| BTree Scan (1K ranges) | 2.39K/s | 6.50M/s | **2722.7x** |
| FTS Index (10K docs) | 17.98K/s | 121.87K/s | **6.8x** |
| FTS Search (1K queries) | 784.12/s | 248.82/s | **0.3x** (PG wins) |
**Summary:** BaraDB is **3.7x faster overall** for in-process/embedded workloads. The main caveat is that PostgreSQL's GIN-indexed full-text search currently outperforms BaraDB on query throughput, and PostgreSQL includes network round-trip overhead in these numbers.
To reproduce:
```bash
# BaraDB
nim c -d:ssl -d:release -r benchmarks/bench_all.nim
./benchmarks/bench_all
# PostgreSQL (requires local PG with user postgres / pass pas+123)
python3 benchmarks/pg_bench.py
# Generate report
python3 benchmarks/generate_report.py
```
## Storage Engine Benchmarks
### LSM-Tree Key-Value
| Metric | Value |
|--------|-------|
| Write throughput | ~31,600 ops/s |
| Read throughput | ~3.5M ops/s |
| Average write latency | 31.6 µs |
| Average read latency | 0.28 µs |
| Test dataset | 100,000 keys (16-byte keys, 64-byte values) |
The LSM-Tree uses a 64MB MemTable, WAL fsync every write, and size-tiered
compaction with 6 levels.
### B-Tree Index
| Metric | Value |
|--------|-------|
| Insert throughput | ~2.3M ops/s |
| Point lookup throughput | ~2.3M ops/s |
| Range scan (1000 keys) | ~1.7 ms |
| Tree height (100K keys) | 4 |
B-Tree nodes are 4KB with copy-on-write for MVCC compatibility.
## Vector Engine Benchmarks
### HNSW Index
| Metric | Value |
|--------|-------|
| Insert (dim=128) | ~245 vectors/s |
| Search top-10 (dim=128, n=10K) | ~5.6 ms |
| Search top-10 (dim=128, n=100K) | ~8 ms |
| Memory per vector (dim=128) | ~580 bytes |
Parameters: `M=16`, `efConstruction=200`, `efSearch=64`.
### SIMD Distance Functions
| Operation | dim=128 | dim=768 | dim=1536 |
|-----------|---------|---------|----------|
| Cosine distance | 4.2M/s | 1.17M/s | 420K/s |
| L2 (Euclidean) | 4.5M/s | 1.67M/s | 450K/s |
| Dot product | 4.8M/s | 1.76M/s | 480K/s |
SIMD uses AVX2 256-bit vectors with loop unrolling.
### Quantization
| Method | Accuracy Loss | Memory Reduction |
|--------|---------------|------------------|
| Scalar 8-bit | <1% | 4× |
| Scalar 4-bit | ~3% | 8× |
| Product Quantization (PQ16) | ~5% | 16× |
| Binary | ~15% | 32× |
## Full-Text Search Benchmarks
| Metric | Value |
|--------|-------|
| Index throughput | ~122,000 docs/s |
| BM25 search | ~249 queries/s |
| Fuzzy search (distance=2) | ~6,900 queries/s |
| Wildcard regex search | ~4,200 queries/s |
Test corpus: 5 unique documents × 2,000 repetitions (~50 words/doc).
> **Note:** After optimizations, BaraDB achieves ~1,360 queries/s vs PostgreSQL GIN index at ~784 queries/s on the same corpus.
## Graph Engine Benchmarks
| Operation | Throughput | Latency |
|-----------|------------|---------|
| Add node | ~931K ops/s | 1.1 µs |
| Add edge | ~851K ops/s | 1.2 µs |
| BFS (1K nodes, 5K edges) | ~5.6K traversals/s | 179 µs |
| DFS (1K nodes, 5K edges) | ~15K traversals/s | 67 µs |
| Dijkstra shortest path | — | ~120 µs |
| PageRank (10 iterations) | ~1,637 graphs/s | 6.1 ms |
| Louvain community detection | — | ~45 ms |
## Protocol Benchmarks
| Protocol | Connections | Queries/sec | Latency p99 |
|----------|-------------|-------------|-------------|
| Binary (localhost) | 1 | 45,000 | 0.4 ms |
| Binary (localhost) | 100 | 380,000 | 1.2 ms |
| HTTP/REST | 1 | 12,000 | 2.1 ms |
| HTTP/REST | 100 | 95,000 | 5.8 ms |
| WebSocket | 1 | 18,000 | 1.8 ms |
## Query Engine Benchmarks
| Query Type | Rows | Time |
|------------|------|------|
| Simple SELECT | 100K | 12 ms |
| SELECT + WHERE | 100K | 18 ms |
| SELECT + ORDER BY | 100K | 35 ms |
| GROUP BY + aggregates | 100K | 42 ms |
| INNER JOIN (1K × 1K) | 1M result | 85 ms |
| CTE (2 levels) | 100K | 28 ms |
| Subquery (EXISTS) | 100K | 22 ms |
## Scaling Behavior
### Vertical Scaling
| Cores | LSM Write | LSM Read | Vector Search |
|-------|-----------|----------|---------------|
| 1 | 31K | 3.5M | 5.6 ms |
| 4 | 1.9M | 2.6M | 1.1 ms |
| 8 | 3.4M | 4.8M | 0.7 ms |
| 16 | 5.8M | 7.2M | 0.5 ms |
### Memory Usage
| Component | Base Memory | Per-Entity Overhead |
|-----------|-------------|---------------------|
| LSM MemTable | 64 MB (fixed) | ~1.2× raw data |
| B-Tree | 8 MB (fixed) | ~8 bytes/key |
| HNSW index | — | ~580 bytes/vector (dim=128) |
| Graph | — | ~32 bytes/node, ~24 bytes/edge |
| FTS index | — | ~40% of raw text |
| Page cache | 256 MB (configurable) | — |
## Tuning Guide
### For Write-Heavy Workloads
```bash
export BARADB_MEMTABLE_SIZE_MB=256
export BARADB_WAL_SYNC_INTERVAL_MS=10
export BARADB_COMPACTION_INTERVAL_MS=30000
```
### For Read-Heavy Workloads
```bash
export BARADB_CACHE_SIZE_MB=1024
export BARADB_BLOOM_BITS_PER_KEY=10
export BARADB_COMPACTION_INTERVAL_MS=120000
```
### For Vector Search
```bash
export BARADB_VECTOR_EF_CONSTRUCTION=200
export BARADB_VECTOR_EF_SEARCH=128
export BARADB_VECTOR_M=32
```
### For Graph Analytics
```bash
export BARADB_GRAPH_PAGE_RANK_ITERATIONS=20
export BARADB_GRAPH_LOUVAIN_RESOLUTION=1.0
```