用于复杂查询的Nosql数据库设计

Question

一个nosql问题：

假设我有这种情况：

用户作为经常更改的状态（比方说每秒），它还具有不同的特征，例如国家/地区（每个用户最多10k个特征）...... 用户可以发布具有不同类型的消息。

问题：

在我看来，这个场景非常面向RDS，其中JOIN将被用于查询。但是，它不是一种选择（为了练习）。因此，我不是在寻找具有伪RDS的解决方案，如HIVE或其他具有伪连接的解决方案。我正在寻找可以使用mongodb或mapreduce的{​​{1}}之类的内容。

我的解决方案（使用mongodb）：

假设你有3个收藏品：

1. user =＆gt;用户特征（大量不同的特征，如年龄/性别......）
2. message =＆gt;消息特定字段
3. status =＆gt;状态特定字段

解决这个问题的可行方法（据我所知）是：

1. 通过复制用户字段来对数据进行非规范化，并在消息和状态中aggregation（或将所有内容放在一个集合中）=＆gt;似乎没有优化，因为你有每个用户的很多特性，你将达到2MB的文件限制（你可以使用GridFS，但我担心这样的性能，你还复制了大量无用的数据存储）
2. 通过向message和status =＆gt;添加user_id embed来使用类似SQL的解决方案。似乎是一个合理的解决方案。但是，如果您确实想要进行reference之类的特定查询，则会陷入困境（就查询性能而言）。在SQL中，它将是count the number of message of type X for users that have their last status equal to Z and have characteristic Y equal to E and group them by characteristic W（此查询实际上并不完全符合您的要求知道最后一个状态是否等于Z而不是如果状态等于Z，则需要在选择内选择但不是练习点。在你必须进行多次查询的情况下，它变得非常苛刻（在这个示例中，一个用于获取最后状态等于Z的用户id，然后另一个用于将此用户id列表过滤到具有等于E的特征Y的那个，然后从这些用户获取所有消息，然后按特征W将其分组，并使用地图缩减作业。
3. 使用引用消息和消息给用户的双引用用户。也是引用用户和用户参考状态的状态。 =＆GT;可能看起来很好，但是用户文档已经很大了，你可能会回到解决方案1的问题，假设会有大量的消息和状态。

我使用了选项2，但我对此感到不满，因为查询它的处理时间似乎不会优化。

问题：

在上述场景中，实现可扩展解决方案的最佳实践是什么，允许复杂查询，如上面给出的示例。