MongoDB 4.4中新建库存聊天集合相比现有库建集合是否有性能优势

先说结论：如果你的现有数据库已经承载了其他核心业务，优先选择单独新建数据库存储聊天集合，性能和运维收益远大于直接在现有库创建的方案。

两种部署方案的核心差异 #

• 资源隔离维度：MongoDB支持在数据库层级配置独立的存储引擎参数、资源配额限制，单独建库的情况下，聊天业务的高读写不会抢占现有业务的CPU、内存、IO资源，避免互相影响。如果把聊天集合放在现有库，一旦聊天业务出现流量尖峰，很可能拖慢原有库的其他业务请求。
• 运维成本维度：单独建库后，你可以针对聊天消息的业务特性做独立的备份、扩容、过期清理策略：比如聊天消息一般只需保留3~6个月，你可以单独对这个库设置TTL索引的清理阈值，也可以单独做分片扩容，不需要动现有业务的任何配置。
• 存储成本维度：聊天消息一般属于冷热数据分明的场景，单独建库后你可以针对该库配置更适合的存储介质，比如冷数据归档到低成本机械盘，不需要和现有业务的热数据抢高速SSD资源。

WiredTiger文档级锁是否意味着无性能差异 #

这个理解是错误的，WiredTiger的文档级锁只是解决了同集合内不同文档的写冲突问题，不代表两种部署方案没有性能差异，核心原因如下：

• WiredTiger除了文档级写锁之外，还有全局的意向锁、集合级的元数据锁，如果你在现有库创建聊天集合，当聊天业务有极高的并发写入时，元数据锁的竞争概率会大幅提升，影响现有库其他集合的操作。
• 即便是没有锁冲突，数据库层级的WiredTiger缓存是共享的，如果聊天集合的大量热点数据占满了缓存，会把原有业务的热点数据挤出缓存，导致原有业务的查询命中率下降，延迟升高。
• WiredTiger的后台刷盘、Checkpoint操作是按数据库维度调度资源的，多个高负载集合放在同一个库，会导致刷盘队列阻塞，所有集合的写入延迟都会出现明显波动。

可选择同库部署的特殊场景 #

如果你的业务规模较小，现有数据库的负载本身很低，且预估聊天业务的峰值QPS不会超过1000，也没有严格的业务隔离要求，可以直接在现有库创建集合，降低运维复杂度。

内容的提问来源于stack exchange，提问作者wisha