Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

MongoDB, Data Durability and Improvements coming in 1.8

paperplanes.de

Post reply on HN
Print view View original

21–30 of 60 posts

Re: MongoDB, Data Durability and Improvements coming in 1.8

#21

Post by aneth »

harryh wrote: post #17
noelwelsh wrote: post #5

I'm pleased Mongo is getting single server durability. I have never understood why it got so popular without this feature. I'd love to know why people choose Mongo over say, Riak, or CouchDB, as the majority of projects don't need more than one server.

Because single server durability is a myth when hardware can fail at any time.

A city could be destroyed by a nuclear bomb at any time - that doesn't mean components of a system shouldn't be reasonably durable. Often it's impractical or unnecessary to have multiple servers for a proof-of-concept, a staging/test server, etc., yet it would be nice to not have to start from scratch, or to deal with backups, just because the database is so fragile. Basically, having a non-durable system forces you to take unnecessary precautions on non-critical systems because of the higher likelihood of failure and lost time investment.

Re: MongoDB, Data Durability and Improvements coming in 1.8

#23

Post by mathias_10gen »

richcollins wrote: post #22

You can also use fsync to guarantee that a transaction was written to disk at a severe hit to performance.

Actually that doesn't add any additional durability guarantees in the general case. The only way to use MongoDB durably with a single server is to use the new --dur flag coming in 1.8. I assure you there is no other way.

Re: MongoDB, Data Durability and Improvements coming in 1.8

#24

Post by thenduks »

tessro wrote: post #4

This is exciting. MongoDB (and the suite of libraries building up around it) has made prototyping web applications an order of magnitude easier than using SQL. Lack of single-server durability, however, is a showstopper in production, before you've grown enough to justify scaling the database beyond one machine. In my case, that meant going back to MySQL once our schema was finalized (sadly). Looks like that won't be…

What's with the aversion to replicas?

I have an app I'm working on launching right now, it's in what you might call 'private beta': real people accessing the app is What I'm saying is that you don't need to grow before adding a second box. My project currently runs on ec2 micro instances and the second box will probably cost you less than your GitHub code hosting costs! Just seems to me that (in ec2 terms, as an example) going from $9/month burn to $18/month is hardly a show stopper.

Re: MongoDB, Data Durability and Improvements coming in 1.8

#25

Post by thenduks »

noelwelsh wrote: post #5

I'm pleased Mongo is getting single server durability. I have never understood why it got so popular without this feature. I'd love to know why people choose Mongo over say, Riak, or CouchDB, as the majority of projects don't need more than one server.

You just have to tilt your head a bit and realize that you do need more than one server. For example - I don't know about you but I don't want to take down the site to deploy everytime I have to update some code (esp in the early days, this happens practically once a day).

With MongoDB you simply add a cheap second box and use it as at least a replica of your database. When you get tired of "we're updating the site with shiny new code" interrupting your users, you simply make it into a web-node as well.

Re: MongoDB, Data Durability and Improvements coming in 1.8

#26

Post by steveklabnik »

lwat wrote: post #18
pashields wrote: post #15

Earlier quoted context omitted.

In my admittedly limited experience with mongo, it felt like they were designing the ultimate database for the web. Not in a "web-scale" sort of way, more in a swiss army database for the web dev way. This came to me when I wanted to do location queries on a db. Most people using standard DBs do this with PostGIS for postgres, which is incredibly powerful and accurate. But mongoDB supports the "find shit near me with…

I assure you that that anyone who has used any kind of SQL database can do the same stuff you did on Mongo in the same time or less. Development speed is much faster on the SQL database once you have some more data and you can start using joins and searches and all the other nice RDBMS features.

I've built a lot of stuff on RDBMSen, and often, those 'nice features' are actually what I call 'a giant pain in the ass.'

Sometimes, data doesn't fit a relational model well. In those cases, something like Mongo is a godsend. And yeah, you could de-normalize your data and get halfway to Mongo, but I'd rather use each tool for what it's good at.

Re: MongoDB, Data Durability and Improvements coming in 1.8

#27

Post by steveklabnik »

megaman821 wrote: post #8

I am never sure what niche MongoDB is supposed to fill. If I want a large cluster to handle "big data" Riak or Cassandra seem to fit the bill better. If I want speed Redis is great. If I want a schema-less SQL-like (but not SQL) database, MongoDB?

Well, you could look at their own use-cases document: http://www.mongodb.org/display/DOCS/Use+Cases

Personally, Mongo maps so nicely to Ruby that sometimes, I just use the regular driver rather than an ORM. A database that naturally understands hashes and arrays is lots of fun.

Also, it seems like with Mongo, I can often design most of my pages to need just one query, and therefore they're crazy fast. This might be possible with other NoSQL stores too, and I'm trying to get more experience with more of them.

Re: MongoDB, Data Durability and Improvements coming in 1.8

#28

Post by lwat »

steveklabnik wrote: post #26
lwat wrote: post #18

Earlier quoted context omitted.

I assure you that that anyone who has used any kind of SQL database can do the same stuff you did on Mongo in the same time or less. Development speed is much faster on the SQL database once you have some more data and you can start using joins and searches and all the other nice RDBMS features.

I've built a lot of stuff on RDBMSen, and often, those 'nice features' are actually what I call 'a giant pain in the ass.' Sometimes, data doesn't fit a relational model well. In those cases, something like Mongo is a godsend. And yeah, you could de-normalize your data and get halfway to Mongo, but I'd rather use each tool for what it's good at.

"Sometimes, data doesn't fit a relational model well."

I keep hearing this but I've yet to see any good examples.

Re: MongoDB, Data Durability and Improvements coming in 1.8

#29

Post by steveklabnik »

lwat wrote: post #28
steveklabnik wrote: post #26

Earlier quoted context omitted.

I've built a lot of stuff on RDBMSen, and often, those 'nice features' are actually what I call 'a giant pain in the ass.' Sometimes, data doesn't fit a relational model well. In those cases, something like Mongo is a godsend. And yeah, you could de-normalize your data and get halfway to Mongo, but I'd rather use each tool for what it's good at.

"Sometimes, data doesn't fit a relational model well." I keep hearing this but I've yet to see any good examples.

Here's what I posed last time someone asked me this, I got no answer: http://news.ycombinator.com/item?id=1637903

Re: MongoDB, Data Durability and Improvements coming in 1.8

#30

Post by tmcneal »

jkkramer wrote: post #16
utx00 wrote: post #11

Earlier quoted context omitted.

what about couchdb?

In my experience, using CouchDB for prototyping is not fun. With SQL and (from what I gather) MongoDB, you can create ad-hoc queries as you go. Creating views in CouchDB requires thought and time -- usually lots of time -- to generate the views, unless you're working with a very small amount of data. Changing your mind is painful. You end up using weird hacks to get around rebuilding your views all the time. Maybe I…

I don't have any experience with MongoDB, but I am building an application right now using CouchDB and I've found it to be pretty easy to use -- definitely easier to prototype with vs a relational database + ORM framework.

CouchDB supports ad-hoc queries in the form of 'temporary views'. The downside (and I think a difference compared with MongoDB) is that temporary views can't be used in production since they are not indexed and thus are much slower than permanent views.

I'm developing my application in Python, which has great support for CouchDB in the form of CouchDB-Python (http://packages.python.org/CouchDB/) and CouchDBKit (http://couchdbkit.org/). Using CouchDBKit, it was pretty easy to set up CouchDB artifacts (map functions, reduce functions, design documents) into a nice file/folder hierarchy and write the simple Python glue code to deploy updates to CouchDB via a single shell command.

Post reply on HN