| 在“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个月内，我们必须要紧牙关完成这个迁移。” |
