6 ms·
Rackspace acquires ObjectRocket
- ericcholis 14y agoInteresting that they chose ObjectRocket over MongoHQ or MongoLab.
- nlh 14y agoTake 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.
- ericcholis 14y agoAgreed, I believe that the SSD instances made a big difference.
- bretpiatt 14y agoThe performance and tech detail post linked in the general article may be interesting to folks here: http://devops.rackspace.com/benchmarking-hosted-mongodb-services.html http://devops.rackspace.com/benchmarking-hosted-mongodb-serv... Disclosure: I'm a Racker on the team helping out with the project.
- ericcholis 14y agoAny insight on what version of MongoDB was used in the tests?
- pquerna 14y agoObjectRocket provides 2.2.
- nirvana 14y agoI 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.
- bretpiatt 14y agoWhat 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 14y agoI'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 14y agoNot 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 14y agoA data tool should be used for appropriate data. Mongo DB is the best for flexible and loosely coupled data structures.
- nirvana 14y 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 14y agoCan 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 14y 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.
- pquerna 14y agoThe 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.
- dschiptsov 14y agoThe 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.)
- nirvana 14y agoEngineers 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 14y 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.
- dschiptsov 14y agoIt 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 14y agoWow, 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.
- jedberg 14y agoI just wanted to say congrats to the Objectrocket team! Their founder and CEO used to be my boss at eBay/PayPal. :)
- ebbv 14y agoTitle is misleading. This isn't an article about why one would Choose MongoDB, it's purely a Rackspace press release.
- StavrosK 14y agoIt's not just misleading, it is utterly false. There's no "Why" in the article at all.
- wildchild 14y agoI 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 14y agoGlad 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 14y agoI 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 14y 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.