Sorry for the spam, I guess I'm hitting some keyboard shortcut thats
sending the message. let me try 1 more time.
Can I load 10 messages in 1 call? similar to a sql call "select * from
messages where id in (1,2,3,4,5,6,7,8)"
On Tue, Sep 25, 2012 at 2:17 PM, Charlie Bowman <charlesmbow...@gmail.com>wrote:
> accidentally hit enter before I finished the last question. The last
> sentence was:
>
> Can I load 10 messages in
>
>
> On Tue, Sep 25, 2012 at 2:16 PM, Charlie Bowman
> <charlesmbow...@gmail.com>wrote:
>
>> You actually hit on several nuances regarding the app that I left out of
>> the original email to keep things simple. I go a little deeper now, and I
>> have a question regarding the link walking
>>
>> "should make PlayerMessage PlayerMessages"
>> I agree, I was actually referencing my model name, which I always
>> singularize.
>>
>> "It's going to be some work updating 1M+ PlayerMessages objects when a
>> "mass message" is sent."
>> You can't actually "send" a message to 1M recipients. What I actually
>> is "send" the message to players who match certain criteria. When a player
>> logs in, I look to see if they match the criteria for an incoming message.
>> If they do I add the message id to their "inbox". That way I'm never
>> actually iterating over 1M records to add the id. Very similar to your
>> idea actually
>>
>> "If you need to read PlayerMessage and corresponding Messages in one go,
>> you can model the relation from PlayerMessage to Message with Riak Links,
>> and avoid a database roundtrip by using link walking."
>> If I do this, would I need to keep a second array in the PlayerMessage
>> object to then also map which messages have been read? Would link walking
>> be much faster? Currently I would need to have a separate query to load
>> the message objects? Can I load 10 message objects in
>>
>>
>>
>>
>>
>>
>> On Mon, Sep 24, 2012 at 4:17 AM, Rune Skou Larsen <r...@trifork.com>wrote:
>>
>>> Looks good! A couple of observations:
>>>
>>> The relation from PlayerMessage to Message introduces the possibility of
>>> inconsistency by either dead references to Message or orphan Messages.
>>> Thats managable - just an inconvinience.
>>> If you need to read PlayerMessage and corresponding Messages in one go,
>>> you can model the relation from PlayerMessage to Message with Riak Links,
>>> and avoid a database roundtrip by using link walking.
>>> The PlayerMessage object could also include refs for sent messages if
>>> you need that.
>>> You should probably rename "PlayerMessage" -> "PlayerMessages", as it
>>> contains an array of messages. Or just "Player".
>>> It's going to be some work updating 1M+ PlayerMessages objects when a
>>> "mass message" is sent. Consider modelling the mass messages differently,
>>> with a recipient group or recipient filter. So when you search for a
>>> recipient's messages, you look up separately if there are some mass
>>> messages for him. You can still flag when a mass message has been read by a
>>> player in his PlayerMessages object.
>>>
>>> Good luck with the game! Can I ask you, what game you're making?
>>>
>>> - Rune
>>>
>>> Trifork
>>>
>>> --
>>>
>>> Best regards / Venlig hilsen
>>> *Rune Skou Larsen*
>>> Trifork Public A/S / Team Riak
>>> Margrethepladsen 4, 8000 Århus C, Denmark
>>> Phone: +45 3160 2497 Skype: runeskoularsen twitter: @RuneSkouLarsen
>>>
>>>
>>>
>>> On 21-09-2012 23:37, Charlie Bowman wrote:
>>>
>>> +riak list
>>>
>>> My current plan is to use something very similar to your second idea
>>> (bulk messages in 1 object). Here's my current idea, I would love to hear
>>> your opinion on this! Sometimes a message will be sent to over 1M
>>> recipients, so I think I'll store the message contents in its own model.
>>> My player objects are stored in a relational db, so I can use their id's
>>> in my player_message and deleted_player_message keys for easy lookup.
>>>
>>> Message (actually have 3 different message types, but they're all
>>> fairly similar to this)
>>> ---------
>>> {
>>> :subject => 'fdsa'
>>> :body => 'fdsa'
>>> :sent_at => Time
>>> }
>>>
>>> PlayerMessage (key will include the player id so I can look this model
>>> up by player
>>> --------------
>>> array of:
>>> {
>>> :id => message_id,
>>> :type => message type
>>> :read => boolean
>>> }
>>>
>>>
>>> DeletedPlayerMessage (key will include the player id so I can look
>>> this model up by player)
>>> --------------
>>> array of:
>>> {
>>> :id => message_id
>>> :type => message_type
>>> }
>>>
>>> I'm definitely optimizing for the recipient, I want to be able to load
>>> all or just unread messages as fast as possible. I will not need to look
>>> up a message and see a list of all recipients.
>>>
>>>
>>> My idea is that when I load the "inbox", I'll load the PlayerMessage
>>> object for the given player, then separate the read from the unread emails
>>> inside the application. From my quick testing, this works great with
>>> relatively small numbers of messages. I'm capping the stored messages at
>>> ~1000, and the process is nearly instantaneous. When a user deletes a
>>> message, I copy the message hash from the PlayerMessage model to the
>>> DeletedMesssage model for storage. There's a business requirement to store
>>> all old emails.
>>>
>>> What do you think?
>>>
>>> On Fri, Sep 21, 2012 at 5:18 AM, Rune Skou Larsen <r...@trifork.com>wrote:
>>>
>>>> The best data model always depends on the structure of data and the
>>>> access pattern. The natural access pattern for your messages is likely
>>>> lookup from two sides: sender and receiver. And you might need to support
>>>> message expiry too. This means that you need on-disk indeces if you want
>>>> more messages than will fit in memory.
>>>>
>>>> In Riak you can do it quite simply with any of the ordered backends
>>>> (leveldb, hanoidb, lowkeydb):
>>>>
>>>> One message = one Riak object. Example: {sender='321', recipient='123',
>>>> timestamp = 1234567, text= 'bla bla'}
>>>> Key is timestamp prefixed.
>>>> 2i indeces for <sender_id> and <recipient_id>.
>>>> Consider using a compound index if you often distinguish between
>>>> read/unread messages. For instance: <read-status>_<recipient_id>
>>>>
>>>> Example query returning keys for all unread messages belonging to
>>>> recipient with id 123 using compound index:
>>>> http://myhost:8098/buckets/messages/index/recipient_bin/unread_123
>>>>
>>>> Example query returning keys for all messages older than a year, so you
>>>> can delete old messages (not necesary using backends with autoexpiry):
>>>> http://myhost:8098/buckets/messages/index/$key/0/2011-09-21
>>>>
>>>>
>>>> Here is an alternative approach: You can choose to optimize for the
>>>> recipient side of the access pattern, by bulking all the messages for a
>>>> given recipient in one Riak object. This is much faster that retrieving a
>>>> large number of messages individually, the price being more difficult
>>>> lookup from the sender side:
>>>> Key: recipient_id
>>>> One Riak Object = all messages for a given recipient. Example:
>>>> [{sender='321', timestamp = 1234567, text= 'bla bla'},{sender='456',
>>>> timestamp = 1234569, text= 'bla bla2'}]
>>>> 2i index for <sender_id>s
>>>>
>>>> Example query returning an object with all messages belonging to
>>>> recipient with id 123:
>>>> http://myhost:8098/buckets/messages/keys/123
>>>>
>>>> If you want text search on for instance message content, you should
>>>> consider using Riak Search.
>>>>
>>>> - Rune
>>>>
>>>> Trifork
>>>>
>>>>
>>>> Best regards / Venlig hilsen
>>>> *Rune Skou Larsen*
>>>> Trifork Public A/S / Team Riak
>>>> Margrethepladsen 4, 8000 Århus C, Denmark
>>>> Phone: +45 3160 2497 Skype: runeskoularsen twitter: @RuneSkouLarsen
>>>>
>>>>
>>>> On 20-09-2012 01:33, Charlie Bowman wrote:
>>>>
>>>> I'm in the process of designing an in game messaging system that
>>>> basically replicates the same functionality of email all within the context
>>>> of the application. I do not have a ton of experience with true key/value
>>>> db stores so I'm looking to find a good resource for ideas on how to best
>>>> model this. I have a first version, but I dont want to reinvent the wheel
>>>> if can help it. I've done the requisite googling, but haven't found
>>>> anything relevant yet. Are there any guides/tutorials/open source projects
>>>> that anyone knows of.
>>>>
>>>> Thanks!
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> riak-users mailing list
>>>> 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
