RavenDB 创始人谈.NET、NoSQL 上的 ACID 以及该项目的未来特性

阅读数:1878 2013 年 1 月 31 日

话题:.NET开源语言 & 开发AI

最近发布的RavenDB 2.0 带来了一些新特性。在 InfoQ 对 RavenDB 的创始人和项目主管Oren Eini(Ayende Rahien)的独家专访中,他与我们分享了该项目各种决策背后的理由以及项目的未来。

在 RavenDB 项目于 2009 年启动时,Erlang 也是评估过的选择之一。然而,考虑到大家在.NET 方面的现有经验、很多可选的重要类库以及.NET 在企业级运维社区(Enterprise Ops community)的使用率,团队还是坚持选择了.NET。

我们在.NET 1.0 Alpha 版早期就开始使用了。这是我们熟悉的环境,用着舒服,通过.NET 我们能够获得高性能、可靠性和稳定性,也不必自己开发上层数据库。

此外,我们希望开发的东西容易集成,可以方便地添加到许多组织现有的生态系统中去。我们也希望产品能够构建在一个非常完善的基础之上。这既适用于客户端,也适用于服务端。在客户端,我们提供了非常好的.NET 集成;而在服务端(运维),我们做到了容易扩展、监控和定制。

Erlang 库的类型非常有限,有些东西就是很难实现。特别是与 CLR 这种丰富的环境相比,Erlang 简直是一片荒芜。当然,我知道这么说会招致很多 Erlang 爱好者的不满。但这个决定并不是草率做出的。在做决定之前,我通读了 CouchDB 的整个代码库,希望能喜欢上它(至少在那时,CouchDB 还不是地道的 Erlang 程序)。

举例来说,RavenDB 利用了底层的库,如 Lucene 或是一些现有的、可以直接使用的、针对 CLR 的空间(Spatial)库。即便 Erlang 中存在类似的东西,找起来也非常困难。

但到最后,这就是专业知识方面的问题了。我们知道如何让 CLR 跑起来,如何灵活地控制它,以及让它不再装死。

这种选择看来是有效的,目前 RavenDB 在 Ohloh 列出的所有项目团队中位居前 2%

相对于其他 NoSQL 数据库,保证 ACID 是 RavenDB 的优势之一:

我认为很多 NoSQL 解决方案目前只学习了在上世纪 70 年代后期玩数据库的人看来已经很显而易见的一些东西。没有事务是很难干活的。不能依赖事务,开发者就要尝试在自己的代码中管理事务,甚至无法管理事务,随机的数据损坏以及很多复杂性问题随处可见。

当然,事务并不简单。要正确编写,并使之具有较高的性能,需要一点策略。但实际上并没有很好的选择。对业务开发者而言,除了现在让他们头疼的各种问题,再让他们确保系统的事务性,这要求太高了。

我自己偶尔也开发业务应用,我可以告诉你,你会希望把我冰冷的死亡之手撬开拿到事务功能的。这就是为什么 RavenDB 的核心保证之一就是事务安全性概念的原因。RavenDB 包含了完整的 ACID 保证。

RavenDB 的架构是基于包的,它有一个很薄的核心,便于开发者扩展 RavenDB。Oren 解释说,RavenDB 团队自身发布的很多特性就是通过特性包的形式添加的,可以选择是否加入。随着代码的成熟,这些特性才逐渐移到核心之中。这样就很容易无干扰地提供大量新特性。开发者也可以选择构建自己的扩展,所有他们需要做的就是继承 RavenDB 提供的某个扩展点,编译代码,然后将 dll 放到 Plugins 目录下。

至于明年有什么期待:

我们希望支持额外的客户端,从 WinRT 到 Android 到 iPhone 再到 JVM。我们希望有一个更好的管理大规模 RavenDB 集群节点的集中管理系统,该计划正在进行之中。我们还想在 RavenDB 之上的报告概念方面做些工作,不过这很大程度上是实验性的,可能最后不会有什么结果。但最重要的工作很可能是改进索引管理、查询优化器以及 RavenDB 如何自动调整以便更好地适应生产环境。

RavenDB 使用了双许可证策略,对非开源(商业)项目采用订阅方式。它也可以从如RavenHQCloudBird等供应商处以托管服务形式获得。

查看英文原文RavenDB Founder On .NET, ACID with NoSQL, Upcoming Features