MongoDB爱好者
垂直技术交流平台
        找回密码
当前位置：MongoDB中文社区 > 最佳实践 > 正文

MongoDB大数据量模型设计最佳实践

2021-07-28 分类：最佳实践 / 知识分享 评论(0)

 

项目背景

数据质量项目，实时消费kafka数据，并经过流式计算后，需要展示并处理有问题的数据。

 

数据需求

(1) 数据的schema不固定，并且需要存储在一张表里,并且需要通过这个不固定的字段查询

(2) 需要存储时序数据，数据量较大。每天预估大概6000W条数据写入。

架构图：

基于MongoDB的解决方案

1. MongoDB天生的json处理能力，不需要固定的字段。并在4.2版本推出 Wildcard index 天生支持对不固定子集的查询（索引）。

*这个可以对子集中，不固定的集合自动创建索引，可以有效解决不固定字段的查询性能问题。

创建方式：db.data.createIndex({“unique_key_value.$**:1”})

对unique_key_value这个字段所有的子集建立通配符索引。

2. 使用MongoDB数据桶的方式来存储，数据容器里面的数据做时序，容器里面的数据加一个timestamp来标识。

 

原始数据结构4个文档（mysql中的4行数据）：

原始数据模型结构
{  
  _id: ObjectId(),
    deviceid: 1,
    date: ISODate("2019-11-10"),
    samples : [
       { info: 10, time: 1573833152}，
     
   ]
}
{
    _id: ObjectId(),
    deviceid: 1,
    date: ISODate("2019-11-10"),
    samples : [
       { info: 15, time : 1573833153},
 
   ]
}
{
    _id: ObjectId(),
    deviceid: 1,
    date: ISODate("2019-11-10"),
    samples : [
       { info: 14, time: 1573833154},
 
   ]
}
{
    _id: ObjectId(),
    deviceid: 1,
    date: ISODate("2019-11-10"),
    samples : [
       { info: 20, time : 1573833155},
 
   ]
}

数据桶模型结构（由4个文档合并成了1个文档）：

数据桶模型结构

{
    _id: ObjectId(),
    deviceid: 1,
    date: ISODate("2019-11-10"),
    first: 1573833152,
    last: 1573833155,
    samples : [
       { info: 10, time: 1573833152},
       { info: 15, time : 1573833153},
       { info: 14, time: 1573833154},
       { info: 20, time : 1573833155}
   ]
}

数据模型设计思路：

业务需求，3W个设备，都要查询，但只需要查询最近2天的数据，那就按照时间维度来拆分，每个文档中保持1000条实时数据，每天大概6W个文档。这样，每次业务全量查询，只需要查询6W个文档即可。占用内存参考下面统计的数据大小。

这样不仅解决了时序的需求，同时也降低了冗余数据的存储，可以节约一大笔内存和磁盘开销。

但每个数据桶中存放多少条时序数据呢？

MongoDB本身一个文档大小限制为16M，这里考虑到，我们的设备会比较多，2W个设备。可能每个用户只需要查询其中几十或者几百个设备，所以，我们设计成上面数据桶的方式。

 

字段解释：

id —文档的ID（MongoDB的ObjectId）
deviceId —查询的设备ID
date—样品的日期；我们可以将其存储在此处以简化聚合
first —在存储桶中读取的最旧数据的时间戳
last —存储桶中读取的最新数据的时间戳
samples —数据容器

 

经过实际，测试每个文档对应一个设备id，每个文档中存放1000条设备记录查看这个文档大小：

评估实际场景当个文档大小

rs01:SECONDARY>
rs01:SECONDARY>
rs01:SECONDARY>
rs01:SECONDARY>
rs01:SECONDARY> rs.slaveOk()
rs01:SECONDARY>
rs01:SECONDARY> use dq;
switched to db dq
rs01:SECONDARY>
rs01:SECONDARY> var doc = db.meta_ts_detail.find({ "_id" : ObjectId("60e660d02a0b6833efee50e6")})
rs01:SECONDARY>
rs01:SECONDARY> print(Object.bsonsize(doc))
79222
rs01:SECONDARY>
rs01:SECONDARY>

可以看到，单个文档的大小为80k

下面是研发按照实际生产环境数据模型压测结果：

MongoDB每秒upsert数量

