NoSql Databases - the new and the not so new
The new breed of No-Sql databases has predecessors, which can teach us a lot.
The new breed of No-Sql databases may seem to be the new kids on the block, but in fact they have a long history, that begins before SQL was invented. (Of course, they had to be No-Sql, because SQL was not invented yet)
And even after SQL was invented there were No-Sql databases, and they are still being used in critical projects.
Few know, that both the Chicago and London stock exchange operate on No-Sql databases, or that the high performance embedded databases in network nodes are often object databases. Or that car production of major car manufacturers is controlled by No-Sql databases. Or that the backbone of many health-care applications is no-sql.
Or that the largest database that I am aware of, which stores the results of CERNs nuclear experiments in real time, is a distributed object database.
But these are not Hadoop or Cassandra or Neo4J. They are known as hierachical, network, object, xml or multi-dimensional, databases. The product names that go with this approach are Cache, Versant, ObjectStore, BerkeleyDB, Objectivity, Tamino, GemStone and of course the venerable IMS database.
So how do they compare with todays new flock of databases, and what can we learn from their use?
The first thing we can learn from them is that the technology really works. These databases have been in production for decades and have proven that they perform well, scale well and have professional support.
The other thing I have learnt, is that they are easier to manage and program than relational databases. There are fewer or no DBAs required. And because they map directly into the data types of programming languages, there is no impedance mismatch. This reduces the cost to develop and maintain a database application by up to 30%.
They also show that distribution can be easy and cheap.
They scale well not only with respect to size, but with respect to complexity. I have seen several thousand classes in a complex schema handled gracefully in the above mentioned applications, while a relational database with a schema of over 100 classes is a pain to manage.
On the downside they always lacked tooling support. One reason beeing, that the data model was richer, and thus relational tools could not be adapted to these databases. I predict the same to happen with new breed of No-Sql databases. The tools for the flat relational world will fail to deal with the rich models and performance requirements of complex data models.
That is the reason for the development of ReportsAnywhere. It has a rich data model, designed to handle No-Sql databases. More on reporting for No-Sql databases in this article on "Reporting Options for No-Sql Databases"