yes
> Stop using Java?
yes
Tongue-in-cheek aside, the author's point is that regardless of its current status, MongoDB has been pushed on a lot of people hungry for performance/simplicity; in that singular pursuit they may be setting themselves up for disaster later on. Most developers have a (perhaps unspoken) assumption that a successful write to a database means that data Will Not Disappear. If Mongo violates this assumption, then either developers' attitudes have to change or they should look at other software to avoid being bitten.
Take something like sockets: by using TCP, I am telling my development environment that I would like an unbroken, sequential stream of traffic to another endpoint. Just as importantly, I would like to be notified if this ever is not the case. If I discovered errors in my TCP stack, I want those fixed pronto because any kind of workaround would be reimplementing the very task TCP is meant to cover -- I might as well write my own sequencing and retransmission logic on top of UDP!
There have been plenty.
(Though there weren't a lot of blog posts about it, because the word blog had not been invented yet; blogs developed along with... MySQL.)
It will be interesting to watch Mongo as it matures over the next ten years. Unlike MySQL, it is competing against ubiquitously-deployed, well-known, well-worn open-source RDBMS packages, so its history is unlikely to unfold in the same way that MySQL's did.
Indeed it's the only database system I have ever used where a system with a single transaction running only multi-row inserts into a table can (and frequently does) deadlock against itself. Don't get me wrong, time was when it was easier to use than PostgreSQL but that time is long since passed.
One area I have continued to recommend MySQL has been in areas of content management but to be honest in many of these areas, NoSQL is actually a better fit.
MySQL has a niche too. It's somewhere between that of a NoSQL database and that of a real RDBMS. MySQL does well for single app databases (as NoSQL does), but where the relational data then needs to be fed through other database systems for multi-app access.
I know Facebook seems banal because we interact with it in some way several times a week, but is your head wrapped around how huge that thing is?
One of my customers logs certain web data into a MySQL database and loads/processes it in a PostgreSQL database every day. The data is then accessed in Pg by at least three different applications.
That's reasonable, btw.
Derek Harris puts the larger point about Facebook's trouble with MySQL: "By and large, [MySQL] does [for Facebook] what it’s designed to do, which is to keep up with the myriad status updates and other data that populate users’ profiles. Rather, [the problem is] that Facebook had to expend so much money and so many man-hours to get there."
http://gigaom.com/cloud/is-stonebraker-right-why-sql-isnt-th...