Auto-Tuning Key-Value Storage on Raspberry Pi

ISEF Category: Systems Software

Subcategory: Databases  ·  Difficulty: Advanced  ·  Setup: Home Setup  ·  Time: Full Year

The Hook

A small change in how a database stores data can make it much faster. Think of it like choosing between piling papers on a desk and filing them in folders. Your project asks a sharp question: can software tune itself to the workload instead of using one fixed setting? That kind of adaptivity can decide whether a tiny device feels smooth or sluggish.

What Is It?

A key-value store is a database that saves pairs like a label and a value. You ask for the label, and the system gives you the value. LevelDB is one well-known embedded key-value store. Embedded means it runs inside another app or on a small device, not on a big server.

A B-epsilon-tree is a data structure built for write-heavy workloads. Data first lands in a buffer, then moves down the tree in batches. That can reduce random disk writes, which are slow on flash storage. In your project, the key idea is auto-tuning. The software watches the mix of reads and writes, then changes buffer size on the fly. You can test whether that adaptation helps more than a fixed setting on a Raspberry Pi.

Why This Is a Good Topic

This topic works well because you can measure it with real software, real workloads, and clear numbers like throughput and latency. The main variable, buffer size, is easy to change, and the workload mix gives you a clean way to test cause and effect. The project connects to real problems in phones, sensors, and edge devices, where storage speed matters. You can also learn system benchmarking, data structures, and statistical comparison.

Research Questions

• How does adaptive buffer sizing affect throughput under read-heavy, write-heavy, and mixed YCSB workloads?
• What is the effect of different fixed buffer sizes on average latency and tail latency for the same key-value workload?
• Does an online tuning policy outperform a single hand-picked buffer size across changing workload phases?
• To what extent does the B-epsilon-tree backend reduce write amplification compared with LevelDB on a Raspberry Pi?
• Which workload patterns cause the tuner to choose a buffer size that improves performance the most?
• How does storage device type, such as SD card versus USB SSD, change the benefit of adaptive buffering?

Basic Materials

• Network access for downloading workloads, tools, and documentation.

Advanced Materials

• External power meter for measuring energy use during benchmarks.

Software & Tools

• R or Jupyter Notebook: Compares runs, checks variability, and plots throughput and latency.

Experiment Steps

1. Decide how you will analyze variability, significance, and tradeoffs before you start collecting results.

Common Pitfalls

• Using too few repetitions, which makes noise from the Raspberry Pi look like a real trend.

What Makes This Competitive

A strong version of this project does more than report a speedup. You would compare several tuning rules, test multiple workload shifts, and explain why one policy wins. Better yet, you would separate read latency, write latency, and write amplification, so you know what changed and why. A careful statistical analysis across repeated runs would make the result much more convincing.

Project Variations

• Change the tuning signal from recent read-write ratio to queue depth or latency, then measure which input predicts performance best.

Learn More

• USENIX Publications: Search conference papers on embedded databases, flash storage, and database performance on small devices.