couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jens Alfke <>
Subject Re: Frugal Erlang vs Resources Hungry CouchDB
Date Fri, 01 Jul 2011 15:43:18 GMT

On Jun 30, 2011, at 11:37 PM, Zdravko Gligic wrote:

> Then there is the whole issue of servers (where much of this makes
> sense because of scalability) vs clients (where very little of this
> makes any sense because there are no multi-user concurrency issues).

Sure there are. I’ve spent my career working on client-side software and concurrent access
to databases has definitely been an issue in some cases. Just think of multiple processes
instead of users.

As an example, I worked on the “PubSub” RSS/Atom framework for Mac OS X. This uses a sqlite
database to store the user’s feed subscriptions and current article set. At any time you
could have the following going on simultaneously:
- user reading articles in Safari or Mail, implicitly marking them as read
- MobileMe synchronizing the read/unread state of articles between this computer and another
- background daemon fetching feeds from the net and adding new articles
- another task in the daemon deleting old articles to save room

There were definitely availability problems at times, especially soon after user login when
several of these might be going on simultaneously and disk bandwidth is otherwise constrained
because lots of apps are starting up.

> On top of that, when the same issues are raised with regard to mobile
> devices, the prevalent answer is "oh, those clients only need a much
> smaller subset".  So, when it comes to CouchDB on client devices, one
> is left with an impression that it is not really a database for
> storing hundreds nor even tens of thousands of records but mere dozens
> or few hundreds of key/value pairs.  

You’re exaggerating what I (and others) said. My point was that the typical data set on
a mobile device is a lot smaller than the typical data set on a server, both because it’s
only one user’s data instead of thousands, and because the tasks are often different. But
by ‘smaller’ I didn’t mean ‘toy-sized’.

> Never mind the fact that good
> number of apps need SQLite-like querying capabilities - right down to
> full text searching and table joining.

You can add full-text search to CouchDB, just as people were using external text indexers
with sqlite before one got built into it a few years ago.

Apps don’t need table joining per se — they need the ability to query based on combinations
of the contents of related records, and joins are the particular kind of hammer that does
that job in a relational db. CouchDB’s views support this quite well, it’s just a different
mechanism than what you’re used to. (CouchDB also allows the schema to be denormalized compared
to what you’d do in a relational db, which lessens the need for combining records.)

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message