Why I don't use CouchDB.(blog.woobling.org)
blog.woobling.org
Why I don't use CouchDB.
http://blog.woobling.org/2009/05/why-i-dont-use-couchdb.html
29 comments
Software hipsters are the ones using CouchDB. The relational model has been refined over decades to accommodate the requirements of generic information systems and eliminate a lot of the problems that mapreduce-based databases ignore.
CouchDB solves a subset of information problems. The relational model can solve a vastly greater amount of problems.
CouchDB solves a subset of information problems. The relational model can solve a vastly greater amount of problems.
But both those subsets have very little overlap. CouchDB is great at solving problems that relational databases never can be good at.
As far as I can tell, it's great for solving problems people don't actually have and probably creating problems they didn't imagine.
What? CouchDB gets a lot of hype. Naturally people are curious, and they try to use it to solve their problems. Sometimes these problems aren't the problems CouchDB is good for. You can't fault the "software hipsters"--- the CouchDB documentation does a terrible job of explaining the "Why" of CouchDB.
I don't know, I think it's pretty straightforward. If you're going to use a piece of software that's based around map/reduce, you should understand the how and why of map/reduce first. CouchDB is actually a pretty straightforward piece of software. The documentation is totally fine. If it seems sparse, it's because CouchDB is a pretty sparse piece of software! It actually has very few features compared to most database systems.
If you had actually read my criticism you'd see that I do get what it does. I'm not faulting the design, I like it a lot, it's just that the implementation has issues that caused me to favour other schema free backends.
It's more a framework for building a database system IMO; you do what you need to do in views.
"software hipster" is an inaccurate characterization. Hipsters tend to choose something because it is simple and stylish rather than actually useful. As an example, they like fixed gear bikes.
Unfortunately, simple and stylish doesn't always win. I see lots of people riding fixed gear bikes in Seattle, for example. Actually, I don't see many people riding them, I see them walking them around because they have the wrong gearing for going up and down Seattle's many hills, and they can't actually ride them. In this case, simple and stylish is the wrong tool for the job -- they need a bike that can change gears. That may be inelegant, but it works really well.
CouchDB is the fixed gear bicycle of the database world.
Unfortunately, simple and stylish doesn't always win. I see lots of people riding fixed gear bikes in Seattle, for example. Actually, I don't see many people riding them, I see them walking them around because they have the wrong gearing for going up and down Seattle's many hills, and they can't actually ride them. In this case, simple and stylish is the wrong tool for the job -- they need a bike that can change gears. That may be inelegant, but it works really well.
CouchDB is the fixed gear bicycle of the database world.
Using a fixed gear bike in Seattle would be asinine, agreed. Within a relatively flat city, they make a lot of sense, however, and they're practically ideal for running short (< 3 mi, say) errands. They're mechanically simple and require practically no maintenance.
To push the analogy further, some of the buzz around couchDB reminds me of people obsessed with scaling (racing) without either any real understanding of algorithms (being in shape) or any chance of actually needing it (actually competing). That starts to sound more like a road cyclist with an expensive garage ornament, though... Fixed gear bikes are perhaps more like SQLite than couchDB, in that sense. They're actually really useful on a smaller scale.
I see where you're coming from on the hipster bit, just nitpicking.
To push the analogy further, some of the buzz around couchDB reminds me of people obsessed with scaling (racing) without either any real understanding of algorithms (being in shape) or any chance of actually needing it (actually competing). That starts to sound more like a road cyclist with an expensive garage ornament, though... Fixed gear bikes are perhaps more like SQLite than couchDB, in that sense. They're actually really useful on a smaller scale.
I see where you're coming from on the hipster bit, just nitpicking.
Hills don't stop them in San Francisco, that's for sure.
"software hipster" -- this speaks volumes. nice.
But not about the author of the OODB system, which is who was discussing it.
His point was that for -his- purposes CouchDB is not a convincing option for the backend object store to KiokuDB, with detailed explanations as to why.
I don't really understand why "this tool doesn't work for me and here's why" makes you a bad person - if he was saying why RDBMSes didn't work for his problem space and thus why he was using an OODB at all, I'm sure the comments would be very different.
His point was that for -his- purposes CouchDB is not a convincing option for the backend object store to KiokuDB, with detailed explanations as to why.
I don't really understand why "this tool doesn't work for me and here's why" makes you a bad person - if he was saying why RDBMSes didn't work for his problem space and thus why he was using an OODB at all, I'm sure the comments would be very different.
I'm not sure software hipster equates to "bad person."
dude you totally made my day =D
Discussions about CouchDB focus on its very large and complicated featureset. It would be interesting to see examples of actual problems it's good for and why or how it worked for them. I've seen one example where it wasn't very good and the developer switched to an SQL database, but nothing beyond that. Their website doesn't have anything like this, sadly.
the developer switched to an SQL database
You do know that the author of this article wrote an object database, KiokuDB, right?
You do know that the author of this article wrote an object database, KiokuDB, right?
Unfortunately you can only create a view from the
original data, there is no way to create views whose
input is other views. This means that you cannot do
anything really interesting with values from multiple
documents. You can aggregate data from several documents
using the reduce functionality into buckets, but you
can't process that data further.
Another idea that couchdb already does that is a necessary pre-requisite to this outcome (from http://jchrisa.net/drl/_design/sofa/_show/post/standalone_ap...):
Over the last few days I've polished up my
notion that CouchDB can be a perfectly viable
application host, all on its own, without any
3rd tier between database and client. That
is, CouchDB is capable of serving standalone
applications. These standalone CouchDB
applications can be deployed to any working
CouchDB node and used from any browser.
"If the mechanisms to restrict access were in place the CouchDB backend could be exposed to the browser directly, removing the server side application code as a bottleneck."
Never, EVER expose a database to a client! Doesn't matter what types of controls you think you have, you must ALWAYS have some business logic in place to protect the data.
Never, EVER expose a database to a client! Doesn't matter what types of controls you think you have, you must ALWAYS have some business logic in place to protect the data.
If the business logic is implemented in couchdb or implemented in serverside code, it's still business logic protecting the data.
It could be just as flawed, or even worse (e.g. sql injection allows malicious users to run database operations with no restrictions at all. If there were db level restrictions they could only destroy their own data).
This ALWAYS NEVER EVER type of mentality demonstrates exactly why CouchDB is simultaneously overhyped and condemned.
It could be just as flawed, or even worse (e.g. sql injection allows malicious users to run database operations with no restrictions at all. If there were db level restrictions they could only destroy their own data).
This ALWAYS NEVER EVER type of mentality demonstrates exactly why CouchDB is simultaneously overhyped and condemned.
The biggest advantage of CouchDB - compared with its competition - seems to be the ability to create views to query the schema less dataset. If I have to do this in mysql, then I will
have to create and maintain seperate columns with indices; making sure that updates to the data gets propagated to these columns etc. Do any of the CouchDB alternatives provide a cleaner solution?
MongoDB shows promise.
Have you tried using materialized views (http://en.wikipedia.org/wiki/Materialized_view)?
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 ...
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 ...
"... but it does show plenty of promise."
"Personally I would much rather see feature completeness first"
"Personally I would much rather see feature completeness first"
"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
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.
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.
edit: in case it's not clear, I like couchdb a lot and I think it's absurd that people people are backlashing against it because some monkey coder dorks found it highly buzzword compliant and are making it popular, despite not understanding it at all. So you end up with people hating something because it's getting some limelight for whatever reason, and then also many of the people championing it don't know how to use it correctly to build an app or anything. It's like two layers of stupid.