在nosql/Parse数据模型设计中苦苦挣扎

我已经习惯了SQL和关系设计,所以我对我当前的项目感到有些困惑.这是怎么回事:

有一些叫做"Bubbles"的东西与Google Circle基本相同.它们是用户定义的,可以将任何PFUser作为"成员".

然后有"帖子".每个帖子都有一个可见性设置,它是一组PFUser(或气泡).

应用程序的工作原理是用户制作他/她的泡泡,然后可以浏览Feed/post to bubbles.这个问题变得棘手的原因是:当应用程序启动并且我想查询特定用户的帖子时,我首先需要找到属于他们的气泡(很容易),然后我需要让用户进入这些气泡,然后我需要查询这些用户的帖子,然后我需要确保我在那些帖子的可见性.我尝试制作云代码函数,但由于异步调用弄乱了for循环的索引,因此无法填充字典的帖子部分.

无论如何,我正在拔出我的头发试图找出最好的nosql方法来做到这一点.任何帮助,Parsers？

那里有一个大问题.我不能为你创建一个模型,但我可以给你一些关于你需要思考的提示.

首先,正如您似乎已经发现的那样,您需要停止考虑此任务的关系设计术语.对于所有在SQL数据库中受过教育的人(我们大多数人,仍然是),这是一个漫长的过程.许多NoSQL方法在我们的关系思想中都表现不佳.

其次,您需要专注于数据提取.使用该模型无疑会在您的脑海中形成(甚至可能实现),快速提取所需数据所需的查询变得非常复杂.而且由于您的客户端可能主要是(仅限？)移动设备,因此您需要将查询次数和计算开销降至最低.

第三,如果你相信你的应用程序可能会出现在图表中并且变得非常流行(假设你没有设计企业应用程序),那么你需要设计可扩展性.不一定完美地实现它,但至少为它设计,以便你可以通过改进它来构建你的初始设计,而不是在应用程序变得流行时完全重建它(如果你的努力无法跟上,那么就有可能发生全面的灾难不断增长的用户群).

作为一个典型的例子; 如果您需要由用户列表创建的帖子列表,则不首先获取用户,然后查询这些用户的帖子.您准备架构,以便将此帖子列表(以及通常请求的其他结果列表)作为架构的一部分进行准备.这可以是feed的表(解析类).每个用户一条记录,该记录包含预先准备的Feed数组.每次我关注的用户写新帖时都需要更新.跟随帖子的作者的所有其他用户的记录也是如此!在那里,我刚刚在你的关系思想中打了一个坏话,不是吗？:-)

现在,对于实现细节,我建议您看一下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上询问与您的实现相关的更多具体问题.