Please check the build logs for more information.
See Builds for ideas on how to fix a failed build, or Metadata for how to configure docs.rs builds.
If you believe this is docs.rs' fault, open an issue.
expiring-bloom-rs
Time-Decaying Bloom Filter
A Rust implementation of a time-decaying Bloom filter with multiple storage backends and a high-performance HTTP API server.
Overview
This crate provides a Bloom filter implementation that automatically expires elements after a configurable time period using a sliding window approach. It's particularly useful for rate limiting, caching, and tracking recently seen items where older data becomes less relevant over time.
Key Features
- Time-based automatic element expiration - items naturally age out without manual intervention
- Multiple storage backends:
- In-memory for maximum performance
- ReDB persistence for durability across restarts
- Configurable false positive rate - tune memory usage vs. accuracy tradeoffs
- Multi-level sliding window design with timestamp-based expiration
- Complete API ecosystem:
- HTTP server with Swagger UI documentation
- CLI with interactive TUI mode
- Programmatic Rust API
How It Works
The time-decaying Bloom filter uses a sliding window approach with the following characteristics:
- Sub-Filters: The main Bloom filter is divided into N sub-filters (BF_1, BF_2, …, BF_N)
- Time Windows: Each sub-filter corresponds to a fixed time window T (e.g., 1 minute)
- Rotation Mechanism: Sub-filters are rotated in a circular manner to represent sliding time intervals
Operations
- Insertion: Elements are added to the current active sub-filter with timestamps
- Query: Checks for element presence across all non-expired sub-filters
- Cleanup: Automatically removes expired elements based on configured time windows
Usage
Add this to your Cargo.toml
:
[]
= "0.2"
Basic Example
use ;
use Duration;
Persistent Filter with ReDB
use ;
use ;
Using the HTTP Server
use ;
use Duration;
async
Command line interface
The crate includes a command-line interface with both command mode and an interactive TUI:
# Create a new filter
# Insert an element
# Check if an element exists
# Start interactive TUI
API Endpoints
The HTTP server provides the following REST endpoints:
GET /health
- Health check endpointPOST /items
- Insert an item into the filterGET /items/{value}
- Query if an item exists in the filterPOST /cleanup
- Manually trigger cleanup of expired items/swagger-ui
- Interactive API documentation
Configuration Options
The filter can be configured with the following parameters:
Parameter | Description | Default |
---|---|---|
capacity |
Maximum number of elements | 1,000,000 |
false_positive_rate |
Desired false positive rate | 0.01 (1%) |
level_duration |
Duration before level rotation | 60 seconds |
max_levels |
Number of filter levels | 3 |
hash_function |
Custom hash function | Combined FNV-1a/Murmur3 |
Performance
Bro, it's 🦀🦀🦀 RUST 🦀🦀🦀 and its BLAZINGLY FAST 🚀🚀🚀
Memory Usage
Memory usage is calculated as:
total_bits = capacity * max_levels
memory_bytes = total_bits * 8
Since i use u8
to store bool
.
Contributing
Contributions are welcome! Please feel free to submit a Pull Request. For major changes, please open an issue first to discuss what you would like to change.
License
This project is licensed under the MIT License - see the LICENSE file for details.