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

2019-12-20 10:00

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

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

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

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

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


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

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

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

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

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

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

前台的特点:轻、快、短;

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

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

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

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


MongoDB为数据中台而生

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

多模数据库.png

自然的文档结构

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的特性是无缝衔接的。


推荐阅读

Tapdata 推出“钛计划”公益项目,着力打通数据孤岛助推社会数字化升级

为响应数据要素市场化配置改革政策方向的指引,Tapdata 推出“钛计划”打通数据孤岛公益行动,面向非盈利机构(如各城市政务服务数据管理局、社会公益组织/项目等)以及为社会培养数据技术人才的相关培训机构,提供 Tapdata 实时数据服务平台的特殊免费授权,助推公共领域数据互通、共享与实时应用......

Tapdata 钛铂数据的产品理念

Tapdata 是全球首个基于数据即服务架构理念、面向 TP 场景的企业实时主数据服务平台,可以帮助企业快速实现主数据的统一管理和发布,并为所有数据库、数仓、大数据平台提供最实时的源数据,让数据随时可用。

Tapdata Cloud 是什么?

Tapdata Cloud 是钛铂数据自研的异构数据库实时同步工具 Tapdata Replicator 的云服务版本,现在免费提供所有开发者和企业使用Tapdata Cloud 目前支持 Oracle、MySQL、PostgreSQL、SQL Server、MongoDB、Elasticsearch 之间的数据迁移和同步,未来将陆续上线 DB2、Sybase ASE、Redis、Kafka 等。

什么是数据即服务(Data as a Service)?

数据即服务(DaaS)是一种数据管理策略,旨在利用数据作为业务资产来提高业务创新的敏捷性。它是自 1990 年代互联网高速发展以来越来越受欢迎的“一切皆服务”(XaaS)趋势下关于数据服务化的那一部分,介于 PaaS 和 SaaS 之间。与 SaaS 类似,DaaS 提供了一种方式来管理企业每天生成的大量数据,并在整个业务范围内提供这些有价值的信息,以便于进行数据驱动的商业决策。同时,我们也...

什么是数据虚拟化(Data Virtualization)?

本文将简单易懂地介绍数据虚拟化技术及数据虚拟化软件架构的实现方法,尽量避免教条主义。如需要了解虚拟化定义,可通过wiki 百科了解。先引用一段百度百科的文字来说明数据虚拟化的定义:数据虚拟化(data virtualization)是用来描述所有数据管理方法的涵盖性术语,这些方法允许应用程序检索并管理数据,且不需要数据相关的技术细节,例如它格式化的方式或物理位置所在。正如百科的定义,采用数据...

Tapdata 数据库实时同步的技术要点

Tapdata 专注于实时数据的处理技术,在数据库迁移和同步方面,Tapdata 的表现非常优秀,实时、多元、异构,尤其在关系数据库到非关系数据库之间的双向同步方面,无论是从操作上,还是效率上,都体现了业界领先的水平。本文重点阐述 Tapdata 在数据库实时同步方面的技术要点。

教育中台与第三方系统对接整合数据案例

最近, 南京秦淮区教育中台系统,成功地和市系统进行了一次圆满对接。通过教育中台提供的统一数据能力和低代码API对接能力,实现了对市系统数据的实时推送和拉取,以及各类业务逻辑上的处理。这次对接为南京市中小学生创客大赛的成功举办提供了及时可靠的数据支撑, 体现了中台系统在快速响应业务方面的优越性。

周生生 | 全渠道商品中心建设

通过Tapdata 构建全渠道商品中心,实现: - 支持中国大陆港澳台的上千家门店的生产环境; - 使用JS脚本来进行流处理计算,业务需求从开发到上线过程快至 1 天以内; - 任务配置与执行监测全程可视化操作,不懂技术也能完成操作,极大降低维护成本; - 一套产品可满足不同需求,根据业务需求产出不同类型的业务模型节省大量人力物力。

关系型数据库到MongoDB实时数据同步解决方案

使用MongoDB作为主机下行或新一代数据库的选择,将业务数据从已有主机或Oracle等关系型数据库复制到MongoDB; 使用Tapdata Replicator的CDC技术,实时监听现有业务库的数据变动并同步至MongoDB; 使用Tapdata 的RDM技术将关系型表合并转型到MongoDB JSON数据结构,并保持和源库的高度数据一致; 在MongoDB上进行新业务的开发。

Tapdata肖贝贝:实时数据引擎系列(一)-新鲜的数据流

前言2006 年诞生的 hadoop 和 她周边的生态, 在过去的这些年里为大数据的火热提供了足够的能量, 十几年过去了, 场景在变化, 技术在演变, 大家对数据的认知已经不再局限于 T+1 与 高吞吐高延迟 为主要特征的上一代框架理念, 在真实的场景里, 实时, 准确, 多变 的数据也发挥着越来越重要的作用为满足这些新的需求, 各种框架和中间件如雨后春笋般不断涌出hive 的出现让这头大象...
联络我们:
Email:team@tapdata.io    电话:0755-26656080
深圳市南山区临海大道香江金融中心 2410-13
官方服务号
Tapdata 微信公众号
扫码关注