couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <>
Subject Re: The Blog
Date Mon, 09 Feb 2009 12:03:59 GMT

On 9 Feb 2009, at 12:38, Mister Donut wrote:

>> It be easier to follow your thoughts, if you would take the time
>> to formulate them in complete sentences. Your offensive tone
>> doesn't help either.
> I don't know where I am being offensive, but I don't like when people
> just assume that I stupid or haven't done my research.

I never said you were stupid. Your mails quote prove the opposite.
I implied you haven't done your research, which you have. Sorry,
no offence meant. Thanks for being constructive here! :)

> Because, yes, I
> have searched for pagination, and yes, I have read the Wiki, and yes,
> I realize that CouchDB isn't a RDBMS, and no, I am not trying to put
> my RDBMS ideas into CouchDB. And this isn't mean offensive, but rather
> to show you that I really tried, to my best knowledge. I know what
> MapReduce is. I know what Key/Value pairs are. I know how CouchDB puts
> them together (the idea, I am not an Erland hacker).

I didn't imply that you don't know about any of the above. I was
restating my personal and a commonly observed pattern that it
takes a bit of getting used to the CouchDB way and using analog
SQLisms rather hinder understanding CouchDB. I'm glad that
this is not the case with you.

>> limit is documented to be slow and should not be used to
>> implement paging. That's what startkey and endkey are
>> for and the mailing list archives show you how that is done.
>> Which is not the only solution to pagination.
> Startkey and Endkey allow you to implement "Back" and "Forward". I
> wrote that. They do not allow you to jump directly somewhere. For
> that, you'd somehow need to store start- and endkeys, but the nature
> of CouchDB doesn't allow you to. Unless I am missing a point. Amazon
> SimpleDB, and Google WebApps (sp?) suffer from the same problem, if
> you read their forums. Basically they tell you: "Well, it doesn't
> work".

CouchDB won't allow you to "jump to page X", but if you look at
e.g. Google, it doesn't work either. (You often get 10+ pages
of results shown on the first page and if you go to the second
you end up only seeing 3 follow up pages). You can jump to
a page if you are using a sequence as your key in a view which
would be analogous to how an RDBMS would do it. But surrogate
keys are considered harmful and I'd say (but that really depends
on the application), not very helpful. The problem with sequences
in a distributed database is that you can't create them reliably (CAP
again), that's why SimpleDB and BigTable won't do it.

>> See CAP*, RDBMSs pick consistency and availability where CouchDB
>> picks availability and partitionability.
>> * Consistency, Availability, Partitioning, pick two.
> I know, as I said, I read the book. Not trying to be offensive.
> What application benefits from picking Partitionability and
> Availability? And can work with a lack of Consistency?

CouchDB is eventual consistent (in the partitioned case). The
benefit from allowing for partitioning is that you can build systems
with reliable fault tolerance and load balancing (or scaling if you
will) that use more than single machine.

> You cannot store any kind of counters, or duplicate data, basically
> anything that needs to be the same as something else.

Can you elaborate on that? I don't quote get the "or duplicate data,
basically anything that needs to be the same as something else" bit.

>> If you try to find 1:1 mappings of solutions from the RDBMS world
>> to CouchDB, you must conclude that CouchDB sucks. But that
>> doesn't mean that CouchDB sucks.
> What I am trying to find, is an example, that, by using CouchDB,
> offers an unique solution.
> All examples of CouchDB I have seen so far, are either so simple, they
> don't show what CouchDB is all about (probably the author doesn't get
> it, not trying to be offensive, but posts like "10 Reasons Why CouchDB
> Is Better Than (Random RDBMS)"... well.) or they try to solve a
> problem that has already been solved by RDBMS.

CouchDB solves the similar problems as an RDBMS, but starting
from a different angle (distributed operation instead of single-node
operation, CAP, yadda yadda).

The 10 reasons post is a little populist, granted :)

> Availability (well, yeah, I don't know what to say).
> Partitionability:
> The Replication feature is really interesting. It is intriguing. It
> makes me want to make something with. But I just cannot find anything
> that could "exploit" this very feature.

A couple of things you can do with CouchDB replication (again, not  
that you can't do some of those with an RDBMS but it is getting harder
the further you move down the list):

  - Build a hot-spare failover clone of a live database server.
  - Build a set of read-only nodes for spreading read load.
  - Build an N-master database cluster that is eventually consistent,
    can linearly scale writes by adding more nodes and protects
    against machine failure.
-  The above, but with geographic distribution.
-  Build a distributed p2p application where each user has a local,
    off-line copy of her data (to allow for availability without a  
    connection and reducing latency) that can exchange data with
    other users using replication when online.


View raw message