Why CouchDB doesn't scale(spyced.blogspot.com)
spyced.blogspot.com
Why CouchDB doesn't scale
http://spyced.blogspot.com/2008/12/couchdb-not-drinking-kool-aid.html
5 comments
No, it has those features because it aims to be SQL standard compliant, as do those other RDBMSes.
Where is the Standard for these 'Document-oriented' DBs?
Where is the Standard for these 'Document-oriented' DBs?
Only those cheap imports don't have whip holders.
Otherwise, your contention in-domain feature copying somehow translates to cross-domain feature transfer is something that I fail to understand. Can you explain it better?
Otherwise, your contention in-domain feature copying somehow translates to cross-domain feature transfer is something that I fail to understand. Can you explain it better?
Postgress has certain features because it is competing, both technically and in marketing check-boxes, with other SQL databases. CouchDB is not an SQL DB (and not even an RDMS) and so doesn't automatically have to have the same rich set of features.
Wasn't this posted and discussed some time ago? It is somewhat dated, and the arguments weren't very convincing, in fact they struck me as typical marketing FUD.
Sure the Postgres folks have years of experience and so forth but it's not like the literature is not available to be incorporated in new approaches. CouchDB hits a certain sweet spot in combining a few new ideas together and the folks hacking it are some of the best. I highly recommend giving it a hard look.
I also hear that the canonical folks will be bundling it in an upcoming Ubuntu release so it will be easier than ever to check it out
Sure the Postgres folks have years of experience and so forth but it's not like the literature is not available to be incorporated in new approaches. CouchDB hits a certain sweet spot in combining a few new ideas together and the folks hacking it are some of the best. I highly recommend giving it a hard look.
I also hear that the canonical folks will be bundling it in an upcoming Ubuntu release so it will be easier than ever to check it out
If you see how long it took for MySQL to get features like views and stored procedures, which I consider pretty much indispensable, then warning people that something like CouchDB is far from being mature is hardly FUD. The worst thing is: the cool crowd doesn't even know what they are missing. It's like talking to someone using MySQL 7 years ago: they'd be all enthusiastic, not understanding why you would worry about the absense of mundane things like views or, god forbid, the ability to use multiple indices per table in a query...
> The worst thing is: the cool crowd doesn't even know what they are missing.
Actually, they do. A lot of the people interested in and writing code for these new databases are the ones who have seen first-hand the failures of the traditional DBA view of the world. If you look at where a lot of these projects are coming from and who are sponsoring them you will see that they are some of the companies that are at the leading edge of internet scaling and deployment. The advantage they have which you seem to ignore is that they can look back at the wrong turns in the development of the current crop of RDBMS and avoid those particular dead-ends.
Actually, they do. A lot of the people interested in and writing code for these new databases are the ones who have seen first-hand the failures of the traditional DBA view of the world. If you look at where a lot of these projects are coming from and who are sponsoring them you will see that they are some of the companies that are at the leading edge of internet scaling and deployment. The advantage they have which you seem to ignore is that they can look back at the wrong turns in the development of the current crop of RDBMS and avoid those particular dead-ends.
Yes ! I would totally fit in that camp of many many years experience with RDBMSes and DBAs. Things like CouchDB are a sight for old sore eyes.
I couldn't agree more. I've been using relational dbs my entire career and these attempts at new ideas I find refreshing.
MySQL was a relational database that was missing some very important RDBMS features. CouchDB is not a relational database, and the developers know it's not.
What it is Not
A relational database. A replacement for relational databases.
(http://couchdb.apache.org/docs/intro.html)
Obviously, CouchDB is a cool thing for the cool crowd, and doubtlessly many of the cool crowd are going to shoot themselves in the foot by using CouchDB when they should be using a lame boring RDBMS, which they can't bring themselves to do because that would be like wearing a polo shirt with their company's logo on it. That doesn't mean CouchDB is a bad idea. It's just a very sexy idea that will break a lot of hearts.
What it is Not
A relational database. A replacement for relational databases.
(http://couchdb.apache.org/docs/intro.html)
Obviously, CouchDB is a cool thing for the cool crowd, and doubtlessly many of the cool crowd are going to shoot themselves in the foot by using CouchDB when they should be using a lame boring RDBMS, which they can't bring themselves to do because that would be like wearing a polo shirt with their company's logo on it. That doesn't mean CouchDB is a bad idea. It's just a very sexy idea that will break a lot of hearts.
I've used every major relational database on the market, and views & stored-procedures being requirements are blanket generalizations that are arguable at best. Both of them are enterprise tools for working around stupid schemas and bad code.
Arguing that DBAs 'require' the complex features in the other relational database is like saying that Macs 'require' more complex interfaces so IT people can work with them.
Backwards, and wrong.
Arguing that DBAs 'require' the complex features in the other relational database is like saying that Macs 'require' more complex interfaces so IT people can work with them.
Backwards, and wrong.
views & stored-procedures being requirements are blanket generalizations that are arguable at best.
I hate to break it to you, but for any complex data representation you will have to make abstractions to work with it efficiently and consistently.
Both of them are enterprise tools for working around stupid schemas and bad code.
There are more complex systems out there than your blog. It doesn't have to even be near enterprisey before having solid schemas and relations are indispensable for working reliable and efficiently with your data.
Arguing that DBAs 'require' the complex features in the other relational database is like saying that Macs 'require' more complex interfaces so IT people can work with them.
I've heard worse analogies and will let this one slide. However your argument, in its essence, basically boils down to "lets just ditch databases, all their optimization features and just use unrelational, standalone files as records". You promote simplicity over rigidness and predictability, which is required for any processing and optimization.
If you for a second believe this naivé approach to data-access is going to give you better results in any non-trivial case, I'll challenge you to prove it. As for any trivial case: Performance doesn't matter, you might as well use XML.
I hate to break it to you, but for any complex data representation you will have to make abstractions to work with it efficiently and consistently.
Both of them are enterprise tools for working around stupid schemas and bad code.
There are more complex systems out there than your blog. It doesn't have to even be near enterprisey before having solid schemas and relations are indispensable for working reliable and efficiently with your data.
Arguing that DBAs 'require' the complex features in the other relational database is like saying that Macs 'require' more complex interfaces so IT people can work with them.
I've heard worse analogies and will let this one slide. However your argument, in its essence, basically boils down to "lets just ditch databases, all their optimization features and just use unrelational, standalone files as records". You promote simplicity over rigidness and predictability, which is required for any processing and optimization.
If you for a second believe this naivé approach to data-access is going to give you better results in any non-trivial case, I'll challenge you to prove it. As for any trivial case: Performance doesn't matter, you might as well use XML.
It doesn't have to even be near enterprisey before having solid schemas and relations are indispensable...
Amen! Some operations necessary on our site would be so slow as to make it unusable were it not for stored procedures and multiple indices per table. It would also be incredibly slow were it not for a well-configured PostgreSQL install. And all we do is aggregate ticket listings.
I've seen people fight with barebones MySQL installs over even more data than I deal with and it's simply depressing. Sometimes "stupid schemas and bad code" have nothing to do with it; you just need to process a lot of damn data. And for that, if using an RDMS, you need one that is mature, rock solid, and has a sufficient feature stack.
End PostgreSQL advertisement.
Amen! Some operations necessary on our site would be so slow as to make it unusable were it not for stored procedures and multiple indices per table. It would also be incredibly slow were it not for a well-configured PostgreSQL install. And all we do is aggregate ticket listings.
I've seen people fight with barebones MySQL installs over even more data than I deal with and it's simply depressing. Sometimes "stupid schemas and bad code" have nothing to do with it; you just need to process a lot of damn data. And for that, if using an RDMS, you need one that is mature, rock solid, and has a sufficient feature stack.
End PostgreSQL advertisement.
Not all projects need complex data representations. I would suggest that few projects need a complex data representation rather they need an appropriate one. As to views, transactions, and stored procedures consider a large open messaging system like Twitter. While a traditional database could help with the users profiles and settings giving that up for a significant increase in speed might be a great trade off for them. Or they could mix several database systems using the best tool for the job.
The idea that all databases need all features is a mistake, once one free open source project has everything and the kitchen sink it's time to start solving other problems.
The idea that all databases need all features is a mistake, once one free open source project has everything and the kitchen sink it's time to start solving other problems.
Not all data is relational and not all data fits into records.
examples?
Trees, Pictures, Classes, Anything that varies on a per instance basis and can't be easily shoved into a fixed schema. There are plenty of things relational database suck at, are you implying otherwise?
Not exactly "one-file-per-record", but Haystack is a nontrivial example of a FS based datastore. http://www.facebook.com/note.php?note_id=76191543919
If you see how long it took for MySQL to get features like views and stored procedures
I was using MySQL back in the 90s, and I remember their documentation. You didn't need transactions, they were slow - do it in your own code if you had to. You didn't need foreign keys, they were slow, enforce integrity in your code if you had to. You didn't need stored procs... You get the picture.
Baked deep into MySQL's culture is "if we don't have it, you don't need it" - even now. Feature-wise MySQL is probably 15 years behind Oracle - yet somehow its legions of fans are convinced it's on the cutting edge!
I was using MySQL back in the 90s, and I remember their documentation. You didn't need transactions, they were slow - do it in your own code if you had to. You didn't need foreign keys, they were slow, enforce integrity in your code if you had to. You didn't need stored procs... You get the picture.
Baked deep into MySQL's culture is "if we don't have it, you don't need it" - even now. Feature-wise MySQL is probably 15 years behind Oracle - yet somehow its legions of fans are convinced it's on the cutting edge!
Yeah. It's pretty much like MySQL all over, except this time they are doing something new which doesn't have any absolute, proven references out there, so you have to argue on a philosophical level why they are on the wrong track instead of citing absolute metrics.
The sad thing is that these people use MySQL of all things as a reference point as what a relational database can do, and hence to them it seems all reasonable.
The sad thing is that these people use MySQL of all things as a reference point as what a relational database can do, and hence to them it seems all reasonable.
It is new, I'll give you that. I'm not sure who you mean by "these people". CouchDB is a document database not a relational database. Comparisons are made mostly to help folks understand the differences not to argue superiority. One argument is that a schema-less approach solves the issue of dealing with schema evolution. Having worked with O-R mapping issues for years as well as OODBs and persistent heaps and so forth I think document databases provide a fresh look. The technology choices of JSON over HTTP, Javascript and Erlang all the way down are also very compelling. It strikes me as just good timing. YMMV
> One argument is that a schema-less approach solves the issue of dealing with schema evolution.
That part's not new. I worked in a Notes shop back in the 1990s, and the inevitable result of this was that every database was littered with documents created and updated by so many different versions of the apps that not even the developers really knew whether any fields could be relied on and which features would work for a given document without unpredictable failures.
That part's not new. I worked in a Notes shop back in the 1990s, and the inevitable result of this was that every database was littered with documents created and updated by so many different versions of the apps that not even the developers really knew whether any fields could be relied on and which features would work for a given document without unpredictable failures.
That's a discipline issue. Nothing stops people from writing their apps to do data migration on update. That is, have their model classes fill in any missing attributes with default values etc. before saving it back. The difference is that you can do it selectively.
Nothing stops people from creating retarded schemas for RDBMS's either.
Nothing stops people from creating retarded schemas for RDBMS's either.
Data migration requires a list of what the data looks like as of each version. Doing that by hand is just as much work as maintaining a schema, with the disadvantage that you'll find out the hard way, too late, whether it reflects reality.
> I also hear that the canonical folks will be bundling it in an upcoming Ubuntu release so it will be easier than ever to check it out
I think you're talking about "Ubuntu One"[1] a file syncing tool (kinda like Dropbox), and Ubuntu One use CouchDB for their storage.
[1]: https://ubuntuone.com/
I think you're talking about "Ubuntu One"[1] a file syncing tool (kinda like Dropbox), and Ubuntu One use CouchDB for their storage.
[1]: https://ubuntuone.com/
You keep using that word. I do not think it means what you think it means.
Not talking about immutability at all when talking about CouchDB's (potential?) scaling ability is odd.
Even if immutability in DBs was no innovation from CouchDB itself, CouchDB will have raised the level of awareness for immutable DBs and probably drive further development in this area. IMO immutability is the very basis of creating scalable applications. So, when talking about CouchDB and scalability you should talk about why the current CouchDB implementation is not scalable in spite of immutability.
Disclaimer: I've only read about CouchDB and never actually used it. I'm not convinced of every feature of CouchDB, I don't think, for example, that it is a good approach to dump type-safety in dbs altogether, though, SQL and RDBMS are not the last word in databases and it is valueable to test other, new models of data storage.
Even if immutability in DBs was no innovation from CouchDB itself, CouchDB will have raised the level of awareness for immutable DBs and probably drive further development in this area. IMO immutability is the very basis of creating scalable applications. So, when talking about CouchDB and scalability you should talk about why the current CouchDB implementation is not scalable in spite of immutability.
Disclaimer: I've only read about CouchDB and never actually used it. I'm not convinced of every feature of CouchDB, I don't think, for example, that it is a good approach to dump type-safety in dbs altogether, though, SQL and RDBMS are not the last word in databases and it is valueable to test other, new models of data storage.
CouchDB doesn't scale, but not for any of the reasons the author of this article lists. I especially like meaningless sentences like, "just like PHP programmers don't get namespaces." While true, it's not "just like" that.
The reason those features are in PostgresSQL is because they are in SQLserver, ... because they are in Oracle, ... because they are in DB2.
Based on that logic C should have had a report generator and the unix filesystem should have records - and your car would have a saddle and whip holder.