Rackspace acquires ObjectRocket
rackspace.com
rackspace.com
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.
There was a nice article from NYT about an addictive junk food. It should include MongoDB as a use case - lots of hype and crap inside.)
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.)
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.
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.
You can use SQL on MongoDB? And thanks for telling people who like MongoDB why exactly they like it.
To me that sounds like, "we deploy on SSDs." Which then makes me wonder if the new AWS SSD instances make this obsolete.
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.
Disclosure: I'm a Racker on the team helping out with the project.
Not that any engineer worth a damn would use a database that loses data in the first place.
Configuration data and multiple nodes would be nice.
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.
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 am hopefully that RethingDB can outdo them eventually, but for now BZ Rackspace team
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.
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.