我正在从事一个希望数据库能够增长的项目,并且我对如何设计评论系统犹豫不决。我正在使用总预算进行规划,达到目标的10%真是太棒了,但是如果情况开始增长,我想做好准备。
我想对自定义部件内的小部件实施用户注释。每个小部件将包含大约数百个这些小部件,每个小部件将可能具有数百个注释,并且将有数千个小部件。非管理员用户将无法编辑作品或小部件,只能编辑评论。
我认为的替代方法是:
哪个最好?还有其他方法吗?还有其他重要的事情要考虑吗?
答案 0 :(得分:1)
我了解到您的计划很乐观,这就是为什么我对此表示悲观的原因。 (:就是说,我是在说您的数字,并谈论您将要经历的结果。
首先,您是正确的,MongoDB文档中不能容纳100,000条注释(限制为16MB),并且性能会很糟糕。
第二,虽然在每个小部件中使用联接来获取评论在理论上是可行的,但实际上您仍将在典型的网页浏览量上加载100,000条评论,这将耗尽服务器端和浏览器端的资源。而且您也会遇到SEO问题。
因此,您需要以其他方式考虑这一点。如果在一个“文档”中有成百上千个小部件,那实际上不是一个文档。也就是说,用户不会那样体验。我没有关于您的用例的太多信息,但是我的猜测是每个“文档”实际上更多是一个知识库,并且并不是每个网页浏览都涉及阅读数百个小部件。
因此,请分解这些文档。您当前设计中的每个“小部件”都应该独立存在。它应该有一个永久链接-用户可以共享它的URL,而Google可以将其索引。这是用撇号页得到的。
但是,如果您想在没有传统分页的情况下将它们呈现为“单页”设计,则可以使用撇号页的无限滚动功能以良好的性能实现这一目标。如果用户参与该操作的时间较长并滚动(几乎)滚动至此距离,则会在后台自动加载更多内容。有关该主题的更多信息,请参见reusable content with pieces。
而且,您可以使用piecesFilters
选项添加过滤器,以允许在单独的“元文档”(您目前认为是单个文档)之间进行导航。
此外,请考虑使用Disqus进行评论。它是免费的,您不必自己执行审核等。除非有令人信服的理由进行自我托管评论并担心用户注册等,否则它将大大简化您的实施。
我认为这可能与没有更好地了解用例的情况一样具体。