Hi Nate, There are only 2 secondary keys for now (in addition to the primary key), but this number will grow to 5 or more pretty soon.
I think when you say "insert each separately", you mean create 2 duplicate objects, one keyed by username and one keyed by email. Or do you mean create one object keyed by username, and then another object containing the username and keyed by email (a manual index if you will)? Code complexity is the main reason I'd like to avoid a solution like this. Suddenly a user create operation requires n writes to be considered a success. If one fails, I need to delete the others, etc… It quickly becomes a pain. I don't know what you mean by "some relationship between the keys" -- Greg Clipboard On Monday, November 7, 2011 at 5:59 PM, Nate Lawson wrote: > On Nov 7, 2011, at 5:45 PM, Greg Pascale wrote: > > > Hi, > > > > I'm thinking about using 2i for a certain piece of my system, but I'm > > worried that the document-based partitioning may make it suboptimal. > > > > The issue is that the secondary fields I want to query over (email and > > username) are unique, so each will only ever map to one value. Since 2i > > queries a coverage set, but I'm only ever looking for one result, it's > > going to be hitting n-1 machines needlessly. > > > > So, what I'm looking to understand is how much overhead a single-result 2i > > lookup like this will incur vs. a primary-key lookup, or even vs. search. > > Search doesn't intuitively feel like the right tool here, but I wonder if > > it may actually be preferable since it uses term-based partitioning. > > > > Thanks, > > > If it's only 2 keys, why not insert each separately? You will double your > total number of keys in the db. But both search and 2I are creating extra > keys anyway in their private indices, so it has the same or worse effect on > total storage as doubling your primary keys. And query efficiency is worse, > as you point out. > > 2I and search are more useful where there's some relationship between the > keys, not when they're fully independent as you point out. > > -Nate > > > _______________________________________________ > riak-users mailing list > riak-users@lists.basho.com (mailto: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
