MongoDB 三 数据模型

已于 2022-04-09 22:53:30 修改
阅读量1k 收藏 7
点赞数 1
分类专栏： mongodb 文章标签： mongodb 数据分析
于 2022-04-09 22:31:22 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/July_whj/article/details/124069566
版权

1、什么是数据模型

数据模型是一组符合、文本组成的集合，用以准确表达信息，达到有效交流、沟通的目的。

比如：保险公司经济人，我们关注的客户主要关注：客户年龄，年收入，家庭成员，工作行业等等

而作为理发店，则主要关注每个月来几次，对发型的需求等等。关注的属性和保险公司所关注的属性完全不同。

2、数据模型设计的元素

2.1、实体Entity

  • 描述业务的主要数据集合

  • 谁，什么，何时，何地，为何，如何。

2.2、属性 Attribute

属性是进一步用来描述实体的，比如我们看下联系人这个实体，它包含了姓名、公司、职称等等信息。

2.3、关系 Relationship

关系用来描述实体之间的关系，比如一个人包含多个地址，可能家庭住址，公司住址等等。

  • 结构规则：1-N;1-1;N-N;

3、传统模型设计：从概念到逻辑到物理

模型

  • 概念模型
  • 往往是由用户和需求分析来进行讨论，只是粗旷的了解下大体业务逻辑，梳理业务需求
  • 逻辑模型
  • 基于业务需求，由架构师或者需求分析师，进行实体及实体属性和他们之间的管理罗列出来。
  • 物理模型
  • 具体实现，通过使用什么数据库，将逻辑模型建立起来。

4、开发者角度下的物理模型

物理模型，主流使用的是关系型模型，主要遵循三范式原则。

遵循三范式的优点：可以减少数据冗余，数据表体积小更新快，范式化的更新操作比 反范式化更快，范式化的表通常比反范式化更小。
缺点：对于查询需要对多个表，会关联多个表，在应用中，进行表关联的成本是很高更难得进行索引优化反范式化设计的优缺点
可以减少表的关联，可以对查询更好的进行索引优化，缺点，表结构存在数据冗余和数据维护异常，对数据的修改需要更多资源。
因此在设计数据库结构的时候要将反范式化和范式化结合起来。

二、JSON文档模型设计

2.1、MongoDB文档模型设计的三个误区

  • 不需要模型设计
  • MongoDB应该用一个超级大文档来组织所有数据
  • MongoDB不支持关联或事物

以上这些说法全是错误的。

2.2、关于JOSN文档模型设计

文档模型设计处于是物理模型设计阶段 （PDM）

JSON 文档模型通过内嵌数组或引用字段来表示关系

文档模型设计不遵从第三范式，允许冗余。

严格来说，MongoDB 同样需要概念/逻辑建模

文档模型设计的物理层结构可以和逻辑层类似

2.3、逻辑模型 – JSON 模型

下面是一个JSON模型和逻辑模型的对比， 这里json文档中的联系人，列举出了姓名、性别、创建日期、所属组、和地址；

这样一个物理关系模型中需要多张表，而这里可以直接通过一个json来表述出来。

2.4、文档模式设计原则：性能和易用

在文档模式设计中我们是没有第三范式原则的，这是个好处也是个弊端，很多人不知道该如何设计这个模型。什么样的模型好什么样的模型坏。

我们是有两个关键点，看你这个模型是否性能不错，能够支撑高并发、低延迟的读写。另外一个角度在程序开发过程中是否简易。

这里没有唯一的标准，这里更多的是经验之谈。我们后面给大家些建模的建议。可以尊从文档模式设计三步走：

三、文档模式设计：基础建模

  • 根据概念模型或者业务需求推导出逻辑模型 – 找到对象

  • 列出实体之间的关系（及基数） - 明确关系

  • 套用逻辑设计原则来决定内嵌方式 – 进行建模

  • 完成基础模型构建

3.1、1:1关系建立

