History[04]

SwayDB project started in 2017, and had its first release in 2018. Currently, it is under beta release.

Checkpoints[05]

No checkpoints are supported. For its in-memory implementation, no checkpointing or logging is supported. For the persistent version, it can persist its memory segments to disk, but this is used for reducing that level's storage, not for recovery.

It has a notion of 'eventual persistent' in its documentation. It means that the database can write the memory storage to disk whenever it exceeds a threshold. This is somewhat similar to checkpointing, but it is not a full checkpoint, so the data left in memory can still be lost.

Compression[06][07]

Segments are chunks of key-value pairs in a Log-Structured Merge Tree. Key-values within the same segment can be grouped to create sub-segments and then be compressed by specifying groupingStrategy. SwayDB supports compressing them using LZ4 and Snappy, which are open-sourced Java compression tools. Strictly-speaking, the compression is done on sub-segment level instead of page level.

Additionally, duplicate data within index entries are always compressed. Duplicate values within same segments are also detected and compressed. All index entries are prefix-compressed with the previous index entry.

Concurrency Control[08][09]

SwayDB assumes it runs 'under a single process in a single application', as the author clarifies on Reddit. Everything is atomic in SwayDB, including transactions. The only guarantee it has on transactions is atomicity. No concurrency control is needed, and indeed it is not mentioned in docs at all.

Data Model[01]

SwayDB is a key-value store, having Map[K, V] and Set[T] for data storage and providing APIs to create, read, stream, update, delete & expire data.

Its storage components uses CRC checksums to prevent corruption of data and support recovery.

Foreign Keys

Indexes[10]

SwayDB organizes data in levels of segments, using the Log-Structured Merge Tree data structure. Upper levels write to lower levels in batches when it is full or the user explicitly demanded. Bloom Filters are used in each segment to search quickly whether a key belongs to that segment.

Isolation Levels[01]

Since every operation and transaction is atomic and runs on the same memory space, it is serializable.

Joins

Logging[11]

Write ahead logging is used for its persistent version databases. Because it is a key-value store, it does not have the notion of pages. The logs are physical logging of write operations.

Query Compilation

SwayDB is an embedded database written in Scala. It is compiled along with its Scala/Java application.

Query Interface[12][13]

SwayDB is used embedded in applications. The API is in Scala with its custom APIs. A Java wrapper is also implemented for Java APIs.

Storage Architecture[01]

SwayDB supports both in-memory and disk storage. For its in-memory version, it does not provide guarantee on data durability because it does not have logging. However, the user can persist the memory to disk at some time.

For its persistent database, write-ahead logging is used for durability. Data is organized into segments on different levels, aligning to the Log-Structured Merge Tree algorithm.

Storage Model[07]

For the segment file format, SwayDB stores all values in the head of the file, in the same ordering as keys. Key index entries are stored after the value bytes. At the last of the file is the checksum, bloom-filter and other metadata about the segment.

Storage Organization[14]

Log-Structured Merge Trees are used in SwayDB. Storage are divided into different levels, corresponding to different hardware capabilities. If the upper level cannot find an entry, it will go into the next level. During a compaction, data from upper levels are pushed into lower levels, and deletion is also performed if necessary.

Stored Procedures

System Architecture

SwayDB is an embedded database.

Views