Memstate is a complete redesign of OrigoDB with major improvements in key areas such as performance, availability, licensing, cross-platform, docker and cloud support.
Performance - OrigoDB can process up to 3K write transactions per second, Memstate can process up to 100K, a 33x improvement!
High Availability - An OrigoDB cluster has a single primary and one or more read-only replicas. If the primary fails one of the replicas can be promoted to new primary but this requires manual intervention. Nodes in a Memstate cluster are all read/write.
Licensing - OrigoDB Server is a commercial offering while Memstate server is OSS and free for commercial use.
Cross platform - Memstate targets .NET Standard 2.0 which means it runs on both .NET Framework >= 4.6.1 and .NET Core >=2.0, Mono, Xamarin, UWP.
Here’s a complete guide to get you started with developing your first OrigoDB application!
The following topics are covered:
Adding the library to your project
Define the in-memory model
Create commands and queries
Hosting the engine
Executing commands
Executing queries
Add the library
The OrigoDB.Core library is a single assembly. Grab the latest OrigoDB.Core.dll from the download page and add as a reference to your .NET project. Or install the nuget package by typing Install-Package OrigoDB.Core in visual studio’s package manager console.
Define the in-memory model
Create a class that derives from Model and add members to hold data, usually collections. Mark the class and any referenced types with the Serializable attribute. An instance of this class is your in-memory database.
Create commands
Commands are used to update the model. Derive from Command<M> or Command<M,R> where M is the type of your model and R is the result type
Hosting the engine
Engine.For<M>() will create an initial model, write it as a snapshot to disk and then return an engine ready to execute commands and queries.
Executing commands
Create a command object and pass it to the engine for execution:
Executing queries
You can use either ad-hoc linq queries passed as lambdas to the engine or you can write strongly typed query classes.
Summary
We’ve covered the absolute basics here, but essentially there’s not much more to developing than defining the model, and writing commands and queries. We used explicit transactions, an anemic model and the transaction script pattern. Next, you might wan’t to check out implicit transactions, where commands and queries are derived from methods on the model eliminating the need to explicitly author commands and queries.