MongoDB – 模式设计

注意事项

模式设计,即在文档中表示数据的方式,对于数据表示来说时非常关键的。

为 MongoDB 做模式设计时,在性能、可伸缩性和简单性方面是重中之重,也需要考虑一些特别的注意事项。

限制条件

与常见的 SQL 相比而言,MongoDB 有自己的限制条件:

  • 文档最大限制为 16M 大小
  • 从磁盘读写完整文档
  • 更新会重写整个文档
  • 在文档级别进行原子更新

访问模式

设计模式时最需要关注的就是数据库的读操作,在数据库运行过程中,应尽量减少查询的数量,这就需要在设计时确保一起查询的数据存储在同一个文档中。

其实,就是考虑是否是否可以将动态(读/写)数据和静态(主要是读)数据分离开,如未经常使用的数据应该移到不同的集合中。

在进行模式设计时,提高最常见查询的优先级会获得最佳的性能。

关系类型

数据之间的关系影响着文档之间应该是内嵌还是引用。

比如说,需要弄清楚如何在不执行其他查询的情况下引用文档,以及当关系发生变化时需要更新多少文档。

关系基数对于文档之间的关系非常重要,如一对一、一对多、多对多、一对百万、多对百万等等关系基础,影响的程度差距非常大,应选取最佳格式去做建模。

在关系基数的基础上,还需关注访问的情况、重要数据更新与读取的比例,这些充分考虑之后,将有助于确定应采用内嵌文档还是引用文档。

范式化和反范式化

基本概念

通常来说,多文档之间的关系可以使用反范式化(内嵌)或范式化(引用)。

范式化是指在文档中引用外部数据的标识,同一份数据只存在一个地方。

在查询时,查询完整的数据需要做 JOIN 的操作,需要查询多次才可能获取到所需内容;但是在更改时仅需修改一处地方,不需要担心破坏数据的完整性。

反范式化是指将外部数据复制一份存储在文档中,也就是说同一份数据存在多处地方。

在查询时,只需查询一次即可得到所需内容,查询效率比较可观;而在更改时,需要更新多处地方,可能会出现数据不一致的情况,不能保证完整性。

范式化选择

决定何时采用范式化以及何时采用反范式化是比较困难的:通常,范式化的写入速度更快,而反范式化的读取速度更快。

通过判断以下因素可决策选择使用范式化还是反范式化:

更适合范式化 更适合反范式化
较大子文档 较小子文档
数据经常变更 数据不经常变更
数据要强一致 数据最终一致即可
文档数据大幅增加 文档数据小幅增加
数据通常不包含在结果中 数据通常需要执行二次查询才能获得
快速写入 快速读取

模型设计小技巧

指导原则

通常来说,具有类似模式的文档应该保存在同一个集合中。

对于集合来说,需要考虑的一个大问题是锁机制(每个文档都有一个读/写锁)和存储。

当使用 --directoryperdb 选项时,每个数据库都可以保留在自己的目录中,这允许你将不同的数据库挂载到不同的卷中。

同一个应用程序连接的数据库可以根据业务进行划分,也许可以将高价值的业务数据存储在 SSD 上,或者是使用 RAID10 进行存储,而低价值的数据可以存储在 RAID0 上。

删除旧数据

有些数据只在短时间内比较重要,过了这段时间,保存这些数据只是再浪费存储空间。

删除旧数据有 3 种常见的方式:使用固定集合、使用 TTL 索引、使用多个集合。

最简单的方式是使用固定集合:将集合大小设置成一个较大的值,并让旧数据从固定集合的末尾被“删除”。

第二种方式是使用 TTL 集合:TTL 集合可以更精确地控制删除文档的时间,但其在写入量过大的集合中操作速度不够快。

最后一种方式是使用多个集合:例如每个月的文档都单独使用一个集合。

一致性管理

MongoDB 支持多种一致性级别,从总是能够读取自己所写的数据到读取不确定的旧数据。

其内部实现是服务器端为每一个数据库连接都维护了请求队列,同一个连接发来的请求都会被添加到队列的末尾,连接中的任何后续请求都将依次得到处理。

这个管理方式涉及到多个客户端连接会出现并发问题,在一个连接中插入文档后,在另一个连接的后续查询却不一定会返回这个文档(实际上已经插入成功)。

同样的一致性问题在 MongoDB 拥有副本集时也会出现,副本节点的数据与主节点的数据总是会有时间差,高并发的请求同样存在读取到旧数据的风险。

MongoDB 提供了 readConcern 选项来控制被读取数据的一致性和隔离性。它通常与 writerConcern 组合使用,以控制为应用程序提供的一致性和可用性保证:

如果 readConcern=local,从当前实例查询并返回结果,不能保证数据已经写入大多数副本集成员。默认在主库读,如果本次读取使用了 causally consistent 则在从库读。

如果 readConcern=available,从当前实例查询并返回结果,不能保证数据已经写入大多数副本集成员。默认在从库读,并且此选项与 causally consistent 不能同时使用。

如果 readConcern=majority,查询结果返回被副本集的大多数成员确认的数据,读操作返回的文档是持久化的。前提是 MongoDB 必须是 WiredTiger 存储引擎。

如果 readConcern=linearizable,查询可能会等待并发执行的写操作传播到大多数副本集成员,然后再返回结果。

如果 readConcern=snapshot,这是适用于多文档事务中的操作,通常情况下使用较少。

模式迁移

随着应用程序的增长和需求的变化,数据库模式也可能需要随之增长和改变。理想情况下,如果可以的话,应该考虑使用文档版本控制模式。

最简单的方式是根据应用程序的需要改进数据库模式,以确保应用程序支持所有的旧版模式。但是这种方式可能会导致混乱,特别是当不同版本的模式存在冲突时。

为了以一种更结构化的方式处理不断变化的需求,可以在每个文档中包含一个 version 字段,并使用它来确定应用程序将接受的文档结构。

最后一种方式是在模式变更时迁移所有数据。但这通常不是一个好主意:会给系统带来压力,还必须确保所有文档都被更新成功。

模式管理

MongoDB 3.2 引入了模式验证,其可以在更新和插入操作期间对数据进行验证。

MongoDB 3.6 又通过 $jsonSchema 运算符添加了 JSON 模式验证,现在这是 MongoDB 中所有模式验证的推荐方法。

只有当文档被更改时,验证功能才会检查这些文档,并且此功能是每个集合都需要单独配置的。

要向现有集合添加验证功能,可以在 collMod 命令中使用 validator 选项。在使用 db.createCollection() 时,可以通过指定 validator 选项将验证添加到新集合中。

MongoDB 还提供了两个额外的选项:

  • validationLevel: 决定了在更新过程中验证规则对现有文档检查的严格程度
  • validationAction: 决定了是应该在发生错误时拒绝请求,还是允许请求并发出警告

当然,更详细的相关内容可以查看 官方文档

编写代码来处理数据完整性问题

为保证 MongoDB 数据的完整性,有可能需要在应用程序中增加必要的逻辑代码进行处理,也需要增加定时任务来保持数据的一致性。

有可能需要有以下的任务:

  • 一致性修复程序:检查计算和重复数据以确保每个人都具有一致的值
  • 预填充器:创建将来需要的文档
  • 聚合:保持内联聚合为最新
  • 架构检查器:确保当前使用的文档集都具有一组字段,可以自动更正它们
  • 定时备份:定期锁定和转储数据库

文章来源于互联网:MongoDB - 模式设计

THE END
分享
二维码