时至今日，我们已经不可能把NoSQL的发展趋势与10gen公司的MongoDB割裂开来。当然，NoSQL数据库家族可谓百花齐放，Andrew Oliver还在他的经典文章《我到底该用哪种数据库》中进行了系统整理。众所周知，MongoDB与其它同类开源竞争对手Couchbase及 Cassandra的具体市场占有率也很难说得清楚。然而相信没有人会否认，MongoDB已经成为新一代开发者眼中的至宝。在发展过程中，它很早就将简化Web应用创建与数据库扩展能力放在第一位，也正是凭借这一特色MongoDB才得以从英杰辈出的传统关系类数据库中杀出个黎明。

10gen公司CEO Dwight Merriman于2007年与伙伴合作创办了这家企业——就在不久之前他才刚刚把自己建立的第一家公司DoubleClick卖给谷歌，交易金额达到31亿美元。Merriman拥有令人艳羡的强悍技术背景：1995年至 2005年任DoubleClick公司CTO，主持设计了DART(即动态、广告、报告及定位)初始技术——这项技术如今已经成为网络广告投放的主要基础。据他自己介绍，当初启动MongoDB开源项目的原因在于“我们感觉有必要推出一种新的数据技术类型，而当时也正好是最合适的时间点。”在10gen 公司的创建过程中，MongoDB逐渐转型为商业开源项目，能够为用户提供包括技术支持及特殊认购版本在内的多层次产品供应。

为了进一步了解MongoDB的成长轨迹与影响力，Doug Dineley和我上周一同采访了Merriman。我们开门见山，从开创文档类数据库的灵感开始向Merriman展开了探索之旅。

问: 您是怎样在经营DobleClick公司的过程中意识到市场对新型数据库的需求?

Dwight Merriman：之前的经验确实很有帮助。从某种角度上看，MongoDB正是我希望自己能拥有的数据库产品。当时我们需要自来遍布世界的十二数据中心以及其中成千上万台服务器，还得确保每台设备都处于正常运行状态，这可相当困难。当然，上世纪九十年代的计算机在运算速度上完全无法与如今相提并论，这要感谢摩尔定律的一贯正确。在工作中我们需要一遍又一遍地对原有方案进行重新开发，这种枯燥而毫无价值的任务让我们希望创造出一种适合现代化软件、数据且能够与新时代工作规模相吻合的处理方式——同时还要与公共及私有云结构顺利接轨。但那时候市场上实在没有这种产品，于是大约五年前我们建立了10gen公司，并从零开始打造MongoDB。

问: 要说传统数据库技术的两大主要瓶颈，可能关系类数据库的扩展性与控制性缺失最令人头痛。这个问题您怎么看?这两点是困扰您的主要原因吗?

Dwight Merriman：我赞同扩展位列其中，另一个嘛……我认为是数据模型。大家知道，关系类数据库可能是软件历史中出现过的最成功的技术，很多人都没意识到我们今天还在使用的技术已经有三十到四十岁的高龄。但如果将目光转向软件开发的另一大重点——编程语言，我们会惊奇地发现语言的更迭周期明显要快得多。软件开发方法本身已经发生改变，我们不再遵循瀑布式开发原则。如今，大家更青睐敏捷开发与多版本机制。编程语言不再局限于面向对象这一种，很多新语言都专为云计算而生，这种高度灵活性非常值得肯定。我们认为这种趋势也将给数据层带来重大变革，其影响之深远在过去25年的数据库发展历史中无人能出其右。

问: 您建立了第一款获得广泛成功的NoSQL文档类数据库。这样的成就源自哪些重要积累?

Dwight Merriman：其实没什么特别的积累;我觉得整个职业生涯教给我的宝贵经验就是哪些可行而哪些不可行。我们研究过云计算——因为我们要根据扩展性需求决定如何编写代码——但却找不到理想中的工具。核心难题主要分两个方面，其中之一在于：我们该如何向外扩展?扩展技术在理念上存在几道难以攻克的障碍，分配连接就是这样一道门槛。如果要向容纳有一千台服务器的集群进行负载分配，其难度可想而知。

针对这个问题，我们的态度是：好吧，既然没有明确的解决思路，那就不要再为此浪费时间了。相反，我们尝试选择其它数据模型，希望在达到理想效果的同时回避上述难题。面向文档的数据模型由此诞生，从开发者的角度看我们对这一成果非常满意。尽管不太谦虚，但我们真的认为这套方案非常适合现在的代码开发者。

