A nice list of pro and con articles show up. Have fun!
What’s clear from the titles of the articles is that document based databases, a.k.a. NoSQL, are still in their infancy. Relational still holds the minds of most developers. A look at the Technology Adoption Life Cycle chart superimposed with Gartner’s Hype Cycle gives a good idea where MongoD might be:
If MongoDB has 8% market share it is still selling to early adopters. Somewhere around 15% market share might be considered having gone mainstream and that’s probably a safer time to invest. The risk now is the trough of disillusionment when the stock can easily fall by 50%. MDB’s all time high is around 108, a 50% drop is to 54. My cost basis is $61 down from 68.67 which was my entry price (trading and selling covered calls).
Had the dip been larger I would have bought some trading shares but I had to be content trading covered calls
Denny Schlesinger
The image comes from this article which is way too complicated for me.
Technology-adoption, technology-evolution and lifecycle-management
I’ve spent some time pondering how to explain the NoSQL case and this is what I came up with.
The difference is in the use case. SQL was designed with a specific use case in mind, basically a book keeping system. It is based on three basic assumptions
Your data comes in relatively small batches
You have 100% control over the incoming data
You expect 100% reliability from the data stored in your database (or as close to 100% as you can get)
As I said, essentially something like a book keeping system. Incoming data is something like an invoice. It’s small and you can force whoever is storing it into the system to adhere to the rules: it has to have a date in a certain format, company information that is properly defined, dollar amount etc. It can be that your system is serving a thousands of companies and you are processing a lot of invoices at any given moment, but each transaction is well manageable within a computer’s active memory. And as per point 3) you are expecting the information stored to be bulletproof, because you are using the data for submitting your taxes.
Now imagine the complete opposite of those assumptions.
Your data comes in extremely large batches
You have very little control over the incoming data
You don’t care about 100% reliability
This is the data mining system:
“Here’s 3 terrabytes of data from 92 of our facilities. You’ll get another 3-5 TB each week. Oh and our facilities have differrent combinations of equipment running different software versions so don’t expect the data to be in a unified format plus the composition may change every week. Use it to compile useful statistical data and maybe optimize some of our processes.”
This is a nightmare scenario for a SQL database. Modern SQL systems have adapted over the years to be more flexible than the original 80s era rigid book-keeping like systems but still you probably would have to dump most of the data and concetrate on the 5% of it that is in the same format and then slowly build translators for additional data sets to feed a bit more of the rest of the data.
NoSQL like MongoDB on the other hand is perfect for this. You can load the whole mess of your data on it first and ask questions later - sort your data out, bring it to a common format, run statistics etc. You don’t care about only having 100% reliable data in your system, what you care about is for the data to have statistical significance.
If you look at the system you want to build, it will probably be somewhere between the two extremes but the closer it is to the billing system the better off you are with a SQL database and the closer it is to a data mining one, the better MongoDB will be for you.