insert query update delete getmore command dirty  used flushes vsize   res qrw  arw net_in net_out conn  set repl                time
    *0    *0   4398     *0     611   796|0  5.0% 72.7%       0 7.20G 3.98G 0|0  2|0  2.98m   15.5m  118 rs01  PRI Jul 16 02:54:17.526
    *0    *0   3295     *0     512   663|0  4.3% 72.4%       0 7.20G 3.98G 0|0  1|1  2.32m   15.6m  118 rs01  PRI Jul 16 02:54:18.516
    *0     1   4215     *0     741   941|0  4.5% 72.6%       0 7.20G 3.98G 0|0  1|1  3.08m   16.6m  118 rs01  PRI Jul 16 02:54:19.517
    *0    *0   4475     *0     602   732|0  4.8% 72.8%       0 7.20G 3.98G 0|0  1|0  2.95m   17.9m  118 rs01  PRI Jul 16 02:54:20.516
    *0    *0   4452     *0     640   795|0  5.0% 73.0%       0 7.20G 3.98G 0|0  1|0  3.02m   16.4m  118 rs01  PRI Jul 16 02:54:21.516

    *0     1   3408     *0     522   685|0  5.1% 73.1%       0 7.20G 3.98G 0|0  1|0  2.41m   11.7m  118 rs01  PRI Jul 16 02:54:22.517
    *0    *0     *0     *0       0     3|0  4.5% 72.9%       0 7.20G 3.98G 0|0  1|0   683b   39.1k  118 rs01  PRI Jul 16 02:54:23.516
    *0     2    339     *0      59    85|0  4.5% 72.9%       0 7.20G 3.98G 0|0  1|0   251k   1.52m  118 rs01  PRI Jul 16 02:54:24.516
    *0    *0   4163     *0     560   719|0  4.3% 73.1%       0 7.20G 3.97G 0|1  1|0  2.78m   18.1m  118 rs01  PRI Jul 16 02:54:25.518
    *0    *0   4484     *0     652   786|0  4.5% 73.3%       0 7.20G 3.97G 0|0  1|3  3.03m   18.3m  118 rs01  PRI Jul 16 02:54:26.516
insert query update delete getmore command dirty  used flushes vsize   res qrw  arw net_in net_out conn  set repl                time

    *0    *0   4618     *0     677   873|0  4.9% 73.5%       0 7.20G 3.97G 0|0  1|1  3.17m   16.6m  118 rs01  PRI Jul 16 02:54:27.516
    *0     1   2934     *0     473   628|0  5.1% 73.7%       0 7.20G 3.97G 0|0  1|0  2.10m   10.7m  118 rs01  PRI Jul 16 02:54:28.571
    *0    *0   4673     *0     658   843|0  4.8% 73.9%       0 7.20G 3.98G 0|0  1|3  3.17m   14.1m  118 rs01  PRI Jul 16 02:54:29.516
    *0    *0   4679     *0     568   708|0  4.5% 74.1%       0 7.20G 4.00G 0|0  1|2  3.03m   15.1m  118 rs01  PRI Jul 16 02:54:30.521
    *0    *0   4245     *0     494   642|0  3.7% 74.1%       0 7.20G 4.00G 0|0  1|1  2.74m   15.0m  118 rs01  PRI Jul 16 02:54:31.517
    *0    *0   3339     *0     395   490|0  3.3% 74.2%       0 7.20G 4.02G 0|0  1|0  2.13m   13.2m  118 rs01  PRI Jul 16 02:54:32.517
    *0    *0     *0     *0       0     2|0  3.3% 74.2%       0 7.20G 4.02G 0|0  1|0   681b   39.0k  118 rs01  PRI Jul 16 02:54:33.518
    *0    *0    201     *0      32    40|0  3.3% 74.2%       0 7.20G 4.02G 0|0  1|0   141k    828k  118 rs01  PRI Jul 16 02:54:34.518
    *0    *0   4173     *0     710   985|0  3.6% 74.4%       0 7.20G 4.02G 0|0  1|2  3.09m   17.9m  118 rs01  PRI Jul 16 02:54:35.517
    *0    *0   4320     *0     643   834|0  3.8% 74.6%       0 7.20G 4.02G 0|0  2|0  2.99m   16.8m  118 rs01  PRI Jul 16 02:54:36.516
