couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Metson <>
Subject Re: Best views performance
Date Sat, 08 May 2010 16:20:58 GMT
Glad it helped! The other thing to consider is having 1 design  
document (which means all views in that ddoc gets calculated at once -  
better IO if I understand right) or splitting "hot" views from colder  
ones, to only index what's needed. Again, depends on your use case/ 
access patterns.

The other thing to consider is always querying the views with ? 
stale=ok and having some other process update the views. This means  
your clients will always get a fast response, and you can trigger the  
view indexing when appropriate.

On 8 May 2010, at 10:35, Chris Hicks wrote:

> That does help. I am looking for low client side access times and  
> quick updating of the indexes as in many cases there will be many  
> rapid-fire changes to certain documents and I need the index to be  
> as up to date as possible. All The other concerns, while always  
> important to keep in mind, are lower priority for me for this  
> project. I think going the same route as you did is best, break  
> everything down into really small bits and only grab the specific  
> data needed from a smaller index. Thanks for the reply Simon.
> Chris Hicks
>> From:
>> To:
>> Subject: Re: Best views performance
>> Date: Sat, 8 May 2010 07:56:42 -0500
>> Hi,
>> 	I think it depends on what you are willing to trade. More indexes  
>> can
>> mean using up more disk space, and potentially longer calculation
>> time, but more efficient access on the client side (e.g. I'd get the
>> two fields I wanted instead of 20). So it depends on your  
>> application:
>> do you pay through the nose for storage, do you expect a lot of
>> updates (and hence a lot of view indexing) or are things fairly
>> static, do you have 1 client process of millions....
>> 	I tend to try and have a view that indexes one piece of information
>> and then reuse that as much as possible with grouping, reduce=false,
>> include_docs etc. I'll only add a view when I know that one of my
>> existing ones can't be bent to my will. Not sure if that's the best
>> way to go so YMMV...
>> Cheers
>> Simon
>> On 7 May 2010, at 17:03, Chris Hicks wrote:
>>> If I have a DB of lets say 100K+ documents, with each document
>>> having 20 fields, would it be more efficient to have a view that has
>>> indexed each document and simply run more complex queries over them
>>> or would it be better to have a number of smaller views, each
>>> covering only a few fields, and running much simpler queries on each
>>> of these views for whatever data might be needed at that moment. As
>>> with most things the answer is probably "it depends." If there is no
>>> easy answer could anyone tell me what the pros and cons are to each
>>> of these approaches?
>>> Chris Hicks 		 	   		
>>> _________________________________________________________________
>>> Hotmail has tools for the New Busy. Search, chat and e-mail from
>>> your inbox.
> _________________________________________________________________
> The New Busy think 9 to 5 is a cute idea. Combine multiple calendars  
> with Hotmail.

View raw message