MongoDB爱好者
垂直技术交流平台

成功四步走:借助 MongoDB 从举步维艰到游刃有余

迁移原始数据势必改变现有状况。然而,企业机构对自身科技情况进行摸底后,往往会作出相同的决定:保持现状。这一点似乎情有可原,毕竟升级或更换 20 年以上的应用程序和数据库,谈何容易。不过除去每三年一次的硬件升级,还有许多优势,值得我们奋力挣脱固有羁绊,真正跨入 21 世纪。

有些企业之所以能够在动荡的 2020 年春季中乘风破浪,甚至脱颖而出,正是因为他们采取了更加灵活的使用模型,能够更为快速、稳妥地调整业务形态。MongoDB 的客户 Sanoma 便是其中一例。Sanoma 在保证服务的前提下,将用户量在 24 小时内从 3,000 扩增至 150,000。

创新与“推陈致新”是相辅相成的。虽然“推陈致新”可以在毫无创新的情况下勉强完成,但反向操作则不可能实现。

简要回顾

以在线数据层 (ODL) 或操作数据存储 (ODS) 整合数据,并不是 MongoDB 首创或独有的概念。访问原有系统、整合数据、简化访问,甚至在 20 年前就已成为业内共识,并引发对黄金信息源(即任何既定实体的明确主要信息源)的探索。但由于将数据从过度结构化的多种关系结构转向单个目标(称为操作数据存储 (ODS) 或在线数据层 (ODL))的过程中所遇到的重重困难,导致这样的探索很早就被证实事倍功半。行业内的首次探索是面向对象数据库,但最终钻进了 XML 数据存储的“死胡同”。(个人认为,Xquery 和 Xpath 从来不适合真正的开发人员。)两次尝试相继以失败告终后,又涌现出以 Apache 为首的浪潮,我称之为“Hadoop 解决一切”,参与其中的企业纷纷将全部的结构化数据导入大数据宝库之中。但令人惋惜的是,这样的举措换来的却是数据沙漠,而非众人所期盼的数据湖。企业机构不得不重建所失去的合理结构,同时还要艰难地构建二级索引、数据字典等等概念。

二十一世纪初期,文档模型融合 JSON 表示法,成为新的事实标准出现在公众视野之中。MongoDB 3.x 版本引入 ACID(原子性 (A)、一致性 (C)、隔离性 (I) 和持久性 (D))融合理念,广泛兼容各类数据类型(业内人士可能知道:BSON)。紧接着,MongoDB 团队开始推行关系数据库遗留的额外功能:二级索引、ACID 事务,以及数据的聚合、物化视图、join、union……等等。

聚焦当下

MongoDB 文档可在不触碰内容的情况下,通过多种不同方式和渠道进行扩充,这便保障了所有数据和数据沿袭的一致性。典型示例是从供应链应用程序中提取交付地址,以及从企业资源规划系统中提取账单地址。在大多数情况下,两套系统会有不同的要求。但 MongoDB 文档能够保留两套系统,甚至将多个任一系统关联至单个客户设定,无需完成负载和转换、外部键以及关系过去的所有其他要素。MongoDB 能够轻松添加和利用其他资源,而不损坏相关上下文。

MongoDB 可以实现 ODS 和ODL 体验,同时简化原有应用程序代码的更换过程,压缩所需时间。至此,迎来了真正实现“推陈致新”和创新的数据平台!

经验分享

整个过程可总结为四步:

1.摸底:何处为起点,才能最快实现价值?

2.搭建:如何从现有平台中提取数据并转移至新平台?

3.编码:如何进入调整和改进应用程序的领域?

4.创新:企业要想实现真正的创新,最应该从哪些方面入手?

下文将回答上述四个问题,助力您探索更优解决方案的新局面。

第一步:对现有解决方案进行摸底

数据供给

数据供给是该步骤较为容易的部分,指的是将数据从源系统转移至目标系统。最佳手段可能不尽相同,但绝大部分实现实时数据流的现有模型均可以优化流程,从实时复制到 .CSV 文件批量通讯,制定业务驱动型决策。

打造应用程序

最激动人心是打造应用程序的阶段,包括初始数据域的选择和设计。对此,从经典的优先级概念衍生出的简单机制(早在计算机之前便已存在)能够起到助推作用。

数据域已存在于业务逻辑对象中,以不同的编程语言通过对象进行呈现。不过,即便是最优秀的应用程序开发人员,在应对层出不穷的变化时,也会对这些对象进行取舍,导致原始设计变得模糊,对象也会显而易见。发掘这些“宝藏”,并遵循 ODS,是走向真正“推陈致新”至关重要的一步。

事实上,最简单也是最实用的解决方案:使用现有软件加载一个对象,并将其持久化至 MongoDB 集合。持久化对象可使用两行代码,能够轻松完成添加。两行代码(第一行创建与数据库的连接;第二行持久化对象)的位置并不重要,只要位于对象创建之后即可。届时,您将第一次见证 MongoDB 和 MQL 的优势所在。您无需就对象进行任何操作,例如无分解或抽象层。MongoDB 会替您完成相关操作。在 MongoDB 数据库中观察对象时(如使用 MongoDB Compass),您将会发现,此时的对象已具备所需的域对象之雏形。届时,将对象映射至域或域子集的任务会借由应用程序用例完成。

