NeverBlock 和无阻塞数据库适配器

阅读数:182 2008 年 9 月 15 日

话题:RubyOracle数据库Ruby on RailsMySQLDevOps语言 & 开发架构

NeverBlock

是一个使用 Ruby 1.9 的 Filber 特性构建的库。使用 NeverBlock 可以编写 non-blocking 代码。第一个获益于 NeverBlock 的数据库是 Postgres(可见 InfoQ 上

关于 Fibers 和 NeverBlock

的文章。现在,就在 Postgres 几天之后,NeverBlock 也添加了对于 MySQL 的支持,并使用了新的 MySQLPlus 驱动。MySQLPlus 构建于 Ruby 自带的 MySQL 驱动之上,此外还添加了异步查询处理支持和线程访问支持。

此外,另一个致力于为 Ruby 的 MySQL 连接增加异步操作能力的工程是

Asymy

。InfoQ 为此采访了 MySQLPlus 的一位开发人员 Roger Pack。我们特别感兴趣的是 MySQLPlus 和 Asymy 的差异,以及为什么要创建一个新的适配器。



首先介绍一些历史:之前我们使用的一般是用 C 编写的 MySQL 库,它在任何一次查询时都会进行阻塞。MySQLPlus 和 Asymy 都试图改变这一情况。

MySQLPlus 基本上可以算是在标准的 MySQL Ruby C 库之上增加了一些多线程友好的特性,尤其是在一条查询返回前不阻塞 IO。

Asymy 则是一个为比较纯粹的异步 MySQL 适配器。它用 Ruby 写成,因而解析相对慢的多(大约要慢 10 倍),而且由于推出不久,尚有一些 bug。

让 我来说,二者间的一个差别在于 Asymy“只是”事件驱动的,而 MySQLPlus 则同时兼有线程模式和事件驱动。MySQLPlus 的事件驱动特性有一 定的局限,这体现在当一个查询被读入时,用户不能够真正的检测到何时去等待 IO——这说明 MySQLPlus 尚未完善,但这至少是朝着正确方向迈出的一 步。

实际上,最开始的时候我们曾考虑过使用 Asymy,后来Muhammed [Ali, NeverBlock 的一名工作人员]发现只要对标准的 C MySql 库稍作修改,就可以使其基本具有多线程能力,所以我们就转到了标准库这边。MySQLPlus 库可以看作是对Tomita Masahiro 库的一个修改。

所以我想 MySQLPlus 和 Asymy 之间可能有一些重复的部分,这主要是 C 和 Ruby 两种语言的问题。MySQLPlus 的 C 语言部分并不是我们写的,所以在这部分没有什么重复。

现在 NeverBlock 可以和 MySQLPlus 一起工作,那么它会能够和 Event Machine 一起工作吗?

NeverBlock 基本上可以看作是 Fiber、EventMachine、Postgres 或 MySQLPlus 驱动的结合体。因此答案是:在应用了

一些小补丁后

,NeverBlock 可以和 EventMachine 一起工作。因此如果你很喜欢 EventMachine 的分阶段编程风格,NeverBlock 甚至可以与 1.8.x 版本的 MySQL 驱动一起工作。

值得注意的是 MySQLPlus 已经作为相对于 1.8.x MySQL 驱动来说更加线程友好的代替品而推出。MySQLPlus 也可以很好的与 NeverBlock 和 1.8.x MySQL 驱动兼容,这也是它最初的目标。

这个项目未来的计划是什么样的?你们是否打算去适配其它种类的数据库? 

Muhammed 提到过这一潜在目标。我倒还没有这么想过,因为我觉得我们已经足够好的覆盖了这方面工作最重要的部分。

未来的计划主要是让 rails 2.2 兼容 NeverBlock 和 MySQLPlus,希望能得到比较好的性能。

Aman Gupta,MySQLPlus 的作者之一,将 MySQLPlus 用在了 Aman Gupta 所开发的

异步 Event Machine MySQL 客户端

中。当然,Postgres 和 MySQL 并不是 Ruby 仅可用的两个数据库,所以我们也访问了 KUBO Takehiro,Oracle 数据库接口

ruby-oci8

的作者之一。我们请教了他关于 NeverBlock 的看法,以及 NeverBlock 是否可以方便的与 ruby-oci8 集成:



我觉得集成不容易。Neverblock-pg 使用了

PGconn#send_query 来

登 记一条查询,然后挂起 fiber 直到查询完成。但 ruby-oci8 的无阻塞模式则不是这样。当一个查询被执行时,处于无阻塞模式的 ruby-oci8 等 待结果,但并不阻塞其他线程。在 ruby-oci8 之外不能够增加挂起 fiber 的代码。我们不打算通过修改 ruby-oci8 来适配 NeverBlock。这是因为用户在不用到 NeverBlock 的 fiber 池的情况下,透明的使用无阻塞操作。

另外,我不确定要使用无阻塞操作时,是否一定要用到 NeverBlock。如果通过使用rb_thread_blocking_region() (ruby 1.9 的新特性),让 ruby-pg 包装那些阻塞性操作,其他线程就不会被阻塞。(可参见Ruby 线程机制的未来)。

当然,虽然我有这些看法,我还是很欣赏 NeverBlock 在为 activerecord 增加连接池特性方面所做的工作,这些正是我一直想要的。

说实话,我觉得并不是那么重要。SQLite 是一个内置数据库,而不是像 MySQL 或 PostgreSQL 那样使用客户端 / 服务器架构。为了在 SQLite 中支持异步查询,用户得首先将 SQLite 转换为服务器模式,以使得 SQLite 运行于用户应用外的一个单独进程。如果用户真的这么做了,那 么也许使用 SQLite 就不再是一个好的选择。

确实,我个人非常强烈的不主张人们在一个 web 应用的产品版本中使用 SQLite。SQLite 非常适合测试阶段和开发阶段,并且能够很好的与内置的各种应用协同工作,但在一个 web 环境中,SQLite 并不能像客户端 / 服务器模型那样工作。

读到这里,你有什么想法呢?是不是我们为了性能考虑,需要无阻塞的数据库访问呢?