Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: error (nike.apache.org: local policy)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1283)
Subject: Re: Get the 20 posts, of the last seven days,
 ordered by number of hits
From: Filippo Fadda <filippo.fadda@programmazione.it>
In-Reply-To: <4BF6C96C-E49A-44BB-826C-A5BB7B35B0AA@programmazione.it>
Date: Tue, 23 Jul 2013 02:23:13 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <18E0ED04-5B09-49FA-A9D8-29A1332ECA9B@programmazione.it>
References: <F5E952A2-1B2B-4338-8A2D-84667B7B5E77@programmazione.it>
 <565CA793-C9DA-4BFE-AB3E-17D9E9287A69@programmazione.it>
 <1EC6F8E4-19BE-4368-9B8E-9B9EA317BAD6@calftrail.com>
 <4BF6C96C-E49A-44BB-826C-A5BB7B35B0AA@programmazione.it>
To: user@couchdb.apache.org

I wanna just provide an hint for the one are dealing with the same =
issue.
I was importing over 21000 posts, and for each one I was generating a =
number of documents of type 'hit' equals to the number each article has =
been viewed. This approach let you track the number of views per post, =
avoiding update conflicts.
But unfortunately I found that just the database itself (without any =
view) has grown to 8 GB after having imported 1400 documents. So, at the =
end of the process, I can imagine a database of about 120 GB without any =
views. So, this strategy can't be applied, unless you have a huge disk =
in the order of terabytes because each views will reclaim a lot of =
space.
I think, to avoid conflicts on posts updates, it's a better idea using =
another document type, called 'viewcount', to store the number of hits =
of each post, and run a compaction every few days to remove all the =
emitted 'hit' documents. Those 'hit' documents in fact are going to get =
a lot of space.

The thing I noticed is that CouchDB really needs patterns. Patterns are =
generic solutions to common and recurring problems. People, including =
myself, don't know how to model their schema to obtain a specific =
result, because a lack of experience or more simply, because CouchDB =
needs patterns like any RDBMS does. So, maybe it's a good idea writing a =
CouchDB patterns book. :-)

-Filippo=