贴士:如何利用应用映射加速打造过程

在下方模型(虽然属于金融业,但可快速实现跨行业使用)中,我们会识别不同应用程序中的数据域,并将其行为映射至定位所需得代价及其对应用程序的重要性。

首先,各域会依据对象的复杂程度获得一个评级,其中“复杂程度”由执行团队进行定义。这一点类似于sprint开发过程中的“poker”。其次,各数据域必须位于应用程序内容中。最后,进入记录时间。

正如上述案例所示,排程的概念看似简单,却会被客户设定所代替,更像应用程序上下文(剧透:最终总是会成功)。基于复杂度融合以及影响应用程序的数据域量,我们可轻松实现下述模型。

第二步:搭建

“搭建”指的是建筑一座让人跨越的桥梁,并在完成跨越后随即消失。其中关键的部分是让人跨越过去。原始系统和新数据平台之间的连接也是如此。

起始阶段,我们将数据存储在 MongoDB 数据平台。如果数据限于新应用程序,并且仅出现在 MongoDB 中,则无需进行任何操作。不过,如上方的客户设定示例所示,可能存在需要处理的依赖关系。借助微服务以及数据初始加载所使用的相同概念,可轻松实现原始数据库和 MongoDB 新平台之间的同步。此外,如果起始阶段需要“读取”数据,或已处理“写入”,并且同步要求回写至原始系统,那么也可实现同步。

●  流处理:基于流处理的解决方案适合于单向操作,以最简单的方式允许只读。

●  服务:对于需要选择性写入数据的用例,可采用简单的微服务。它借助 MongoDB 侧的文档模型,但仍能将必要的更新回推至原始系统,反之亦然。其中的好处是,这种服务存在已久,在原始应用程序中只需要使用旧的数据库界面,而在 MongoDB 中仅借助易于处理的新 JSON 文档格式。如果两个数据库均符合 ACID,那么任何事务均会在两侧被自动视作普通的应用程序交互。

● “Y-Loader”:另一种选择是真正的“Y-loader”,所有事务会平行同步写入两个数据库。仅当两套系统报告提交并完成后,才会认定实际事务已提交。虽然两段式协议(写入两者,等待五秒钟,读取两者以验证,如同步,提交至应用程序)作为现成服务,出现在多种分散式事务协调器中,但应用程序中现有的数据访问权通常更具操作性。在此情况下,MongoDB 新数据路径可并行,冗余检查点(应用程序逻辑本应该为原始路径设定)也会因此而延展。

第三步:编码

使用新域数据模型编码,MongoDB 灵活文档模型作为基础,会对业务逻辑和应用程序开发编码立即产生效果,可谓“立竿见影”。数据随着 MongoDB 集合编码对象的初始延续而逐步解锁,使得开发人员能够基于业务要求同时进行编码。借此,开发人员将打破对象映射器的参照和要求。对象会通过 MongoDB 惯用驱动器进行呈现,各编程对象也将直接出现在数据集合中;反之,业务逻辑对象的任何变化也将在 MongoDB 集合中得到自然呈现(无需编码)。

单靠一篇博文,无法解决所有开放式问题和边缘案例。每个应用程序、客户和数据界面都有各自的特点。存在历史性技术负债和隐含假定的数据库,将随着时间的推移而演变成开发人员的集体损失。“千万别动这个部分,我们对此知之甚少,尝试过一次,真的是一团糟……”同事间闲聊时经常会听到这样的“忠告”。但应该从中学到什么呢?实际上,可供我们使用的模板多种多样,并且有很多简便的途径通往成功。

例如,有一位德国客户,尝试融合 IBM DB2 和 Hadoop 而不得解。但得知能够通过微服务逐次“提升”数据后,一切便迎刃而解。这样一来,某些请求查询中“不可能实现”的业务要求,在概念验证的一周时间里,即可“轻松实现”,并且无一例外,日常工作中便能够完成此类用例和更改。这也验证了马克·吐温的一句名言:“领先他人的秘诀就是行动起来”。

第四步:创新

随着原始环境迁移的逐步展开,创新将成为新的重点。

解锁此前的孤岛数据,能够让实时数据和机器学习平台实现快速耦合,满足多种用途:例如,助力金融决策制定,零售业的个性化,或优化物联网环境中的生产过程。拥有打破束缚的数据,便可轻松创建新应用程序和解决方案,即便采用的是多种编程语言、MongoDB Charts 创建的直接实时仪表板,以及不同的范式(MongoDB 惯用驱动器再次彰显魔力!)。

届时,与您的小组和团队中的产品所有者谈话时(真正的“推陈致新”),便可直接提出“最需要更改的组件是什么?”和“哪项功能可以促使这种更改?”等问题。

有人会问:这种漫长的等待,值得吗?但真正的问题在于:为什么不更早一些开始呢?面对那些期盼已久而不得的各项功能,是时候采取行动了。MongoDB 团队将助您乘风破浪。

立即联系我们,共同商讨最佳方案。


添加小芒果微信(ID:mongingcom)进入中文用户组技术交流群。

赞(0)
未经允许不得转载:MongoDB中文社区 » 成功四步走:借助 MongoDB 从举步维艰到游刃有余

评论 抢沙发

评论前必须登录!