NOSQL 怎么翻盘，降本增效为企业节省资源，--DTCC 通过NOSQL给企业系统瘦身

liuaustin32026年08月24日约 12 分钟

NO❝
开头还是介绍一下群，如果感兴趣PolarDB ,MongoDB ,MySQL ,PostgreSQL ,Redis, OceanBase, Sql Server等有问题，有需求都可以加群加群请联系 liuaustin3 ，（共3400人左右 1 + 2 + 3 + 4 +5 + 6 + 7 + 8 ）(1 2 3 4 5 6 7 8群已经爆满 9群为纯聊天群，默认不加入不得发广告，自己公众号文章链接等，发一次直接踢，默认加入8群，开10群PolarDB专业学习群115+)

大家好，我是本次话题的主讲者，刘华阳。本次要给大家带来的话题是，通过NOSQL 给企业系统降本增效。

在开讲之前，我有几个问题想留给当前的参会者。

1 为什么是NOSQL能给企业降本增效

2 为什么我没有说企业数据库系统，而是企业系统的成本

3 在您听完此次的话题后，您认为降本增效中，NOSQL是起到了技术的作用，还是重新规范了开发软件的方法，从而引导了企业系统的降本增效。

好的，下面我们来开始进行相关的讲解。

在每一项技术的革新和变革的过程中，都离不开一件事情，就是顺应当前社会，经济，企业，以及技术的状态。2026年对我们来说一个是特别普通，但又特殊的年份。

2026年很多人选择了低功耗的工作模式，企业也选择了更加节能的方式进行发展，这是我们现在还在社会上工作人的一个共识。

在爆发式增长的阶段结束后，更多的企业开始思考当前的应用系统的成本，这里包含了研发成本和运营成本，甚至现在一些企业将AI运用TOKEN 也列入了成本的列表中。

说到这里，我先做一个自我介绍，先让大家对台上的讲解人员有一个了解，我个人在数据库行业中工作，22年，我个人比较精通的数据库产品有 sql server , MySQL, MongoDB, PostgreSQL 以及 PolarDB 等数据库产品。具有相关的证书和荣誉。

同时我也是一个跟得上形势的半个技术人，另外半个我是一个搞媒体的媒体人。除了数据库的相关认证和荣誉以外，我还有中国广播电视培训中心颁发的全媒体工程师的认证，以及互联网营销师的认证。旗下有两个公众号和两个抖音号。

如果大家对我不是很熟悉，我呢唤起大家的一些记忆，平时在众多数据库群里，打快板的那个人就是我，所以今天不例外，我还是要在打一段。

其实我是一个特别实际的人，一个数据库如果用的好好的，企业用的顺畅，DBA管理的方便，就可以了，我没有必要去研究通过NOSQL去降低应用成本的问题。企业还是花得起那几个钱来支撑业务中的数据库运营的。

而现在经济不行了，我们遇到了经济大萧条，企业外扩不行了，必须要进行内收，如果此时我们还一味的研究技术，不听企业的呼声，那就是白玩。

企业现在第一个关键，或者心声就是用更低的成本活下去。我们在使用互联网经济繁荣时期的，垂直加主机的配置，用尽力气对SQL进行优化耗费人力，或者通过横向增加MYSQL 进行业务的逻辑分库，或直接分库分表降低单库的数据量的方式，正在走向尽头。

企业无法承载业务不增长，但数据库由于数据库量的问题，在持续用各种方案进行扩展的事情。

有一些企业做出了一些决定，比如合库，将不同的业务从多个物理库，进行合并来降低数据库的授权费用，和硬件支出。 DBA 也在尽力的优化SQL来降低烂SQL对资源的消耗和影响，从而间接的降本。

大家发现一个问题吗？数据库的添加不是我们造成的，是业务，是开发，是架构导致的，而数据库的成本治理的关键端在DBA，在数据库工作者身上。

合理吗？不合理，在传统数据库为基础的开发中，DBA很少能参与到数据库的系统的开发和设计，传统数据库为基础的系统，DBA很难再发挥降本增效的作用。

怎么办，我们要变换思路，通过改变应用使用和开发引用使用数据库的方式来进行降本增效的工作，

怎么改变开发的方式，NOSQL 和关系型数据库开发有什么区别，这里我们直接抛出开发的区别性。

1 基于NOSQL这里我们找一个实体，MongoDB 为基础的数据库系统，开发应用开发的模式叫，关系前置，或者我们还可以说性能前置，访问前置，查询前置。

2 传统数据库在设计中是以三范式为基础，数据为优先，数据的提取和写入基本上在设计的时候，开发很少去考虑，或者有限考虑。最终会导致如下的一些问题。

