浅谈 MongoDB 在数据中台实践中的优势

数据中台现在已经是一个被炒得很热的概念。

的确在大数据、移动互联网的背景下，企业在面对业务创新时，数据准备和使用成为了开发和运维者的心头之痛。

为此，数据中台概念应时而生，带来了解决思路。

但是，层出不穷的数据中台解决方案和产品，他们的设计和架构是有着本质区别的。

今天，并不罗列他们之间的不同，而是跟大家讨论一下MongoDB与生俱来的属性在数据中台实践中所带来的优势。

特点变成优点，是因为匹配需求

在讨论MongoDB的属性成为优势之前，先来解释一下数据中台的本质。

数据中台的出现，是因为企业在面向客户的业务创新时，后台跟不上前台的脚步。

我们先定义下前台和后台。

前台：由各类系统组成的前端平台。每个前台平台就是一个用户触点，企业的最终用户直接使用或交互的系统。例如网站、手机App，微信小程序等都属于前台范畴。

后台：由众多系统组成的后端平台。每个后台系统一般管理企业的基础或核心资源（数据+管理逻辑），例如财务系统，产品系统，客户管理系统，仓库物流管理系统等构成了企业的后台。

前台的特点：轻、快、短；

后台的特点：重、慢、长。

企业后台因此往往并不能很好的支撑前台快速创新响应用户的需求。后台更多解决的是企业管理的效率问题，而前台面临的是企业经营的创新挑战。

根据Gartner提出的 Pace-Layered Application Strategy理论，如果企业是一台引擎，那么它的后台基础数据资源和前台创新业务应用这两个齿轮的速率是不一样的。后台基础应用慢而长，需要稳定可靠，而前台业务应用快而短，需要快速响应。这种齿轮速率的”匹配失衡”最终拖累引擎的表现。

而数据中台就象是一个变速齿轮，在其中很好地协调前后台，让基础数据资源顺畅地流向用户，同时更好地服务于前台应用的创新。

MongoDB为数据中台而生

MongoDB与生俱来的特点可以很好地帮助数据中台的方案和产品快速落地实践。

自然的文档结构

MongoDB的文档模型与面向对象的数据表达方式非常类似，充分体现了创始人Eliot Horowitz的理念“Make developers more productive”，“让开发者更高效”。

与关系型数据库中table里面的每条row格式不同，MongoDB的document中可以嵌入数组和子文档，就像程序中的数组和成员变量一样。这在关系型数据库中是无法想象的。实际中我们经常看到一对一和一对多的数据。比如，一张保单下面的地址，包括省、市、区、街道和门牌，作为一个子文档，与保单的信用卡地址很容易区分开。更方便的是，嵌入的数组和子文档之上可以直接建立索引。当然关系型数据库理论很严谨，然而对于开发人员来说，他们用着方便才是最重要的。

灵活和速度

Join是SQL语言的高频词。常常为了进行一个查询，Join多张表的数据，而每一张表都对应着磁盘的读取。而上面谈到MongoDB的文档模型，将数据放在一个地方，一次读完，所使用的机器资源完全不同。

其次，在关系型数据库中，如果在某个表中增加一个字段，那么从数据表到应用数据层都要改。虽然有些工具可以利用，但这仍然是一个相当复杂的工作，尤其在更新产品线上数据库的时候。MongoDB数据的多态性polymorphism，不需要在数据库上大费周章，只需要在应用层面做一些工作。

基于文档的灵活的数据模式，对于数据模型多样或多变的业务场景，相比关系型数据库，无需使用DDL语句进行表结构的修改，相比其他Key-Value数据库，由于MongoDB的Value字段对于MongoDB是非透明的，可以对其建立索引，还可以进行全文检索，在查询效率上更具优势。该模式在游戏、电商、社交、视频直播、物流等领域非常适用，通过在用户或商品中嵌套不同用途的子文档来实现快速查询。对于监控、日志数据存储，第三方信息抓取等场景也同样适用，因为不同监控数据、日志记录、抓取的数据所包含的字段往往是不一样的，某种程度上说也是不可控的。同时，灵活的模式对于类似游戏市场活动、移动App等要求快速开发上线但需求变动（导致数据模型变大）比较大的产品或场景也比较适用。

快速部署、按需扩展

MongoDB的复制集是数据库领域领先的高可用和读写负载均衡解决方案，提供了数据自动（异步/同步）复制能力，一个新节点加入到复制集中会自动进行数据初始同步随后使用oplog进行增量复制，无需人工干预；如果复制集的Primary节点发生宕机，MongoDB会自动进行主从切换，在复制集大多数节点在线的情况下，能够基于Raft协议（MongoDB 3.2开始，之前版本不未使用Raft）自动地快速选出新的Primary并恢复读写服务（在选主期间，无法进行写操作），无需人工干预；MongoDB运维人员所需做的仅仅是将宕机节点重新启动，若宕机的是Primary，则重新启动后，会自动进行数据回滚并最终成为复制集的Secondary节点（正常情况下）。在复制集机制下，还可以通过对节点进行滚动处理的方式进行在线维护升级。

所以，相比目前的大多数关系型数据库，MongoDB复制集实现了自动复制和故障切换，大大减低了运维复杂度，解放了DBA。如果你对数据的持久化和可用性有较高的要求，MongoDB复制集是上佳的选择。此外，复制集还提供了Write Concern、Read Preference、Read Concern和Tag sets等读写行为控制功能，不同的业务应用类型可以参考官方手册（https://docs.mongodb.com/manual/applications/replication/）根据对数据持久化、数据一致性和可用性的不同要求进行灵活地设置。最后，MongoDB是为大数据而生的，提供sharding机制用于实现业务的水平扩展。每个shard都保存业务的一部分数据，shard可以配置为复制集，确保shard上数据的高可用性，shard内部由一系列连续的chunk组成，chunk是某一片键区间内的数据记录集合；mongos用于业务请求的路由，将业务负载分摊到不同的shard上，此外mongos还会对shard上超过一定大小的chunk进行分裂（split）；根据不同shard中数据量的大小，在shard将进行chunk迁移（migrate），应该说sharding提供了完善的业务数据和负载水平扩展的机制，对于物联网、日志系统和监控系统这类包含TB级海量数据的应用场景，使用MongoDB sharding是个不错的选择。

在生产环境中，sharding并不是必须的，并不是新业务起来的时候就马上部署sharding集群，只有当业务的数据量达到单个复制集无法支撑、或者业务的负载超过了复制集的服务能力的时候，才考虑部署sharding。

上述罗列的优势，只是理论上的阐述。有同学会问，实际的案例有吗？有。

MongoDB中文社区在今年5月份南京的活动中介绍了Tapdata数据中台在南京秦淮教委的智慧校园创建中的应用。钛铂数据中台所使用的正是MongoDB。Tapdata DaaS数据中台产品在应用中，帮助区教委项目快速落地，保护了先前投入，同时在项目初期的时候，实施的成本为此也低了许多。日后当应用量达到一定量级，MongoDB复制集可以平滑升级到shard，所以当你真正需要sharding时，可以参考官方文档（https://docs.mongodb.com/manual/tutorial/convert-replica-set-to-replicated-shard-cluster/）进行操作，文档中提供了详细的升级步骤。

数据中台应需求而生，而MongoDB参与的数据中台架构方案，简单便捷，帮助企业前台业务创新快速落地。同时节约成本，保护了先前投入，并且在起步阶段的硬件投入相当低，随着日后数据量的增加，可以按需配套扩展，而这一切基于MongoDB的特性是无缝衔接的。