class="topic_img" alt=""/>
英文原文：11 questions for MongoDB's CTO
在“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 无疑拥有更多的用例，这点同样表现在企业级应用上。因此我们必须要做好迭代速度与谨慎方面的考量，平衡好速度与可靠性，因为许多应用场景都是任务关键性应用。
相关文章