1 随着业务的扩展，查询不同的数据，字段的添加，等等，都会导致表的空间膨胀，索引的增加，直接关联项就是读取到系统内存中的数据量越来越多。系统必须扩展内存和CPU。

2 随着数据库变成重资产，所有的数据都要有关联项，也就是表和表之间的关系，表如果和表之间没有关系。将无法查询，随着表的数据量越来越多，提取数据将变得越来越困难，多个表进行JOIN的方式，将大量消耗CPU。

最终的结果，

1 数据库的归档

2 数据分库分表

3 增加硬件配置

成本上升。

那么我们从数据库的原理上就可以解释为什么传统数据库消耗的资源大。我们就从核心点多表的JOIN入手，我们看一看，为什么传统数据库耗费资源。大家看图，1 2 3 CPU除了处理要处理数据本身，还要协调数据的 IN OUT ，以及处理中间的临时数据的写入落盘和提取，这些都是需要CPU进行上下文切换的。

说完这么多，我们把问题都梳理清楚了，因为传统的开发方式和方法，DBA无法介入，将数据的提取和处理完全的中心砸在数据库中，在这样的核心理念的指导下，数据库成为IT业务系统中，运营管理中的成本消耗主体。

既然我们要说到降本增效，就必须的有标的物，我们以互联网上最盛行的关系型数据库MySQL作为标的物，可以从上面这张图看，MySQL的优势在于MongoDB相比较，唯一有优势的是聚合查询，我们成为复杂查询。

如何通过MONGODB给企业业务系统瘦身，第一个关键的问题我们要明白什么可以什么不能，以下的我们列出来的业务系统都可以转到MongoDB中，比如我们最常见的订单系统，物联网探针系统，一些存储大量评论的系统。

我这里还单独列出来一个聚合系统，对就是刚才我们说到的，不适合在MongoDB中进行操作的聚合操作。

有的同学说，我其实对NOSQL数据库的应用的研发和设计也不是特别清楚，我应该怎么办，这里我开发额一套小的判断系统，他是以一个询问你当前系统状态的方式来逐步判断你的传统的系统到MongoDB 上应该使用的方式。通过你不断的回答一些你当前系统的问题，系统会最终给你推荐你当前在MongoBD开发应用系统表的方式。

大家看下图，这里我们有明确的结果给大家，什么样的情况，什么样的数据量，什么样的原有的设计形式，从传统数据库到NoSQL设计最终的建议模式，与简单的样例。

下面我们直接将案例：拿上来首先这张图是一个非常明显的MonogDB 的collection，也就是我们所说的集合。集合当中有嵌套，和数组通过，嵌套和数组的利用我们将原有不同的表中包含的数据，或者同一张表里，多行的数据并进了一个collections。

那么如果不在MongoDB 做这些事，还是使用传统数据库上做这个事情，大家看上上图，6张表，我们可以算一算，我们会比mongodb 多5个主键，最少6个索引，表和表之间的连接需要连接内存，这比MongoDB 多用多少内存，在数据进行UPDATE的时候，一个访问要打开六个文件，而MongoDB 只打开一个文件，整体的系统消耗会降低很多。

说到这里，有些同学会有问题，普通OLTP迁移到MongoDB 会比较简单，但涉及到聚合操作是不是一点没有办法。

下面我们在举一个例子，大家看这是一个典型的单表做聚合的情况，这里我们需要在查询的时候，给出每一天聚合后，多天的数据的集合。

这里我们使用的是一个预聚合的方案，那么什么是预聚合的方案，我们还要说起，MongoDB的设计思路，关系前置，如果是关系前置我们的计算在业务逻辑允许的情况下是可以前置，当然就可以前置了。

比如我们是否可以建立一个预聚合的文档，对于我们要最终聚合的文档进行提前计算，比如我们订单要计算前一天的消费额，消费额是对于昨天是一个不变的数字，我们只要转天，对于昨天消费的金额进行一个提取然后在程序段进行一个累加即可，最后将结果写入到预聚合的文档内，这个就是昨天的的消费额的预聚合文档。如果我们查询的时候

我们参见上图我们只需要查询出对应每天的文档即可，因为数据是预计算的，所以不存在使用CPU在进行计算的过程，而提取聚合数据就是遍历文档，并展示文档的一个过程，基本上CPU没有大的计算。

我们看上面的这个图，原有的计算方式是整体计算然后展示，而MongoDB的算法是将每个最终展示的数据拆出，然后在每天进行计算，最终组成需要展示的数据，直接提取即可。

这是要给分时计算，充分平摊计算方式的聚合方式，也叫预聚合。其中核心的原理就是分时，将在短时间需要进行数据聚合的工作，平摊，均分，数据量均分了，计算的时间也均分了。

