4 ms·

I'm a pretty big detractor of mongo, but I don't agree with this post. One of mongo's main design decisions is to defer writes, making this sort of thing possib

I'm a pretty big detractor of mongo, but I don't agree with this post. One of mongo's main design decisions is to defer writes, making this sort of thing possible. I think it's a crappy tradeoff but it is one of the things that makes mongodb mongodb. If you use it without knowing this you haven't researched it well.

DanWaterworth 14y ago
When is this behaviour useful? (Benchmarks don't count)
- pooriaazimi 14y ago
  I'm no expert in this area, but maybe if you want to use mongo for logging? Or things like that. I kinda like TCP vs. UDP analogy. Sometimes you care more about speed than precision. A few dropped items in a log. Not a big deal. I'd rather have that, than to be forced to use a more expensive machine for the job. That said, I absolutely think the default should be the TCP way.
- eli 14y ago
  Well, any time you'd rather have speed over completeness. Maybe you're aggregating tweets from the Twitter API and if the occasional one goes missing, it's not a big deal, or perhaps you can grab it on the next update. Maybe you're generating a real-time stats dashboard for your site and if one pageview gets lost every million, it's not a big deal. Look, I agree that in most cases you probably want to do everything you can to make your data 100% complete. But failed writes should be really rare, and there are plenty of times I'd trade the rare missing write for cheaper/faster database servers.
  - DanWaterworth 14y ago
    This wasn't the occasional write though, this was every write after 2GB. That should set off alarm bells somewhere.
    - benatkin 14y ago
      The way MongoDB is designed, this would be outside the scope of a driver. A storage library that's based on the ruby MongoDB driver could certainly do it, though. That's what the OP ideally should have been using. In fact MongoDB would be a good choice for his use case, if he would switch to a 64-bit VM and handle error conditions (heh).
  - twerquie 14y ago
    The problem with your code not caring if the odd record gets lost is that it probably also doesn't care if all records start getting lost.
- prodigal_erik 14y ago
  If your failure modes are uncorrelated (i.e., spread across datacenter facilities with separate power supplies), you might be happy knowing a majority has accepted the write in memory, even though none of them have stored it yet (because that's slower if you're on spinning rust).

DanWaterworth 14y ago

When is this behaviour useful? (Benchmarks don't count)

pooriaazimi 14y ago
I'm no expert in this area, but maybe if you want to use mongo for logging? Or things like that. I kinda like TCP vs. UDP analogy. Sometimes you care more about speed than precision. A few dropped items in a log. Not a big deal. I'd rather have that, than to be forced to use a more expensive machine for the job. That said, I absolutely think the default should be the TCP way.
eli 14y ago
Well, any time you'd rather have speed over completeness. Maybe you're aggregating tweets from the Twitter API and if the occasional one goes missing, it's not a big deal, or perhaps you can grab it on the next update. Maybe you're generating a real-time stats dashboard for your site and if one pageview gets lost every million, it's not a big deal. Look, I agree that in most cases you probably want to do everything you can to make your data 100% complete. But failed writes should be really rare, and there are plenty of times I'd trade the rare missing write for cheaper/faster database servers.
- DanWaterworth 14y ago
  This wasn't the occasional write though, this was every write after 2GB. That should set off alarm bells somewhere.
  - benatkin 14y ago
    The way MongoDB is designed, this would be outside the scope of a driver. A storage library that's based on the ruby MongoDB driver could certainly do it, though. That's what the OP ideally should have been using. In fact MongoDB would be a good choice for his use case, if he would switch to a 64-bit VM and handle error conditions (heh).
- twerquie 14y ago
  The problem with your code not caring if the odd record gets lost is that it probably also doesn't care if all records start getting lost.
prodigal_erik 14y ago
If your failure modes are uncorrelated (i.e., spread across datacenter facilities with separate power supplies), you might be happy knowing a majority has accepted the write in memory, even though none of them have stored it yet (because that's slower if you're on spinning rust).