> 3. MongoDB is the de facto choice for NoSQL applications
The point of "NoSQL" systems are to use the most appropriate solution for the problem instead of a one-size-fits-all solution, which was the tradition when relational systems were the only choice.
The notion of a "de facto choice" at all seems to be the biggest mistake nearly everyone makes when evaluating such systems these days. People are so focused on evaluating the available systems that they forget the most important step: to analyse their own problem domain.
Engineers need to be disciplined. You know there's a problem with the culture when things like MongoDB become popular, despite very highly public failures, and fundamentally bad engineering choices.
It shows the power of marketing and ideology (people like mongoDB because it's fast on a single node and they can use SQL rather than having to learn something new, so they become "believers" in it without regard for its lack of scalability, or reliability, etc.)
Wow, axe to grind or what? You have three comments on here all belittling something that many people find perfectly acceptable and successful in production. Of all the non-SQL choices, Mongo isn't a terrible one. We've got (along with many other companies) 300gb in Mongo and it's been loads more enjoyable to use in a replica set than MySQL has been in a master/slave architecture, and every bit as reliable. More so if you count the simple live failover that just works.
It's a data model that works very very well for some datasets. We use MySQL for stuff that is obviously relational, but we store a bunch of geo data as JSON for fast serving to javascript etc. It's a perfect fit.
But seriously, if you don't have a backup of any of your data stores, that's a big problem.
It is exactly how to sell - give what users want - documentation full of adjectives but omitting important details, success stories, examples. Javascript! NoSQL! Fast! Always OK. (and never loses data) Grab, don't think.)
To be little more serious, this is an example of what happens when professional sales strategies from proprietary shops come to open source. Now we have open source crapware.
Actually, the best heuristic to evaluate open source project - why it was created - for sale, or for internal use. Ryak or redis, for example, were made for use, not for sale.
"Instead of using AWS primitives, they built their service on their own hardware in neighboring data centers, and utilized AWS DirectConnect to provide low latency connectivity."
To me that sounds like, "we deploy on SSDs." Which then makes me wonder if the new AWS SSD instances make this obsolete.
The High-I/O Quadruple Extra Large starts at around ~$2232 per month for 2tb of SSD storage.
With this kind of pricing you will have a hard time meeting user expectations about price; Even with high multi-tenancy on top, and if you tune up that density too much, you will probably push too much ram, as the instances only have 60.5GB accessible, which with 2tb of disk is pretty unbalanced for many mongodb use cases.
Disclosure: I'm a Racker and worked on this project.
I love all these "benchmarks" of "NoSQL" databases running on single nodes. Plus you don't name the competitors or any configuration data so... this is really marketing not engineering.
Not that any engineer worth a damn would use a database that loses data in the first place.
I'm pretty sure that Provider #1 is MongoHQ ("Replica Set: Small") and Provider #2 is MongoLab ("Mini"). MongoHQ doesn't show a "Replica Set: Small" anymore, though, on their pricing page - only Large.
Configuration data and multiple nodes would be nice.
What type of configuration data are you looking for? The tests used the $150/month price point offering on each DBaaS, the configuration options are built into the service.
Regarding NoSQL and "single node" vs. "multi node" -- NoSQL isn't just about scale out systems, it is about mapping the proper type of data store to the data model. If you have a complex relational schema you should use a SQL database. If you need a simple to use document or object store the NoSQL solutions are often easier to code against.
Not that any engineer worth a damn would use a database that loses data in the first place.
Ironic and invalid generalization. When the tradeoffs are acceptable or preferable (e.g. data persistence is not vital and your application can get better performance out of a database that can "lose data") it makes sense.
Whether it's relevant to the article or not, this is simply false and not constructive at all.
I may be a meta-contrarian but MongoDB is thus far my favorite database, after years with MySQL and Postgres. I spend all day building MVPs and there's nothing better than adding to the schema [sic] halfway through without having to run a migration.
...where you don't care if you lose the data. So data sets where you are getting a new version of the data every day and so if you lose yesterday's dataset you don't care.
also, datasets that fit on a single machine, rather than need to scale out over many machines, unless you don't mind the intrinsically broken "scaling" solution that is master-slave architectures.
Can you explain what you mean by "lose data". I don't know much about mongo, but I thought you could configure the client to wait for the disk write before returning.
Take a peek at the article and associated benchmark post. I assume that "Hosted AWS providers #1 and #2" refer to MongoHQ and MongoLab. You'll see why they made their choice.
But as someone else pointed out, it's worth asking whether the new SSD instances will help those other guys catch up or if there's more than disk performance bottlenecks going on.
I hate being NoSQL hater. How to became a lover? Probably I got too much this nosql noise around. Please somebody tell me how to write apps without transactions at all? It solves one problem by adding different headaches.
