11–20 of 24 posts
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?
Earlier quoted context omitted.
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?
ya i kinda want 'durability' to be enabled by default, actually
MongoDBs killer feature was/is sharding. If your deployment isn't going to require sharding from the get go, then I'm not sure why you'd be attracted to it instead of any of the other more mature alternatives.
Adding single server durability just gives MongoDB more possible use cases (e.g. small site, single server, low overhead enviroment, etc.).
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?
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 conc…
This covers what MongoDB is doing for durability.
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 conc…
Take a look at the documentation for Journaling: http://www.mongodb.org/display/DOCS/Journaling This covers what MongoDB is doing for durability.
Earlier quoted context omitted.
ya i kinda want 'durability' to be enabled by default, actually
I thought the whole idea behind MongoDB is to deploy at scale . In other words, deploy over 100s of boxes and don't worry about RAID, or single sever durability because at that scale any single server is liable to fail so you'll need to ensure platform-wide durability via replication. MongoDBs killer feature was/is sharding. If your deployment isn't going to require sharding from the get go, then I'm not sure why you…
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…
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.
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.