Concurrency Control[05][06][07]

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.

Data Model[08]

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.

Foreign Keys

Logging[04][01]

Because OrigoDB is stored in memory, logging is crucial to ensure persistence of data. Logging is determined by the PersistenceMode. 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 screenshots. Even if one of these modes is selected, the system will still generate logs.

Query Interface[09][07]

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

Storage Architecture[10][11]

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.