Ok, then 2I will work fine for what you're doing if you're going to keep adding fields like that. You can just use the binary type for the 2I keys (_bin).
http://basho.com/blog/technical/2011/09/14/Secondary-Indexes-in-Riak/ You first said you were concerned about the query performance due to the covering set access and that you only had 2 unique fields. That's why I suggested you create a manual index (either email or userid) to lookup the other key. But with this additional info you mention, I think you should just use 2I since that's one of its main purposes. -Nate On Nov 7, 2011, at 6:11 PM, Greg Pascale wrote: > 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 >> [email protected] >> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com > _______________________________________________ riak-users mailing list [email protected] http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
