Why use it
A log-structured store you can read end to end
Solarium gives Raft logs and key-value stores a log-structured engine in C# that you can step through in a debugger.
A complete storage engine in .NET
One directory, column families, atomic batches across them, range deletes, ordered iterators, checkpoints, and leveled compaction.
No native library
Solarium is managed code only. It runs on every platform that .NET 10 runs on, with no native binary to build, ship, or match to a runtime.
Built for a Raft log
It covers what the Raft log of Kommander needs. Appended log files move down the levels with no rewrite, and a dead prefix goes away as whole files.
Fast writes from many threads
Group commit shares WAL appends and flushes across writers, pipelines the next group, and lets each writer insert its own batch.
Reads that take no locks
A read takes a version and a snapshot and searches a lock-free skip list and immutable SSTables. Fragmented range tombstones keep reads fast.
Recovery that tells damage from a crash
Each WAL record carries the durable offset of its file, so recovery cuts a torn tail but refuses damage to data that was flushed.
Integrations
A drop-in WAL for Kommander and Kahuna
Solarium exists to be a durable log store for Kommander. Two packages connect it to Kommander and Kahuna with no change to either.
Solarium.Kommander
SolariumWAL, a Kommander IWAL. Pass it to RaftManager, with no change to Kommander and no native library.
Read about Solarium.KommanderSolarium.Kahuna
The persistence backend and the Raft WAL of a Kahuna node, loaded with --extension-assembly.
Read about Solarium.KahunaHow it is tested
Tested against power loss and crashes
A storage engine is only as good as its recovery. The tests cut the power and kill processes at random points, and then check every acknowledged write.
Power-loss tests
A storage environment keeps only what each file held at its last flush, then writes out what a power loss can leave, in order or sector by sector in any order.
Read about the crash testsKill tests
A real worker process gets SIGKILL at a random moment. Every acknowledged batch must be there after the reopen, and the batch in flight must be whole or absent.
Read about the kill testsKommander conformance
Solarium.Kommander passes the conformance suite of Kommander for WAL backends, and the tests run three-node Kommander clusters on it.
See the Kommander WALCheckpoints under load
A checkpoint is held at its first write while the source writes, flushes, and compacts. The copy must read as the source did when the checkpoint began.
Read about the checkpoint testsWhat it is
Is Solarium right for your project?
Solarium is a brand-new database. Use it where its scope matches yours, and read the list of what is not done yet.
Good fit
Not the target (yet)
- A database server with a network protocol
- Workloads that need a cache of data blocks in the process
- Fast synced writes beside heavy compactions, without a rate limit tuned to your drive
- Production use without your own testing: Solarium is a young database
Inside the engine
Every part of the engine explained
The architecture pages describe each part of Solarium in the order that a write and a read go through it.
Group commit
How one leader writes the batches of many writers to the WAL in one append, and how pipelined memtable stages keep the next group moving.
Read about the write pathLeveled compaction
Seven levels with dynamic level sizing, appended keys that move down with no rewrite, and whole-file drops with DeleteFilesInRange.
Read about compactionWAL and recovery
The WAL format, the durable offset in each record, and the rules that recovery uses after a crash or a power loss.
Read about recovery