couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jack chrispoo <jackchris...@gmail.com>
Subject Re: Question on what is CouchDB's strength
Date Tue, 13 Dec 2011 19:57:03 GMT
Thank you all for the helpful information : ) !

jack

On Tue, Dec 13, 2011 at 5:15 AM, CGS <cgsmcmlxxv@gmail.com> wrote:

> Hi Jack,
>
> The strength of a product is in your need for what that product can
> provide. Each product has its own characteristics which makes it more or
> less useful to your needs. So, not knowing your needs, I can only theorize.
>
> Here is a list of advantages/disadvantages CouchDB may present
> (considering only what you spoke about):
> 1. Update. Requires document ID, which may slow down the performance.
> 2. Insert. If not update, I peaked at ~6k medium size documents per second
> on a "not-so-great" computer (my personal laptop is better than that
> computer which is dedicated for tests at low hardware capabilities).
> 3. Scan. Advantage: given Erlang capabilities and the CouchDB smart way to
> read/write from/to a database, it can be performed in parallel with other
> requests. Disadvantage: it doesn't provide an accurate response if more
> documents were added meanwhile, but the update in views works faster after
> that (if you referred to views).
> 4. Latency. Difficult to answer because I don't know which type of latency
> you refer to. The overall latency depends on the type of request. If you
> refer to the time of response since the request is sent till Erlang code
> gives back a response, I wouldn't go for "the embarrassing Erlang". Erlang
> has a nice "habit" to spawn threads with no sweat and that compensate with
> the response time gained by other languages (in Erlang you need to think in
> parallel threads by default), especially in long jobs. That's my personal
> opinion.
> 5. Functionality. CouchDB has unique replication and document read/writing
> system (at least from what I know, but I don't know many things, so, I
> might be wrong :) ). You don't have master-slave type of replication (that
> makes it unique in my opinion), but only master-master type of replication.
> That makes it more suitable for complex sharding where you need extra
> control over the data insertion process. The read/write system is based on
> two-heads document versioning update. That decreases by far the probability
> for the database to be left in an inconsistent state and makes it recover
> the databases faster from crashes.
>
> Another drawback in terms of time is compaction. But, as I said, it
> depends on your needs. The compaction is useful only when you want to save
> space on your storage device. Otherwise, the banking system of bookkeeping
> the full history of the operations made by that moment has its own
> advantage.
>
> There are more "advantages/disadvantages" one can speak of in terms of
> comparing CouchDB with other noSQL products. But all these
> "advantages/disadvantages" are subject to one's needs at a given time (some
> advantages can turn / be turned into disadvantages and vice-versa, even for
> the same user whose needs are dynamic).
>
> I tried to be as objective as possible, so, my feedback to help you in
> your decisions. If I mislead you by a wrong information, please, forgive
> me, I am just an user.
>
> CGS
>
>
>
>
> On 12/12/2011 02:41 AM, jack chrispoo wrote:
>
>> Hi all,
>>
>> I am new to CouchDB. I and my friends have been evaluating several
>> datastores including Cassandra, HBase, MongoDB, CouchDB in terms of
>> update,
>> read, insert, scan throughput and latency. In our tests CouchDB performs
>> worst in all tests. I once read about some saying that because CouchDB is
>> written in Erlang, throughput and lantency is not CouchDB's strength. So
>> can someone tell me some advantages of CouchDB compared to other
>> datastores? I did look into views, but it seems that other datastores have
>> similar funtionalities - MongoDB can also execute javascript to generate
>> result, HBase has filter. So what exactly is CouchDB's strength?
>>
>> I'll be grateful to any comments, Thanks,
>>
>> jack
>>
>>
>

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