邹欣对话MongoDB CTO：新数据库时代将带来什么？

【CSDN 编者按】MongoDB CTO Mark Porter认为，在过去的几十年里，最大的变化在于数据在企业中所扮演的角色变了。在新数据库时代，MongoDB又该如何在众多新兴数据库中保持自身优势一往无前？Mark在本文中为我们进行了生动而形象的解析。

作者 | 侯菲艳     译 |  何雨

出品 | 《新程序员》

天下苦关系型数据库久矣。

在MongoDB诞生以前，整个工业界几乎为关系型数据库所垄断，其严格定义的数据模型让广大开发者又爱又恨。数十年间，虽有无数编程勇士试图用新的模型“扳倒”关系型数据库，但无一成功，直到Dwight Merriman、Kevin Ryan和Eliot Horowitz三位出现。因为关系型数据库无法按其需求扩展，所以他们毅然决然地写了一个新的数据库，也就是后来的MongoDB。

较之关系型数据库的复杂难用，MongoDB凭借灵活的模式和丰富的文档结构等特性圈粉无数，活跃的开源社区氛围获得了无数用户的支持。很快，MongoDB便一跃占据文档型数据库第一的位置，直到今天，它在DB-Engines排行中始终位居前五。

在本期《新程序员》中，CSDN副总裁邹欣独家对话MongoDB CTO Mark Porter，邀请他为我们分享MongoDB一路走来的成功秘诀，并对最近MongoDB新功能的发布情况展开详细而深刻的解析。

数据库也曾经历过寒冬期

邹欣：数据库行业已经发展几十年之久，也是最早的计算机应用方向之一，另一个早期的应用AI经历了三次行业寒冬期，那么对于数据库行业而言呢？

Mark：我认为数据库行业其实是经历过寒冬期的，第一次大概发生在20世纪60年代，那时候的人们还不知该如何管理数据，当关系型数据库随着E. F. Codd和他的理论出现时，数据库行业度过了这个寒冬。第二个寒冬出现在20世纪80年代末，人们不知道该如何大规模地查询数据，于是数据仓库挽救了大局。2000年左右，由于互联网的冲击，数据库系统必须扩展10至100倍以上，这也是一个巨大的考验，非关系型数据库和MongoDB应运而生。

有一个笑话，说大家以为 AI 的工程师们从周一到周五的早上8点至下午5点是在训练模型。但其实，他们真正在做的却是加载数据、清理数据，以及安装新版本的软件。

过去，人们95%的时间都花费在了处理数据的脏活累活上。但如果有更高效的数据库系统，就可以将自己50%或者更多的时间用来思考和数据相关的应用。

邹欣：你曾经提到“几十年来，最大的变化在于数据在企业中扮演的角色变了”，能详细说一下么？

Mark：以前的数据以联网交易处理为主，它是静态的、少量的。但现在，加上AI/ML和数据分析平台，我们每年能够收集高达29ZB的数据。

我在GrabTaxi（东南亚出行巨头）时，有600位数据分析师和AI/ML工程师，平均每天要进行400项不同的实验。我们通过实验数据分析城市里的红绿灯，比如它们是不是正常工作状态，以及红灯和绿灯什么时候进行切换，我们将这些信息同步给司机。这正是数据的神奇力量！通过这种方式，我们的运营效率从1%提高到了10%，进而又到了20%、30%、50%。因此我们相信，实时数据分析能完成很多事情。通过代码实时地进行数据分析并作出决策，是如今数据可以帮助我们提高效率的关键所在。

但同时还有一个不容忽视的问题就是，我们在亚马逊和GrabTaxi做的实验假设正确率远低于50%，即便有真实的实验数据，也无法得出百分百符合事实的准确预测，世界上仍然有很多我们难以预料的东西，需要我们不断地进行探索。

邹欣：是的，如果数据一团糟，无论模型有多好，输入输出的数据都只会更糟。我们必须花时间对数据进行清理，这些数据才能反映出真实世界的情况，否则一切都是无用功。

Mark：因此，我所任职过的这些公司处理这个问题的方式是一遍又一遍地建立模型。给模型一个特定的输入，然后根据输出训练模型，这样我们就能及时发现有可能引起奇怪反应的模型漂移或数据漂移。不过有时候数据确实会变得很奇怪，当我还在GrabTaxi的时候，由于人们的行为方式不同，有一次我们的模型警告居然全部都消失了，因此我建议大家在人工智能系统上使用人工智能递归来检测模型漂移，这能帮你迅速找到坏数据。

邹欣：有些人抱怨数据库不就是乏味的增删改查 （CRUD，即Create、Read、Update、Delete）么，对此你怎么看？

