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 并不能像客户端 / 服务器模型那样工作。
读到这里,你有什么想法呢?是不是我们为了性能考虑,需要无阻塞的数据库访问呢?
评论