MongoDB 学习建模与设计思路--统计数据更新案例

AustinDatabases 2025-01-15

开头还是介绍一下群，如果感兴趣PolarDB ,MongoDB ,MySQL ,PostgreSQL ,Redis, OceanBase, Sql Server等有问题，有需求都可以加群群内有各大数据库行业大咖，可以解决你的问题。加群请联系 liuaustin3 ，（共2700人左右 1 + 2 + 3 + 4 +5 + 6 + 7 + 8 ）(1 2 3 4 5 6群均已爆满，7群400+，开 8群 9群)

最近在读萧少聪老师翻译的书，MongoDB DATA MODELING AND SCHEMA DESIGN,主要是关于如何对数据建模的部分，当然这里建模是有倾向性的，是对于NOSQL的部分进行数据建模的一些理论和案例。

同时也找了另一本书,对比着看，NOSQL 与 RDBMS的建模之间的差异点在哪里。

先说相同点 1 其中的一些相同都具有的固定的概念实体，关系，属性，数据模型的三个层次，业务需求或叫做业务术语，逻辑概念或者称之为逻辑数据建模，以及都有的物理数据设计。

其中实体指的是具象化的数据本身，且可以进行归类的数据实体，通过第二个递进的关系，将实体和实体之间进行关联，关系一般分类为，一对一，一对多，多对一，多对多。

在进行细分的情况下，一对多中可以分为一对多，一对少，一对巨多的关系。关系的拿捏对于传统数据库和MongoDB这类数据库都十分的重要，相对于传统数据库，这里关系对于MongoDB更重要，起因在于MongoDB有更灵活的设计模式。

这里我们画一个表格

关系与设计 MongoDB
一对一关系推荐使用键值对嵌入到文档中
一对少关系推荐使用嵌入式文档
一对多关系根据“多”的一方的数量选择嵌入式文档或引用式文档
一对巨量关系推荐使用引用式文档，并将关系信息存储在“巨量”的一方
多对多关系推荐使用引用式文档，并在双方都维护关系信息

一对一关系：一个实体只与另一个实体关联。

例子：一个员工只在一个部门工作。

一对少关系：一个实体与少数几个其他实体关联。

例子：一个用户可能有多个地址。

一对多关系：一个实体与多个其他实体关联。

例子：一个产品可能包含多个零件。

一对巨量关系：一个实体与海量其他实体关联。

例子：一台服务器可能生成大量的日志消息。

多对多关系：多个实体与多个其他实体关联。

例子：一个用户可以拥有多个任务，一个任务也可以分配给多个用户。

其中建模的的三个过程，在NOSQL 和 RDBMS 之间也是有名词的区别，RDBMS 中的三个过程是概念，逻辑，物理，NOSQL的三个过程为对齐，细化，设计。

最终的目的都是为了完成业务的需求，业务数据的存取和提取。

在对实体的描述中，RDBMS 和 NOSQL 之间并无太大的差异，而到了逻辑或者称之为细化的时候，两者的差异才显现或者是有较大的不同。

在RDBMS的逻辑实现中，通常我们的设计人员可以没有数据库的经验，他根本不管你用的数据库是SQL SERVER 、ORACLE 、 PostgreSQL ，他们关注的是怎么通过LDM来实现业务的目的。

而MongoDB的数据库对设计人员的知识水平明显要更高一些，因为这些设计人员要懂得，业务中的主体是更倾向于写数据，还是读取数据，这也是需要关注的环节。比如我们要关注的查询的频率，结果的延迟，数据量，数据写入的速度，数据的更新等等。

举一个简单的容易让人理解的说法，传统的RDBMS数据库是一个做好的汽车模型，你需要将这个汽车模型放到该放的地方即可，而NOSQL数据库则是“乐高”，他需要你有更多的数据库知识，将一块块的积木打造成你独一无二的汽车模型。

如何打破原有的传统的RDBMS理论中的一些概念如三范式，外键，级联等关系的概念有助于你设计出一个更好的基于NOSQL的业务系统。

废话了这么多，我们举几个书中的案例，且和可以在深入一下。

以书中的130页的近似案例为模型：

比如有一个统计页面被读取的统计的需求，按照原有的传统的数据库思路，我们只要一个用户读取这个页面我们就在我们的表中对应的字段UPDATE+1 即可。

但这样的做法如果是一个比较热的文字，比如川普被枪杀的新闻呢。可能在瞬间就有几万，几十万的阅读量，此时传统数据库的UPDATE 可能会干冒烟了。

这样的设计方式的确是不合适，在MONGODB中我们可以采用近似法的方式，如一个页面的阅读量是否是一个不能差的方式，而是我们采用一个近似值，通过我们的应用程序的访问的缓存进行计数，通过间隔法来进行数据的写入到NOSQL中集合中。

缓存在10秒内获得的数字是1000以内，900以上，我们就写1000，缓存10内获得数字是10000以内 90000万以上，我们就写10万，以此类推，我们UPDATE到NOSQL中的数字的频率大大降低了，可以10秒进行一次数据的更新，但付出多大代价是我们的页面的阅读量并不准确。

但从业务的角度来说，这并不完全重要他要的是一个近似值，且10秒内有10万的阅读量也不是太可能，我们的统计的数字大概率是不会有太多误差的，但是，但是，但是，我们的数据库的性能稳定了，再大的流量我们的MONGODB 也能承受，且这就是一种NOSQL思路的设计方式，当然用到传统的数据库也是可以的。

同时我们可以在进行扩展，比如我们的页面统计的方法不同，比如一个页面要统计国家宪法的准确阅读的数量，那么我们可以将程序的中间值进行调整，通过增加属性的字段来告诉程序这个页面的统计的docuemnt误差值更低，那么在MonogDB中我们仅仅需要的是在一个所需要的Document里面增加一个key value，而在传统数据库里面，你需要再整个表里面添加一个字段，来说明我们统计的这个数值的误差率，如果你的这个表里面有1亿个行，就为这一个页面你要将9千9百9十九万9百九十九的行都加上这个字段。

此时MongoDB的灵活性就大大的体现的他的好处，我们就只需要的document来增加这个属性即可，其他的几千万行，根本就没有这个字段或者KEY VALUE。

后续会继续读这本书，将一些数据建模中MongoDB在数据建模领域中的一些灵活的思路进行学习，有一些思路是可以用在传统的数据库中，将数据处理人员思考的维度逐步拉升是最终的目的。

MongoDB 相关文章

MongoDB 大俗大雅，高端的知识讲“通俗” -- 2 嵌套和引用

MongoDB 大俗大雅，高端的知识讲“低俗” -- 1 什么叫多模

MongoDB 合作考试报销活动贴附属，MongoDB基础知识速通

MongoDB 年底活动，免费考试名额 7个公众号获得

MongoDB 使用网上妙招，直接DOWN机---清理表碎片导致的灾祸 (送书活动结束)

数据库《三体》“二向箔” 思维限制！8个公众号联合抽奖送书建立数据库设计新思维

MongoDB 是外星人，水瓶座，怎么和不按套路出牌的他沟通？

17000多张MongoDB表的锅自动分析删除表数据难题--从头到尾的处理过程（文尾有MongoDB开发规范）

MongoDB 插入更新数据慢，开发问哪的问题？附带解决方案和脚本