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

最近发布的 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 使用了双许可证策略，对非开源（商业）项目采用订阅方式。它也可以从如 RavenHQ 和 CloudBird 等供应商处以托管服务形式获得。

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