Checkpoints

Not Supported

OrigoDB does not support checkpoints. However, it has the ability to take snapshots, which are similar to checkpoints. Snapshots can only be taken between writes and store a copy of the database in a file on disk. Unlike checkpoints, these are optional and are not needed to persist data.

Concurrency Control

Multi-version Concurrency Control (MVCC)

Transactions

OrigoDB has implicit transactions. Each read and write is treated as a separate transaction, and access to the database is controlled by a reader/writer lock. Writes are strictly sequential and take an exclusive lock on the database, and reads run concurrently using a shared lock. A custom command class can be used if several reads and writes need to be executed as a single transaction. OrigoDB supports fully ACID transactions on a single node. However, atomicity, isolation, and consistency are not guaranteed when data is partitioned across several nodes.

Immutability

OrigoDB has the option to use only immutable data structures in memory. Using this model, a write takes the state of the database as input and outputs a new state, which becomes the current state. When a read begins, it takes the current state as input, and uses this state for the duration of the read. Therefore, each transaction maintains its own copy of the database. Using this model, a read can occur concurrently with any other transactions (reads and/or writes), and at most one write occurs at a time.

Data Model

Relational Key/Value Document / XML Graph Object-Oriented

OrigoDB supports several built-in data models. The built-in models are relational, document/XML, key-value pair, graph, Redis clone, and JavaScript. In addition to these generic data models, users can specify a custom data model using any .NET language. A custom model includes custom commands and queries. All data models are stored as strongly typed graphs.

Indexes

Hash Table Red-Black Tree

Indexes can be created using C# collections, which are implemented as arrays, hash tables, or red-black trees.

Isolation Levels

Serializable

Queries are executed serially in the order they are received.

Joins

Not Supported

OrigoDB has no defined join operation for the pre-defined models. Users can choose to implement a custom in-memory join.

Logging

Command Logging

Logging is determined by the configured persistence mode. In the default mode, commands are written to a log. When the system is launched, it must redo all logged commands to restore the previous state of the database. These log files can become very large, and the amount of time required to load the system is directly proportional to the size of the logs. Therefore, unless logs are regularly truncated, the time needed to load the system can increase significantly over time.

OrigoDB also supports two other persistence modes that take snapshots of the entire database rather than logging commands. In one mode, the user must explicitly specify when to take a snapshot. In the other, the system automatically takes a snapshot each time a command completes. While the snapshot is being created and stored, the system is temporarily read-only to ensure consistent snapshots. Even if one of these modes is selected, the system will still generate logs. Snapshots cannot be used with non-serializable data models.

Query Interface

Custom API

Queries can be written in C# or LINQ. Parametrized LINQ queries can be passed to a C# function, which fills in the arguments and executes the query.

Storage Architecture

In-Memory

OrigoDB is completely in-memory. When the system starts, the entire database is loaded into memory. Because of this, the size of the database cannot exceed the amount of RAM available.

Data Persistence

All information about the database is stored in memory, with periodic writes to disk. Information is stored using write-ahead logging, with the option of also taking snapshots of the state of the entire system. When the system starts, this information is used to load the database into memory. If snapshots are being used, the most recent snapshot is loaded. Otherwise, the logged commands are replayed to restore the state of the database. The time needed to load the database is directly proportional to the size of the snapshot or the size of the logs, so the amount of time needed can increase significantly over time.

Disk Storage Options

By default, data is stored in a user-specified directory in the file system. Each snapshot is stored as a single file. Logs begin with a single file, and more files are added as needed.

The logs can also be stored as a relational database using MySql or OleDb. Some of the documentation indicates that there is also support for MongoDB, RavenDB, and Azure, but there is no support for these in the source code. However, users can define a custom object to use other databases. This option is not available for snapshots.

Stored Procedures

Not Supported

System Architecture

Shared-Nothing

When multiple nodes are used, one node functions as the primary node, and all others are replicas. Each replica can be configured to sync with the primary synchronously or asynchronously. In addition, each replica is specified to be in either read-only or on standby. A read-only replica can complete read-only queries, and a standby replica cannot process any queries. A replica can be promoted to primary manually if the primary fails or needs to be taken down for maintenance. However, a replica will not be promoted automatically if the primary node fails.