十一问MongoDB CTO,NoSQL之王回击业界质疑

MongoDB_Brown_Trees-in_Macbook_Background.png
IT经理网点评:作为NoSQL数据库阵营的领头羊,MongoDB过去几年取得了令人瞩目的发展,不但市值超过10亿美元,更是赢得了包括IBM在内的IT巨头的背书,但近来MongoDB,甚至整个NoSQL数据库市场不断遭受IT业界质疑,认为“大数据时代NoSQL并非颠覆性技术”,MongoDB技术门槛不高,其市场正面临Teradata、MemSQL和Heroku的威胁。这使得很多潜在用户开始担心——MongoDB的成功是否建立在过度的炒作之下。(此外,斯诺登事件后,MongoDB的产品安全性还因为其获得CIA等美国情报单位支持的风险投资机构In-Q-Tel的投资而饱受政府用户质疑),近日该公司CTO兼联合创始人Eliot Horowitz对这些声音进行了回击。以下内容由CSDN编译

 

总结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(编译/仲浩  审校/魏伟)

第一时间获取面向IT决策者的独家深度资讯,敬请关注IT经理网微信号:ctociocom

   
除非注明,本站文章均为原创或编译,转载请务必注明出处并保留原文链接: 文章来自IT经理网
相关文章:
标签: ,


关于作者

写评论

忘记密码

X