tag:blogger.com,1999:blog-11683713.post5060389222595268934..comments2024-01-12T21:16:50.520-08:00Comments on Spyced: CouchDB: not drinking the kool-aidJonathan Ellishttp://www.blogger.com/profile/11003648392946638242noreply@blogger.comBlogger18125tag:blogger.com,1999:blog-11683713.post-56135547943349361532009-06-26T05:30:32.952-07:002009-06-26T05:30:32.952-07:00As everyone knows, scalability isn't about sin...As everyone knows, scalability isn't about single-node numbers (although those don't look too hot either); it's about whether adding Nx machines gives you Nx performance, and it's about automating growing and failure recovery so that you don't have to add Nx members to your ops team at the same time. If sharding + replication were enough to scale we'd all stick with pg and mysql, but it's not; at this point everyone's pretty much concluded that that's not adequate for big data.<br /><br />But manual sharding is labor intensive, error prone, and inflexible. You _can_ deal with machine failures but it's painful. And that's the good news. Growing your cluster is much worse. So is dealing with load hot spots.<br /><br />That's what my problem is with couchdb -- as Zach quoted, the first feature they tout is "distributed," which has become associated, fairly or not, with scalability features couchdb doesn't have. But none of their devs ever post a correction to articles lumping couchdb in with scalable databases to say, "actually, we mean this _other_ definition of distributed." They seem content to allow people to assume they have these other features too, which is understandable in some sense, but not really honest.Jonathan Ellishttps://www.blogger.com/profile/11003648392946638242noreply@blogger.comtag:blogger.com,1999:blog-11683713.post-13839854693708471112009-06-26T01:03:19.672-07:002009-06-26T01:03:19.672-07:00Bah, just saying something isn't distributed b...Bah, just saying something isn't distributed because it doesn't do X isn't really valid. There isn't a single technology what makes a thing distributed. The fact that it can do clusters makes it distributed. <br /><br />Claiming it can't scale calls for actual proof - tests and numbers - and not just words.Anonymoushttps://www.blogger.com/profile/09142492357180295534noreply@blogger.comtag:blogger.com,1999:blog-11683713.post-80104729572879530562009-06-25T22:18:20.521-07:002009-06-25T22:18:20.521-07:00CouchDB, MonogoDB(http://www.mongodb.org/display/D...CouchDB, MonogoDB(http://www.mongodb.org/display/DOCS/Home) and stuff like it have a place as it is essentally REST type service interfaces to databases where traditionally RDBMS was only accessible over specific ports, pipes or other network walls.<br /><br />CouchDB in that respect is a 'distributed' database.<br /><br />CouchDB may not be the end all but document databases are better suited for the future it is just we will be coding different where the middle tier is smarter about where data lies not just the database. Lots of people are coding that way already dealing with terabytes of data that really go beyond the point of being able to even run a process across all data at all. <br /><br />CouchDB was addressing a locking down of databases to one machine or cluster and freeing it to be more globally unique data (hash in the sky) when that type of system was just emerging, it will evolve just as RDBMS did.<br /><br />I do believe there are strong futures for RESTful HTTP/JSON based databases that can handle some vertical scale like something like terracotta gives you but the future is horizontal scaling mostly. Document databases fit that much better than RDMBS even if they are young and still iterating to get to market ready.drawkhttps://www.blogger.com/profile/02415622450354918934noreply@blogger.comtag:blogger.com,1999:blog-11683713.post-70429458491767691642009-06-25T22:14:59.826-07:002009-06-25T22:14:59.826-07:00Maybe it's just me with being join challenged....Maybe it's just me with being join challenged. Just yesterday, I was trying to do something with sqlite3 (which I love BTW for certain things) with nested selects and had to read up on the syntax for half hour because it forced me to think about the problem in a different way. I think the simplicity of writing P.O.JS (plain old javascript) to express what you want to query vastly overcomes any limitations of a project that's barely 1.0. Atleast to me, that's the attractiveness. We'll eventually have sharding, parallel map-reduce and all the bells and whistles. But the magic of Couch is that it's simple and it __just__ works and it helps me think about the problem the way it needs to be thought about.kowsikhttps://www.blogger.com/profile/14906926081633887368noreply@blogger.comtag:blogger.com,1999:blog-11683713.post-82785607621542992652009-01-02T16:42:00.000-08:002009-01-02T16:42:00.000-08:00@PENIX I see where you are coming from, but as I m...@PENIX I see where you are coming from, but as I mentioned in my earlier comment, what is introducing about CouchDB is the p2p distribution model. Nothing else even comes close for the purpose of distributing simple applications to users, while letting them own their own data.<BR/><BR/>CouchDB's storage model is closer to GFS than it is to Drizzle, so if you're looking for "big boys" to compare it to, that'd be one place to start.J Chris Ahttps://www.blogger.com/profile/11598260533932670972noreply@blogger.comtag:blogger.com,1999:blog-11683713.post-18142560659222142772009-01-02T16:08:00.000-08:002009-01-02T16:08:00.000-08:00When MySQL first started taking hold, many DB guru...When MySQL first started taking hold, many DB gurus dismissed it as useless. Sure, it doesn't do half of what big boys like Oracle can do, but it doesn't need to. Oracle is overkill to the people using MySQL.<BR/><BR/>CouchDB is another such technology. RDBMS is overkill for many web related projects. Those same PHP programmers who don't understand namespaces, and struggle with SQL, are going to eat this up.<BR/><BR/>I'm personally more interested in the Drizzle fork of MySQL than I am about CouchDB, but I'm definitely going to watch it closely so I can consider it for projects where it might fit the bill.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-11683713.post-43167672673292538082009-01-01T18:21:00.000-08:002009-01-01T18:21:00.000-08:00Thanks for the dynomite mention. If you want to p...Thanks for the dynomite mention. If you want to pick my brain about it, feel free to get in touch. Thanks.Cliffhttps://www.blogger.com/profile/03270187545997733098noreply@blogger.comtag:blogger.com,1999:blog-11683713.post-22349058644677802022009-01-01T15:00:00.000-08:002009-01-01T15:00:00.000-08:00@Jonathan, CouchDB will handle that for you.@Jonathan, CouchDB will handle that for you.JanLhttps://www.blogger.com/profile/04778932038681738668noreply@blogger.comtag:blogger.com,1999:blog-11683713.post-51942784511156130442009-01-01T14:18:00.000-08:002009-01-01T14:18:00.000-08:00@JanL: "just use database-per-disk" is not a solut...@JanL: "just use database-per-disk" is not a solution; you just run into the "CouchDB is not a truly distributed database" problem that much quicker, i.e., you have to manually partition. Manual partitioning is more painful the more nodes you have to manage, so a system that can only effectively handle a single disk per node is that much less attractive.Jonathan Ellishttps://www.blogger.com/profile/11003648392946638242noreply@blogger.comtag:blogger.com,1999:blog-11683713.post-16720044906007371562009-01-01T14:05:00.000-08:002009-01-01T14:05:00.000-08:00@StephanMore importantly. Scalaris lacks persisten...@Stephan<BR/><BR/>More importantly. Scalaris lacks persistent storage. It is memory-only.<BR/><BR/>--<BR/><BR/>@Peter<BR/><BR/>Same for memcached.JanLhttps://www.blogger.com/profile/04778932038681738668noreply@blogger.comtag:blogger.com,1999:blog-11683713.post-47927071075085156692009-01-01T14:03:00.000-08:002009-01-01T14:03:00.000-08:00> Writes are serialized. Not serialized as in ...> Writes are serialized. Not serialized as in the isolation level, serialized as in there can only be one write active at a time. Want to spread writes across multiple disks? Sorry.<BR/><BR/>Writes are serialized per database. Want to spread writes across multiple disks? Use multiple databases.JanLhttps://www.blogger.com/profile/04778932038681738668noreply@blogger.comtag:blogger.com,1999:blog-11683713.post-32866885331880304132008-12-31T23:20:00.000-08:002008-12-31T23:20:00.000-08:00I'm much more excited about Scalaris.http://code.g...I'm much more excited about Scalaris.<BR/><BR/>http://code.google.com/p/scalaris/<BR/><BR/>(Really-)Distributed, Erlang, Transactional Key/Value-Store.<BR/><BR/>What they lack is the JSON-API (easy to do yourself) and the server side map reduce (I miss that one, it's cool! but I'm still not sure how important that is or if it can be done with Hadoop as easily)<BR/><BR/>Peace<BR/>-stephanStephan.Schmidthttps://www.blogger.com/profile/03845125686370893937noreply@blogger.comtag:blogger.com,1999:blog-11683713.post-45312351157688027882008-12-31T17:06:00.000-08:002008-12-31T17:06:00.000-08:00@Peter CouchDB uses MVCC, so "whoever saves first ...@Peter CouchDB uses MVCC, so "whoever saves first wins" on a single node. Out of date saves fail, so clients must retry saving after fetching (and hopefully merging) the latest rev. <BR/><BR/>Replication flags any conflicting writes as they come in from other nodes. So if your application can process a queue of conflicted revs, you can scale it to multiple disconnected replicas, and have a guarantee of eventual consistency, as long as the nodes eventually complete a successful replication.J Chris Ahttps://www.blogger.com/profile/11598260533932670972noreply@blogger.comtag:blogger.com,1999:blog-11683713.post-38552591071428037272008-12-31T16:32:00.000-08:002008-12-31T16:32:00.000-08:00If I'm correct, CouchDB has no way to synchronize ...If I'm correct, CouchDB has no way to synchronize accesses across multiple keys (no transactions or locks).<BR/><BR/>In my mind, that makes it totally useless for just about anything interesting. Why would I use CouchDB over memcached?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-11683713.post-50142385618248561272008-12-31T11:00:00.000-08:002008-12-31T11:00:00.000-08:00CouchDB is no replacement for a relational databas...CouchDB is no replacement for a relational database. However, I think a lot of the excitement over it is driven by developers for whom the relational model is overkill. DHH was mocked for calling his database "a hash in the sky" but the reality is, that's what a lot of applications really need.<BR/><BR/>As far as scalability is concerned, CouchDB currently supports multi-master replication, as well as offline or disconnected writes. Availability is favored over consistency, so application developers will have to take seriously the chance that two different users could update the same document within a short time frame on separate nodes.<BR/><BR/>However, as Couch progresses, we're working to add cluster-wide transactions (as well as integrated partitioning) so in the long term, Couch should be able to scale with your data.J Chris Ahttps://www.blogger.com/profile/11598260533932670972noreply@blogger.comtag:blogger.com,1999:blog-11683713.post-16624112242594987032008-12-31T10:22:00.000-08:002008-12-31T10:22:00.000-08:00Eric, yes, that's why I said it's competing with t...Eric, yes, that's why I said it's competing with those systems "in the popular imagination, if not in its author's mind." The official position has always been what you say, but a lot of the blog activity hypes it as more than that.Jonathan Ellishttps://www.blogger.com/profile/11003648392946638242noreply@blogger.comtag:blogger.com,1999:blog-11683713.post-35590393827987642672008-12-31T09:43:00.000-08:002008-12-31T09:43:00.000-08:00I think that all your points are valid.However, yo...I think that all your points are valid.<BR/><BR/>However, your premise is that somehow it will replace current relational database technologies. I don't think that's its goal (in fact, in the "Introduction to CouchDB" on its own website, it states that it's not "a replacement for relational databases").<BR/><BR/>I think that comparing CouchDB to PostgreSQL is just comparing two different things.<BR/><BR/>If your premise is that other database technologies are better for storing logical documents in a distributed way, then I'd be really interested to see a post on that.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-11683713.post-48784794426013902252008-12-31T09:29:00.000-08:002008-12-31T09:29:00.000-08:00Amen. The CouchDB website starts off "Apache Couch...Amen. The CouchDB website starts off "Apache CouchDB is a distributed, fault-tolerant and schema-free document-oriented database accessible via a RESTful HTTP/JSON API." It took me a couple weeks before I realized that their definition of "distributed" was not my definition of "distributed".Zachhttps://www.blogger.com/profile/01934383936619649826noreply@blogger.com