Cloudant / Couchdb架构 [英] Cloudant/Couchdb Architecture

问题描述

我正在构建一个使用后端Cloudant数据库的地址簿应用程序。数据库存储3种类型的文档：

I'm building an address-book app that uses a back-end Cloudant database. The database stores 3 types of documents:

-> User Profile document
-> Group document
-> User-to-Group Link document

随着文档名称的增加，我的数据库中有用户，有多个用户组（例如whatsapp），并且每个用户都有指向该组的链接文档（链接文档还存储该用户在该组中的设置/权限）。

As the names of the document go, there are users in my database, there are groups for users(like whatsapp), and there are link documents for each user to a group (the link document also stores settings/privileges of that user in that group).

我的客户端应用程序登录后，使用视图排序规则对该用户的链接文档进行查询，以查询用户的cloudant以及每个组文档。

My client-side app on login, queries cloudant for the user document, and each group document using view collation over the link documents of that user.

然后使用上面确定的组，我找到了该组的所有其他用户。

Then using the groups that I have identified above, I find all the other users of that group.

现在，挑战在于，我需要监视该组上的所有更改并用户文档。我在应用程序端使用pouchdb，可以针对所有组和用户文档的ID调用 changes API。但是，此规模可能是每个组500个用户，而已登录的用户是10-50个组的一部分。数量增加到1000的用户将成为后端支持的噩梦。

Now, the challenge is that I need to monitor any changes on the group and user documents. I am using pouchdb on the app side, and can invoke the 'changes' API against the ids of all the group and user documents. But the scale of this can be maybe 500 users in each group, and a logged in user being part of 10-50 groups. That multiplied to 1000s of users will become a nightmare for the back-end to support.

我的扩展性值得吗？还是对云云来说正常？

Is my scalability concern warranted? Or is this normal for cloudant?

推荐答案

第1部分。
我建议

代替这里，最好利用文档存储的好处，例如，将用户组存储在用户属性组中；

Instead of this, it is better to utilize a benefit of Document Storage, i.e. store user groups in property "Groups" for "User"; and property "Users" for "Group".

通过这种方法，您可以设置过滤的复制以仅处理特定组的更改，并且这些更改将已经包含所有用户

With this approach you can set up filtered replication to process only changes of specific groups and these changes will already contain all the users of the group.

我想注意到，我做了一个假设，一个用户的组数和组数是合理的（最多数百个），并且没有

I want to notice, that I made an assumption, that number of groups for a user and number of groups is reasonable (hundreds at maximum) and doesn't change frequently.

第2部分。
您可以仅将ID存储在这些属性中，然后使用视图加入其他数据。或者，我也在考虑其他方法（对于我的用例，但您的用例与此类似）：

Part 2. You can just store ids in these properties and then use Views to "join" other data. Or I was also thinking about other approach (for my use case, but yours is similar):

1）组仅包含用户ID-无需视图。

1) Group contains only ids of users - no views needed.

2）您创建每个用户联系人的视图，即为每个用户获取与其具有共同组的所有用户。

2) You create a view of each user contacts, i.e. for each user get all users with whom he has mutual groups.

3）将此视图复制到客户端应用程序。

3) Replicate this view to client app.

当用户打开一个组时，值（例如联系人的姓名和照片）将从该本地词典中获取）。
这种方法可以节省一些流量。

When user opens a group, values (such as names and pics of contacts are taken from this local "dictionary"). This approach can save some traffic.

请让我知道您的想法。因为现在我正在设计解决方案的体系结构。谢谢！）

Please, let me know what do you think. Because right now I'm working on designing architecture of my solution. Thank you!)

这篇关于Cloudant / Couchdb架构的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！