chronix_engine/storage/
mod.rs

1//! # chronix-storage
2//!
3//! Pluggable storage backend for the Chronix time-series database.
4//!
5//! This module defines the [`StorageBackend`] trait that abstracts segment
6//! file storage. It has **one** implementation,
7//! [`ObjectStoreBackend`](crate::objstore::ObjectStoreBackend) — the cold
8//! tier — because the hot path does not go through it: a flush hands an
9//! absolute path to [`SegmentWriter`](crate::segment::SegmentWriter) and a
10//! read `mmap`s the file.
11//!
12//! It used to have two more, and both were reachable from nowhere. A
13//! `LocalFsBackend` reimplemented the hot path's file I/O behind the async
14//! trait and nothing called it. An `EncryptingBackend` wrapped any backend in
15//! AES-256-GCM and nothing called that either — and because the trait is only
16//! implemented by the cold tier, the most it could ever have encrypted is the
17//! objects a bucket already encrypts server-side. The documentation described
18//! it as Chronix's encryption at rest, down to a configuration key
19//! (`storage.encryption.enabled`) that has never existed.
20//!
21//! ## Architecture
22//!
23//! Object keys are namespace-scoped and shard-based, for defence-in-depth
24//! tenant isolation:
25//! ```text
26//! ns_{namespace}/shard_{id}/segment_name.csx
27//! ```
28//!
29//! The storage backend is `Send + Sync + 'static` for use across async tasks.
30
31#![warn(missing_docs)]
32#![deny(unsafe_code)]
33
34pub mod backend;
35pub mod error;
36
37pub use backend::{SegmentPath, StorageBackend};
38pub use error::StorageError;
chronix_engine/storage/mod.rs

chronix_engine/storage/
mod.rs
