A bit early to write off the project, isn't it? The CouchDB devs have repeatedly stated that they're concentrating on getting it working right before making it fast. It's still in alpha, for crying out loud.
There are many positive aspects of Couch's MapReduce implementation. Sure, you can use Hadoop or what not for increased flexibility, but Couch gives you a baked-in storage system, universal HTTP interface, incremental views (big feature!), replication (another biggie) and a structure for it all to sit in, with a nice interface to boot. Sure, you could set that all up separately, but isn't there a lot of value having it all just there and working? And check out the MLs - chained reduce is a constant point of discussion; it's definitely on the roadmap.
The lack of strong authentication is also a puzzling point - how many people implement complex auth at the DB level in a web app?
He does have some good points - the overhead of setting up and pulling down a socket for each connection cannot be denied, but that seems solvable with persistent connections. Furthermore, Couch's stateless API and eTag integration offer powerful caching options.
One point that did strike home for me was about the lack of development direction - this does seem to be a problem. For example, the effort to make applications run directly from CouchDB seems speculative and pretty useless. If you're going to install erlang and CouchDb you may as well install an app server as well. But the BTree rewrite priortisation? There were good reasons for that: it was going to break backwards compatibility, so essential to do it ASAP.
All in all, decent points, but way premature. How about we at least get to beta first?
Then again, if this article rams home the huge importance of speed to the devs, maybe I shouldn't be arguing ...
"Personally I would much rather see feature completeness first"
As I said in my comment, the BTree rewrite was a breaking change. It required all users to dump and reload their DBs. (1)
You do agree that things like that are best done ASAP, right?
I want to see feature completeness too but with more people adopting the project every day, and beginning to use it in semi-serious situations, pushing file format changes through quickly is just good release practise.
(1) if it's the one I'm thinking of. The other you could be referring to just needed a view rebuild; still annoying but nothing like the file format change
Not sure if anyone will see this, but Matt Aimonetti (yes, that Matt Aimonetti) just posted to the CouchRest (a ruby library) ML reporting that with the availability of recent RPC-JSON ruby/erlang direct access libraries, an estimated 5x speedup was possible over the straight HTTP.
5x speedup by integrating with erlang direct, and the HTTP is still there if you need it. So there goes much of the premise of the blog post. Needless to say, the DB itself has still not been optimised for speed - not even close - so this is far from the last word on the project's ultimate speed potential.
This is why you don't read too much into the current performance characteristics of alpha software.
There are many positive aspects of Couch's MapReduce implementation. Sure, you can use Hadoop or what not for increased flexibility, but Couch gives you a baked-in storage system, universal HTTP interface, incremental views (big feature!), replication (another biggie) and a structure for it all to sit in, with a nice interface to boot. Sure, you could set that all up separately, but isn't there a lot of value having it all just there and working? And check out the MLs - chained reduce is a constant point of discussion; it's definitely on the roadmap.
The lack of strong authentication is also a puzzling point - how many people implement complex auth at the DB level in a web app?
He does have some good points - the overhead of setting up and pulling down a socket for each connection cannot be denied, but that seems solvable with persistent connections. Furthermore, Couch's stateless API and eTag integration offer powerful caching options.
One point that did strike home for me was about the lack of development direction - this does seem to be a problem. For example, the effort to make applications run directly from CouchDB seems speculative and pretty useless. If you're going to install erlang and CouchDb you may as well install an app server as well. But the BTree rewrite priortisation? There were good reasons for that: it was going to break backwards compatibility, so essential to do it ASAP.
All in all, decent points, but way premature. How about we at least get to beta first?
Then again, if this article rams home the huge importance of speed to the devs, maybe I shouldn't be arguing ...