Question

我们正在开发一款与Instagram基本类似的应用，但使用groups。用户可以邀请其他用户加入群组。群组中的成员共享posts，其中包含照片，媒体等。用户拥有feed，其中包含最近在群组中发布的所有帖子，并带有分页。用户还可以从组内访问帖子。

由于我们当前架构设计的性质，feed query很慢。实际上，请求时间会随着数据量的增加而增加，而当我们在平台上看到更多用户时，这并不是很可扩展。

问题1 ：我们应该如何使用MongoDB以最佳方式对数据建模，以使Feed查询更快，更可扩展？

我们当前的后端是使用带有MongoDB和Node.js的Parse Server构建的

A simplified version of our schema is as follows:

Class/Document
    - Attribute

Users
    -  id
Group
    - id
    - members (array of user pointer objects)- basically an array of ids
    - admins (array of user pointer objects) - basically an array of ids
    - createdBy (pointer to user object) - basically an id of the owner of the group
Posts
    - id
    - groups (array of group pointer objects) - basically an array of ids

现在，当我们想将posts放入用户的feed中时，我们必须经历以下过程：

遍历所有groups，为用户检查组的成员/管理员阵列，并为用户获取所有组
遍历所有posts，检查帖子的分组数组以查看帖子是否应包含在Feed中。

问题1的可能解决方案（MongoDB - Many-to-many relationship?）

这意味着：

在group array中有一个User class（指向组对象的指针），它指向用户是管理员/成员或所有者的组。与以前一样，在Group类中具有member / admin数组和createdBy。

在post array中有一个Group class（用于发布对象的指针）。和以前一样，在Post类中具有groups数组。

This would translate into the following schema:  

Class/Document
    - Attribute
Users
    -  id
    - groups (array of group pointer objects, where the user is either admin/member or owner) - basically an array of ids
Group
    - id
    - members (array of user pointer objects)- basically an array of ids
    - admins (array of user pointer objects) - basically an array of ids
    - createdBy (pointerObject to user) - basically an id of the owner of the group
    - posts (array of post pointer objects) - basically an array of ids
Posts
    - id
    - groups (array of group pointer objects) - basically an array of ids

意思是，您将具有双向查询功能。缺点是您必须小心保持这些阵列彼此一致。

问题2 对于我们的应用程序类型，长期使用MongoDB是否明智？或者我们是否打算迁移至例如 PostgreSQL的？（随着我与RDMS的合作越来越多，我有些偏颇，比NoSQL数据库）

我们还将继续扩展统计信息界面，以显示stats中的不同活动及其活动groups，并预测我们将有更多many-to-many情况，或{{1} }关系。我们已经开始尝试，将PostgreSQL添加到了组合中。将few-to-few中的数据Mirroring与MongoDB一起使用，并对上面的某些查询使用SQL，这些查询在我们当前的MongoDB模式设计中无法很好地扩展。我们还考虑逐步过渡到PostgreSQL。但是，如果我们可以使MongoDB一切正常，这可能是一个过早的决定。随着我们将继续扩展统计信息界面，是否最好改用PostgreSQL之类的RDMS？

感谢所有帮助。祝你有美好的一天！

MongoDB-多对多/很少关系模型设计，没有查找性能问题

0 个答案: