我将数据插入到一个集合中来存储用户历史记录（大约100条/秒），并使用聚合框架查询最后一小时的数据（每分钟一次）
为了使我的收藏保持最佳状态，我正在考虑两种可能的选择：
哪个是更有效的解决方案？即对 mongo 盒子的要求较低 - 在 I/O、内存使用、CPU 等方面。（我目前有 1 个主节点和 1 个辅助节点，还有一些隐藏节点。以防产生影响）
（我可以在我的上限集合中添加一点缓冲区来平均存储 3-4 小时的数据，并且如果用户在某些时候变得非常忙碌而无法获取完整小时的数据）
使用上限集合会更高效。上限集合通过不允许删除文档或以增加其大小的方式更新它们来保留记录的顺序，因此它始终可以附加到集合的当前末尾。这使得插入比标准集合更简单、更高效。
TTL索引需要为TTL字段维护一个额外的索引，每次插入都需要更新该索引，这会进一步减慢插入速度（当您还在时间戳上添加索引时，这一点当然是无关紧要的）使用上限集合）。此外，TTL 由后台作业强制执行，该作业定期运行并占用性能。该作业的优先级较低，当有更多高优先级任务要做时，MongoDB 可以延迟它。这意味着您不能依赖 TTL 的准确执行。因此，当时间间隔的精确度很重要时，即使设置了 TTL，您也必须在查询中包含时间间隔。
上限集合的一大缺点是很难预测它们真正需要多大。如果您的应用程序规模扩大并且您收到的文档比预期多得多或大得多，您将开始丢失数据。通常，您应该仅在过早丢失旧文档不是什么大问题的情况下使用上限集合。
由于这在 Google 上相当高，因此应使用 MongoDB 官方声明更新该答案，称 TTL 提供更好的性能：
一般来说，TTL（Time To Live）索引提供更好的性能和 比上限集合更具灵活性。 TTL 索引过期并且 根据日期类型的值从正常集合中删除数据 字段和索引的 TTL 值。
上限集合会序列化插入，因此性能更差 并发插入性能优于非上限集合。在你之前 创建一个上限集合，考虑是否可以使用 TTL 索引 相反。
上限集合最常见的用例是存储日志 信息。当上限集合达到其最大大小时，旧 日志条目会自动被新条目覆盖。
https://www.mongodb.com/docs/manual/core/capped-collections/