insert query update delete getmore command dirty  used flushes vsize   res qrw  arw net_in net_out conn  set repl                time

    *0    *0   4495     *0     629   794|0  4.0% 74.8%       0 7.20G 4.02G 0|0  1|1  3.03m   16.4m  118 rs01  PRI Jul 16 02:54:37.518
    *0    *0   3543     *0     577   764|0  4.0% 74.9%       0 7.20G 4.02G 0|0  1|0  2.54m   13.0m  118 rs01  PRI Jul 16 02:54:38.516
    *0    *0   4252     *0     671   873|0  4.2% 75.0%       0 7.20G 4.02G 0|1  1|4  3.01m   13.4m  118 rs01  PRI Jul 16 02:54:39.516
    *0    *0   4654     *0     670   865|0  4.3% 75.2%       0 7.20G 4.02G 0|0  1|5  3.18m   15.1m  118 rs01  PRI Jul 16 02:54:40.517
    *0    *0   4522     *0     696   913|0  4.5% 75.4%       0 7.20G 4.02G 0|0  1|2  3.18m   17.4m  118 rs01  PRI Jul 16 02:54:41.516
    *0    *0   3276     *0     530   714|0  4.7% 75.5%       0 7.20G 4.02G 0|0  1|0  2.36m   13.1m  118 rs01  PRI Jul 16 02:54:42.516
    *0    *0     *0     *0       0     2|0  4.7% 75.5%       0 7.20G 4.02G 0|0  1|0   682b   39.0k  118 rs01  PRI Jul 16 02:54:43.517
    *0    *0    146     *0      14    21|0  4.0% 75.5%       1 7.20G 4.02G 0|1  1|1  90.2k    528k  118 rs01  PRI Jul 16 02:54:44.546
    *0    *0   4110     *0     676   892|0  3.6% 75.3%       0 7.20G 4.02G 0|0  2|2  2.96m   16.6m  118 rs01  PRI Jul 16 02:54:45.516
    *0    *0   4181     *0     407   512|0  3.1% 75.5%       0 7.20G 4.02G 0|0  1|3  2.54m   15.8m  118 rs01  PRI Jul 16 02:54:46.517
insert query update delete getmore command dirty  used flushes vsize   res qrw  arw net_in net_out conn  set repl                time

    *0    *0   4448     *0     482   614|0  2.5% 75.7%       0 7.20G 4.02G 0|0  2|2  2.78m   16.6m  118 rs01  PRI Jul 16 02:54:47.517
    *0    *0   3883     *0     451   597|0  1.2% 75.4%       0 7.20G 4.02G 0|0  1|0  2.50m   15.4m  118 rs01  PRI Jul 16 02:54:48.518
    *0    *0   3995     *0     525   679|0  1.4% 75.5%       0 7.20G 4.02G 0|0  1|1  2.65m   12.7m  118 rs01  PRI Jul 16 02:54:49.518
    *0    *0   4415     *0     649   811|0  1.7% 75.7%       0 7.20G 4.02G 0|0  1|2  3.01m   15.4m  118 rs01  PRI Jul 16 02:54:50.516
    *0    *0   4804     *0     631   779|0  2.0% 75.5%       0 7.20G 4.02G 0|0  1|1  3.16m   18.0m  118 rs01  PRI Jul 16 02:54:51.516
    *0    *0   3573     *0     582   766|0  2.1% 75.6%       0 7.20G 4.02G 0|0  1|0  2.56m   12.9m  118 rs01  PRI Jul 16 02:54:52.517
    *0    *0     *0     *0       0     3|0  2.1% 75.6%       0 7.20G 4.02G 0|0  1|0   683b   39.1k  118 rs01  PRI Jul 16 02:54:53.516
    *0    *0     *0     *0       0     2|0  2.1% 75.6%       0 7.20G 4.02G 0|0  1|0   682b   39.1k  118 rs01  PRI Jul 16 02:54:54.516
    *0    *0   4032     *0     719   976|0  2.3% 75.8%       0 7.20G 4.02G 0|1  1|0  3.02m   16.7m  118 rs01  PRI Jul 16 02:54:55.519

一台2C  4G 的机器，为什么upsert能达到4000/s呢？这个得益于上面的模型设计，将每次从10个文档批量更新转换成了一次从一个文档中更新10次，这样的好处就是，磁盘和内存中数据交换的数量减少了10倍，大大节省了磁盘io的开销。

