Mongodb 个性化的相似/不同逻辑—是否应将其推送到视图、数据或服务层？

希望了解在客户端视图或数据库查询中，对于显示喜欢/不喜欢的按钮的逻辑保留在何处，是否存在共识。将逻辑推送到查询本身可以保持其干净性和一致性，但需要对主页帖子列表的每个查询进行个性化处理，并且不允许缓存该请求

设置：MongoDb数据库（或者可能是neo4j）、node.js api和应用程序服务器、iOS移动客户端和网站。大多数帖子可能会有十几个喜欢的帖子，但也有少数帖子会有数百个喜欢的帖子。大多数用户会喜欢50-300篇文章，少数用户喜欢数千篇文章

我的用例：用户浏览最近流行的帖子列表，并根据他们是否已经喜欢该帖子，在每个帖子旁边看到一个“喜欢”或“不喜欢”按钮

溶液-

方法1：将查询中的userid传递给数据库，并返回最流行的帖子列表，其中包含在查询中计算的isLiked属性

方法2：客户端应用程序获取并同步该用户喜欢的ID，视图决定是否为任何给定的帖子列表显示“喜欢”或“不喜欢”按钮。帖子列表可以缓存在服务器或cdn中，不需要任何个性化设置

---

方法3？在REST API服务层有更有效的方法吗？

< P>我想你需要考虑它的优缺点，看看哪一个是最好的。 MongoDB支持一种非常有效的单原子模式。您甚至不必等到数据库层确认插入并简单地显示“喜欢”的数量

如果在大约同一时间，另一个用户正在阅读同一篇文章，并且您希望100%确保他的计数是正确的，那么您可能不希望进行任何缓存

也就是说，在某人“喜欢”一篇文章后的毫秒内，你可能不需要有这个数字。因此，您可以缓存数据库信息，包括计数，并每x分钟访问一次数据库

请注意，博客帖子在最初几天非常流行，然后就不再流行了

出于好奇，您可能会发现这个有趣的视频：YouTube视频计数系统中的一个视频，出于验证和多数据中心的原因，该系统的计数会保持在301。

---

我遇到的问题是个性化的“isLiked”属性，而不是计数本身。增加计数很容易，而且效果也很好，但是如何以可伸缩的方式显示该用户是否已经喜欢这篇文章的商业逻辑是一个问题。我认为您应该将其缓存在浏览器localstore中，因为用户更可能在同一设备/浏览器上看到同一篇文章。但是，如果他试图在没有本地缓存的情况下从其他设备或浏览器读取文章，您仍然需要查询数据库或一些中级缓存。-如果您希望保持架构简单，那么一旦您的新闻应用程序变得流行，使用MongoDB“向外扩展”可能会扩展您的阅读。这是通过本地缓存实现的，在方法2中可能会起作用，但同步似乎会变得非常复杂，并且容易出错。在这种情况下，切分是没有帮助的，因为问题不在于数据库的大小，而在于每个帖子得到的喜欢的数量，切分个人记录是没有意义的。每个喜欢的都将链接到特定的用户。这必须是唯一的，并且有索引，所以您可以使用集合

userlike

{userid:Object（），postid:Object（）}

。然后在

userid

，

db.userlike.ensureIndex（{userid:1，postid:1}，{unique:1}）

上创建一个唯一索引。对于NoSQL数据库，您可能需要有重复的数据才能获得更高的性能