十一问MongoDB CTO，谈NoSQL人气王的扩展、事务及运维

【编者按】在“MongoDB成为首位10亿美元初创”一文中，我们曾介绍过这个千禧年的宠儿――NoSQL领域的人气王，只通过6年时间就将公司市值发展到12亿美元，其成果相当于著名开源公司Red Hat 20年的发展。

总结MongoDB的成功之路，一大部分归功于Web开发者，因为作为一个文档数据库，在许多场景下它都优于RDBMS，同时还可以获得非常高的读性能。此外，动态、灵活的模式更可以让用户在商用服务器上轻松的进行横向扩展。

然而还是有很多潜在用户抱有这样的担心――MongoDB的成功是否建立在过度的炒作之下。同时，有些则是担心MongoDB还不够成熟，认为其只适合某些Web应用，并且在事务上存在很大的风险。为了弄清这些问题，近日，InfoWorld的Eric Knorr走访了MongoDB CTO兼联合创始人Eliot Horowitz。

下为采访译文

Eric：对于MongoDB，业内通常会有这样一个说法，MongoDB只适合初创公司，可以用它很方便的进行扩展。但是对于变化较少的企业级应用程序来说，这点似乎并不需要？

Eliot：我在与许多企业CIO交流的过程发现他们受许多问题困扰，其中之一就是一个项目究竟需要多少个开发者。另一个问题就是，有些想做的项目无法完成，可能是资源不足，也能使花费时间太长。

但有一点是肯定的，在使用MongoDB之后，这些问题出现的频率减少，他们可以更快的完成一个事情。企业往往获益于将系统拆分为多个可以交互的小型系统，而这些更小的系统完全可以看成是“初创公司” 。

Eric：你口中的他们从事的项目类型是？

Eliot：通常情况是获得某个方面的single view，比如用户。他们期望对大量不同的数据源进行抓取，然后清洗转换成一个易于观察的single view。

Eric：如果这么来看的话，这似乎是CRM的主要应用场景？

Eliot：这和CRM有很多区别，主要的不同在于，如果用户拥有72个不同的CRM系统，那么将这些系统整合将难于登天。另外，还会存在风险问题，如果你拥有20个不同风险需求的系统，也期望采用不同的通信方式，这样的话你就需要一个可以连接不同系统的服务。

Eric：即使发展至今，NoSQL的事务处理上仍然存在疑问，对于这一点你怎么看？

Eliot：为了更好的实现事务功能，MongoDB加入了越来越多的特性。同时，因为MongoDB本质上是一个分布式系统，所以你不需要担心因为单一磁盘故障所造成的系统崩溃。

实际情况中，可能会使用两个独立的数据中心，对比只在一个物理硬盘上操作，用户将获得更强的可靠性，这些都是新型分布式环境所带来的便利。但无可否认是模式发生了整体的变化，然而只要人们真正的了解了这个环境，肯定会更加偏向于分布式系统。

对于成熟。MongoDB已投入市场5年之久，当Oracle 5岁时，它肯定也没有现在这么成熟。数据库是个长期的工作，这个领域的产品需要更长时间能打磨，但是因为需求问题，我们已经成熟的非常快了，永远比我们想象的快。MongoDB的企业应用流程一般是这样的，在一个用例中测试==》投入生产环境==》任务关键型应用上使用，这个是1到2两年后了。经过5年的发展后，我们已经看到MongoDB支撑着许多企业的任务关键性应用程序。

Eric：什么样的任务关键型应用？

Eliot：其中一个情景就是user-facing数据。在Adobe的中，当人们使用Photoshop时，所有的数据都会保存在Adobe中，如果服务发生故障，将会产生非常麻烦的事情。同样，在银行和风险系统中也是如此。

Eric：MongoDB有在银行系统中投入使用？

Eliot：如果你着眼银行这个领域，许多事情变化都非常快，比如业务操作时的管理需求、业务操作方式等等。MongoDB可以快速的适应并跟随变化，这点是其他系统做不到的。MongoDB能进入这个领域主要就是基于这个原因，即使它不像Oracle那样成熟。同时，这也是开源技术背后需要公司来支撑的原因，开源道企业级应用有很大一部要走。

