Crate mira_core 

Mira storage engine.

Three layers, in dependency order:

• schema — the OTAP-shaped Arrow schemas that are simultaneously the in-memory and the on-disk layout. There is no translation step.
• identity — the stable entity key that correlation joins on.
• attrs — the attribute tables and Resource-Scope preamble every signal shares.
• signal — the one shape every signal’s encoder presents to the flusher.
• logs / traces / metrics — OTLP protobuf into those schemas, with block-local id rebasing.
• block — atomic publish of immutable block directories and zero-copy mmap reads back out of them.

See docs/architecture.md for why each of those is shaped the way it is.

Re-exports

pub use error::Error;

pub use error::Result;

pub use signal::Sealed;

pub use signal::SignalBuilder;

Modules

attrs

The parts of the star schema that every signal has in common.

block

Immutable block storage.

bloom

Block-level “might contain this” filters.

error

frame

The frame algebra: correlation as a closed set of operations (section 7.3).

identity

Stable entity identity — the join key that makes correlation work across blocks.

json

A JSON writer, because the alternative is 30 crates.

logs

OTLP logs -> Arrow, one allocation-lean pass over the decoded protobuf.

metrics

OTLP metrics -> Arrow. The widest of the three signals, and the one where the layout choice is worth the most.

query

The read path: prune blocks, scan columns, materialize JSON.

schema

On-disk Arrow schemas. These follow the OTAP star schema (otap-spec.md sections 5.4 and 6.3) rather than a flattened one-row-per-span layout: a root table per signal carrying resource_id/scope_id foreign keys, plus entity-attribute-value side tables keyed by parent_id.

series

The metrics read path: match metrics, gather points, group into series.

signal

What logs, traces and metrics have in common on the write path.

traces

OTLP traces -> Arrow, following the same shape as crate::logs.

wal

The write-ahead log, which exists to decouple the acknowledgement from the seal.

zone

Block-level numeric ranges — the zone map.

Statics

DEGRADED_SYNCS 🔒

Backs degraded_syncs.

Functions

degrade 🔒

Everywhere else sync_all is already fsync, so there is nothing to degrade to and an error is an error.

degraded_syncs

How many syncs have fallen back to fsync(2).

sync_all

File::sync_all, with the fallback Apple targets need and std does not do.

sync_data

File::sync_data, degrading the same way sync_all does.

sync_with 🔒

The seam the two above share, and the one a test can drive: strong is the barrier that might not be supported, and there is no way to make a real filesystem refuse F_FULLFSYNC on demand inside a unit test.