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: docs/performance/SQLITE_COMPARISON.md
+41-1Lines changed: 41 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -39,8 +39,48 @@ We addressed the gaps via the following optimizations:
39
39
2.**Pinned Page Iteration**: Modifying our `HeapTable::Iterator` to hold pages pinned across slot iteration avoids repetitive atomic checks and LRU updates per-row.
40
40
3.**Batch Insert Mode**: Skipping single-row undo logs and exclusive locks to exploit pure in-memory bump allocation. This drove the `INSERT` speedup well past SQLite limits, as we write raw tuples uninterrupted.
Distributed shuffle joins send **all tuples** across the network to partitioned nodes, even when many will never match. This causes unnecessary network traffic and buffer memory usage.
46
+
47
+
### Solution: Bloom Filter Integration
48
+
Implemented bloom filters to filter tuples at the source before network transmission:
49
+
-**One-sided bloom filter**: Built from the left/build table, applied to filter the right/probe table
50
+
-**Distributed construction**: Each data node constructs its local bloom during the left/build scan phase
51
+
-**Coordinator coordination**: `BloomFilterPush` RPC broadcasts filter metadata to all nodes before the right/probe shuffle
52
+
53
+
### Architecture
54
+
```
55
+
[Phase 1: Shuffle Left] [Phase 2: Shuffle Right]
56
+
| |
57
+
v v
58
+
Build local bloom Apply bloom filter
59
+
from join keys before buffering
60
+
| |
61
+
+---- BloomFilterPush ----->---+
62
+
(filter metadata) |
63
+
v
64
+
Filtered tuples buffered
65
+
```
66
+
67
+
### Key Components
68
+
| Component | Location | Purpose |
69
+
|-----------|----------|---------|
70
+
|`BloomFilter` class |`include/common/bloom_filter.hpp`| MurmurHash3-based bloom filter |
71
+
|`BloomFilterArgs` RPC |`include/network/rpc_message.hpp`| Serialization for network transfer |
72
+
|`ClusterManager` storage |`include/common/cluster_manager.hpp`| Stores bloom filter per context |
73
+
|`PushData` handler |`src/main.cpp`| Receives and buffers filtered tuples |
74
+
|`ShuffleFragment` handler |`src/main.cpp`| Applies bloom filter before sending |
75
+
| Coordinator |`src/distributed/distributed_executor.cpp`| Broadcasts filter after Phase 1 |
Added probabilistic filtering to reduce network traffic in shuffle joins.
30
+
-**MurmurHash3-based BloomFilter**: Configurable false positive rate (default 1%) with optimal bit count and hash function calculation.
31
+
-**Filter Construction**: Built during Phase 1 scan, stored in `ClusterManager` per context.
32
+
-**Filter Application**: `PushData` handler checks `might_contain()` before buffering, skipping tuples that will definitely not match.
33
+
27
34
## Lessons Learned
28
35
- Shuffle joins significantly reduce network traffic compared to broadcast joins for large-to-large table joins.
29
36
- Fine-grained locking in the shuffle buffers is critical for maintaining high throughput during the redistribution phase.
37
+
- Bloom filters provide significant network traffic reduction when join selectivity is low, at the cost of a small false positive rate (typically <1%).
30
38
31
39
## Status: 100% Test Pass
32
40
Verified the end-to-end shuffle join flow, including multi-node data movement and final result merging, through automated integration tests.
41
+
- 10 unit tests for bloom filter implementation and integration (`tests/bloom_filter_test.cpp`)
0 commit comments