迁移原始数据势必改变现有状况。然而，企业机构对自身科技情况进行摸底后，往往会作出相同的决定：保持现状。这一点似乎情有可原，毕竟升级或更换 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）进入中文用户组技术交流群。