Thanks, Jeremiah. I didn't think about cache. I think cache is the way to go in production.
-- buriwoy On Thu, Mar 29, 2012 at 10:22 AM, Jeremiah Peschka < [email protected]> wrote: > Cache everything you can, even if you're persisting that cache in the > database. Data duplication is important when you want to make queries > faster. Doing a simple GET is going to be much faster than a MapReduce. > > --- > Jeremiah Peschka, Managing Director, Brent Ozar PLF, LLC > Microsoft SQL Server MVP > > On Mar 29, 2012, at 8:51 AM, Buri Arslon <[email protected]> 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 <[email protected]> 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 >> [email protected] >> >> 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 >> [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 > >
_______________________________________________ riak-users mailing list [email protected] http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
