In view of our discussions last month about persistence solutions leading from CouchDB (particularly, the
different strategy by CouchBase) I discovered just now another direction from there, namely "bigcouch"
referred to in this post:
http://dieswaytoofast.blogspot.com/2012/02/migrating-from-couchdb-to.html
https://github.com/cloudant/bigcouch
"Clusters behave according to concepts outlined in Amazon's Dynamo paper, namely that each BigCouch node can
accept requests, data is placed on partitions based on a consistent hashing algorithm, and quorum protocols
are used for read/write operations."
Personally, this route sounds more attractive to me, since it seems likely to preserve more of CouchDB's
core virtues (REST API, master-to-master replication) whilst addressing its stability and deployment issues.
But who knows! This terrain changes every week or so :)
Antranig
_______________________________________________________
fluid-work mailing list - [email protected]
To unsubscribe, change settings or access archives,
see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
