5 ms·

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 Mo

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.

stilkov 16y ago
Would that be that majority that doesn't really care about uptime?
- deleted 16y ago
  [deleted]
ericflo 16y ago
Because they market infinite scalability, insane speeds, and they have a nice API. But people don't realize that, while the speed is fast, you're driving without a seatbelt, and the scalability story is more or less false. They do have a nice API though.
- prosa 16y ago
  Can you point us toward data that backs up your point that "the scalability story is more or less false"? Seems like FUD. There are several well-documented, major production deployments of MongoDB already, that seem to contradict your assertion: * Etsy * CERN * BoxedIce (600MM+ documents) * BuzzFeed (400MM+ datapoints/month) That's just a few from http://www.mongodb.org/display/DOCS/Production+Deployments http://www.mongodb.org/display/DOCS/Production+Deployments
weixiyen 16y ago
For those projects I just ran backups of the file system. Linode does it for $5/month. If your data was worth anything you'd also be using replication in which case the single server durability point becomes moot.
yummyfajitas 16y ago
Because MongoDB is webscale. http://www.xtranormal.com/watch/6995033/ http://www.xtranormal.com/watch/6995033/
harryh 16y ago
Because single server durability is a myth when hardware can fail at any time.
- lwat 16y ago
  We're talking about data durability. When my SQL server crashes due to hardware failure I know that when I eventually get it back up and running the data will be consistent with at worst the last couple of transactions being rolled back.
  - harryh 16y ago
    This is most certainly not true. Disks fail in ways where the whole volume becomes unreadable all the time.
    - lwat 16y ago
      What I'm saying is that I can go up to my SQL server and disconnect the power cord and my database will not be corrupt when I start it back up. Sure if your HDD gets taken out by a meteor then nothing will save you but that's why you have backups.
      - bsg75 16y ago
        Not guaranteed. I have had more than one customer experience hardware failure, resulting in a corrupt or suspect SQL Server database, that was unrecoverable via normal means. In each of the cases where the customer had a true standby system, implemented via replication, log shipping, or mirroring, they were able to failover with little (log shipping) or no data loss. In the cases where they had a single, standalone server, the option was to restore the last known good backup, or sent the database files had to Microsoft for analysis and repair. ANY system (RDBMS, NoSQL, or otherwise), should have a standby replica to prevent data loss. If you data is stored on a single machine, you are doing it wrong.
        lwat 16y ago
cdavid 16y ago
I use mongodb to record fine grained log for performance tests, where it works like a charm. It is fragile (in that I have lost full databases when VM were full, for example) 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).
- cdavid 16y ago
  I cannot seem to edit my post, so here is the issue I am referring to w.r.t. couchdb and unused CPU: http://www.mail-archive.com/dev@couchdb.apache.org/msg06520.html http://www.mail-archive.com/dev@couchdb.apache.org/msg06520.... here is the interview of Damian Katz concerning couchdb: http://howsoftwareisbuilt.com/2010/06/18/interview-with-damien-katz-apache-couchdb http://howsoftwareisbuilt.com/2010/06/18/interview-with-dami..., which mentions that large data is not a focus. There are some companies which seem to use couchdb for large usage, for example bbc (http://enda.squarespace.com/tech/2010/3/4/couchdb-at-scale-4-billion-requests-so-far.html http://enda.squarespace.com/tech/2010/3/4/couchdb-at-scale-4...). I don't know their infrastructure, but they claim to server 4 billions requests as of 4th march 2010 since summer 2009 on a 32 nodes (16 master, 16 backups). Assuming that summer starts in september to get an upper bound of the traffic, this means 250 rq/sec on average, which is nothing impressive for an infrastructure with 32 machines without more information about what they do. Generally, I would not say much about this kind of usecases, but since it is often advertised by couchdb proponents, the burden of the proof is theirs.
thenduks 16y ago
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.
va_coder 16y ago
"I'd love to know why people choose Mongo over say, Riak, or CouchDB" Here are some reasons: * excellent documentation * runs right out of the box * excellent libraries like Mongoid * user can easily perform deep queries (e.g person.address.zip = '90901') * services are available like MongoHQ