说到这里，有同学会问，既然MongoDB是内存数据库，而且，性能如此出众，那么如何在有限的内存中，处理庞大的数据呢？

下面我和大家介绍下MongoDB的eviction，MongoDB是如何将数据淘汰出内存，确保内存的数据的热点：

当cache里面的“脏页”达到一定比例或cache使用量达到一定比例时就会触发相应的evict page线程来将pages（包含干净的pages和脏pages）按一定的算法（LRU队列）淘汰出去，以便腾挪出内存空间，保障后面新的插入或修改等操作。

触发page eviction条件由如下几种参数控制，如下表所示：

参数名称 默认配置值 含义
eviction_target 80% 当Cache的使用量达到80%时触发work thread淘汰page
eviction_trigger 90% 当Cache的使用量达到90%时触发application thread和work thread淘汰page
eviction_dirty_target 5% 当“脏数据”所占Cache比例达到5%时触发work thread淘汰page
eviction_dirty_trigger 20% 当“脏数据”所占Cache比例达到20%时触发application thread和work thread淘汰page

第一种情况：当cache的使用量占比达到参数eviction_ target设定值时（默认为80%），会触发后台线程执行page eviction；

如果使用量继续增长达到eviction_trigger参数设定值时（默认为90%），应用线程支撑的读写操作等请求将被阻塞，应用线程也参与到页面的淘汰中，加速淘汰内存中pages。

第二种情况：当cache里面的“脏数据”达到参数eviction_dirty_target设定值时（默认为5%），会触发后台线程执行page eviction；

如果“脏数据”继续增长达到参数eviction_dirty_trigger设定值（默认为20%），同时会触发应用线程来执行page eviction。

 

下图可以看到，内存使用置换在合理范围之内：

图片

扩展处理：

1. 后期可以根据热加载的数据量评估，如果内存压力过大，可以扩容内存，或者做分片处理。

2. 开启读写分离模式，减少主库压力。

 

我们大部分数据库存储引擎在资源限制都是一个绕不开的问题，限制也会比较麻烦，一般都会借助第三方中间件之类的工具来完成，所以我们在考虑限制资源之前，可以从业务特征出发，结合数据库的底层原理，做好适合的模型设计，把限制变成充分利用。

作者：陈亮亮

MongoDB中文社区南京分会主席

远景能源集团数据库架构师，曾任UCloud负责UDB MongoDB的研发和运维工作，在数据库架构和调优方面有丰富的经验。

图片

来这里，点亮自己！

MongoDB中文社区北京大会将于7月31日（周六）在北京市朝阳区举办，点击报名：https://sourl.cn/fWyXBY

加入MongoDB北京交流群：添加小芒果微信，并备注：mongo北京

MongoDB中文社区技术大会议题征集中，打开链接来这里分享经验与见解——

https://sourl.cn/f7Bgsf

活动资料发布消息订阅：

https://sourl.cn/DgdiNd

报名MongoDB免费线上培训：

https://sourl.cn/EtVUrP

我们还将继续在上海广州深圳南京等城市举办技术大会，有合作意向请提前联系小芒果微信或社区核心成员。

图片

MongoDB-全球领先的现代通用数据库

点击访问MongoDB官网www.mongodb.com/zh

图片

Tapdata-异构数据库实时同步工具

点击访问Tapdata官网https://tapdata.net/

Mongoing中文社区 MongoDB中文社区微信公众号

图片

扫描关注，获取更多精彩内容

社区网站www.mongoing.com

AD：【希望获得更专业的 MongoDB 数据库技术支持？】点击这里 → 提出的您的疑问或需求
赞(7)
未经允许不得转载：MongoDB中文社区 » MongoDB大数据量模型设计最佳实践

xiaomangguo

相关推荐

评论 抢沙发

评论前必须登录！

 

强力推荐

回放视频|MongoDB 使用规范及最佳实践线上直播来啦！

回放视频| MongoDB 可调一致性

Tapdata | Tapdata 开源社区

回放视频|mongo的时序新特性

MongoDB技术大会议题招募中

 

中文社区公众号

MongoDB 同步/迁移工具

友情链接

MongoDB官方

Tapdata 实时数据融合平台

Tapdata Cloud 同异构数据库同步工具

语音之家