On Thu, Jun 30, 2011 at 01:06, Dirkjan Ochtman <[email protected]> wrote: > On Thu, Jun 30, 2011 at 09:53, Randall Leeds <[email protected]> wrote: >> But beyond the parallelization of request handling there's concurrency >> in the more general sense. The neat thing about Erlang, and why it has >> its reputation, is that the CouchDB code can be liberal about its use >> of concurrency at the code level without suffering from deadlocks or >> other headaches that often plague programmers of complex, >> multi-threaded shared memory systems. The Erlang team has taken care >> of all the hard parts about sharing data in a concurrent environment. >> As I understand it, the Erlang runtime's use of chipsets with many >> hardware threads is only improving, and those benefits will be >> automatically conferred upon CouchDB. > > One thing that, as far as I know, has not been parallellized is the > view indexer. While it should be possible to execute at least the map > part of map/reduce concurrently, CouchDB doesn't do that yet. IIRC > there were reasons for that? But at least it's good to be aware of.
This is true. The reason is that the protocol between CouchDB and the view server is synchronous. Just as you need multiple connections to a web server to make parallel HTTP requests, additional view server processes could be run with some added complexity in the CouchDB code. The better solution is to make this protocol asynchronous in the future, but such a change will only happen with a major version bump (2.0, for example) since it will break all the view servers currently written for other languages.
