在非关系型DBMS(AppEngine中的BigTable)中,我应该如何为大量消息传递类型的系统设置实体?

想象一下,例如我有很多用户。每次用户发送消息时,他/她都可以将消息发送给其他用户列表(类似于群发电子邮件)。但是,我只想存储一次消息以节省存储空间。因此,当其中一个消息接收者打开他的邮箱时,他/她必须在那里查询该消息。在设置消息传递系统的实体(表)方面哪些更有效?请注意:在非RDBMS中,不允许加入查询。这是一个看似合理的设置,我怎样才能使它更有效率(1):
Table: Message (keeps one copy of all messages)
| Message_ID | Sender | Title | Body | List of Receivers |

// In this strategy, if I'm a receiver, I would check each message and search through the list of receivers to check and see whether I'm one of the receivers or not.
或者我应该采用以下策略(2):
Table: Message (keeps one copy of all messages)
| Message_ID | Sender | Title | Body |

Table: Message Receivers (store the same message ID for all receivers)
| Message_ID | Sender | Receiver |

// In this strategy, in runtime, make copies of the same message ID and same Sender and store one row for each receiver.
哪种策略效率更高?即,通过一个arraylist迭代比简单地迭代DBMS慢? 任何评论都将受到高度赞赏。 *注意:消息可以任意长,因此我不想存储同一消息的多个副本。 谢谢。     
已邀请:
查看Brett Slatkin在Google IO 09上的“在App Engine上构建可扩展的复杂应用程序”演讲。 他提出了一种称为'RelationIndex'的模式,它类似于你的第一个建议,但你将列表移动到它自己的实体。通过将列表实体的键名设置为消息的键名,您可以使用keys_only查询扫描给用户的消息,然后仅加载消息本身而无需反序列化收件人列表。     

要回复问题请先登录注册