best practices on data storage?

Antonio Rohman Fernandez rohman at mahalostudio.com
Thu Jul 28 03:10:09 EDT 2011


  

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 rohman at 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 rohman at mahalostudio.com [4] rohman at mahalostudio.com>
rohman at mahalostudio.com [5]> *Projects* MaruBatsu.es PupCloud.com
Wedding Album line _______________________________________________
riak-users mailing list riak-users at lists.basho.com [9]
riak-users at lists.basho.com> riak-users at 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 rohman at mahalostudio.com [13] rohman at mahalostudio.com>
rohman at mahalostudio.com [14]> *Projects* MaruBatsu.es PupCloud.com
Wedding Album line _______________________________________________
riak-users mailing list riak-users at lists.basho.com [18]
riak-users at lists.basho.com>
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
[19]
>> -- line logo *Antonio Rohman Fernandez* CEO, Founder & Lead
Engineer rohman at mahalostudio.com [21] rohman at mahalostudio.com>
*Projects* MaruBatsu.es PupCloud.com Wedding Album line

-- 

 		 [25]


ANTONIO ROHMAN FERNANDEZ
CEO, Founder & Lead
Engineer
rohman at mahalostudio.com [26] 		 
 PROJECTS
MaruBatsu.es
[27]
PupCloud.com [28]
Wedding Album [29] 

   

Links:
------
[1]
mailto:rohman at mahalostudio.com
[2] mailto:rohman at mahalostudio.com
[3]
http://mahalostudio.com
[4] mailto:rohman at mahalostudio.com
[5]
mailto:rohman at mahalostudio.com
[6] http://marubatsu.es
[7]
http://pupcloud.com
[8] http://wedding.mahalostudio.com
[9]
mailto:riak-users at lists.basho.com
[10]
mailto:riak-users at lists.basho.com
[11]
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
[12]
http://mahalostudio.com
[13] mailto:rohman at mahalostudio.com
[14]
mailto:rohman at mahalostudio.com
[15] http://marubatsu.es
[16]
http://pupcloud.com
[17] http://wedding.mahalostudio.com
[18]
mailto:riak-users at lists.basho.com
[19]
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
[20]
http://mahalostudio.com
[21] mailto:rohman at mahalostudio.com
[22]
http://marubatsu.es
[23] http://pupcloud.com
[24]
http://wedding.mahalostudio.com
[25] http://mahalostudio.com
[26]
mailto:rohman at mahalostudio.com
[27] http://marubatsu.es
[28]
http://pupcloud.com
[29] http://wedding.mahalostudio.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.basho.com/pipermail/riak-users_lists.basho.com/attachments/20110728/8e1cd59e/attachment.html>


More information about the riak-users mailing list