Foreign Keys

Supported

Data Model

Relational Key/Value Document / XML Graph

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 is an instance of the Model class, and includes custom commands and queries. All data models are stored as strongly typed graphs.

Concurrency Control

Multi-version Concurrency Control (MVCC)

Transactions

OrigoDB does not explicitly support 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.

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.

Query Interface

Custom API

All queries are written in C#. Queries can be based on LINQ, but must be in C#.

Storage Architecture

In-Memory

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 SqlStatements object to use other databases. This option is not available for snapshots.