在非关系型数据库管理系统(AppEngine中的BigTable)中，我应该如何为群发消息类型的系统设置实体？

Question

想象一下，例如，我有很多用户。每次用户发送消息时，他/她都可以将消息发送给其他用户列表(类似于群发电子邮件)。但是，我只想将消息存储一次，以节省存储空间。因此，当一个消息接收者打开他的邮箱时，他/她必须在那里查询该消息。在设置消息传递系统的实体(表)方面，哪个更有效？注意:在非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.

哪种策略看起来更有效？也就是说，迭代数组列表比简单地迭代DBMS慢吗？

如有任何意见，我们将非常感谢。

*注意:消息可以任意长，因此我不想存储同一消息的多个副本。

谢谢。

Answer 1

看看Brett Slatkin在Google IO 09上的'Building Scalable, Complex Apps on App Engine'演讲。

他提出了一种称为“关系索引”的模式，它类似于你的第一个建议，但你可以将列表移到它自己的实体中。通过将列表实体的键名设置为消息的键名，您可以使用keys_only query扫描发送给用户的消息，然后只加载消息本身，而不需要反序列化收件人列表。