这样会大大降低CPU 内存和 IOPS 的在瞬时的需求量，那么这里有人会问，到底使用了mongodb 相对于传统的数据库体系会节省多少资源，我们引入官方的一个对比过程和结果。

这里引用的是一个第三方的开发的网站的一个MONGODB 和MYSQL的比较，具体的比较结果在同配置 6核心，20G HDD的磁盘的系统上，MongoDB 采用于MySQL完成同类型的业务，写入的速度快了67% ，查询的速度快了98%。

那么在实际的工作中我们怎么去做这件事，这是本次话题的一个关键，技术我都会，我就是推不动的并不是少数。

下面我们给大家一个方案，来说说怎么推动这个事情，第一自己要清楚的知道，哪些业务常见不适合，哪些业务场景是适合的。

找到合适的业务项，我们针对其中一个核心的部分，比如数据的插入，我们做一个简单的DEMO，通过简单的压测我们先得到同样数据情况下的指标，比如在同等的数据插入下，多少情况下MySQL无法支撑，MongoDB在多少情况下无法支撑，二者的数据库的业务支撑的差在哪里。

除了在数据读写上的差距，在系统的稳定性上以及高可用上，MongoDB相对于传统数据库还是有甚多的优势，这点我们也可以作为一个推动项来进行总结，如果当前的系统中有类似的问题，可以进行补充。

最后不要为了迁移而迁移，一定要有真实的需求和痛点，比如我们找到对应的企业正在为数据库成本发愁的项目，或者新的项目等，来开展相关的工作，切记不要直接硬套。

所以我们这页也是在说这个问题，我们在测试中，项目的实现中要确实的让项目看到同样的业务逻辑，在MongoDB上跑的更快，更好，同时提供对应的一些设计知识，给到开发共同发展。

在发起相关的工作前，应该先让在一些公司级别的评审会或者项目会发表一些对降本增效的看法或者想法，作为工作前的一些铺垫。

这里我们也给大家一个简单的对比的成本优势的对比方法比如我们得到认可进行尝试的情况下，我们对同样业务（某一个模块）进行针对两种数据库的开发代码进行压测，通过业务API进行压测，比如我们在测试完成单向100个任务的情况下，两种数据库CPU消耗的时间是多少，通过多的减去少的，我们假设MySQL完成任务的时间长，MongoDBD的时间端，将其相减除以时间长的，就是MongoDB节省的时间。

在这样的情况下，我们可以针对3-5个关键的业务进行对比和测试，最终计算出一个平均的MongoDB 在同样的业务情况下节省的CPU单位成本是多少。

另外我们也可以从其他的部分入手，比如计算锁，死锁，BLOCKED的触发情况数量，等我们可以测量的部分，通过这些来说明我们在更换了数据库系统后给我们整体业务系统带来的改变。

斧正我们更换数据库给企业带来的利益，和优势。

除此以外我们还可以通过MongoDB的一些新技术特性来对一些适合的业务进行比对，比如MongoDB 最近推出的针对时间序列的处理方式，更多减少存储的数量，提高计算能力的部分，对特别适合MongoDB的业务进行一个争取。最后我们通过一些特性比如数据的压缩模式，针对同等量的数据进行一个数据存储的比对。

之前我们说过的数据存储的特性和有点等，对我们之前的提及的一些MongoDB的综合优势进行列出，如降低表的数量，整体降低了数据量，索引量，在业务进行运行时整体节省的资源，如内存，磁盘等等。

最终我们可以估算出使用MongoDB和传统数据库对比后，到底节省了多少资源，或者我们可以算出，同等硬件下，我们可以有多少业务的增量在在传统库上需要加库，而在使用NOSQL数据库后，不需要。

说完这么多从传统数据库到NOSQL的优势，我们在说说其中的一些问题，比如开发问订单或类似的系统在设计中，一些技巧，在订单中，如果有频繁进行更新的业务数据，是否要和静态的数据放到一起，比如物流信息，物流信息会在订单中体现，但这个部分不应该放到订单信息，它应该单独放到一个单独的collections ，在调用订单时可以进行挂载。这样就可以避免页，最大化避免页分割。如果设计不好，后期会出现Update 操作极其耗时的情况。

同时在开发设计系统的时候，我们数据库人员还可以关注一些MongoDB中的设计规范，比如Key也就是键值设计的特别长的一个问题，尤其是这里没有如二维表格一样的字段大小的限制。同时值也可以进行一些精简的方式，比如对一些特性的固定的值，我们可以用替代法，让他用更短的文字来表达，而不是全部表达的方式，来最大化精简系统的负担。