stilkov 16y ago

Would that be that majority that doesn't really care about uptime?

deleted 16y ago
[deleted]

ericflo 16y ago

Because they market infinite scalability, insane speeds, and they have a nice API. But people don't realize that, while the speed is fast, you're driving without a seatbelt, and the scalability story is more or less false. They do have a nice API though.

prosa 16y ago
Can you point us toward data that backs up your point that "the scalability story is more or less false"? Seems like FUD. There are several well-documented, major production deployments of MongoDB already, that seem to contradict your assertion: * Etsy * CERN * BoxedIce (600MM+ documents) * BuzzFeed (400MM+ datapoints/month) That's just a few from http://www.mongodb.org/display/DOCS/Production+Deployments http://www.mongodb.org/display/DOCS/Production+Deployments

weixiyen 16y ago

For those projects I just ran backups of the file system. Linode does it for $5/month. If your data was worth anything you'd also be using replication in which case the single server durability point becomes moot.

yummyfajitas 16y ago

Because MongoDB is webscale. http://www.xtranormal.com/watch/6995033/ http://www.xtranormal.com/watch/6995033/

harryh 16y ago

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

lwat 16y ago
We're talking about data durability. When my SQL server crashes due to hardware failure I know that when I eventually get it back up and running the data will be consistent with at worst the last couple of transactions being rolled back.
- harryh 16y ago
  This is most certainly not true. Disks fail in ways where the whole volume becomes unreadable all the time.
  - lwat 16y ago
    What I'm saying is that I can go up to my SQL server and disconnect the power cord and my database will not be corrupt when I start it back up. Sure if your HDD gets taken out by a meteor then nothing will save you but that's why you have backups.
    - bsg75 16y ago
      Not guaranteed. I have had more than one customer experience hardware failure, resulting in a corrupt or suspect SQL Server database, that was unrecoverable via normal means. In each of the cases where the customer had a true standby system, implemented via replication, log shipping, or mirroring, they were able to failover with little (log shipping) or no data loss. In the cases where they had a single, standalone server, the option was to restore the last known good backup, or sent the database files had to Microsoft for analysis and repair. ANY system (RDBMS, NoSQL, or otherwise), should have a standby replica to prevent data loss. If you data is stored on a single machine, you are doing it wrong.
      - lwat 16y ago

cdavid 16y ago

I use mongodb to record fine grained log for performance tests, where it works like a charm. It is fragile (in that I have lost full databases when VM were full, for example) 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).

cdavid 16y ago
I cannot seem to edit my post, so here is the issue I am referring to w.r.t. couchdb and unused CPU: http://www.mail-archive.com/dev@couchdb.apache.org/msg06520.html http://www.mail-archive.com/dev@couchdb.apache.org/msg06520.... here is the interview of Damian Katz concerning couchdb: http://howsoftwareisbuilt.com/2010/06/18/interview-with-damien-katz-apache-couchdb http://howsoftwareisbuilt.com/2010/06/18/interview-with-dami..., which mentions that large data is not a focus. There are some companies which seem to use couchdb for large usage, for example bbc (http://enda.squarespace.com/tech/2010/3/4/couchdb-at-scale-4-billion-requests-so-far.html http://enda.squarespace.com/tech/2010/3/4/couchdb-at-scale-4...). I don't know their infrastructure, but they claim to server 4 billions requests as of 4th march 2010 since summer 2009 on a 32 nodes (16 master, 16 backups). Assuming that summer starts in september to get an upper bound of the traffic, this means 250 rq/sec on average, which is nothing impressive for an infrastructure with 32 machines without more information about what they do. Generally, I would not say much about this kind of usecases, but since it is often advertised by couchdb proponents, the burden of the proof is theirs.

thenduks 16y ago

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.

va_coder 16y ago

"I'd love to know why people choose Mongo over say, Riak, or CouchDB" Here are some reasons: * excellent documentation * runs right out of the box * excellent libraries like Mongoid * user can easily perform deep queries (e.g person.address.zip = '90901') * services are available like MongoHQ