When NoSQL Storage Systems Make Sense

A couple people emailed and thought the piece on NoSQL databases was unfair. Perhaps it was heavier handed than is really justified, as Mohawk Software has its own, albeit out of date, NoSQL system.

MSession was a NoSQL solution built about 10 years ago for handling transient shared data for an MPI compute cluster. It was later adapted to PHP as a shared session management system. After that, it was used as a shared data cache.

MSession, when used with PHP, allowed a number of web servers to share session information. This was typically done with a database, but with transactional semantics, performance was poor and I/O overhead of the system was high. At DMN (Digital Music Network) I adapted an old simple data cache I wrote previously to manage session information for PHP. It was added to the old 3x series of PHP as MSession.

MSession was a perfect example of a NoSQL data system. It did not care about durability as session information could be rebuilt (expensively) if it failed. It held everything in RAM and was very very fast. I dare say, the performance of MSession would have been impossible to reproduce in a standard SQL database. On top of that, because MSession was tailored for web session management, it was able to make assumptions about the data. Getting specific information out of the system with queries that would have been expensive on a SQL system were now pretty efficient.

MSession, while still pretty old and in virtually unmaintained state, still runs some web sites.

That is one example of where, I believe, a NoSQL system is useful and there are many other cases, i.e. storage, redundancy, scaling, etc. It is just that a "NoSQL" system is by definition harder to use and has less support than more traditional SQL based databases. As a professional, you should always try the more generic systems first if there is a reasonable expectation of success. If then they do not work, you look at more exotic ones.