Mark：通过拥有一个数据库系统，可以让你更快、更可靠地开发应用程序，并在生产中更快迭代。要做好数据库系统，你需要了解软件栈的整个生态系统，和相关公司生态系统的背景以及可以产生的影响等，这是很有挑战的事情。我总是要求工程师们抬起头来，去了解你的技术将如何为这个世界做贡献，你可以成为一个影响世界的人，而不仅仅是CRUD。

MongoDB脱颖而出的秘诀

邹欣：在职业生涯中，你曾经加入过很多公司，现在为什么会选择加入MongoDB？

Mark：我从很早的时候就开始研究数据了，我觉得提交数据以及让它经历机器故障、网络故障、软件故障是一件很神奇的事情。我一直都自称Tech Geek。

大约在三年前，我和一个朋友（某关系型数据库的创始人之一）促膝长谈，我们一致认为现在的数据库仍然难以做到安全操作，它需要大量的数据库管理员来维护，浪费了很多时间和金钱。老实说，在那时我很沮丧，因为我已经六十多岁了，这个问题可能到我退休都没办法解决，直到一年后MongoDB邀请我加入他们的董事会。

MongoDB被定位成一个神奇的应用，这是从E. F. Codd开始人们就一直在寻找的应用，所以当时我欣然接受了他们的邀请。

邹欣：你认为MongoDB成功的秘诀是什么？

Mark：几个月前，我开始思考为什么MongoDB如此受欢迎，其中一个原因是我们不怕挑战现状。当初 Merriman、Ryan和Horowitz因为无法让关系型数据库按需扩展，所以毅然决然地写了一个新的数据库MongoDB。文档模型（Document Model）和灵活存储数据是MongoDB的关键要素，世界上没有一个数据库能在符合ACID（原子性、一致性、隔离性、持久性）的情况下，在分布式处理方面能有MongoDB一样好的表现。

根据分片模型（Sharding Model），我们发现有用户运行了一个超过1000节点的集群，毫不夸张地说，世界上没有一个关系型数据库的集群能超过16个，这会让计算机的运算能力达到峰值。在过去的十年里，CPU的运算能力没有进一步发展，分布式计算是唯一能对运算能力进行扩展的路径。

Oracle、SQL Server、PostgreSQL都有数百万行代码，而MongoDB只是一个高度分布式的服务，这就意味着当上述团队需要实现新特性的时候，所要花费的时间远比MongoDB多得多。我相信这才是MongoDB能够在市场上成为主流数据库的原因。

邹欣：各行各业都在向人工智能迈进，MongoDB将会如何利用好这一机会？

Mark：根据我的经验，如果把数据扔进模型，然后在上面运行多个模型，这样你马上就能开始研究人工智能了，所以我给公司的第一条建议就是尝试对数据进行训练。一个月以后，或许它不会产生立竿见影的效果，但你可以对其进行优化，慢慢地你就能知道到底哪些功能是最重要的。

MongoDB允许你在系统中处理数据，同样也支持Kafka Stream输入输出。我们看到很多人是在MongoDB之外训练他们的模型，然后将模型加载到旧的数据库中，进而在数据库中进行推理，这一现象让我感到十分激动。未来，开发人员借助人工智能，只需20%的努力就可以获得80%的收益，我相信AI会成为未来游戏规则的改变者。

如今的技术正在快速迭代，在面对无数竞争对手的时候，你唯一的竞争优势就是对你的用户和数据有更多的了解，而人工智能就是其中的一个关键部分。

邹欣：我很好奇，MongoDB的发布周期是怎样的？你对产品发布周期和回滚测试有哪些建议？

Mark：过去我们一年发布一次，最近打算一个季度发布一次，云团队是每两周发布一次。在默认情况下，所有的东西都必须经过测试才能交付生产，所以对于公司而言保持快速前进的方法就是相信测试结果。

另外我发现了一个有趣的事情：部署产品的时候就是发现“真相”的时候。“真相”不仅仅是你的软件有没有在工作，更是衡量软件是否在正常的标准，以及你能不能对一次错误的发布进行回滚。

这些年来，我研究了一套关于回滚的“180秒规则”。当你将软件部署到Fleet后，有60秒的时间来进行部署以使机器正常运行，然后用第二个60秒去确认这是不是一次成功的部署，用最后的60秒完成回滚，这些加起来总共180秒。有的公司可能需要10分钟部署、10分钟检查、10分钟回滚，有的是3分钟部署、3分钟检查、3分钟回滚，不同公司有不同的规则。

