Mongo存储模型优化

矫情吗；* 2022-09-04 06:43 174阅读 0赞

author：skatexg

time：2021/08/11

**一. mongo系统架构选择**

我们mongo系统架构选择依据是什么？选副本集架构？还是选择分片集群架构？

1.存储容量遇到单机限制时选择分片集群架构。  
2.读写能力遇到单机限制(可能是CPU、内存或者网卡等资源遭遇瓶颈)，导致读写能力无法扩展时，选择分片集群架构。

如果选择分布式集群架构，最重要的是shared key设计  
1.shared key易于切分，最好是无限的。  
2.shared key具有高度的随机性，保证数据分布均匀。  
3.shared key应该是你的请求的主要字段，避免scatter-gather查询。

**二.存储模型优化**

**确定业务场景**  
确定业务场景，数据存储整体风格，嵌套存储？还是外联存储？

嵌套存储：意味着将数据存储到多个集合collections中，并在它们之间设计关联关系。更新数据比较容易，但是在读取数据性能变慢  
外联存储：将若干对象数据，以嵌套的方式存储到单个文档中。它在读取数据的时候表现更好，但在写入时会变慢。这种存储数据的方式将占用更多空间

如果数据更新不是频繁，更新性能不是很重要，但是在读取时需要良好的性能，那么外联存储可能是明智的选择  
如果数据库中的文档数据需要不断的更新，并且您希望在写入时具有良好的性能，那么您可能需要考虑嵌套存储

**Collection设计**  
Mongo中的collection对象之间的关联关系，基本上在一个collection里就能体现了。如果还是通过关系型数据库的关系表的表示，那就没有发挥mongo的优势

Mongod一对多的设计：主要是平衡读写性能（通过合理数据合并，减少网络io、磁盘IO，达到读写平衡）

**1.一对一-完整内嵌**  
表样例：  
键盘与主机的关系。一台主机有一个键盘，一个键盘有一台主机。

字段：  
主机：id、CPU核数、内存大小、显卡大小。  
键盘：id、主机的id、键盘类型（机械/非机械）、颜色、牌子

对象一对一关系比较简单，在mongo中强烈建议使用完全内嵌模式，如下数据样例

\{  
"主机id":"1",  
"CPU核数":"2核",  
"内存大小":"16GB",  
"显卡大小":"2GB",  
"键盘":\{  
    "键盘类型":"机械",  
    "颜色":"Black",  
    "牌子":"双飞燕"  
\}  
\}

**2.一对多-完整内嵌**

场景：订单与订单项的关系

字段：  
订单字段：id、订单号、运费、总价格、订单状态。   
订单项字段：名称、单价、数量

1）查看订单：查看订单时，都是从订单进入，然后查看所有的订单项。  
2）支付成功或失败后，修改订单时，都是修改订单，没有修改订单项。  
   
完整内嵌型的一对多设计非常适合这种场景，数据样例如下  
   
   
\{  
        "id": "asdg184981651568956",   
        "订单号": "201809270012598323334",   
        "运费": 0,   
        "总价格": 41,   
        "订单状态": "已经支付",   
        "订单项": \[  
                \{  
                        "名称": "益达口香糖",   
                        "单价": 8,   
                        "数量": 2  
                \},   
                \{  
                        "名称": "大大口香糖",   
                        "单价": 5,   
                        "数量": 1  
                \},   
                \{  
                        "名称": "绿箭口香糖",   
                        "单价": 10,   
                        "数量": 2  
                \}  
        \]  
\}

小结：  
使用完整内嵌一对多设计时，前提有这几点  
     1）内嵌数组不宜过大。因为太大会导致整个实体内容大，从而导致网络延迟问题。建议不超过30个。具体根据内嵌实体大小而定。  
     2）如果内嵌实体数组过多（一般多于5个），查询时，内嵌实体内容没有作为单独的实体查询需求。  
     3）如果内嵌实体数组过多（一般多于5个），修改/删除/插入时，内嵌实体内容没有作为单独的实体修改/删除/插入需求。  
        
       
**3.一对多-内嵌id型**  
场景：公司与员工的关系。一个公司对应N个员工。  
   
1）员工的属性很多。  
2）一个公司员工人数不确定。  
3）单独查询员工信息的场景。  
4）修改员工信息的场景。

这种场景采用完全内嵌设计就不合理，因为内嵌数组太大，所以可考虑内嵌id型，数据样例如下：

公司表：  
\{  
        "id": "45465516654",   
        "名称": "千度科技有限公司",   
        "注册地址": "北京市朝阳区",   
        "所有人": "张大大",   
        "注册日期": "2001-9-1",   
        "员工": \[  
                \{  
                        "id": "员工id1"  
                \},   
                \{  
                        "id": "员工id2"  
                \}  
        \]  
\}

员工表：  
\{  
        "id": "员工id",   
        "姓名": "alun",   
        "入职时间": "2010-8-8",   
        "身份证号": "423632155502",   
        "职位": "架构师",   
        "工资": 1000,   
        "入职年限": 1,   
        "公资金百分比": 5,   
        "得奖数": 1,   
        "体重": "50KG",   
        "住址": "广东省广州",   
        "下属人数": 20,   
        "年假剩余天数": 0,   
        "评价级别": 10  
\}

