1. Sep 12th, 2007

    Conflicting Reads and Writes

    Dare Obasanjo, not impressed with what I have to say about CouchDB.

    No pun intended, but I think a lot of Dare’s arguments have nothing to do with the consistency of what I wrote, but the consistency of what Dare reads. Take for example:

    Me, in the opening statement: There are no indexes.

    Dare: There are indexes, otherwise the system would be ridiculously slow since you would have to run the function and evaluate every single document in the database each time you ran one of these views (i.e. the equivalent of a full table scan).

    Context: Opening statement was about that which you already know (tables), as I believe all good introductions should be, before transitioning to explain the difference, in this case computed tables (which they call views, but are not equivalent to RDBMS views).

    Not having queryable indexes that update immediately on write is an issue, very easy to illustrate in a working example. So if you want to present counter argument, there’s enough material there. But instead Dare, you nitpick a statement out of context, and then follow to show that you actually understood what I meant to convey. So why not start with that understanding, and take the discussion to a higher level of abstraction?

    I think our readers would be much more interested in reading that.

    I also want to use this as an opportunity to go on the record on a couple of points:

    The problem described by Pat isn’t a failure of relational databases vs. document oriented ones as Assaf’s implication would have us believe.

    I implied no such thing.

    Relational databases have failed the software industry in much the same way XML, Java and client-server failed the software industry. In other words, no failure to see here, move along. Those are all excellent technologies for solving a wide range of problems. Just that there are some problems they’re particularly poor at solving.

    The “failure”, as the case maybe, has nothing to do with technology but with people. It’s the familiarity syndrome: the hammer you know is the hammer you use. They fail only when used outside their original specification.

    What could be implied requires a reading of my post with zero sum eyes. As zero sum would have it, either RDBMS are the be all do all for data (not content) storage, or they’re piece of crap that needs to be thrown out with the trash. To zero sum eyes, pointing out that something is not the appropriate solution to all problems is the equivalent of tearing it from one extreme and implanting it in the other.

    There are no hidden implications in ‘thinking beyond the RDBMS’. It’s a reprhase of, not even a witty one, ‘thinking outside the box’. And thinking outside the box is not an issue of whether you’re going to throw the box or recycle it. It’s giving consideration to alternatives beyond that which we already know.

    It is the business reality that availability is more important than data consistency for certain classes of applications.

    It is business reality that got me seriously involved with RDBMS, and it is business reality that got me interested in read consistency databases. Business reality is a wide spectrum of requirements that requires a wide range of solutions.

    I trust that my readers are in the same position. That your interest in RDBMS has nothing to do with some executive decision made on the gold course of Oracle CIO Retreat, but from realizing how well it solves a certain class of business problems. And that you’re fully aware that for many business applications, using RDBMS is as appealing as running a marathon in your wedding shoes.

    One last point. What you think read consistency vs write consistency means is not what I think it means, which is perfectly ok. I took the point before to mention that there’s a concept behind it that I still need to explain. In a future post.

    1. Sep 12th, 2007

      Gabe

      I think he was responding more to the rising tide of hype around CouchDB rather than to your brief post per se. I’ve found myself in much the same boat, thinking that scalability and simplicity are awesome, but why isn’t anyone talking about the trade-offs? I mean there’s an awful lot of thought-hours in the relational model, and all those features are useful and sometimes necessary regardless of what level of relational knowledge the average programmer has.

      Certainly a large number of applications can do with a simple data store. There clearly need to be good options between flat files and RDBMSes. But all this hate of the relational model seems spurious. If you need the features than what other options are there (a pure relational DB rather than SQL might be a start)? Everybody dreams of scaling huge, but what percentage of real world applications actually needs more than a single dedicated DB box?

      So if CouchDB does what you need, then by all means go for it, but I’m not particularly looking to get away from RDBMSes. Sure, using an RDBMS could cause incredibly difficult scalability problems that require a massive re-thinking and re-factoring, but if I choose CouchDB hoping to avoid that, there will be a whole different set of challenges that may or may not be worse. Speculating about what those problems might be is above my head at this point, but over the next few years as we see serious adoption I’m sure we’ll all have a better idea of where the limitations are (sort of like we do now with SQL).

      Anyway, I have a great deal of respect for you, so I didn’t read it exactly the same as Dare, but in all honesty it did feel a little bit cheerleady.

    2. Sep 12th, 2007

      Assaf

      Few points. I didn’t get to talk about the benefits yet, I have a post on the back burner, so I don’t want to talk about the drawbacks yet. I think it’s premature of me to point out cons before explaining the pros.

      I don’t hate the relational model, I have an issue with relational databases, and I don’t think one is equivalent to the other. I actually do expect to use the relational model to work across data sources. But when I do that, some of the features relational databases offer seem to be more cost than benefit.

      And that’s because the relational database is not strictly an implementation of the relational model, but a lot of other things, that are in combination useful in some contexts, not in others.

      Read consistency vs write consistency best sums where I think the differences lay.

      On scalability. I for one do not have a Google size record count scalability problem to solve. I do, however, have other and much different scalability issues I want to solve, most of which related to the lifecycle and location of the data, which got me looking into read consistency before CouchDB came out.

      CouchDB happens to be the poster child in all of this, it’s like talking about social networks and referencing Facebook, putting a name to the idea. I don’t think CouchDB will be the only solution, may not even be the best one, but it’s something I can point people at right now and say “go play with this, let’s build some real experience to figure out the pros and cons, when to use and for what”.

      Because the best way to learn that is from usage, not idle speculation. And right now, CouchDB is the only thing I can play with.

      And yes, I do think my post was cheerleadery. It wasn’t particularly deep or well though out for that matter. It’s a pointer to something I’m excited about, of which we know very little right now, but I think has a great potential in the future, and I’m excited being able to play with it.

      A couple of months back I thought about writing one myself, now I don’t need to. So yes, more excitement than perspective.

    3. Sep 14th, 2007

      as days pass by » Blog Archive » CouchDb

      [...] FUCKING SUCKS“, and ne’er a truer word was spoken. As Assaf Arkin says, “Relational databases have failed the software industry in much the same way XML, Java and client-ser…” It’s a neat and clever way of trying to solve some of those things that an RDBMS may [...]

    Your comment, here ⇓

    Or using OpenID