很多开发人员都没有办法对他们的软件进行回滚，大多数人听到这句话都会说“我回滚失败了”。我们的操作都是在预发布（Staging）环境中进行的，实现了Z-deployment。Z-deployment就是你在预发布中的角色，当你学会有意地回滚，然后对软件版本进行推进，接着运行测试，只有通过这些操作，你才能完成生产部署。很多公司都经历过生产上的回滚失败。通过Z-deployments和180秒规则，在生产过程中，可以减少80%~90%的停机时间。以上都是我在实践中得到的经验。

邹欣：MongoDB马上会有什么有趣的发布吗？

Mark：MongoDB.live是我们的全球会议，我们在大会上宣布了一系列令人兴奋的事情，其中也不乏我认为值得一提的有趣项目和功能。

第一个项目与时间序列息息相关。时间序列数据是来自传感器的数据，比如制造传感器，或者是股票交易事件，这是一种需要特殊处理的数据，所以我们用特殊的时间序列操作符和索引来启动时间序列集合。它允许你将时间序列数据存储在与其他数据类型相同的数据库中，从而不需要有这么多不同的数据库。

第二个项目是我最喜欢的，因为我是一名开发人员，所以我最不喜欢的一件事就是：当我写好应用程序并准备部署它时发现服务器需要升级，紧接着就要去重新测试、认证和部署。现在好了，通过MongoDB版本化API特性，可以将应用程序绑定到API的特定版本上。我们确保服务器可以年复一年地完成升级工作，同时你就能持续地运行这个应用程序，而不需要重新验证、测试以及部署，我认为这对开发人员来说真的很重要。

第三，是一个叫作实时重新分片（Live Resharding）的功能。MongoDB允许你在很多机器上对数据进行分片，然后通过一个小时的时间排序并完成索引。然而随着时间的推移，你所希望的分片数据的方式可能会发生变化，在此之前，你必须手动重新组织这些数据，而且还非常容易出错，现在有了Live Resharding，只需要告诉MongoDB如何重新组织这些数据，它就会自动为你做所有的事情。这样你就通过新的方式拥有了新的数据。

最后，MongoDB还拥有自己的云服务Atlas，它有很多其他的功能，也是非常令人兴奋的。

邹欣：当数据库成为新闻热点时，很多情况下都是因为安全出了问题，那么MongoDB在数据库安全方面做过哪些努力？

Mark：所有与数据库相关的公司都很关注安全性的问题，很多情况下，我们的首要任务就是尊重那些已经信任我们软件的客户。新的功能会让人觉得很有意思，但按照优先级顺序排列，依次是安全性、耐久性、正确性、可扩展性、可用性、可操作性，新功能只能排到第七位。

在MongoDB，安全排在所有事情的前面，是第一位的。我们每个功能都有安全审查环节，每个团队都有一个安全合作伙伴融入其中。但尽管这样，我们仍然会有遗漏，因此我们需要把测试做完美，也就是红蓝对抗测试。红队就是那些试图侵入软件的人，我们以此来进行模拟操作。当你把一个黑客可利用的漏洞部署在生产服务器上时，你就需要定期对可能发生的紧急事件进行演练，如该关闭哪些系统？如何减轻事故可能会造成的影响？这些我们都需要遵循NIST（美国国家标准技术研究所）的规则去处理应急事件。

Tech Geek的程序管理之道

邹欣：在加入MongoDB之前，你管理过很多不同的项目，当你加入一个全新团队的时候，是如何快速接手项目并最终成为专家和领导者的？

Mark：刚进入职场时，我通过大量学习和疯狂工作来达到目的。然而在逐渐成长中，我渐渐意识到最好的学习方法就是多听取别人的意见，然后就可以关注主要能够提升自己核心价值的地方。

现在，作为一家公司的高管，我不可能知道MongoDB做的所有事情。但我能做的是，去了解重要项目的关键要素。我的方法就是通过倾听，并探寻那些没有被提出来的、大家真正担忧不知该如何处理的问题。如果你能倾听“沉默”，就可以通过提出问题来推进讨论。

同时，交流和同理心也很重要。在二十多岁时，我会试着独自拼命加班学习去了解一切事情，但这其实并不是最有效的学习方法。

邹欣：但是往往在加入一个新团队时，你还没有形成足够的权威，这个时候要如何带领团队？

Mark：在动用职权或者“权威”之前，我都会先了解清楚事情的来龙去脉，与我的团队进行讨论然后再作出决策，成为与他们一起思考的领导者。

在大多数情况下，如果你能给团队足够的自由、信任他们，在讨论的时候提一些问题帮助他们更好地思考，让他们大胆地去作决定，即便在他们犯错误的情况下也不去惩罚他们，这样你就没有必要去行使所谓的“权威”了。你应该慎用所谓的“权威”，否则就会有很糟糕的结果。

