thanks for the info.
Rohman On Thu, 28 Jul 2011 00:05:06 -0700, Aphyr wrote: > Same deal, re conflict resolution. Personally, I'd store associations in > the body; you don't save *that* much serialization cost, and links are > limited to a thousand or so records. > > --Kyle > > On 07/28/2011 12:04 AM, Antonio Rohman Fernandez wrote: > >> what about the use of Links? Rohman On Wed, 27 Jul 2011 23:54:34 -0700, Aphyr wrote: >> >>> If you don't delete the associated records, you can use allow_mult to handle concurrent writes. If you do need to delete them consistently, you can use a statebox model to handle it within certain size bounds. --Kyle On 07/27/2011 11:47 PM, Antonio Rohman Fernandez wrote: >>> >>>> I also thought on that... but then the "User" object could become really big... imagine i post 10 statuses every day and thousands of friends comments all the time on them... also... wouldn't be troublesome to update the "User" object when "friends" comments on statuses? as you should have to retrieve the data to insert the new comment nested and if several friends comment at the same times i see data getting lost in the way... or i'm missing something? thanks Rohman On Wed, 27 Jul 2011 23:40:30 -0700, Sylvain Niles wrote: >>>> >>>>> Hi Rohman, the conversation yesterday got us to thinking and Basho confirmed that buckets are a form of key prefix. So no matter how small the bucket it will traverse the whole key space for a map reduce. We sat down and did some thinking of how to work our data differently as we have a similar use case to you and decided on nested docs using Ripple. In our case we had special buckets for each user like you describe below. Now that bucket is a nested JSON struct inside the user object instead of a separate bucket. In your use case you could have all statuses as a nested struct on your user object and display would be a matter of linkwalking all an user's friends and parsing status content with some time/sorting. On Wed, Jul 27, 2011 at 11:26 PM, Antonio Rohman Fernandez roh...@mahalostudio.com [2]>> wrote: Yesterday, somebody suggested that not for having the data distributed on smaller buckets, Riak's MapReduce operations would be faster... while nobody at Basho confirmed that yet, i'm now wondering which is the best way for storing data... lets imagine this simple excercise: 1. We have entities users, friends, statuses and comments in a web app 2. Users can make friends with other users 3. Users can post statuses 4. Friends ( Users ) can comment on user's statuses At first i thought on having a bucket called "users" with all users and then for friend linkage i was thinking on having personal buckets like "rohman_friends", "fyodor_friends", etc... with the keys to the users instead of a big "friends" bucket for easy querying... but seems i'm wrong... so... How would you distribute the data on buckets? and how would you run MapReduce jobs? Would you use a support SQL database to store relationship between keys? is possible on an only Riak environment? thanks Rohman line logo *Antonio Rohman Fernandez* CEO, Founder & Lead Engineer roh...@mahalostudio.com [4] roh...@mahalostudio.com> roh...@mahalostudio.com [5]> *Projects* MaruBatsu.es PupCloud.com Wedding Album line _______________________________________________ riak-users mailing list riak-users@lists.basho.com [9] riak-users@lists.basho.com> riak-users@lists.basho.com [10]> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com [11] >>>> -- line logo *Antonio Rohman Fernandez* CEO, Founder & Lead Engineer roh...@mahalostudio.com [13] roh...@mahalostudio.com> roh...@mahalostudio.com [14]> *Projects* MaruBatsu.es PupCloud.com Wedding Album line _______________________________________________ riak-users mailing list riak-users@lists.basho.com [18] riak-users@lists.basho.com> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com [19] >> -- line logo *Antonio Rohman Fernandez* CEO, Founder & Lead Engineer roh...@mahalostudio.com [21] roh...@mahalostudio.com> *Projects* MaruBatsu.es PupCloud.com Wedding Album line -- [25] ANTONIO ROHMAN FERNANDEZ CEO, Founder & Lead Engineer roh...@mahalostudio.com [26] PROJECTS MaruBatsu.es [27] PupCloud.com [28] Wedding Album [29] Links: ------ [1] mailto:roh...@mahalostudio.com [2] mailto:roh...@mahalostudio.com [3] http://mahalostudio.com [4] mailto:roh...@mahalostudio.com [5] mailto:roh...@mahalostudio.com [6] http://marubatsu.es [7] http://pupcloud.com [8] http://wedding.mahalostudio.com [9] mailto:riak-users@lists.basho.com [10] mailto:riak-users@lists.basho.com [11] http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com [12] http://mahalostudio.com [13] mailto:roh...@mahalostudio.com [14] mailto:roh...@mahalostudio.com [15] http://marubatsu.es [16] http://pupcloud.com [17] http://wedding.mahalostudio.com [18] mailto:riak-users@lists.basho.com [19] http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com [20] http://mahalostudio.com [21] mailto:roh...@mahalostudio.com [22] http://marubatsu.es [23] http://pupcloud.com [24] http://wedding.mahalostudio.com [25] http://mahalostudio.com [26] mailto:roh...@mahalostudio.com [27] http://marubatsu.es [28] http://pupcloud.com [29] http://wedding.mahalostudio.com
_______________________________________________ riak-users mailing list riak-users@lists.basho.com http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
