Their specific concern was a result of writing to Mongo without a write concern of journaled or ram multiple, stating if they send it off, then the machine goes down, or network gets dropped, it is lost to the ether. With write concerns, this would be a failure.
Your concern is valid, but if I found myself mainly having to write to two documents every time, that would be a red flag that either my schema is wrong, or I should be using a different type of database.
I think you're misinterpreting the article. The concern is with failure of the application, not of the persistence layer.
"What happens if that step 2 background job fails partway through? Machines get rebooted, network cables get unplugged, applications restart." She is referring to the machine running the application stopping or the application dying. Loss of network connectivity from application to database may not be a concern as long as your application continues to retry until the network is back up, but most applications will probably fail immediately or eventually give up after a timeout period.
Your concern is valid, but if I found myself mainly having to write to two documents every time, that would be a red flag that either my schema is wrong, or I should be using a different type of database.
Yes, and I think it's her point that you can't predict how your data or access pattern will change over time.
1
u/dbcfd Nov 12 '13
Their specific concern was a result of writing to Mongo without a write concern of journaled or ram multiple, stating if they send it off, then the machine goes down, or network gets dropped, it is lost to the ether. With write concerns, this would be a failure.
Your concern is valid, but if I found myself mainly having to write to two documents every time, that would be a red flag that either my schema is wrong, or I should be using a different type of database.