我已经习惯了SQL和关系设计，所以我对我当前的项目有点困惑。事情是这样的：
有些东西叫做"泡泡"，其运作方式与谷歌圈子基本相同。它们是用户定义的，可以将任何 PFU 作为"成员"包含在其中。
然后是"帖子"。每个帖子都有一个可见性设置，该设置是一组 PFUSER（或气泡）。
该应用程序的工作原理是用户制作他/她的气泡，然后可以浏览气泡的提要/帖子。这变得棘手的原因是：当应用程序启动并且我想查询特定用户的帖子时，我首先需要找到属于他们的气泡（足够简单），然后我需要在这些气泡中获取用户，然后我需要查询这些用户的帖子，然后我需要确保我处于这些帖子的可见性。我尝试制作一个云代码函数，但由于异步调用弄乱了 for 循环的索引，它无法填充字典的 posts 部分。
无论如何，我目前正在拔头发，试图找出最好的nosql方法来做到这一点。有什么帮助吗，解析器？
那里是一个大问题。我不能为你创建一个模型，但我可以给你一些提示，说明你需要如何思考。
首先，正如你似乎已经发现的那样，你需要停止用关系设计术语来思考这项任务。对于所有首先接受SQL数据库教育的人来说（我们大多数人仍然如此），这是一个很长的延伸。许多NoSQL方法在我们的关系思维中引起了不好的影响。
其次，您需要专注于数据提取。毫无疑问，有了您在脑海中形成（甚至可能实现）的模型，提取所需数据所需的查询很快就会变得非常复杂。由于您的客户可能大多（仅？）是移动设备，因此您需要将查询数量和计算开销降至最低。
第三，如果你相信你的应用程序可能会登上排行榜并变得广受欢迎（假设你不是在设计企业应用程序），你需要设计可扩展性。不一定能完美地实现它，但至少要为它设计，以便你可以通过改进它来构建你的初始设计，而不是在应用程序变得流行时完全重建它（如果你的努力无法跟上不断增长的用户群，那么冒着完全灾难的风险）。
举一个典型的例子;如果你需要一个由用户列表创建的帖子列表，你不会先去获取用户，然后查询这些用户的帖子。您准备架构，以便此帖子列表（以及通常请求的其他结果列表）已作为架构的一部分准备。这可以是源的表（解析类）。每个用户一条记录，该记录包含预先准备的源数组。每次我关注的用户写新帖子时都需要更新。关注该帖子作者的所有其他用户的记录也是如此！在那里，我只是在你的关系头脑中打了一个不好的音符，不是吗？:-)
现在，对于实现细节，我建议您查看NoSQL模式设计示例。我发现"Twissandra"（一个用Apache Cassandra实现的Twitter克隆）是一个很好的关于如何设计NoSQL的入门。特别是因为Twitter是我们很容易与之相关的用例。尽管 Parse 是由 MongoDB 而不是 Cassandra 支持的，但大多数原则都延续了下来： http://www.rackspace.com/blog/cassandra-by-example/
此外，比较本演示文稿中的第 6 页和第 7 页，可以很好地直观地了解 SQL 和 NoSQL 之间的此类模式设计有何不同：https://speakerdeck.com/mongodb/mongodb-dc-2012-schema-design-by-example
我建议您在阅读这些（可能还有其他）文章后尝试（重新）设计您的架构，然后在需要时在 SO 上询问与您的实现相关的更具体问题。