坦白讲，我发现很多时候我的职位会阻碍大家去作一些很好的决策，可能我只是给出了一些建议，但他们却认为“Mark已经作出了决定”，所以有时候我开始学着退一步，给大家更多的机会和空间去成长。

邹欣：从自己的初创公司到现在的跨国公司，你的管理秘诀是什么？

Mark：小团队是可以进行自我管理的，因为他们每个人都互相熟悉，且具备先进、精细的知识结构。但当你身处一个大型开发团队时，你会发现交流成了一种负担，每个人都需要和其他部门的人交流。所以我的管理方式是对代码进行拆解，把它切分成很小的、可管理的片区，然后根据代码进行人员的管理。长时间以来，许多团队（包括我的一些团队）都存在一个误区：就是围绕着团队构建代码，最后发现自己的效率变得十分低下。所以我经常会问团队成员：你需要和多少人交谈才能作出决定？如果这个数字很大，那这时我就要对代码进行处理了，把它分成更小的、可以更好管理的模块。

跨组合作就更困难了。我们是通过API来实现的，假设每个团队都创建一个服务，比如微服务，只要每个团队有一个记录详尽的API，以及异常机制，以便有需要的时候能绕过API机制。通过API机制，团队就能进行扩张，保证工作的顺利进行。

邹欣：你现在还写代码吗？之前技术圈一直有关于“CTO核心技能”的讨论，你认为CTO最重要的核心能力应该是什么？

Mark：我认为CTO也分很多种，虽然我更愿意去敲代码，但公司希望我专注于向外部传递MongoDB的价值以及带领团队方面。理想尽管很美好，但现实是我们必须在各自的能力范围内以员工身份助力公司成长，成为公司的一部分。我是一个技术性很强的人，而且参与了很多技术文件的复审，但是现在我不会再去写代码了。

邹欣：你在组建团队时的选拔标准是怎样的？

Mark：诚实、好奇心、乐于接受失败。我很享受参与面试的过程，当我面试一个技术负责人的时候，我会认真倾听他们的失败经历，重点关注他们是否做过和我一样多的实验。我认为有60年发展历史的计算机科学至今仍然是一个研究项目，就像是制造汽车那样。

Charlie Bell（前AWS高级副总裁）是我的导师之一，他曾经教过我，在面试时要学会倾听，我经常会问面试者：你的招聘理念是怎样的？你是如何做产品计划的？他们可以就此展开讲很多东西，但你要去分析他们没说什么，而这往往就是不同面试者之间的差距，“听”他们没说过的话，会告诉你他们从未想过的事情。

邹欣：最后，回想你我30年前上学的时候，如果现在再给你一次机会，你还会选择计算机专业吗？

Mark：如果能够重新选择，我依然会选择计算机专业，因为这是一个充满了挑战的专业！同时我会专注于遗传学和生物学，因为我相信我可以从中学到很多东西。据我所知，我们只触及了人体和自然生态系统的冰山一角，在这一领域，人类要走的道路依然很远。

本文部分出自《新程序员·新数据库时代&软件定义汽车》，即将正式上市！

2018年图灵奖得主、深度学习三巨头之一Yann LeCun（杨立昆），2020年图灵奖得主、龙书《编译原理》作者Jeffrey Ullman，英特尔副总裁Erez Dagan，阿里巴巴集团副总裁李飞飞，腾讯自动驾驶总经理苏奎峰……《新程序员》第二期，我们以「新数据库时代&软件定义汽车」为主题，邀请到国内外60余位学术领航人、技术大咖与产业先锋，为智能驾驶及数据库产业奉上酣畅淋漓的理论交锋及实战演练。

何谓新数据库时代？需要从过去和现在看未来。在“十问数据库”中，华东师范大学副校长周傲英、达梦数据库副总经理冯源、TiDB创始人黄东旭、OceanBase CTO阳振坤……各路产学研大神齐聚，从数据库国产化历史，到开源、云，再到数据安全，共话未来数据库走向何方。

扫描下方二维码，添加小助手，即刻加入《新程序员002》「读者群」，抢先一步获取杂志最新资讯，精彩内容不再错过。

《新程序员》立足于行业前沿，深度探索技术未来，通过音视频、图文专栏等丰富的多媒体形式为载体，全方位解读技术与产业，为中国开发者打开新时代的技术之门。

《新程序员001：开发者黄金十年》内容涵盖：

• 60位+ 技术大咖的经典观点与实践干货；

• 34篇 精彩文章；

• 13个 配文视频；

• 1000位+ 技术人才共同学习成长；

• 2张 开源核心技术全景工具收藏图。

 长按识别二维码即可订阅

无论你是编程爱好者还是职场萌新，无论你是资深程序员还是架构师、CTO，在《新程序员》里，你都会有所收获。