这有点像一种催化剂，指引着我们向正确的方向做出努力。我认为如今NoSQL家族中大家所看到的各类次世代、可扩展的非关系类数据库基本都具备这些特性。我真的很喜欢面向文档这一概念，因为它非常符合我们编写代码的方式。文档类数据库令信息变得可读，尤其是在开发者及数据库管理员眼中。在开发 MongoDB的过程中，最令人印象深刻的点子就是把数据从代码中分离出来。我们应该有能力在不损坏程序的前提下查看数据库内容。关系类数据库在这方面表现不错，而我们应该继承这一优势。

作为文档的基础，我对JSON(即JavaScript对象表示法)也很喜爱。JSON赋予我们一套用于处理对象类数据的标准化独立语言，而且对于人类而言，它的可读性要比XML更高。据我所知有几款NoSQL产品属于JSON风格的面向文档型数据库。我认为作为这一领域的标准化数据模型范例，JSON给大家带来了非常理想的切入点。

问: 为什么要让MongoDB走开源道路?您是不是在项目启动之初就构思好了未来的商业模式?

Dwight Merriman：这么做也是出于多种因素的考量。首先，作为开发者我们很喜欢开源的概念，甚至可以被称为开源粉丝。当然，我们在坚持开源路线的同时，也相信自己有能力在开源这一领域创造出不断发展但又极具商业价值的免费项目。红帽公司是一家了不起的企业，规模也相当之大，所以开源并不会成为业务道路上的绊脚石。

问: 您的第一位客户是谁?

Dwight Merriman：我们的第一批客户来自Web 2.0与startup world网站。这要回溯到2009年，那时候Shutterfly、Craigslist及Foursquare等企业开始尝试MongoDB。而一年之后，我们的产品迎来了更多规模更大的客户，例如Intellisponse、O2、迪士尼乃至eBay。时至今日，即使在企业层面我们也早已跨过了早期试用这个阶段。2012年，MongoDB的普及趋势开始向金融服务业界扩展，目前银行及其它金融机构开始广泛采用MongDB及NoSQL类产品——至少会在新项目中采用。甚至有不少企业表示：这是我们开发应用的默认方式。

问: 他们指的是Web应用，对吗?

Dwight Merriman：哦，不是，因为MongoDB中不包含任何针对Web应用的特殊设计。从概念上说，这是一款通用型数据库。虽然刚刚接触MongoDB 的客户会通过Web应用进行试水，但我认为人们应该把它推广到各个方面：内容管理系统、个性化系统以及移动流媒体等等。MongoDB被用在Web开发中，但也同样被用于账目管理及离线分析等方面，这些都是历史数据存储量巨大的领域。总而言之，MongoDB的适用范围非常广阔。

答:客户所开发的企业应用之间存在共通点吗?因为在您的介绍中，我们会有种缺乏特色的杂烩感。

Dwight Merriman：使用范围的确很广很杂，而且你的问题比较宽泛，有点像：甲骨文关系类数据库包含哪些使用实例?我当然能够回答，但这既复杂又耗时。文档类数据库在数据对象符合面向文档的数据模型时表现出色，无论是从编程语言、分类效果还是数据合集角度看都是如此。

举例来说，某家电信公司自主开发了一套产品目录应用。由于公司规模极为庞大，产品数量也达到上万种，其中包括电话、延保产品以及其它一些服务计划。每种产品都拥有独特的属性，而由于MongoDB的数据模型非常适合这种工作，企业开发者会发现整个工作流程都变得更加简便。这算是个很好的使用实例。

我认为MongoDB的出色之处还不仅如此。内容管理应用后端、使用量巨大的移动应用、需要实时进行操作数据存储的在线应用等任务每秒钟需要处理数万次读写操作，而这也是文档类数据库的长项。

当然MongoDB也存在局限性，复杂度极高的工作或者对SQL及UVC的遗留请求进行处理就不太适合它。

问: 从CIO的角度分析，我们认为大家的普遍看法是NoSQL类产品不太适合进行交易处理。您对这种观念有什么见解?

