2i for single-result lookup
nate at root.org
Mon Nov 7 21:19:48 EST 2011
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).
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.
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"
> On Monday, November 7, 2011 at 5:59 PM, Nate Lawson wrote:
>> On Nov 7, 2011, at 5:45 PM, Greg Pascale wrote:
>>> 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.
>> 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.
>> riak-users mailing list
>> riak-users at lists.basho.com
More information about the riak-users