前言：7 月 13 号, MongoDB 发布了大版本 5.0, 官方 Release Note 在这里:
docs.mongodb.com/manual
本文由社区成员肖贝贝在14号发布于知乎上，他选择了一些亮眼的特性介绍给大家。文末我们还给大家介绍了两个MongoDB岗位，以及MongoDB 5.0 新特性在线研讨会入口，欢迎关注！
时序集合: 版本核心功能
在创建集合时, 可以指定此集合为时序集合, 一个创建命令如下:
db.createCollection(
"weather24h",
{
timeseries: {
timeField: "timestamp",
metaField: "metadata",
granularity: "hours"
},
expireAfterSeconds: 86400
}
timeField 是时间戳, metaField 是标签, granularity 是聚合粒度,
expireAfterSeconds 是过期时间
timeField 是时间参数, 必须为 BSON data。
和其他时序数据库类似, metaField 影响维度基数, 好的 metaField 应该选择低基数的, 有选择性的指标, 高基础必然带来性能的下降。
granularity 是可选的聚合粒度参数, 数据库会将一个时间段的数据聚合存放, 这个参数影响性能, 不影响功能。
expireAfterSeconds 影响数据的过期, 是通过每 60s 一次的检测实现的。
时序集合对于查找连续时间块的指标具有非常好的性能, 同时可以降低磁盘占用, 相比与其他时序数据库, 需要注意的点有:
- 时序集合底层存储依然是 WiredTiger, 但是现在创建集合, 已经支持了表级别 storageEngine, 未来不排除会有各种各样的集合级引擎出现；
- 没有为时序查询定制新的语法, 各种聚合依然需要通过 aggregate 进行, 或者通过 Materialized Views 创建视图来查看数据；
- 索引上, 时序集合已经按照常用的查询模式, 对数据进行了索引, 但是这个索引不会被 list 索引命令列出来, 同时, 如果有自己的针对 metafield 的过滤需求, 可以正常创建二级索引；
- 和其他时序引擎一样, 为了保证存储效率, MongoDB 的时序集合不支持更新与手动删除, 另外, 在当前版本里, 时序集合不支持分片。
所以, 时序集合是一个在使用上与传统集合几乎无差别, 但是针对时序场景做了特定优化的集合类型, 这是一个非常好的开始, 加上创建集合时, 支持了 stotageEngine 参数, 我们期待在 MongoDB 上, 可以出现集合级别的引擎这种特性, 将各种数据库的优势集中到一起, 不仅仅是文档, 而是** ALL IN ONE DATABASE**!
修改了默认的写参数
不是个特别大的特性, 不过到现在网上还天天说 MongoDB 丢数据, 这次新版本把默认的写参数从 1 改成了大多数, 丢数据的 “罪证” 又少了一个, 接下来升级之后, 估计会出现一堆 MongoDB 升级后性能大幅度下降 的黑帖。
需要注意下, 在存在投票节点, 且投票节点的存在会让大多数实际上无法实现时, MongoDB 依然使用 1 作为默认写入参数。
其实, 性能和一致性本来就是一个看场景的东西, 一个好的程序员, 应该能在其中找到适合自己的设置, 而不是把这些东西都丢给数据库, 毕竟, 数据库又不会帮你写业务。
动态修改片键
在生产中, 难免会出现片键设计不合理的情况, 之前修改片键基本需要停机进行, 或者通过一些在线迁移工具, 比如国内领先的异构数据同步工具 TAPDATA, 将数据实时从一个集合迁移到另一个集合, 来实现变相的片键修改。
本质上, 是因为修改片键需要挪动大量的存量数据, 这个性能上很难做得很好, 官方一直没提供这个功能, 这个版本提供了 reshardCollection 命令, 可以不停机直接在线修改片键, 很方便。
不过在这里提醒下, 不要对这个功能有太高的性能期待, 可以参考第一个版本的数据均衡, 后面的版本会慢慢改善的。
快照读
在新版本里, snapshot 读参数可以用在普通的 find, aggregate 和 distinct 命令里了, 感觉离传统的范式数据库又近了一步。
当然, distinct 目前不能用在分片集合上, 总的来说, 这些事务性的支持提高, 会让 MongoDB 的应用场景变得更丰富。
需要注意, snapshot 依赖 minSnapshotHistoryWindowInSeconds 这个老长的参数, 如果参数设置不合适, snapshot 读取会报 SnapshotTooOld 错。
isMaster 命令重命名
isMaster 命令被 hello 命令替代掉, 这里在这里说明的原因是, MongoDB 客户端依赖 isMaster 命令来做一些自动发现的事情, 这个修改可能导致对这个命令敏感的场景无法工作。
考虑一个系统架构, 一个三节点副本集, 三节点全部使用内网 IP 进行通信, 这些内网 IP 是外网客户端无法直接访问的, 为了让外网可以访问, 需要通过一个外部可用的网关(VIP OR 域名 或者一些其他的设备), 对副本集的地址做一个映射提供给外网, 但是 MongoDB 客户端为了做高可用, 在副本集方式连接时, 会额外发送 isMaster 命令, 获取集群配置的节点列表做真实的连接, 这样外网网关就被绕过了。
所有的云服务厂商都在这里做了一些自己的源码修改, 来支持这种场景, 这个命令修改之后, 可能需要进行一些适配。
Whatever, 大部分用户是不感知这个修改的。
Change Streams 新增了一个事件
新增了 truncatedArrays 来记录对数组的 truncated 操作, 这里提这个是希望 MongoDB 在 Change Streams 上可以有更细致的支持, 现在业务上对 Change Streams 的应用越来越多, 性能上和功能上的需求越来越强烈, 这次 Change Streams 的更新, 让我们看到官方没有放弃这个特性。
如果 Change Streams 能提供完整的 before, after, 提供一些唯一键信息, 片键信息, 然后性能能做一些根本性提升, 会有更多的适用场景。
MongoDB Shell 项目废弃
新的 MongoDB 命令行客户端 mongosh 成为默认客户端, MongoDB Shell 将会停止支持, 使用的同学需要关注下。
读性能提升
从当前版本开始, 这些操作:
find
count
distinct
aggregate
mapReduce
listCollections
listIndexes
不再受一些独占锁的影响, 会提升一些场景下的读性能。
聚合查询功能增加
提供了一些额外的操作符, 比如 setWindowFields 允许在一个窗口进行计算等等。
这里并不是想说的重点, 重点是除了功能之外, 希望 MongoDB 的聚合性能能想办法从根本上提升一下, 否则基于现在的表现, 在聚合上基本是被 某另外一个文档数据库 吊打的节奏, 适用场景非常有限, 这次的修改让我们看到 MongoDB 没有放弃聚合, 泪奔。
期待之后的新版本里对聚合的性能做一些提升。
升级须知
5.0 版本包含一些对旧版本不兼容的特性, 需要通过 featureCompatibilityVersion 来做一些设置。
虽然有一些非常激动人心的特性, 不过当前阶段, 不建议在生产环境对数据库做升级, 按照惯例, 可以等 5.2 发布再升级。