Dwight Merriman：这要看具体的产品类型，不同产品所使用的处理模式也有所不同。MongoDB的实力就要比人们的普遍看法强一些。通过MongoDB，用户可以对个人JSON文档进行原子操作，而且支持的文档处理量也相当理想，这当然也是交易处理的一种表现。而在同一文档的条件下，如果我们想从A处借记款项并以信贷形式交付给B，这样的交易活动完全能够顺利进行。只是我们无法在不同文档之间进行这样的操作。

我们很希望能满足用户的需求，但问题在于要让分布式交易在上千台服务器规模的集群中快速完成实在是非常、非常、非常困难。所以我们的做法是……在保证速度的前提下为大家提供解决方案，尽管还存在一定缺陷。事实证明这样的思维方式能够让产品走得更远，特别是在设计过程中考虑到无法完成的任务。我发现在 75%的使用实例中，都有很多其它方法处理这一看似难以完成的任务。不过仍然有少数客户对产品的表现不太满意，这一点我并不否认。

如果某个项目拥有二十项要求，典型数据库会优先分配交易要求，但这就会使其在其它一些方面表现乏力——例如数据映射、处理速度以及扩展性等。用户需要从综合角度进行审视，评估哪款产品最适合自己的实际需求。

问: 前一阵子，我们网站的一位撰稿人Andrew Oliver刊发了一篇名为《糊涂的极端分子死咬MongoDB》的文章。在他看来，很多用户面对日益普及的MongoDB提出了一些不切实际的期望。您对这样的观点有何看法?

Dwight Merriman：我们确实发现了此类情况，尤其是在一年前。但随着产品的逐步完善，目前这种争议已经越来越少。我认为在厂商不断改进产品的同时，开发者们的经验积累与知识储备也在与日俱增，这样的组合非常科学。所有有利于MongoDB发展的最佳实践与设计模式乃至设计方案都不会凭空出现。作为项目开发者，我认为MongoDB易于上手的特性非常有吸引力，用户应该在轻松入门后进一步学习并发掘。遗憾的是就目前来看，这种健康的生态系统还未完全建立起来。

本着这样的思路，我们在去年秋季推出了MongoDB免费在线教育课程。这是一种大规模网络公开课，与Coursera或者斯坦福讲堂类似，而且收到了不错的成效。仅在项目启动的两周之后，我们就迎来了两个班共计三万名学员。这两个班分别是开发者班与数据库管理员班，全部受到广泛响应与热烈参与。目前我们的课程刚刚步入第二学期，并有计划再开设一个Java开发者班。把信息分享给大家确实能够帮助他们取得成功。

问: 你会聘用班上成绩优异的学生吗?

Dwight Merriman：当然，我们很乐意这么做。

问: Couchbase所提供的文档数据库版本也具备相当的竞争实力。您对于市场竞争打算采取什么样的应对策略?毕竟这块新兴市场还处于混乱且快速增长的趋势之中。

Dwight Merriman：其实这跟早期面对关系类数据库的压力没什么区别，那时候甲骨文和Sybase同样实力强劲。

问: 没错，您肯定不想成为下一个Sybase。

Dwight Merriman：是啊，但那都是过去的事了。如今具备竞争力、项目规模庞大的企业不少，增长也都非常迅速。但在MongoDB这边，我们的扩展性与开发者效率方面拥有独特的优势。我认为在同等条件下MongoDB堪称独一无二。

问: 您觉得自己的主要竞争对手是谁?

Dwight Merriman：Cassandra、Couchbase和HBase是我首先能想象到的MongoDB三大竞争对手。

问: 你对甲骨文NoSQL有什么看法?

Dwight Merriman：没有什么看法。

问: 最后一个问题，10gen公司在2013年有何打算?作为用户我们又该做出哪些期待?

Dwight Merriman：作为MongoDB的供应商，每次进行大规模更新都会将版本号提升0.2;因此今年大家会迎来2.4和2.6两个新版本。我们正在全文检索方面进行一系列研发工作，打算添加一些新的安全功能，并在性能上做出大量调整工作。如果大家使用五百台规模的服务器集群，MongoDB对于管理员而言非常友好且易于使用。但如果服务器规模超过五百台，工作量就会有所增加，但我们仍然希望尽可能保持数据库易用性。总之，在接来的十二个月中，我们将继续给大家带来新惊喜。