apostrophe-cms - 可扩展性：处理有关撇号的大量评论的最佳方法是什么？

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

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

我认为的替代方法是：

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

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

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

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

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

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

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

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

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

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

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