Rackspace acquires ObjectRocket

http://www.rackspace.com/blog/why-mongodb/

by grimey27 • 13 years ago

42 28 13 years ago

ericcholis3• 13 years ago

Interesting that they chose ObjectRocket over MongoHQ or MongoLab.

nlh• 13 years ago

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.

ericcholis3• 13 years ago

Agreed, I believe that the SSD instances made a big difference.

bretpiatt2• 13 years ago

The performance and tech detail post linked in the general article may be interesting to folks here: http://devops.rackspace.com/benchmarking-hosted-mongodb-serv...

Disclosure: I'm a Racker on the team helping out with the project.

ericcholis3• 13 years ago

Any insight on what version of MongoDB was used in the tests?

pquerna2• 13 years ago

ObjectRocket provides 2.2.

nirvana3• 13 years ago

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.

bretpiatt2• 13 years ago

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.

davidkassa• 13 years ago

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.

obviouslygreen• 13 years ago

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.

kushti• 13 years ago

A data tool should be used for appropriate data. Mongo DB is the best for flexible and loosely coupled data structures.

nirvana3• 13 years ago

...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.

jshen• 13 years ago

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.

jbellis• 13 years ago

"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.

pquerna2• 13 years ago

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.

dschiptsov2• 13 years ago

The best marketed database-level locks ever.)

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.)

nirvana3• 13 years ago

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.)

luigi• 13 years ago

> people like mongoDB because it's fast on a single node and they can use SQL rather than having to learn something new

You can use SQL on MongoDB? And thanks for telling people who like MongoDB why exactly they like it.

dschiptsov2• 13 years ago

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.

cullenking• 13 years ago

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.

jmspring• 13 years ago

Don't forget, MongoDB is webscale.

http://mongodb-is-web-scale.com

jedberg• 13 years ago

I just wanted to say congrats to the Objectrocket team! Their founder and CEO used to be my boss at eBay/PayPal. :)

ebbv• 13 years ago

Title is misleading. This isn't an article about why one would Choose MongoDB, it's purely a Rackspace press release.

StavrosK• 13 years ago

It's not just misleading, it is utterly false. There's no "Why" in the article at all.

wildchild• 13 years ago

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.

dkhenry• 13 years ago

Glad to see more support behind MongoDB. I know its popular to hate it, but It still has served me better then any of the alternatives I have tried.

I am hopefully that RethingDB can outdo them eventually, but for now BZ Rackspace team

sprobertson• 13 years ago

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.

nicktelford• 13 years ago

> 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.

Rackspace acquires ObjectRocket

Related Stories