Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1078)
Subject: Re: performance issues
From: Jan Lehnardt <jan@apache.org>
In-Reply-To: <4BBAEF76.40705@julianmoritz.de>
Date: Tue, 6 Apr 2010 16:18:30 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <CE12A794-636D-40D0-A31C-6ABAF4DA4EE3@apache.org>
References: <4BBA0C4A.9080304@julianmoritz.de>
 <4BBA315B.5010701@julianmoritz.de>
 <7FB459A8-6A46-4CC0-818B-AE60B554A673@gmail.com>
 <4BBA37C8.7010702@julianmoritz.de>
 <8F7808FC-5840-4142-A149-E2AA94AB0012@gmail.com>
 <4BBAEF76.40705@julianmoritz.de>
To: user@couchdb.apache.org


On 6 Apr 2010, at 10:23, Julian Moritz wrote:

> Hi,
>=20
> first of all: to make the keys of a view unique via reduce, i do it as
> it's desribed in the "definitive guide to couchdb".

try using "_sum" as your reduce function, it'll use an Erlang version =
that
will be faster than the JS version. "_sum" expects the emit() value to =
be
an integer. Just emit(doc.whatever, 1).

Cheers
Jan
--

>=20
> J Chris Anderson schrieb:
>> On Apr 5, 2010, at 12:19 PM, Julian Moritz wrote:
>>=20
>>> But I need it for making my list unique. This is an important =
feature
>>> for my application.
>>=20
>> This is probably explains the slowness. When you do a group=3Dtrue =
query, CouchDB has to run the reduce function once for each unique key =
(serializing all the rows in the key to the JS process, and parsing the =
results.)
>>=20
>> I haven't tested this, but you might get better response throughput =
by dropping the reduce function and using a _list which only sends one =
row of output each time the key changes. This will avoid some additional =
Erlang processing of the result.
>>=20
>> Some documentation for _list is here:
>>=20
>> http://books.couchdb.org/relax/design-documents/lists
>=20
> Thank you, I will have a look on it.
>=20
> Regards
> Julian
>=20
>>=20
>>> Thanks, I'll think about how to set up a couchdb cluster and do more
>>> testing.
>>>=20
>>> Regards
>>> Julian
>>>=20
>>>> Chris
>>>>=20
>>>>=20
>>>>> Regards
>>>>> Julian
>>>>>=20
>>>>>> I've developed a (in my eyes) simple view. I have a wordlist =
which does
>>>>>> not  contain unique words. I want to store it in a view, with =
every word
>>>>>> occurring once and ordered by random. Therefore I have a simple =
view
>>>>>> function:
>>>>>>=20
>>>>>> function(doc){
>>>>>> emit([hash(doc.word), doc.word], null);
>>>>>> }
>>>>>>=20
>>>>>> and a simple reduce:
>>>>>>=20
>>>>>> function(key, values, rereduce){
>>>>>> return true;
>>>>>> }
>>>>>>=20
>>>>>> calling that view with group=3Dtrue it does what I want.
>>>>>>=20
>>>>>> When storing plenty of words to the database, one of my two cpu =
cores is
>>>>>> used completely by couchjs.
>>>>>>=20
>>>>>> Isn't the view built using two (or all) cpu cores? I thought =
(obviously
>>>>>> I'm wrong) that it would be calculated in parallel and using a
>>>>>> quadro-core (or more cores) would make storing faster.
>>>>>>=20
>>>>>> Is there a solution for that? Should I use another query-server?
>>>>>>=20
>>>>>> Regards
>>>>>> Julian
>>>>>>=20
>>>>=20
>>=20
>>=20