At Duetto, we are building a modern cloud application tailored to the needs of the travel industry and lodging companies in particular. Although every lodging company above a certain size uses a software system as its cash register (so called Property Management Systems which take reservations and output customer bills) we find a surprising lack of products focused on Operational Intelligence in the travel world. Most hotels lack basic systems that help managers and owners understand trends, make operational forecasts and predictions, and identify unusual circumstances that need addressing both for a single property as well as at a corporate level.
While Duetto Edge derives new data (such as the forecasts we produce and score over time) much of our database content is mastered in another system (e.g. the Property Management Systems). Therefore Duetto Edge resembles a Data Warehouse in many respects. We form a historical record of transactions (such as past rates and reservations) though we also capture brand new data sources such as web analytic data from booking engine web sites (so-called “Regrets and Denials”). The integrity and reliability of the data is paramount. But the system also experiences a relatively high read volume compared to write volume.
Of course one major architectural decision early in our product development was the choice of data store and we chose MongoDB. Despite our significant personal experience with relational databases such as Oracle (or perhaps because of that experience) Mongo provided an interesting blend of simplicity and power, both functionally and operationally.
MongoDB has started to run away with the lead in the “NoSql” wars of late. Although other data stores provide more industrial strength scalability and write performance (see HBase, Riak, Cassandra) Mongo does provide an interesting horizontal scalability model through its use of replica sets and sharding. The single writer problem is real, but not necessarily something that can’t be worked around.
But Mongo’s most important features, especially early on in a company’s development lifecycle, are those that center around simplicity. As a strongly consistent data store (when using the appropriate journaling features) Mongo represents a reliable place to store data and reason about your application. Much has been written about the beauty of Mongo’s developer Api and language-specific drivers and they are in fact world class for ease of use. We use the Java driver and everything from the natural Map/List data structures of its Api’s to its pre-built connection pooling and thread safety make working with Mongo simple.
As a Document Store Mongo lacks complex transactions (a single document, which can be surprisingly deep and rich, is the only unit of atomicity) but it does provide features that bring it closer to a relational database than other new data stores. The presence of consistent secondary indexes and a query optimizer that uses them well is a huge need for an enterprise application like ours. Duetto uses configurable metadata stored in Mongo as the life blood of the application and through the use of several novel techniques we approximate key features of a relational data model including many-to-many relationships, semi-joins using Mongo multi-key array semantics, etc.
And of course the schema-less nature of Mongo allows for much more fluid design and upgrade processes than those that are possible with a rigid relational database schema. For a young product undergoing frequent changes and major enhancements this has proven extremely effective for Duetto Edge.
We’ve had to build a number of infrastructure levels on top of the underlying data store but so far Mongo has hit the mark for enterprise application development – in ways that might surprise its naysayers.