11–20 of 60 posts
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…
Sure, we all know the saying about assumptions. But why are we at a point where it's cool to use a data persistance layer that assumes it doesn't have to live up to any of those assumptions? It's why we have things like ACID, the LSB, etc. Contracts about how these systems should work for the end user.
It's hard to get all that stuff right off the bat, sure. But losing the entire database when a few bytes land in the wrong place? Yikes. Hardly something I'd trust real data to.
This stuff can always get better. Of course the solution as pointed out is tried and true. Glad to see that the developers aren't covering their ears...
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.
If your data was worth anything you'd also be using replication in which case the single server durability point becomes moot.
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.
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?
I was able to make a simple test page that told you the IP of the previous visitor who was closest to you. It took me thirty minutes from "hey mongo has some sort of geo support" to that (and I'm not a web dev and was using ATT 3G to read doc). PostGIS took me longer to figure out how to set a lat,long pair in the DB.
I'm not saying raw speed of development is the best measure of a database, but if your #1 priority is the ability to rapidly prototype, I'd imagine mongo is a good fit in your toolbelt.
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 about couchdb?
Maybe I was doing it wrong, but it seems like if your app has more than a little data and you plan on changing your mind about how best to present it, you will experience discomfort.
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.
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?
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'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.
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.
I don't know about riak, but we are forced to use couchdb at work, for the wrong reasons I think, and I was not impressed. First, its performances are pretty bad: document insertion is slow unless you batch them, but even though it is slower than in mysql, even though the guarantees about durability are certainly not the same (couchdb was not configured to fsync at each write). Building views is excruciatingly slow, and the view engine does not use all the CPU available (even when IO wait is low, so not a simple IO issue). There are bug reports about this issue (cannot find it at the moment). Replication is not very reliable either for large data (where large against means a few GB, so actually not that large).
I am sure we are using couchdb the wrong way at work (out of my hands), and for the wrong application, but its design choices as well as my limited experience does seem to imply couchdb is not adapted for large amount of data, especially one which are written often (there was an interview last summer with D. Katz who said that there were not yet much optimization for large data).