I suppose if you had a really small number of keys in Riak it might be
faster, but you're almost certainly better off maintaining a second
object and making the lookup constant time. Here's an example:
https://github.com/aphyr/risky/blob/master/lib/risky/indexes.rb
--Kyle
On 05/05/2011 03:49 PM, Andrew Berman wrote:
Ah, that makes sense. So is it the case that using the link
implementation will always be faster? Or are there cases where it makes
more sense to use a key filter?
Thanks!
--Andrew
On Thu, May 5, 2011 at 3:44 PM, Aphyr <ap...@aphyr.com
<mailto:ap...@aphyr.com>> wrote:
The key filter still has to walk the entire keyspace, which will
make fetches an O(n) operation as opposed to O(1).
--Kyle
On 05/05/2011 03:35 PM, Andrew Berman wrote:
I was curious if anyone has any thoughts on what is more performant,
links or key filters in terms of secondary links. For example:
I want to be able to look up a user by id and email:
*Link implementation:*
Two buckets: user and user_email, where id is the key of user
and email
is the key of user_email. User_email contains no data but
simply has a
link pointing back to the proper user.
*Key Filter:*
One bucket: user, where id_email is the key of the bucket. Lookups
would use a key filter tokenizing the id and then looking up the
id or
email based on the proper token.
Obviously both work, but I'm curious what the implications are
from a
performance standpoint.
Thanks,
Andrew
_______________________________________________
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
