Versant ODB as Easy as ORM

Yet another alternative to the relational database is the object database.  Learning a new method for data storage can be scary for some developers, but there are a few ODB vendors that have built controls that are familiar to most.  The Versant Object Database (VOD) is one ODB in particular that uses many concepts found in Object Relational Mapping (ORM).  It's used for applications with complex domain models and a high level of OLTP (Online Transaction Processing) requirements under high concurrency.  It supports C++, Java or .NET object models.  Recently, VOD moved to version 8 with some significant upgrades.  Versant also owns the GPL licensed open source ODB db40.

                                                                       Versant ODB Architecture

                              

In our current programming ecosystem, where object oriented programming is mainstream, the object database provides high performance because of the object relationships in the database storage model.  High performance OLTP is also possible with ODBs because an object's in-memory representation is stored directly on disk without using serialization, eliminating the need to convert the object into a fixed type system for RDBs.  Operations involving the calculations of millions of records' relationships are modeled in an ODB as a collection reference in the application space.  The collection contents are quickly made available without a costly JOIN operation.  Some ODBs, like Versant, can even work in cloud deployment topologies.  This allows parallel database queries and other CRUD operations across a distribution of nodes.  Objects can be transferred between nodes without impacting the application's code.  

So how hard is it to use this thing?  There are several layers of control. In one instance, when you query back an object graph, you can simply return the references to the objects that satisfy the query or you can go get the objects and then get some configurable level of referenced objects.  If you're familiar with the ORM concepts of FetchGroups, then you're in luck, because the concept is the same with VOD.  It's a lot like using ORM at the API level, except there's no mapping.  Here's an example using Versant's proprietary query API, VQL:

VQLQuery query = new VQLQuery( session, "select selfoid from model.Person order by ssn ASC" );
Enumeration ofResults = query.executeWithCursor( 0, -1, Constants.IRLOCK, Constants.RLOCK );

In this example, 0 is an int option parameter for things like, pinning objects permanently into cache on fetch, flushing the cache contents to participate in query scope, returning result objects, etc.  The -1 represents the level of reference objects you want to fetch.  -1 means 'fetch all related objects, you can set any level.'  Constants.IRLOCK and Constants.RLOCK are lock controls on class and instances respectively.

You can do this with Java Data Objects by using FetchGroups per the standard. Just setup a fetch-group and then bind it to a query instance with query.setFetchGroup("named_path").  Object references that are involved in the "named_path" are loaded across the wire on query execution.

VOD 8 includes significant upgrades from the last version.  They include:

• Increased multi core scalability
• Optimized internal memory management and caching implementations
• Enhanced database administration tools (e.g., monitoring, dbcheck, dbreorg)
• Upgraded the Versant JDO SDK compatibility to the latest JDO 2.0 standard.
• NET binding with LINQ support
• FTS for .NET and JDO based applications
• "Black Box" recorder and analysis

Versant is used by many airline booking sites and online stock market trading portals.  Alcatel-Lucent-Nortel, Ericsson, NEC, Siemens, Samsung, and other national network management suites are all built on Versant.  Their pricing model depends on the usage and the customer.  In the next few months there will also be an express version for people that don't need cloud type deployments, but still have complex models and want to avoid mapping.  Versant does not charge for the client/cache.  So if there's a scenario where 100 CPU's are in the app server tier and only 8 CPU's are on the database server (this happens commonly with Versant) , then you'll only pay for those 8 CPU's.