【编者按】在“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：主要的不同之处在于，如果用户拥有72个不同的CRM系统，很难将这些系统整合起来。另外，还会存在风险问题，如果你拥有20个不同风险的系统，期望采用不同通信方式，这样的话你就需要一个可以连接不同系统的服务。在汽车产业，可能就会是交通工具的single view。
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无疑拥有更多的用例，这点同样表现在企业级应用上。因此我们必须要做好迭代速度与谨慎方面的考量，平衡好速度与可靠性，因许多应用场景都是在任务关键性应用。