比如，一个联系人只有一个头像，

  • 基本原则：一对一关系以内嵌为主作为子文档形式 或者直接在顶级不涉及到数据冗余；
  • 例外情况：如果内嵌后导致文档大小超过16MB
1{
2  "name": "TJ Tang",
3  "company": "TAPDATA",
4  "title": " CTO",
5  "portraits": {
6    "mimetype": "xxx",
7    "data": "xxxx"
8  }
9}

3.2、一对多关系建立

比如一个联系人可以有多个地址：

  • 一对多关系同样以内嵌为主用数组来表示一对多不涉及到数据冗余；
  • 例外情况：如果内嵌后导致文档大小超过16MB，数组长度太大（数万或更多），数组长度不确定;
 1{
 2  "name": "TJ Tang",
 3  "company": "TAPDATA",
 4  "title": " CTO",
 5  "portraits": {
 6    "mimetype": "xxx",
 7    "data": "xxxx"
 8  },
 9  "addresses": [
10    {
11      "type": "home",
12      ....
13    },
14    {
15      "type": "work",
16      ....
17    }
18  ]
19}

3.3、多对多关系建模

比如一个联系人可以有多个地址：

  • 一对多关系同样以内嵌为主用数组来表示一对多，通过冗余来实现N-N；
  • 例外情况：如果内嵌后导致文档大小超过16MB，数组长度太大（数万或更多），数组长度不确定;
 1{
 2  "name": "TJ Tang",
 3  "company": "TAPDATA",
 4  "title": " CTO",
 5  "portraits": {
 6    "mimetype": "xxx",
 7    "data": "xxxx"
 8  },
 9  "addresses": [
10    {
11      "type": "home",
12      ....
13    },
14    {
15      "type": "work",
16      ....
17    }
18  ],
19  "groups":[
20    {"name":"FRI"},
21    {"name":"DF"},
22  ]
23}

四、文档模式设计：工况细化

在做工况细化过程中，我们需要根据技术需求对我们模型进行调整，这是个技术导向，我们需要和业务方进行详细的沟通，了解到数据的使用方法，是根据什么来查询的。如：单个查询，报表查询，查询参数是什么、数量有多大、读写比例有多少等等。针对不同需求，我们可以引入引用、关联、或者冗余等手段来解决这些问题。

● 最频繁的数据查询模式

● 最常用的查询参数

● 最频繁的数据写入模式

● 读写操作的比例

● 数据量的大小

比如：联系人管理应用的分组需求

4.1 解决方案：Group 使用单独的集合

类似于关系型设计，使用 id 或者唯一键关联，使用

4.2、联系人的头像： 引用模式


头像使用高保真，大小在 5MB-10MB
头像一旦上传，一个月不可更换
基础信息查询（不含头像）和 头像查询的比例为 9 ：1


建议： 使用引用方式，把头像数据放到另外一个集合，可以显著提升 90% 的查询效率。

4.3、什么时候使用引用模式

MongoDB 引用设计的限制

  • 内嵌文档太大，数 MB 或者超过 16MB

  • 内嵌文档或数组元素会频繁修改

  • 内嵌数组元素会持续增长并且没有封顶

MongoDB 引用设计的限制

  • MongoDB 对使用引用的集合之间并无主外键检查

  • MongoDB 使用聚合框架的 $lookup 来模仿关联查询

  • $lookup 只支持 left outer join

  • $lookup 的关联目标（from）不能是分片表

五、文档设计模式：套用设计模式

文档模型：无范式，无思维定式，充分发挥想象力；

设计模式：实战过屡试不爽的设计技巧，快速应用；

举例：一个IoT场景的分桶设计模式，可以帮助把存储空间降低10倍并且查询效率提升数十倍。

问题：物联网场景下的海量数据处理 - 设备监控数据

