当前位置: 首页 > 分布式系统 > 正文

HandlerSocket:走向NoSQL技术的魔法帽

1 星2 星3 星4 星5 星 (1 次投票, 评分: 5.00, 总分: 5)
Loading ... Loading ...
baidu_share

引文

NoSQL技术虽然主要是为了解决传统关系型数据库在面向Internet Scale时的可扩展性问题而生,但其风生水起的直接原因还是在单机上建立赫赫功勋的DB在Web2.0进程中遇到了前所未有的挑战,包括海量数据,高并发访问,低延时性的读写需求等。因此如果我们能够继续提升其单机的性能以足够满足当前的需求的话,我相信没有人会急于应用没有成熟的NoSQL技术,大家都知道吃螃蟹是有风险的。

随着现在多核、高速网卡、SSD存储等硬件技术的发展,CPU、网络、磁盘IO等资源被暂时缓解,继续提升单机DB性能不是什么困难的事情,因此,在今后一段时间内传统数据库仍将继续稳坐在神坛的位置,这也是我对NoSQL和传统数据库目前关系的一个基本观点,但这个观点并没有否认NoSQL在Availability、Scalability、Schemeless等方面的优越性,也不会阻碍我继续作为NoSQL技术的爱好者和开发者。对这个话题感兴趣的话,可以参照下文:Is the Relational Database Doomed? 

HandlerSocket

今天介绍的是另一个传说中可以大大提高数据库性能的利器:HandlerSocket, 又称为HandleSocket。但是我怀疑HandleSocket是一个误称,就像NoSQL被叫成NOSQL一样。它就像一顶魔法帽几乎不费吹灰之力,将传统的Mysql变成NoSQL的一员,更惊讶的是居然取得了神奇的疗效。

Yoshinori Matsunobu目前是DeNA的首席数据库和基础设施架构师,之前是Sun/Oracle的雇员,从事MySQL的研发工作,他经过profiling发现,很显然性能降低的原因主要在SQL层,而不是存储层。”SQL层的功能包括解析SQL语句、打开/锁定/解锁/关闭表、解决并发问题等”。因此,他们决定以插件的方式提供直接和存储引擎进行交互的方式,以绕过SQL层,降低CPU的消耗.

于是,他的团队开发了HandlerSocket插件,通过监听独立的端口9998和9999,接收标准SQL协议请求,然后通过MySQL内部存储引擎API直接访问InnoDB,同时,常用端口3306仍然可以接收处理复杂查询。这一变化把数据库性能提升到了750K qps以上(当然水分挺大),这也意味着已经超过了现在绝大多数KV存储系统性能,普通DB仅有10k左右。

优缺点

相对于其他NoSQL解决方案,MySQL+HandlerSocket优势很明显,因为它是在服务器端的插件,都不用重新编译,兼容之前运行协议和模式,对程序员、运维人员而言几乎没有任何额外的学习、开发以及头疼的维护成本,老程序的迁移也会出奇的顺利,如何解决无缝切换的升级是每个人心中的痛,而HandlerSocket可以认为是一个很完美的解决方案。

但是从技术上来讲它还是有缺陷的,这些缺陷导致了目前没有如人们所期待的那样得到大力的推广应用。其中,有些是致命性的,有些则是暂时性的。比如它本身并没有在存储IO层上做过多的优化,更主要的是节省了CPU资源的消耗,同时它依赖于Innodb引擎,仅支持Row-Based的主从同步,而且没有解决自增的unique id问题,以及存在读到脏数据的可能性,违反了ACID中的一致性等(不知道最新版本有没有解决)。

总结

尽管HandlerSocket有诸多的缺陷,但是瑕不掩瑜,其思想和实现方案有很多地方非常值得借鉴,它就像RISC简单指令系统计算机的诞生一样,从实践中来,到实践中去;又像C++的语法设计一样,通过一种兼容并包的演化而非革命的方式,却提供了具有爆炸性的效果,完全值得期待有更大的发展和在大型网站的成功应用经验的推广。

补充参考

其他详细信息和实测性能及对比测试请参考下文链接:

http://www.infoq.com/cn/news/2010/11/MySQL-HandlerSocket-VoltDB

http://blog.csdn.net/tt6668282/archive/2011/03/03/6219588.aspx

http://xiaoy.info/2010/12/11/229/handlersocket_study/

本文固定链接: http://www.chepoo.com/handler-socket-nosql.html | IT技术精华网

HandlerSocket:走向NoSQL技术的魔法帽:等您坐沙发呢!

发表评论