Paul, Thanks for the reply, I found this in the basho doc's..
Maybe the Basho guys can shed some light on the performance trade offs Lookup Performance # Secondary Indexes uses document-based partitioning, which means that the indexes for an object are stored on the same partition as the object itself. This has implications on query-time performance. When issuing a query, the system must read from what we call a "covering" set of partitions. The system looks at how many replicas of our data are stored and determines the minimum number of partitions that it must examine to retrieve a full set of results, accounting for any offline nodes. By default, Riak is configured to store 3 replicas of all objects, so the system can generate a full result set if it reads from one-third of the system's partitions, as long as it chooses the right set of partitions. The query is then broadcast to the selected partitions, which read the index data, generate a list of keys, and send them back to the requesting node. So am I correct in thinking as you increase the number of nodes whilst keeping N constant you will see a decrease in query performance? or have I got a stick which I am holding the wrong end of :-) Dave On 21 Feb 2012, at 22:09, Paul Gross wrote: > I can't speak to the performance differences, but my understanding is that > secondary indexes perform very well. > > Personally, I prefer one document with multiple secondary indexes instead of > extra documents. I think it's cleaner conceptually, and it's a simpler > implementation. > > On 2/21/12 2:46 PM, David Dawson wrote: >> >> This looks great >> >> Although I am still not clear when to use index's and when not to, for >> instance if I wanted to build a high speed backend system where you could >> look up a user either by their email address or their mobile number I see 2 >> ways to do this: >> >> 1 .Create a user document, followed by a user_email_index / >> user_msisdn_index document which points back to the user document >> 2. Create a user document and add a index called email and msisdn. >> >> My concern with options 2. is the performance characteristics and other >> tradeoffs ? e.g. is it quicker to do the lookup against a key, rather than a >> secondary index? >> >> Dave >> >> >> On 21 Feb 2012, at 15:29, Paul Gross wrote: >> >>> We at Braintree (http://www.braintreepayments.com/) open sourced our Riak >>> ORM for Ruby called Curator. It follows a repository pattern rather than an >>> ActiveRecord or Ripple pattern. >>> >>> You can check out the code on github: >>> https://github.com/braintree/curator >>> >>> We also released a blog post that explains our pattern: >>> http://www.braintreepayments.com/devblog/untangle-domain-and-persistence-logic-with-curator >>> >>> Comments welcome. >>> >>> Thanks, >>> Paul >>> >>> _______________________________________________ >>> riak-users mailing list >>> riak-users@lists.basho.com >>> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com >>
_______________________________________________ riak-users mailing list riak-users@lists.basho.com http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
