incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Zdravko Gligic <zgli...@gmail.com>
Subject Re: Frugal Erlang vs Resources Hungry CouchDB
Date Fri, 01 Jul 2011 06:37:28 GMT
I mapped out a set of web 2.0 level questions:
>>> a) How many of the update headers are actually useful?  Is it just the
>>> last successfully written one or even just a few last ones ?

Jason Smith tried reducing them to my 0.2 level:
>> Excellent point. That's just it, isn't it?
>> How useful are the lower rungs of a ladder? How useful is the food you
>> ate a year ago?

Jens Alfke tried re-reduced them even much lower:
> How useful was the accident insurance policy you paid for last year and then
> didn’t have an accident? :-)
> The update header is largely there for disaster recovery.

But neither one even bothered trying to answer my question of whether
just the last updated header or perhaps the last few are ever used.

> The update header is largely there for disaster recovery.

I was also under an impression that the update headers (pointers to
the root of btree) are also somehow being used for reading
consistency.  If so then this might suggest that a database could be
rolled back to some previous point in time.  How far back and how
practical is another question.

In any case, this whole thread is about me trying to understand what
is happening under the hood - strictly in trying to understand for
what CouchDB can best be used.  However, since we are being a bit
flippant about it, let me give you my 0.2 impression of CouchDB.

On the surface, that RESTful API is so darn appealing and mostly
because many portals have gone back and added such RESTful API's to
whatever gunk they had beforehand.  Youtube is an excellent example.
So, the most appealing thing to me is that by using CouchDB, a
publicly exposable API to my own application ends up already being
baked in by CouchDB itself, without me having to do any additional
work. It's a whole another kettle of fish, whether I actually need to
expose such an API or even worse - what if it's detrimental to me to
do so and whether it is even possible not to.

However, much of CouchDB is like an onion, where you can not be all
that certain what you will end up getting underneath, until you have
carefully peeled off a layer or two and tried it yourself.  Case in
point is not just the issue of disk usage but number of concurrently
open files that can be into tens or hundreds of thousands. There is
just something about numbers like that, that does not feel natural -
mostly because it raises the question of how the heck did relational
databases ever manage to do with merely dozens of tables within a
single database.

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).
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.  Never mind the fact that good
number of apps need SQLite-like querying capabilities - right down to
full text searching and table joining.

But when all is said and done, while we are discussing what seem to be
quite large disk usage inefficiencies, I can not help but keep
thinking about those wonderful attachments capabilities.  What exactly
are they for, if not for attaching "things" that themselves can be of
appreciable size and especially if we consider multimedia and all.
So, what happens when one of those attachment(s) change?  Do the old
revs with the old attachments become dead and a new rev is written out
with the new attachment(s).  Does all of this not magnify the overall
disk "wastage" problem by the sheer size of such attachment(s).

Sincerely,
teslan

Mime
View raw message