couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vladimir Kuznetsov <vova...@gmail.com>
Subject Re: _global_changes database best practices
Date Thu, 06 Jul 2017 04:20:07 GMT
thanks guys!
--Vovan

> On Jul 5, 2017, at 9:19 PM, Joan Touzet <wohali@apache.org> wrote:
> 
> And as a corollary to this, we are enabling the compaction daemon by
> default shortly. I expect this change to be enabled for the upcoming
> CouchDB 2.1 release.
> 
>    https://github.com/apache/couchdb/pull/624
> 
> -Joan
> 
> ----- Original Message -----
> From: "Robert Samuel Newson" <rnewson@apache.org>
> To: "user" <user@couchdb.apache.org>
> Sent: Wednesday, 5 July, 2017 7:07:54 PM
> Subject: Re: _global_changes database best practices
> 
> Hi,
> 
> Sorry.
> 
> The global database schema is well designed and the database should compact down very
neatly, so be sure you _are_ compacting it regularly. If it's still a problem, just delete
it, it's completely optional. Obviously you lose the /_db_updates feature without the backing
store, but everything else works.
> 
> B.
> 
>> On 5 Jul 2017, at 23:47, Vladimir Kuznetsov <vovanec@gmail.com> wrote:
>> 
>> Hi guys,
>> 
>> Can somebody please answer this?
>> 
>> thanks
>> --Vovan
>> 
>>> On Jun 29, 2017, at 3:37 PM, Vladimir Kuznetsov <vovanec@gmail.com> wrote:
>>> 
>>> Hi guys,
>>> 
>>> Can somebody please answer this? I'd really appreciate If somebody could provide
any good pointer to the documentation about _global_changes internals. I think it'd be useful
for many people. Basic answers like at what circumstances _global_changes is being updated(I
noticed it's not always updated on document insert), does it provide any expiration or self-management
capabilities to get it's size under control, any other things to keep in mind...
>>> 
>>> thanks,
>>> --Vovan
>>> 
>>> 
>>>> On Jun 27, 2017, at 1:09 PM, Vladimir Kuznetsov <vovanec@gmail.com>
wrote:
>>>> 
>>>> Hi guys,
>>>> 
>>>> I have thousands of databases in Couchdb 2 cluster and I get them constantly
updated. Each database is also rotated on monthly basis i.e. I'm keeping dbs for the last
several months, then just remove oldes ones. I suppose _global_changes database is going to
extensively grow as databases are going to be continuously created/updated/deleted. Does _global_changes
database provide any mechanism of automatic data expiration? Or is it better to disable _global_changes
database with such a usage pattern? 
>>>> 
>>>> thanks,
>>>> --Vovan
>>> 
>> 


Mime
View raw message