Live data from Hacker News

MongoDB 1.7.5 Released with single server durability

groups.google.com

1–10 of 24 posts

Re: MongoDB 1.7.5 Released with single server durability

#3

Anyone did write benchmarks with durability enabled?

I didn't but I would be interested.

FWIW, here's the FAQ on performance with durability enabled:

How's performance?

Read performance should be the same. Write performance should be very good but there is some overhead over the non-durable version as the journal files must be written. If you find a case where there is a large difference in performance between running with and without --dur, please let us know so we can tune it. Additionally, some performancing tuning enhancements in this area are already queued for v1.8.1 and beyond.

Re: MongoDB 1.7.5 Released with single server durability

#6
This is great news, thank you!

Until 1.7.5, the advice seems to have been that ANY single server is vulnerable, always use replication sets to prevent losing data.

While I appreciate that point, and we do use ReplSets for every DB, in the real world problems happen.

    A circuit might explode in a DC, causing all the machines to go down. (Happened to me at ThePlanet)
    Our Secondary machine might go down, and while fixing it, the primary might fail. (Happened two weeks ago on dev machines)
    Our devs might run a test database on their Macbooks; While this isn't mission critical to stay up, potentially losing records means they need to restart all tests after an event, rather than resuming.
There's a million other places that this will be helpful. Yes, we should always spread things out as much as possible.. But I still use redundant power, RAID arrays, a journaled filesystem and in ideal times a ACID DB.

Here's hoping 1.8.0 will be out soon! ;)

Re: MongoDB 1.7.5 Released with single server durability

#7
post #4

I think making this an opt in feature is poor strategy. This should be opt out for the people who know what they are doing.

I agree that it's poor technical strategy. It may not be poor marketing strategy --- there are a lot of folks who are attracted by gaudy performance numbers, and may not care (at least not until they get burned) that they're dependent on unsafe defaults.

Re: MongoDB 1.7.5 Released with single server durability

#8

Anyone did write benchmarks with durability enabled?

This is a situation where the physical disk configuration may make a real difference. If the journal and the data files are on the same disk, a write-heavy load will be continually seeking between them. If they're on different disks, there's a lot less seeking, and that may reduce the performance penalty quite a bit (at the cost of extra hardware).

And of course, if you're on SSDs, this is all a non-issue, but that also still comes at a premium.

Re: MongoDB 1.7.5 Released with single server durability

#9
post #4

I think making this an opt in feature is poor strategy. This should be opt out for the people who know what they are doing.

No one is ruling it out as being the default in the future. However 1) it was a pretty major code change and 2) this is the first release to make it publicly available.

Do you really want that enabled by default right off the bat?

Re: MongoDB 1.7.5 Released with single server durability

#10
post #4

I think making this an opt in feature is poor strategy. This should be opt out for the people who know what they are doing.

Durability is a new feature, and should be treated as such. While it is currently not the default, that may change in a later release.
Post reply on HN