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)
Message-ID: <4BEC43B3.8070807@digitalgott.de>
Date: Thu, 13 May 2010 20:23:47 +0200
From: "c.Kleinhuis" <ck@digitalgott.de>
Reply-To: ck@digitalgott.de
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: user@couchdb.apache.org
Subject: Re: large attachments/huge databases ?`
References: <AANLkTimb6aZ0PY75tUYoOB1tVcooFfHwjXuQMCDjvHkt@mail.gmail.com>
 <4FD426D8-F807-4FCE-8B98-36B9B0B2C058@googlemail.com>
 <4BEBCDAB.4070708@digitalgott.de>
 <AANLkTikgHoM8publkQ1wWxMaJksZ_0OIEe43cZgFS63W@mail.gmail.com>
 <20100513160136.GB9782@seblaptop> <4BEC2A4C.4090303@digitalgott.de>
 <2C9F0F2E-F87B-4BC7-B55D-7D7A2E965428@googlemail.com>
In-Reply-To: <2C9F0F2E-F87B-4BC7-B55D-7D7A2E965428@googlemail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


>> -he read that indexing is significantly higher than e.g. mysql -
>> my answer was that indexing is not affecting performance because it is a
>> one time action ....
>>     
>
> Right, once indices are generated, they are updated incrementally and very fast on access.
>
>   
ok, sounds good

>> -another point is general performance of about e.g. 200.000 documents in a single
>> database ... how is disk usage when maintaining versioning of each document ?
>> -can the versioning be deactivated or deleted ?!
>>     
>
> Again, there is no "versioning" of documents - at least not what most people expect from document versioning. There are only two reasons why couchdb keep "versions" of documents: MVCC and the append-only principle.
>
> You need to compact your database on a regular bases (depending on your updates to documents) and no, there is no way to completely disable "versioning" (and it wouldn't make any sense to do that). The append-only approach leads automatically to higher disk usage compared to in-place updates, thus you need to cleanup your database (run compaction) but you win robustness and there is no fixup phase needed in case of hardware failure e.g.
>
>   
in fact i would like to use the versioning exthausive, because each 
version of a task status should be
accessible, can i access older versions of a document easily ?!

the versioning feature is quite cool, because i would have to implement 
it using hibernate/spring
otherwise ...

> you're welcome :)

thx
ck