上报数据格式如下：

 1{
 2  "_id":"10000000022200000222:CA2091",
 3  "icao":"CA2091",
 4  "ts":ISODate("2022-04-03T20:21:35.000+0000"),
 5  "events":{
 6    "tem":35.3，
 7    "humidity":50.3,
 8    "lon":38.345,
 9    "lat":58.987,
10    "open":"0",
11    "b":"b"
12    "p":[123,245],
13    "s":91
14  }
15}

我们假设有10万个设备，每分钟上报一条数据，一年的数据量大约52560*100W = 525亿数据，约10TB;

每分钟1条计算说明
文档条数52.5B10W * 365 * 24 * 60
索引大小6364GB10W * 365 * 24 * 60 * 130
_id index1468GB
{ts:1,icao:1}4895GB
文档平均大小92Bytes
数据大小4503GB10W * 365 * 24 * 60 * 92

5.2、解决方案-分桶设计

思路将之前每分钟数据汇总到每小时一条，将每分钟数据存放在events中，变更结构如下：

 1{
 2  "_id": "10000000022200000222:CA2091",
 3  "icao": "CA2091",
 4  "ts": ISODate("2022-04-03T20:00:00.000+0000"),//每小时
 5  "events": [//每小时60条数据，集合条数固定
 6    {
 7      "tem": 35.3,
 8      "humidity": 50.3,
 9      "lon": 38.345,
10      "lat": 58.987,
11      "open": "0",
12      "b": "b",
13      "p": [
14        123,
15        245
16      ],
17      "s": 91,
18      "ts": ISODate("2022-04-03T20:01:00.000+0000")//每分钟
19    },
20    {
21      "tem": 35.3,
22      "humidity": 50.3,
23      "lon": 38.345,
24      "lat": 58.987,
25      "open": "0",
26      "b": "b",
27      "p": [
28        123,
29        245
30      ],
31      "s": 91,
32      "ts": ISODate("2022-04-03T20:02:00.000+0000")
33    }
34  ]
35}

这里我们一个文档可以存储一个小时的设备数据，而events集合中的数据条数是固定的，每小时60条。

可视化表现 24 小时的设备数据，查询1440 次读操作即可。

指标每分钟1条每小时一个文档
文档条数52.5B876 M
索引大小6364GB106 GB
_id index1468GB24.5 GB
{ts:1,icao:1}4895GB81.6 GB
文档平均大小92Bytes758 Bytes
数据大小4503GB618 GB

分桶方式总结：

场景痛点设计模式方案及优点
时序数据数据点采集频繁，数据量太多利用文档内嵌数组，将一个时间段的数据聚合到一个文档里
物联网大量减少文档数量
智慧城市大量减少索引占用空间
智慧交通

六、设计模式集锦

6.1、列转行模式

问题: 大文档，很多字段，很多索引

screenshot-20220409-215935

解决方案：列转行

  • 列转行总结：
场景痛点设计模式方案及优点
产品属性 ‘color’, ‘size’, ‘dimensions’, …物联网，多语言（多国家）属性文档中有很多类似的字段，会用于组合查询搜索，需要建很多索引转化为数组，一个索引解决所有查询问题

6.2、版本字段

问题：模型灵活了，如何管理文档不同版本？

修改前版本：

1{
2  "_id": ObjectId("5de26f197edd62c5d388babb"),
3  "name": "TJ",
4  "company": "Tapdata"
5}

新增手机号后版本：

1{
2  "_id": ObjectId("5de26f197edd62c5d388babb"),
3  "name": "TJ",
4  "company": "Tapdata",
5  "phone":"182XXXX8888"
6}

解决方案：增加一个版本字段：

1{
2  "_id": ObjectId("5de26f197edd62c5d388babb"),
3  "name": "TJ",
4  "company": "Tapdata",
5  "phone":"182XXXX8888",
6  "schema_version": 2.0
7}
  • 版本字段总结：
场景痛点设计模式方案及优点
任何有版本衍变的数据库文档模型格式多，无法知道其合理性,升级时候需要更新太多文档增加一个版本号字段;快速过滤掉不需要升级的文档;升级时候对不同版本的文档做不同的处理

