A New Renaissance for ODBMS? Part 1

Me: What are some use cases that benefit from an Object Oriented Database?

Luis Ramos: There's three main uses cases: complex (multi-dimensional) data, transactional caching, cloud-databases—and given today’s SaaS-world, you can see why ODBMSs are becoming more and more relevant.

By complex, multi-dimensional data, I mean data that is hard to render into rows and columns.  For an easy example of non-complex information consider the current roster for the Boston Red Sox Baseball team; the roster lists each player and their name, number, position and statistics–it looks like a rectangle with two dimensions.  This formulation makes it easy for me to ask the question – what is the current batting average of the 1^st baseman for the Red Sox?

But consider a slightly different question – how are individuals in a family tree related?  Consider Barack Obama’s family tree. If you visualize the data, it is not a matrix at all. It looks more like a tree of nodes. This would be very natural to store as objects with links to other objects. Consider asking a question like, is George W. Bush related to Barack Obama? Answering this question is quite easy in an object database. You simply follow pointers from the node representing Barack Obama and see if you can reach George W. Bush (and apparently they’re 11^th cousins). Following pointers or de-referencing references is certainly a lot more efficient than doing an arbitrary number of joins.

On the transactional caching use case. Our clients have selected object databases over other data caching technologies such as Memcache and Tangosol for a these important reasons: transactional access, durability, and automatic cache replacement. With object databases, there’s transactional access to the cache thereby preserving the data integrity of the cache – you don’t find this in many caching solutions.  Also, the cache is durable. If the application is terminated intentionally or otherwise, recreating the cache is fast and efficient because it is being populated from an object database.  In this case, there is no overhead for running SQL queries to find to the objects to bring into the cache and no overhead to transform between relational data and objects. Third, ObjectStore automatically manages the cache if the amount of data being accessed in the cache exceeds the amount of memory.

On cloud-databases, object-oriented databases are a more natural fit for persisting cloud data, which is inherently tuple-based, for a number of reasons. First, storing tuple-based data, whose values are arbitrary (strings, integers, double, boolean, etc) and that are automatically indexed could be challenging to do in a relational database. This type of problem is reminiscent of the issues related to formulating a relational model to store an object model that has an inheritance hierarchy. Second, scaling a relational database is not easy. The usual practice to scale a relational database in order to support more load is to use more powerful hardware. In an object-oriented database such as ObjectStore, it is easier and simpler. Since the queries are performed at the client (the cloud node or service), scaling the database can be accomplished by simply launching more services.