Eric：你好像一直在说新系统的打造，这是否意味着很少有遗留的企业系统迁至MongoDB？

Eliot：如果遗留的系统可以工作，那么为什么要迁移？这是完全没意义的。我们看到许多新的应用程序基于MongoDB建立，可以说每时每刻都在发生。同时，如果遗留系统崩溃，那么通常情况下它会被重构和重新建立。但是如果遗留系统可以正常的工作，基于成本问题，相信不会有任何人做这种无意义的迁移。

因此，只有在重建时你才会看到遗留应用程序的迁移。如果你有接触这种情况，你可能就会听到工程师的抱怨：“因为不能快速演进，我们已远落后产品路线图了，因此在接下来的6个月内，我们必须要紧牙关完成这个迁移。”

Eric：都有哪些机构的工作者在推动MongoDB采用的前行？

Eliot：毫无疑问，开发者是最大的推动者。架构师因为一些架构上的问题使用MongoDB，有些情况下运营团队使用MongoDB来减少运维复杂度，有些时候类似VP及CIO也期望使用它来创新。但是，我认为这些都只是基础，重点在于使用并喜欢它的人们，他们可能会对CIO上报：瞧，我正在使用这个产品，我认为它可以在更广泛的项目中投入使用，它肯定会运行的很好。

Eric：从运营的角度上看，我听到反馈说MongoDB扩展并不像宣传的那么容易，这些人的问题是出在了什么地方？你们是怎么回答的？

Eliot：我认为最大的问题在于MongoDB的底层系统设计是针对最大横向扩展性及许多常见的运维操作，而当下这些最常见的运维操作可能还不是最简单的。我们尽力让MongoDB由一堆很小的独立组件组成，让用户基于需求选择来解决扩展难问题。

那么问题就发生了，使用这种新型的集群，你可能需要管理许多小的部分。从运维的角度来说，这确实令人烦恼。这个部分会在今年搞定，将会推出一套自动化系统，只需简单的点击就可以完成工作。同时，我们还将推出管理大型分布系统的工具，彻底解放运维人员。

Eric：在MongoDB中，一些最常见的错误是什么？

Elito：或许也不能称之错误吧，MongoDB面临最大的挑战就是正确的数据模型。因为MongoDB非常灵活，所以用户经常不考虑花时间去设计比较合适的模型，最终这将演变成搬着石头砸自己的脚。

对于传统的RDBMS来说，它们只提供简单的模型和选项，而基于太多的硬性规则，用户一般也不容易陷入困境，这点在MongoDB中就很可能发生。因此，用户需要阅读一些相关的书籍和文档，避免误区。

使用关系型数据库的思维管理MongoDB，把MongoDB当做关系型数据库来使用，这样无疑会带来困境而不是好处。

Eric：什么会让你夜不能寐？

Eliot：对于我们来说，最大的挑战就是让产品运行良好，让用户喜欢MongoDB。毫无疑问的是，对比5年后的产品，当下在技术方面还存在很大的差距。坦率的说，在产品的这个生命周期，我们拥有了太多的用户。

如果你对比MongoDB和其他数据库的同个生命周期，MongoDB无疑拥有更多的用例，这点同样表现在企业级应用上。因此我们必须要做好迭代速度与谨慎方面的考量，平衡好速度与可靠性，因为许多应用场景都是任务关键性应用。

原文链接：11 questions for MongoDB's CTO（编译/仲浩  审校/魏伟）

免费订阅“CSDN大数据”微信公众号，实时了解最新的大数据进展！

CSDN大数据，专注大数据资讯、技术和经验的分享和讨论，提供Hadoop、Spark、Imapala、Storm、HBase、MongoDB、Solr、机器学习、智能算法等相关大数据观点，大数据技术，大数据平台，大数据实践，大数据产业资讯等服务。

生活不易，码农辛苦
如果您觉得本网站对您的学习有所帮助,可以手机扫描二维码进行捐赠