Storage Layer & Key-Value Architecture
RUSEON Core implements a Dual-Tier Storage Architecture (pkg/storage/) that strictly separates low-latency transactional state metadata from high-throughput sequential video recordings.
1. Tier 1: Embedded State Store (BadgerDB v4)
For operational state, camera registries, user credentials, and folder hierarchies, RUSEON uses BadgerDB v4 (a pure Go, embeddable LSM key-value database):
Key Schema Design:
| Namespace / Prefix | Key Format | Value Structure (JSON) |
|---|---|---|
camera: | camera:{camera_id} | CameraConfig (URL, record flags, retention, SIM phone/ICCID, tags, folders) |
tag: | tag:{tag_id} | TagConfig (ID, Name, Hex Color) |
folder: | folder:{folder_id} | FolderConfig (ID, Name, Parent ID) |
user: | user:{username} | User (Username, Bcrypt Password Hash, Role: admin/operator/viewer/service) |
BadgerDB Engine Tuning:
- Low Memory Overhead: Configured with
MemTableSize = 16MBandNumMemtables = 1. - Scheduled Value Log GC: Automated nightly cron (
0 3 * * *) executesRunValueLogGC(0.5)to compact storage and reclaim disk space. - Atomic Backup Export/Import:
GET /api/system/backup/exportstreams a complete JSON snapshot (BackupData), restored with atomic validation viaPOST /api/system/backup/import.
2. Tier 2: High-Throughput Media Store (LocalFS)
Video files are stored directly on disk in the configured recordings root:
- Directory Structure:
recordings/{camera_id}/{YYYY-MM-DD_HH-mm-ss}_to_{HH-mm-ss}.mp4 - During write:
recordings/{camera_id}/{YYYY-MM-DD_HH-mm-ss}_ongoing.mp4 - Linux Page Cache eviction via
POSIX_FADV_DONTNEEDkeeps host RAM usage strictly bounded.