小结：  
使用内嵌id型一对多设计时，前提有这几点：  
     1）一对多的多那方数量要多，最好是几千个不等。  
     2）需要单独把内嵌的实体取出。  
    这种方案的缺点：  
     1）查询员工属于哪些公司时，需要跨表查询。  
     2）内嵌方的数量不能过多。    
       
       
**4.一对多-内嵌id+查询字段型**  
场景：继续上面例子

查询公司下面的员工名字。这个功能是占用查询率70%以上，可以考虑使用内嵌id+查询字段型。数据样例如下：  
\{  
"id":"45465516654",  
"名称":"千度科技有限公司",  
"注册地址":"北京市朝阳区",  
"所有人":"张大大",  
"注册日期":"2001-9-1",  
"员工":\[  
    \{ "id":"员工id1", "姓名":"alun" \},  
    \{ "id":"员工id2", "姓名":"vivien" \}  
\]  
\}

在查询时，不需要关联员工表，直接查询公司表即可。查询效率大大提升

小结：  
使用内嵌id+查询字段型一对多设计时，前提有这几点  
     1）一对多的多那方数量要多，最好是几千个不等。  
     2）内嵌方的属性（字段）不宜过多。  
     3）查询需求远大于修改需求。  
     这种方案的缺点：  
     1）修改时需要原子性操作。  
     2）文档内容加大了，即产生了多余字段。如上面的【姓名】。

**5.一对多-父级引用型**  
场景：电子商务的某商城与商铺的关系，商城里的商铺有几万到几十万，甚至几百万不等。

这么大量的数据，使用内嵌型有些力不从心。因为文档大小也有限制，如果太大的话，不禁mongodb报错，还可能导致网络延迟。因为一次查询的数据量过大。  
所以这里使用父级引用，即子对象引用父对象id。数据样例如下：

商城表：  
\{  
"id":"hijgio19089popik",  
"名称":"某宝",  
"注册地址":"杭州市",  
"所有人":"某某某",  
"注册日期":"2005-1-1"  
\}

商铺表   
\{  
"id":"84948654",  
"名称":"alun的商铺",  
"创建时间":"2018-2-1",  
"过期时间":"2019-2-1",  
"是否合法":true,  
"商品品质级别":"高",  
"是否个人商铺":true,  
"持有人身份证号":"441922365587444468",  
"某宝/某东id":"hijgio19089popik"  
\}

查询：查询属于某商城的商铺时，在商铺表通过某商城id可以查出所有的商铺。  
修改：修改商铺、修改某商城表的属性都是单个表修改。

**小结：**  
使用父级引用型一对多设计时，前提有这几点  
     1）一对多的多那方数量很多，几万以上。  
     2）对性能要求不高。

** 三.索引设计**

**创建索引原则：**

1.排序、分组的字段上创建索引

2.在查询条件的字段上创建索引

3.索引的数量不宜过多，建议控制在3个以内

4.创建的索引最大化覆盖SQL语句

**1.单字段索引**  
为普通字段添加索引，并且为索引命名

db.集合名.createIndex( \{"字段名": 1 \},\{"name":'idx\_字段名'\})

说明： （1）索引命名规范：idx\_<构成索引的字段名>。如果字段名字过长，可采用字段缩写。  
            （2）字段值后面的 1 代表升序；如是 -1 代表 降序。  
         
eg:  
db.doc\_test.createIndex( \{"productname": 1 \},\{"name":'idx\_productname',background:true\})

为内嵌字段添加索引

db.集合名.createIndex(\{"字段名.内嵌字段名":1\},\{"name":'idx\_字段名\_内嵌字段名',background:true\})

eg:  
db.doc\_test.createIndex(\{"prodname.child\_prodname":1\},\{"name":'idx\_prodname\_child\_prodname',background:true\})

**2.组合索引**  
db.集合名.createIndex(\{"字段名1":-1,"字段名2":1\},\{"name":'idx\_字段名1\_字段名2',background:true\})

eg：  
db.doc\_test.createIndex(\{"prodname":-1,"projectname":1\},\{"name":'idx\_prodname\_projectname',background:true\})

说明：  
当查询语句覆盖精确匹配，范围查询与排序的时候，\{精确匹配字段,排序字段,范围查询字段\} 创建这样的索引排序会更为高效

**3.唯一索引**  
db.集合名.createIndex( \{"字段名": 1 \},\{"name":'idx\_字段名',unique:true,background:true\},)

eg:  
db.doc\_test.createIndex( \{"productname": 1 \},\{"name":'idx\_productname',unique:true,background:true\})

**4.设置TTL索引(document自动过期删除)**

db.集合名.createIndex( \{ "字段名": 1 \},\{ "name":'idx\_字段名',expireAfterSeconds: 定义的时间,background:true\} )

说明 ：expireAfterSeconds为过期时间（单位秒）

eg:  
db.doc\_test.createIndex( \{ "productname": 1 \},\{ "name":'idx\_productname',expireAfterSeconds: 3600,background:true\} )