可扩展性:处理有关撇号的大量评论的最佳方法是什么?

时间:2018-06-19 23:59:41

标签: apostrophe-cms

我正在从事一个希望数据库能够增长的项目,并且我对如何设计评论系统犹豫不决。我正在使用总预算进行规划,达到目标的10%真是太棒了,但是如果情况开始增长,我想做好准备。

我想对自定义部件内的小部件实施用户注释。每个小部件将包含大约数百个这些小部件,每个小部件将可能具有数百个注释,并且将有数千个小部件。非管理员用户将无法编辑作品或小部件,只能编辑评论。

我认为的替代方法是:

  1. 注释作为小部件,位于主体内部:很好,无需执行自定义查询即可在页面上加载注释,但这可能非常缓慢且繁琐,至少使用chrome(例如,编辑器模式加载500个小部件,每个小部件具有200条注释。一次加载100,000条注释!),并且很难在所有部件和小部件中搜索注释。
  2. 注释,使用_id字段与主要内容关联:更好,因为可以通过过滤器逐个审核注释,并在用户单击时加载它们一个具有ajax,分页等功能的小部件。但是,会不会挤满aposDocs集合并影响其他作品?例如,10,000个主要作品,每个具有100,000个评论,= 10亿个评论。如果每个评论都有5kB,则总大小约为4,66TB,这对mongo来说还可以,但是对Apostrophe来说还可以吗?我可以接受吗?
  3. 在另一个收藏集中的评论:会更加井井有条,不会影响其他作品,但是我将失去使用Apostrophe(丰富的评论文本)本地管理评论的功能。很伤心是否有一种简单的方法来创建将注释存储在另一个集合(例如commentsDoc)中并保持Apostrophe功能的作品?

哪个最好?还有其他方法吗?还有其他重要的事情要考虑吗?

1 个答案:

答案 0 :(得分:1)

我了解到您的计划很乐观,这就是为什么我对此表示悲观的原因。 (:就是说,我是在说您的数字,并谈论您将要经历的结果。

首先,您是正确的,MongoDB文档中不能容纳100,000条注释(限制为16MB),并且性能会很糟糕。

第二,虽然在每个小部件中使用联接来获取评论在理论上是可行的,但实际上您仍将在典型的网页浏览量上加载100,000条评论,这将耗尽服务器端和浏览器端的资源。而且您也会遇到SEO问题。

因此,您需要以其他方式考虑这一点。如果在一个“文档”中有成百上千个小部件,那实际上不是一个文档。也就是说,用户不会那样体验。我没有关于您的用例的太多信息,但是我的猜测是每个“文档”实际上更多是一个知识库,并且并不是每个网页浏览都涉及阅读数百个小部件。

因此,请分解这些文档。您当前设计中的每个“小部件”都应该独立存在。它应该有一个永久链接-用户可以共享它的URL,而Google可以将其索引。这是用撇号页得到的。

但是,如果您想在没有传统分页的情况下将它们呈现为“单页”设计,则可以使用撇号页的无限滚动功能以良好的性能实现这一目标。如果用户参与该操作的时间较长并滚动(几乎)滚动至此距离,则会在后台自动加载更多内容。有关该主题的更多信息,请参见reusable content with pieces

而且,您可以使用piecesFilters选项添加过滤器,以允许在单独的“元文档”(您目前认为是单个文档)之间进行导航。

此外,请考虑使用Disqus进行评论。它是免费的,您不必自己执行审核等。除非有令人信服的理由进行自我托管评论并担心用户注册等,否则它将大大简化您的实施。

我认为这可能与没有更好地了解用例的情况一样具体。