MongoDB 1.7.5 Released with single server durability

http://groups.google.com/group/mongodb-user/browse_thread/thread/4b94744f1f709048

by princeverma • 15 years ago

83 23 15 years ago

groups.google.com

mike_esspe• 15 years ago

Anyone did write benchmarks with durability enabled?

thibaut_barrere2• 15 years ago

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.

rst2• 15 years ago

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.

xal• 15 years ago

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.

thibaut_barrere2• 15 years ago

Good point - I asked on the list to see what their opinion is on that point.

rst2• 15 years ago

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.

kchodorow• 15 years ago

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?

snissn• 15 years ago

ya i kinda want 'durability' to be enabled by default, actually

ehwizard• 15 years ago

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.

jacques_chester• 15 years ago

Durability is the new web scale.

e1ven• 15 years ago

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! ;)

cheald• 15 years ago

It's worth noting that this is not a "stable" release. MongoDB releases with an odd minor version number (1.3, 1.5, 1.7) are unstable development releases, and should be treated as such. 1.8 will be the first official "stable" release with single-server durability.

johngalt2• 15 years ago

Forgive my ignorance, but I had no idea what single server durability was. So I had to look it up. I couldn't find any direct definitions, but from what I read it sounds like it does this:

Single server durability is a disk buffered list of pending writes so if the server reboots while in operation it can just resume where it left off. In larger deployments this risk is handled by having multiple servers running concurrently.

Does this sound right?

rit• 15 years ago

Take a look at the documentation for Journaling: http://www.mongodb.org/display/DOCS/Journaling

This covers what MongoDB is doing for durability.

johngalt2• 15 years ago

Thanks that is exactly what I was looking for.

lazyjeff• 15 years ago

I've always thought the MongoDB database was really good, but has poor drivers for node.js. I've been using node-mongodb-native, and it has basically no documentation. If you want to use a relatively new feature, you have to figure out how to convert from the MongoDB command line syntax in the MongoDB docs, to some syntax that the driver understands (which may sometimes be impossible). If you have poor drivers, even an awesome database won't make up for it.

mnutt• 15 years ago

It also requires way more nesting than it should, in my opinion. It would be nice to have a synchronous connect method so that I don't have to wrap my entire app in a connect callback.

And I don't see why 'collection' should take a callback either, unless you're in strict mode and querying mongo to see if it exists.

Some people have written higher level APIs on top of node-mongodb-native, two that I have seen are mongoose and mongous. I'm still evaluating them to see what their performance characteristics look like.

MongoDB 1.7.5 Released with single server durability

Related Stories