Comments on: Conflicting Reads and Writes http://labnotes.org/2007/09/12/conflicting-reads-and-writes/ Thu, 18 Mar 2010 06:29:32 +0000 http://wordpress.org/?v=2.9.2 hourly 1 By: as days pass by » Blog Archive » CouchDb http://labnotes.org/2007/09/12/conflicting-reads-and-writes/comment-page-1/#comment-138398 as days pass by » Blog Archive » CouchDb Fri, 14 Sep 2007 09:20:57 +0000 http://blog.labnotes.org/2007/09/12/conflicting-reads-and-writes/#comment-138398 [...] 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 [...] [...] 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 [...]

]]> By: Assaf http://labnotes.org/2007/09/12/conflicting-reads-and-writes/comment-page-1/#comment-138392 Assaf Wed, 12 Sep 2007 19:50:07 +0000 http://blog.labnotes.org/2007/09/12/conflicting-reads-and-writes/#comment-138392 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. 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.

]]> By: Gabe http://labnotes.org/2007/09/12/conflicting-reads-and-writes/comment-page-1/#comment-138391 Gabe Wed, 12 Sep 2007 19:28:52 +0000 http://blog.labnotes.org/2007/09/12/conflicting-reads-and-writes/#comment-138391 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. 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.

]]>