On Fri, May 28, 2010 at 6:10 PM, J Chris Anderson <[email protected]> wrote: > > On May 27, 2010, at 3:16 AM, Robert Buck wrote: > >> On Wed, May 26, 2010 at 9:01 PM, Randall Leeds <[email protected]> >> wrote: >>> On Wed, May 26, 2010 at 15:39, J Chris Anderson <[email protected]> wrote: >>>> >>>> On May 26, 2010, at 1:53 PM, Robert Buck wrote: >>>> >>>>> Hi Folks, >>>>> >>>>> Thank you for kindly answering my last round of questions. Here is >>>>> another question related to Couch: >>>>> >>>>> What sort of locality of reference exists in Couch with respect to >>>>> retrieval of state ? Is locality of reference solely at the document >>>>> level, or is locality of reference also exhibited elsewhere that >>>>> developers can take advantage of ? >>>>> >>>> >>>> Hmm, I'm not sure what you mean by locality of reference (I know it in the >>>> context of performance optimizations) >>> >>> Same. >>> >>> If you're using it this way, I guess the best answer is that documents >>> might be very sparsely spread out across the disk in a large database >>> that has not been compacted for a long time. Documents updated around >>> the same time might be closer to the tail of the file. We really rely >>> on the filesystem cache to make this something we can forget about. >>> >>> Does that answer anything at all? >> >> That's good, that confirms what I have read, just wanted to verify. >> Some database technologies allow you to "group" data more closely >> together, some call this a container, others call it a segment. From >> what I read Couch apparently has no such feature. >> >> Thanks so much for your help. > > Another performance thing you can do it, is use document ids that are near > each other in the keyspace. This will give better cache-locality in the > filesystem cache. Luckily, CouchDB does a good job of this by default, if you > use the built-in uuid generator. > > There were some analysis / benchmarks on this list a few months ago about the > difference between sorted, sorry I don't have the links handy. Upshot, small, > sequential-ish ids are the fastest. > > Chris
Thanks
