On Wed, Jan 13, 2010 at 2:54 PM, Roger Binns <[email protected]> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Chris Anderson wrote: >> see: http://books.couchdb.org/relax/reference/recipes for Banking >> >> without MVCC views, there's no way to query accurately at all when >> inserts are underway (short of blocking reads during writes). > > I am afraid I do not understand what you are saying. Sure the scheme listed > in the book makes sense, but only if a transaction maps exactly to one > document (which I guess is the point). Even then I still don't see the > relevance. Things would only break down if the view returned partial > information (eg if a single document caused two view rows to be emitted but > only one of those was returned.) BTW views do not return the update_seq so > as an end user you still do not know up to date it is.
If that would help, there are I think people working on an update_seq patch for views. > > The file format does not need to protect each view row, but does need to do > so for the main database where the unit is a document. A reduce giving an balance for a particular account, could be effected by documents being inserted anywhere in the db. The current map reduce system guarantees that the balance returned reflects a consistent snapshot of the database, even if other operations are ongoing. (eg a given transfer will appear consistently, even if those same accounts are undergoing concurrent operations for other transfers.) We can't atomically prevent overdrafts, but how many banks do that, anyway? > > For example the view file format could use an atomic unit of 10,000 > document's view output or some number of megabytes. That unit can still be > regenerated if something bad happened (a rare circumstance such as untimely > power failure). There are alternate storage systems which either use locking or avoid any consistency guarantees at all. > >> If you need something with less consistency, you are encouraged to >> wrap your own indexing system around couchdb's map reduce runtime, or >> even build your own runtime. > > I am becoming very tempted to just dump CouchDB for SQLite with a trivial > REST front end, since it appears that CouchDB is just not capable of > handling 10million documents/2GB of data in anything resembling a sensible > amount of disk space or compute time for the foreseeable future. > It sounds like Couch does just fine if you run compaction. Perhaps we should recommend view compaction more aggressively. Chris > Roger > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAktOTyUACgkQmOOfHg372QRoZwCgqMCpYfZT3aHYXGMfqfMzXpk6 > 1UIAoN+CV+wtsyOW8Ndiq7c/qM5Qt4+Y > =7gg2 > -----END PGP SIGNATURE----- > > -- Chris Anderson http://jchrisa.net http://couch.io
