mongo datamodel

[FS1360472174]

https://docs.mongodb.com/manual/core/data-modeling-introduction/

[FS1360472174]

datamodel 主要的挑战是平衡应用的需求，db储存的性能，数据产生的模式。

document结构 document关联关系有两种：

1. 引用 像关系型数据库那样，collections之间字段关联，规范化数据模型

2.Embedded Data(嵌套) 反规范化数据模型

写操作的原子性 写操作原子性在单个document level.

所以反规范化数据模型某种程度上提供了事务来控制了多个表的数据插入。

document 增长 对于MMAPv1存储引擎，如果文档大小超过了分配的空间， 会在磁盘上重新分配。当使用MMAPv1存储时，document增长是 决定规范化，还是反规范化数据的一个因素。

数据使用和性能 设计一个data model，需要考虑应用程序如何使用你的database.比如 如果只使用最近插入的数据，可以考虑使用Capped Collections.

如果应用程序主要是读操作，加indexes提高性能。

[FS1360472174]

数据验证

mongo提供数据的验证 db.createCollection( "contacts", { validator: { $or: [ { phone: { $type: "string" } }, { email: { $regex: /@mongodb\.com$/ } }, { status: { $in: [ "Unknown", "Incomplete" ] } } ] } } )

甚至可以是正则表达式，当数据插入，更新时可以进行校验。

影响 已有的数据不会在你设置验证条件时进行校验，只有当对数据进行更改时才会。 对已有数据的校验级别可以设置。默认的validationLevel是strict。就是MongoDb会对 所有的inserts 和update实行校验。如果设置为moderate,.则只会应用到满足条件的insert和update

不能对admin,local,config,system database 设置验证

[FS1360472174]

数据模型设计

1.嵌套document 优点:查性能好

缺点: document 增长影响写性能(??？影响什么的写性能) 导致数据分散(基于MMAPv1储存引擎，Mongo3.0.0 以后，使用Power of 2 Sized Allocation.) 另外，如果query是返回整个json。那数据量也会过大

2.引用 case: 1.当嵌套会导致数据冗余，但是又不能提供充分的读性能去弥补数据的冗余

2.更加复杂的多对多的关系

3.对更大层级的数据集建模

[FS1360472174]

总结

data model 的设计好坏直接影响到read,write性能。可能影响的因素

1. document 大小增长 使用MMAPv1存储引擎时，需要考虑这个问题。因为要避免 document的重新分配，但是mongo3.0.0以后，默认使用Power of 2 Sized Allocations. 大大减少了这种概率，所以这个不在考虑范围。

2.Atomicity 只有单个document才有原子性

3.sharding 水平扩展，需要定义shard key

4.indexes index 代价： 1.需要至少8KB的数据空间 2.影响写性能 query性能分析

5.大量的collections 大体来说，大量的collections并没有什么性能损失，同时会带来好的性能。 但是namespace可能会有限制

6.collection包含大量的小document 需要考虑是不是要将这些小的document组成一个大的 7.数据生命周期管理 可以使用TTL,

[FS1360472174]

1. 1 X 1 关系 如果查询case经常要带另一个实例，那么将实例嵌套进来
2. 1 X N关系 这个要看1对多的增长情况 比如一个人的地址，可以有多个。但是不会是无限个，可以将地址嵌套在人中

但是出版社与书，这个是没有上限的。就会考虑使用collection之间的关联关系来解决。

[FS1360472174]

Model Data 去支持关键词搜索

关键词搜素和文本搜索，全文本搜索不一样。 这个功能比较鸡肋，没什么用

model 金融数据