Most databases are based on single data model. Relational, Key/Value, Column store, document, graph etc. OrigoDB is different. You can choose from a number of existing data models, extend an existing model or define your own using any NET language. The modeling section describes defining your own custom domain model.
An OrigoDB in-memory model is an instance of a single class which derives from OrigoDb.Core.Model`. Start by creating a class that inherits Model and add fields/properties to represent the state of your system, usually strongly typed collections containing custom entities. Define Entities, Value Types, Enums, Structs, built-in types. Write Command and Query classes to read and write the model.
Just use plain old object oriented design principles.
We often see domain specific object-oriented modeling based on either an anemic model and fat transactions or a rich model with thin transactions:
You have to consider performance when choosing data structures. Analyzing data access patterns and estimated data volume will help you choose between dictionaries, lists, hashsets, queues, stacks, arrays etc
Traditional disk-based relational databases use B-trees for tables and indexes. B-trees provide a reasonable and balanced performance for all types of operations: seek, scan, insert, delete, etc.
SortedDictionary<K,V> are pretty good equivalents.