6.3、近似计算

问题：统计网页点击流量

  • 解决方案: 用近似计算

每隔10 (X)次写一次，

  • 近似计算总结：
场景痛点设计模式方案及优点
网页计数；各种结果不需要准确的排名；写入太频繁，消耗系统资源间隔写入，每隔10次或者100次，大量减少写入需求

6.4、使用预聚合字段

问题: 业绩排名，游戏排名，商品统计等精确统计

热销榜：某个商品今天卖了多少，这个星期卖了多少，这个月卖了多少？

电影排行：观影者，场次统计

传统解决方案：通过聚合计算

痛点：消耗资源多，聚合计算时间长

  • 解决方案: 用预聚合字段

在模型中新增预聚合字段，每次更新数据的时候同步更新统计值。

1{
2  "product": "Bike",
3  "sku": "abc123456",
4  "quantitiy": 20394,
5  "daily_sales": 40,
6  "weekly_sales": 302,
7  "monthly_sales": 1419
8}

1db.inventory.update({_id:123},
2{$inc: {
3  quantity: -1, 
4  daily_sales: 1, 
5  weekly_sales: 1，
6  monthly_sales: 1，
7    } 
8})
  • 预聚合字段总结：
场景痛点设计模式方案及优点
准确排名,排行榜统计计算耗时，计算时间长模型中直接增加统计字段;每次更新数据时候同时更新统计值

注：以上内容参考《MongoDB 高手课》

Julywhj
关注
专栏目录
MongoDB实战-面向文档的数据(找到最合适的数据建模方式)
wanght89的专栏
08-15 2385
本博文首先讲解了RDBMS和MongoDB对Schema的建模要求和支持情况。后面以电子商务的实例讲解了具体的建模方法，以及由于MongoDB不支持联结查询带来的局限性问题的去正规化解决方案，从而找到一个最适用于应用的schema。
MongoDB数据模型设计
SongD1114的博客
04-17 3090
MongoDB数据模型设计
MongoDB 的功能
最新发布
Flying_Fish_roe的博客
09-07 1396
MongoDB 的功能丰富多样，能够高效应对各种应用场景。其灵活的文档模型、水平扩展、强大的查询与索引机制、事务支持以及高可用性和扩展性，使其成为现代应用开发中的热门选择。无论是小型的实时应用，还是大型分布式系统，MongoDB 都能够提供强大的功能支持。
MongoDB 数据模型
大痴小乙的博客
07-30 744
顾名思义，JSON与JavaScript语言是分不开的，它是JavaScript对象的一种文本表现形式。BSON（BinaryJSON）是二进制版本的JSON，其在性能方面有更优的表现。二者最大的区别在于JSON是基于文本的，而BSON则是二进制（字节流）编/解码的形式。作为一种轻量级的数据交换格式，JSON的可读性非常好，而且非常便于系统生成和解析，这些优势也让它逐渐取代了XML标准在Web领域的地位，当今许多流行的Web应用开发框架，如SpringBoot都选择了JSON作为默认的数据编/解码格式。..
MongoDB数据模型
qq_19268039的博客
12-08 1907
MongoDB数据模型设计Embedded Data - 内嵌数据模型文档大小限制规范化数据模型MongoDB特性与数据模型原子性分片索引大量的集合 与SQL数据库在插入数据之前必须确定并声明表的模式不同，MongoDB的集合不要求其文档具有相同的模式： 单个集合中的文档不需要具有相同的字段集，并且字段的数据类型可以在集合中的文档之间不同。 要更改集合中文档的结构（例如添加新字段，删除现有字段或...
简要介绍MongoDB的数据模型
weixin_33675507的博客
08-29 218
    MongoDB数据是特别灵活的，与SQL数据库相比，它不需要在插入数据前先定义表的结构。MongoDB的集合不强调固定的文档结构。这种灵活性使它能够轻松映射文档结构。每一个文档都可以映射它要表达的对象，即使这些数据有实质性的不同。其实在实际中，同一集合下的文档通常采用相似的结构。    MongoDB数据建模的主要问题时在应用程序的需求，数据库引擎的性能特性和数据检索模型之间做一个平衡。设...
