可扩展性：处理关于 Apostrophe 的大量评论的最佳方式是什么？

Question

我正在做一个项目，希望在这个项目中数据库会增长，我正在犹豫如何设计一个 cmets 系统。我正在使用粗略估算来进行计划，达到 10% 的目标会很棒，但如果事情开始增长，我想做好准备。

我想在自定义片段内的小部件上实现用户 cmets。每件大约有数百个这样的小部件，每个小部件可能有数百个 cmets，并且将有数千个。非管理员用户将无法编辑片段或小部件，只能编辑 cmets。

我认为的替代方案是：

1. 评论作为小部件，在主要部分中：不需要进行自定义查询来加载页面上的 cmets 会非常好，但这可能会非常缓慢和繁重，编辑该部分会至少使用 chrome 是不可能的（想象一下编辑器模式加载 500 个小部件，每个小部件有 200 个 cmets.. 100,000 个 cmets 一次加载！），并且很难在所有部分和小部件中搜索 cmets。
2. 评论作为一个片段，使用 _id 字段关联到主片段：更好，因为可以使用过滤器逐个调节 cmets，并在用户单击小部件时加载它们，使用 ajax、分页等。但是，它不会挤满 aposDocs 集合并影响其他片段吗？例如，10,000 个主片段和每个 100,000 cmets-pieces = 100,000 cmets-pieces。如果每条评论有 5kB，那么总大小约为 4,66TB，这对 mongo 来说还可以，但是 Apostrophe 可以吗？我可以去吗？
3. 其他收藏中的评论：会更有条理，不会影响其他作品，但我会失去用撇号，cmets 的富文本本地管理 cmets 的能力......这非常可悲。 是否有一种简单的方法可以创建一个将 cmets 存储在另一个集合中的片段（例如 cmetsDoc），同时保留撇号功能？

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

Answer 1

我知道你的计划是乐观的，这就是为什么我的反应是悲观的。 （：也就是说，我相信你所说的数字并谈论你将经历的结果。

首先，您是对的，100,000 cmets 不适合 MongoDB 文档（16MB 限制），而且性能会很糟糕。

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

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

所以，分解这些文件。当前设计中的每个“小部件”都应该是一个独立的部分。它应该有一个永久链接——一个用户可以共享它并且谷歌可以索引它的 URL。这就是您使用 apostrophe-pieces-pages 获得的结果。

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

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

另外，考虑将 Disqus 用于 cmets。它是免费的，您不必自己实施审核等。除非有令人信服的理由自行托管 cmets 并担心用户注册等问题，否则它将大大简化您的实施。

我认为这是在不更好地理解您的用例的情况下尽可能具体。