A "durability matrix" that lays out all the possible combinations of headers and behavior would be a good place to start. Something that clearly states when data is synced to disk (and what fsync does on different OS'es) would be an excellent deliverable in its own right. I don't know all the spots on that grid, but perhaps I should start a wiki page with what we do know?
B. On Tue, Sep 15, 2009 at 11:54 PM, Jan Lehnardt <[email protected]> wrote: > > On 15 Sep 2009, at 20:30, Chris Anderson wrote: > >> On Tue, Sep 15, 2009 at 10:22 AM, Jan Lehnardt <[email protected]> wrote: >>> >>> On 15 Sep 2009, at 19:09, [email protected] wrote: >>> >>>> Author: jchris >>>> Date: Tue Sep 15 17:09:22 2009 >>>> New Revision: 815404 >>>> >>>> URL: http://svn.apache.org/viewvc?rev=815404&view=rev >>>> Log: >>>> changed default for 0.10 to delayed_commits = true for fast out of box >>>> experience >>> >>> Chris, please discuss this first on d...@. >>> >> >> Sorry about that - just having a strong gut reaction to the potential >> of releasing 0.10 that's too slow to use. >> >> Good thing is that this commit got everyone talking on IRC. >> >> The basic tradeoff here is between safety and speed. With a simple >> benchmark on my Mac laptop (OSX 10.5) delayed_commits gives ~230 >> writes/second while we only get about 5/sec with the slow safe option. >> >> I think 5 writes/second is too slow to be useful, so it doesn't matter >> how safe it is. > > I think we need to define use-cases a bit more clearly and then try to > determine how much safety we can and want to guarantee. I'd like to > avoid situations where we send a Created 201 response when that > doc is still in limbo and CouchDB could do extra work to make sure > it is on disk. > > I especially don't want to enable delayed commits by default for simple > speed-freak reasons. CouchDB could easily detect long running fsync()s > and send a log entry about enabling delayed commits. Proper documentation > & release notes will help too. Finally, there will always be people claiming > CouchDB has whatever properties (slow, fast, green) they see fit*. > > If we want to bill CouchDB as everybody's personal database, we better > keep that personal data safe :) > > Cheers > Jan > -- > * See Postgres. > > > > > >