基于threejs的在线3D场景编辑器使用mongodb保存3D模型和场景数据
08-10
标题中的“基于threejs的在线3D场景编辑器使用mongodb保存3D模型和场景数据”指的是一款使用Three.js库构建的Web应用程序，允许用户在浏览器中创建、编辑和保存3D场景。Three.js是JavaScript的一个强大库，专门用于...
MongoDB的文档数据模型
ghf183184的博客
09-11 936
MongoDB的文档数据模型 首先，文件系统中的文件基本上对应于某个应用程序。当不同的应用程序所需要的数据部分相同时，也必须建立各自的文件，而不能共享数据，而文档数据库可以共享相同的数据。因此，文件系统比文档数据库数据冗余度更大，更浪费存储空间，且更难于管理维护 其次，文件系统中的文件是为某一特定应用服务的，因此，要想对现有的数据再增加一些新的应用是很困难的，系统难以扩展，数据和程序缺乏独立性。而文档数据库具有数据的物理独立性和逻辑独立性，数据和程序分离 NoSQL 中的文档数据库 NoSQL 中的文档数据
MongoDB：数据模型介绍
czp1001的专栏
07-27 1966
ngoDB的数据有灵活的模式。不像SQL数据库，（SQL数据库）要求你必须在插入数据之前决定和声明一个表的模式，MongoDB的集合不强制文档的结构。这个灵活性有利于文档到实体或对象的映射。每个文档可以匹配所要表示实体的数据字段，即使数据的变化很显著。但在实际操作中，一个集合的文档共享一个相似的结构
【待完善】MongoDB - 数据模型
jclee95的个人博客
08-26 269
MongoDB - 数据模型 CSDN用户名：jcLee95 附：【概念对比】 SQL关系型数据库 MongoDB 数据库 数据库 表 集合（collection） 行 文档（document） 列/字段 字段（field） 索引 索引（index） 主键 _id（默认索引字段） 视图（view） 视图（view） 表连接（table joins） 聚合操作（$lookup） MongoDB集合中所有的文档都有一个唯一的_id字段作为集合的主键。如果创
mongodb-数据模型
xiongda1122的博客
11-10 911
数据建模简介(https://docs.mongodb.org/manual/core/data-modeling-introduction/) 一些概念，一个mongod服务可以有建立多个数据库，每个数据库可以有多张表，这里的表名叫collection，每个collection可以存放多个文档（document），这个文档就是一行记录，每个文档都以BSON（binary json）的形式存放于硬...
MongoDB的数据模型
12-16 200
文档的数据模型代表了数据的组织结构，一个好的数据模型能更好的支持应用程序。在MongoDB中，文档有两种数据模型，内嵌（embed）和引用（references）。 内嵌 MongoDB的文档是无模式的，所以可以支持各种数据结构，内嵌模型也叫做非规格化模型（denormalized）。在MongoDB中，一组相关的数据可以是一个文档，也可以是组成文档的一部分。看看下面一张MongoD...
MongoDB学习【二】MongoDB数据模型
2301_76508397的博客
04-15 824
然而，与传统的关系型数据库表相比，MongoDB的集合具有无模式（schema-less）的特性，意味着同一集合内的文档可以有不同的字段和结构。MongoDB作为NoSQL数据库，其数据模型的核心是基于JSON-like文档的集合（Collections），每个文档可以自由地拥有动态schema，这意味着同一个集合中的文档可以有不同的字段和结构。根据实际业务场景，有时会结合使用嵌入和引用，即部分常用或小粒度的数据嵌入在主文档内，而大粒度或频繁更新的数据则通过引用的方式存放在其他集合中。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

Julywhj

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值