Link or Secondary Indexes?

Alexander Sicular siculars at gmail.com
Thu Mar 29 15:03:39 EDT 2012


Fat data is a dirty little secret amongst system architects. "nosql"
solutions are practically based on the concept. Denormalization leads to
data duplication all over the place. Disk is cheap. Like the kid at dunken
donuts handing munchkins out at closing time. Eat that shit up. Yes, you
might hate yourself the next day; there are costs to pay like
synchronizing/invalidation and everything is a tradeoff but often it is a
price worth paying... And munchkins are delicious.

-alexander

@siculars
http://siculars.posterous.com

Sent from my rotary phone.
On Mar 29, 2012 11:51 AM, "Buri Arslon" <buriwoy at gmail.com> wrote:

> Kresten, Jeffrey: Thanks a lot for enlightenment!
>
> This link was very helpful to understand what to use when.
> http://wiki.basho.com/MapReduce-Search-2i-Comparison.html
>
> The information I obtained pushed me to another question :) .
>
> Q: Is it a good (or at least 'ok') practice to duplicate information in
> order to get cheaper/faster queries?
>
> i.e. If a user becomes a member of a group/fanpage I could store that
> information both in 'users' and 'groups' bucket. If I want to get the
> members of a particular group I query just one value/record in 'groups'
> bucket. The only drawback that came to my mind is when you delete that
> relationship you have to delete it from two buckets.
>
> Another scenario might be to get last 20 comments by a user. Instead of
> searching all posts/comments by author_name, I could just store the post or
> comment key in the user object as a secondary index and set some limit,
> say, 20 for <<"index">>, <<"last_posts_bin">>.
>
> What do you think?
>
> Thanks again,
> -- buriwoy
>
>
>
> On Thu, Mar 29, 2012 at 8:52 AM, Jeffrey Massung <jeff at basho.com> wrote:
>
>> Buriwoy,
>>
>> Neither is better (or worse) for "storing" those bits of information. The
>> question is how you expect to use that data once it is stored. Let's take a
>> look at friend relationships (note: I don't use Facebook, so I might be
>> missing a subtle feature with this example)...
>>
>> Do you merely plan on following a list of friends to other pages quickly?
>> For example, on your page, you see a list of your friends quickly, be able
>> to click them, and go to their page? If so, the links are quite nice. Links
>> are nice for being able to follow in a query as well. This is a good
>> example of using links to perform link walking:
>>
>> http://basho.com/blog/technical/2010/02/24/link-walking-by-example/
>>
>> Or, do you plan on doing reverse lookups by friends? For example, do you
>> want to say "find every who has Tony as a friend" and get a list of users?
>> Note: this is not asking who is a friend of Tony (you'd just lookup Tony
>> and get his list of friends). In this case 2i works nicely, as do other
>> query methods: search, a general MapReduce, etc. But links would be an
>> extremely poor choice.
>>
>> Does this help? This page might also be applicable to your question:
>>
>> http://wiki.basho.com/MapReduce-Search-2i-Comparison.html
>>
>> If you plan on just doing MapReduce queries without 2i, and don't care
>> about link walking, then just storing a typical JSON object and not using
>> either is perfectly fine as well.
>>
>> --
>> Jeffrey Massung
>> Software Engineer
>> jeff at basho.com
>>
>> On Mar 29, 2012, at 8:29 AM, Buri Arslon wrote:
>>
>> Hi,
>>
>> While developing my pet project few questions came to my mind and I
>> decided to consult with you.
>>
>> Which of them are more effective for recording relationships: Link or
>> Secondary Indexes?
>>
>> 1. Friend relationships: like Facebook friends?
>> 2. Followed/follower relationships like in Twitter?
>> 3. Member/Club relationship like fanpage in Facebook?
>> 4. Like in Facebook?
>>
>> Thanks,
>> -- buriwoy
>> _______________________________________________
>> riak-users mailing list
>> riak-users at lists.basho.com
>> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
>>
>>
>>
>
> _______________________________________________
> riak-users mailing list
> riak-users at lists.basho.com
> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.basho.com/pipermail/riak-users_lists.basho.com/attachments/20120329/f6a8c467/attachment.html>


More information about the riak-users mailing list