HandlerSocket

发布时间:2019-12-09 06:20    浏览次数 :

[返回]

UsingMySQLasaNoSQL

FROM: Using MySQL as a NoSQL - A story for exceeding 750,000 qps on a commodity server
  由于 MySQL 的局限性,很多站点都采用了 MySQL+Memcached 的架构。另外一些站点放弃 MySQL 而采用 NoSQL,比如 TokyoCabinet/Tyrant 等。不可否认,在做一些简单查询 (尤其 PK 查询) 的时候,NoSQL 比 MySQL 要快很多很多。而且网站上的绝大多数查询都是这样的简单查询。
  像其他大规模的公司一样,DeNA 也面临过类似的问题。但最后我们采用的是一完全不同的方法, 仅使用了 MySQL。我们仍然使用 Memcached 做前端缓存(例如,预处理 HTML, 数量/摘要 信息),但在后端,既没有使用 Memcached 缓存任何记录,也没有使用 NoSQL,这是为什么呢?因为与其他的 NoSQL 产品相比,我们的 MySQL 能得到更好的性能。 在我们的基准测试中,一普通的 MySQL/InnoDB 5.1 服务器达到了 750,000+ QPS,生产环境中的性能当然更不列外。或许,你们很难相信这个数字,但这是事实。我将在以下分享我们的经验。
  (作者经历)2010-08,我离开了 Oracle, 现在任职于日本最大社交游戏平台供应商之一的 DeNA。
  在每秒中,需要做多少次的 PK 查询了?在 DeNA 公司的应用中,经常要进行 PK 查询。比如根据 user id 取出 userinfo,根据 diary id 取出日志内容, 对于这样的需求,不用说,Memcached 和 NoSQL 都相当适合。在简单的多线程 “Memcached GET”基准测试中,很可能每秒进行 400,000 次 get 操作,即使 Memcached client 在不同的服务器。在一台 Nehalem box 2.5GHz x 8 核 CPU, Broadcom 四端口千兆网卡的服务器上,最新的 libMemcached 和 Memcached 每秒可达到 420,000 次 get 操作。
  在 MySQL 下, 每秒可作多少次的 PK 查询呢, 我们可用 sysbench, super-smack or mysqlsla 等来进行基准测试

[[email protected] ~]$ mysqlslap --query="select user_name,..  from test.user where user_id=1" \
--number-of-queries=10000000 --concurrency=30 --host=xxx -uroot

  通过如下命令,很快就得知 InnoDB 的 QPS 大概为 100,000, 几乎只有 Memcached 的 1/4.

[[email protected] ~]$ mysqladmin extended-status -i 1 -r -uroot \
| grep -e "Com_select"

...
| Com_select                            | 107069     |
| Com_select                            | 108873     |
| Com_select                            | 108921     |
| Com_select                            | 109511     |
| Com_select                            | 108084     |
| Com_select                            | 108483     |
| Com_select                            | 108115     |
...

  看上去, 100, 000+ QPS 也不是太差,但为什么 MySQL 比 Memcached 差这么多呢,MySQL 到底在做什么呢。从 vmstat 的统计信息得知, %user 和 %system 的数据都非常高.

[[email protected] ~]$ vmstat 1

r   b  swpd   free   buff  cache      in     cs us sy id wa st
23  0     0 963004 224216 29937708 58242 163470 59 28 12  0  0
24  0     0 963312 224216 29937708 57725 164855 59 28 13  0  0
19  0     0 963232 224216 29937708 58127 164196 60 28 12  0  0
16  0     0 963260 224216 29937708 58021 165275 60 28 12  0  0
20  0     0 963308 224216 29937708 57865 165041 60 28 12  0  0

  再看 Oprofile 输出,可知 CPU 消耗的出去:

samples  %        app name                 symbol name
259130    4.5199  mysqld                   MYSQLparse(void*)
196841    3.4334  mysqld                   my_pthread_fastmutex_lock
106439    1.8566  libc-2.5.so              _int_malloc
94583     1.6498  bnx2                     /bnx
284550    1.4748  ha_innodb_plugin.so.0.0.0 ut_delay
67945     1.1851  mysqld                   _ZL20make_join_statisticsP4JOINP10TABLE_LISTP4ItemP16st_dynamic_array
63435     1.1065  mysqld                   JOIN::optimize()
55825     0.9737  vmlinux                  wakeup_stack_begin
55054     0.9603  mysqld                   MYSQLlex(void*, void*)
50833     0.8867  libpthread-2.5.so        pthread_mutex_trylock
49602     0.8652  ha_innodb_plugin.so.0.0.0 row_search_for_mysql
47518     0.8288  libc-2.5.so              memcpy
46957     0.8190  vmlinux                  .text.elf_core_dump
46499     0.8111  libc-2.5.so              malloc

  MySQL 的 SQL 解析阶段,有调用 MYSQLparse() 和 MYSQLlex(); 查询优化阶段,调用 make_join_statistics() 和 JOIN::optimize()。很明显,主要耗资源的是SQL 层,而不是 InnoDB 存储层。与 Memcached/NoSQL 比起来,MySQL 还要额外做一些工作:
Parsing SQL statements 解析 SQL.
Opening, locking tables 打开并锁定表.
Making SQL execution plans SQL 执行计划.
Unlocking, closing tables 解锁并关闭表.

  另外,MySQL 还必须要做大量的并发控制,比如在发送/接收网络数据包的时候,fcntl() 就要被调用很多次; Global mutexes 比如 LOCK_open,LOCK_thread_count 也被频繁地取得/释放。所以, 在 Oprofile 的输出中,排在第二位的是 my_pthread_fastmutex_lock()。并且 %system 占用的 CPU 相当高(28%)。

  其实 MySQL 开发团队和外围的开发团体已意识到大量并发控制对性能的影响,MySQL5.5 中已经解决了一些问题。未来的 MySQL 版本中,应该会越来越好。

  还有一个大的问题是,%user 达到了60%。互斥量的争夺导致 %system 上增,而不是 %user,即使 MySQL 内部关于互斥量的的问题都得到修复,还是很难达到我们所期望的 300,000 QPS.也许,会有人提到使用 HANDLER ,但是因为在解析 SQL时,opening/closing table 还是必须的,所以对于提高吞吐量,它还是只能爱莫能助。

  如果只有一小部分数据进入内存,那么 SQL 带来的消耗可以忽略不计。很简单,因为磁盘的 I/0 操作所带来的消耗会要大,这种情况下时,就不需要太过的去考虑 SQL 所带来的消耗。

  但是,在大多数的 hot MySQL 服务器中, 大部分的数据都是因为全部载入至内存中而变的只受 CPU 的限制。Profiling 的结果就类似上所述的那样: SQL 层消耗了大量的资源。假设,需要做大量的 PK 查询(i.e. SELECT x FROM t WHERE id=?)或者是做 LIMIT 的范围查询, 即使有 70-80% 都是在同一张表中做 PK 查询(仅仅只是查询条件中给定的值不同,即 value 不同而已), MySQL 还是每次需要去做 parse/open/lock/unlock/close, 这对我们来说,是非常影响效率的。

  到底有没有好的方法来减少 MySQL SQL 层的 CPU 资源/争夺呢? 如果使用 MySQL Cluster, NDBAPI 不失为一个很好的解决办法。 在我还是 MySQL/Sun/Oracle 的顾问时,就见到过很多客户对SQL Node + NDB performance 感到非常不爽,但当他们用了 NDBAPI 客户端后,发现性能调提高了 N 倍。当然,在 MySQL Cluster 中是可以同时使用 NDBAPI 和 SQL 的,但在做频繁的访问模式时还是推荐使用 NDBAPI,而在 ad-hoc 或者 查询不频繁的情况下使用 SQL + MySQL + NDB。

  以快捷的速度访问 API, 这正是我们需要的,但同时我们也想在 ad_hoc 或者复杂的查询的情况时还是使用 SQL. 像其他的 web service, DeNA 使用的是 InnoDB, 转为 NDB,这并不是一件容易的事情,因为内置InnoDB 即不支持 SQL 也不支持网络层的服务。

  最好的办法可以是在 MySQL 的内部,实现一以 MySQL plugin 的形式存在的 NoSQL 的网络服务。它侦听在某端口来接收采用 NoSQL 协议/API 的通讯, 然后通过 MySQL 内部的存储引擎 API 来直接访问 InnoDB。这种方法的理念类似于 NDBAPI, 但是它可以做到与 InnoDB 通讯。

  这个理念最初是去年由 Kazuho Oku 在 Cybozu Labs 上提出的,他曾写过采用 Memcached protocols 通讯的MyCached UDF。而我的大学同学实现了另外一个插件 ― HandlerSocket,

  是以 MySQL daemaon plugin 形式存在,所以在应用中可把 MySQL 当 NoSQL 使用. 它最大的功能是实现了与存储引擎交互,比如 InnoDB,而这不需要任何的 SQL 方面的开销. 访问 MySQL 的 table 时,当然她也是需要 open/close table 的,但是 它并不是每次都去 open/close table, 因为它会将以前访问过的 table 保存下来以供来是使用,而 opening/closing tables 是最耗资源的,而且很容易引起互斥量的争夺,这样一来,对于提高性能,非常有效。在流量变小时, HandlerSocket 会 close tables, 所以,它不会阻塞 administrative commands (DDL).

  它与MySQL + Memcached 的区别在哪呢? 对比图1 和图2 ,可从中看出其不同点。图2 展示了典型的 MySQL + Memecached 的使用. 因为 Memcached 的 get 操作比 MySQL 的内存中/磁盘上的主键查询要快很多,所以 Memcached 用于缓存数据库记录。如果 HandlerSocket 的查询速度能和 Memcached 媲美,我们就不需要使用 Memcached 来缓存记录。

  

  举一个例子,假设有一 user 表,通过 user_id 来获取用户信息:

CREATE TABLE user
(
user_id INT UNSIGNED PRIMARY KEY,
user_name VARCHAR(50),
user_email VARCHAR(255),
created DATETIME
)
ENGINE=InnoDB;

  用 SELECT 语句获取用户信息

mysql> SELECT user_name, user_email, created FROM user WHERE user_id=101;
+---------------+-----------------------+---------------------+
| user_name     | user_email            | created
|  +---------------+-----------------------+---------------------+
| Yukari Takeba | [email protected] | 2010-02-03 11:22:33
|  +---------------+-----------------------+---------------------+
1 row in set (0.00 sec)

  下面我们来看看如何使用 HandlerSocket 完成同样的事情.

HandlerSocket

目录:

HandlerSocket的原理

HandlerSocket的优势和缺陷阐述

HandlerSocket的性能测试

HandlerSocket的原理

HandlerSocket的应用场景:

MySQL自身的局限性,很多站点都采用了MySQL+Memcached的经典架构,甚至一些网站放弃MySQL而采用NoSQL产品,比如Redis/MongoDB等。不可否认,在做一些简单查询(尤其是PK查询)的时候,很多NoSQL产品比MySQL要快很多,而且前台网站上的80%以上查询都是简洁的查询业务。

MySQL通过HandlerSocket插件提供了API访问接口,在我们的基准测试中,普通的R510服务器单实例Percona/XtraDB达到了72W+QPS(纯读),如果采用更强劲的CPU增加更多的网卡,理论上可以获得更高的性能。而同等条件下Memcached仅有40W+QPS(纯读),并且在R510上Memcached单实例已经无法提升性能,因为Memcached对内存的一把大锁限制了它的并发能力。

HandlerSocket原理:

MySQL的架构是“数据库管理”和“数据管理”分离,即MySQL Server+Storage Engine的模式。MySQL Server是直接与Client交互的一层,它负责管理连接线程,解析SQL生成执行计划,管理和实现视图、触发器、存储过程等这些与具体数据操作管理无关的事情,通过调用Handler API让存储引擎去操作具体的数据。Storage Engine通过继承实现Handler API的函数,负责直接与数据交互,数据存取实现(必须实现),事务实现(可选),索引实现(可选),数据缓存实现(可选)。

图片 1

(图1-1 MySQL架构)

HandlerSocket是在MySQL的内部组件,以MySQL Daemon Plugin的形式提供类似NoSQL的网络服务,它并不直接处理数据,只是侦听配置好的某个端口方式,接收采用NoSQL/API的通讯协议,然后通过MySQL内部的Handler API来调用存储引擎(例如InnoDB)处理数据。理论上,HanderSocket可以处理各种MySQL存储引擎,但是用MyISAM时,会出现插入的数据查不出来,这个实际上是构造行时第一字节没有初始化为0xff,初始化以后就没有问题,MyISAM也一样可以支持,但是为了更好地利用内存,用HandlerSocket都会搭配InnoDB存储引擎一起使用。

图1-2描述HandlerSocket具体做了哪些事情:

图片 2

(图1-2 HandlerSocket原理)

因为HandlerSocket是以MySQL Daemon Plugin形式存在,所以在应用中,可把MySQL当NoSQL使用。它最大的功能是实现了与存储引擎交互,比如InnoDB,而这不需要任何SQL方面的初始化开销。访问MySQL的TABLE时,当然也是需要open/close table的,但是它并不是每次都去open/close table,因为它会将以前访问过的table cache保存下来以重复使用,而opening/closing tables是最耗资源的,而且很容易引起互斥量的争夺,这样一来,对于提高性能非常有效。在流量变小时,HandlerSocket会close tables,所以它一般不会阻塞DDL。

HandlerSocket与MySQL+Memcached的区别在哪呢?对比图1-2和图1-3,可从中看出其不同点,图1-3展示了典型的MySQL+Memecached的应用架构。因为Memcached的get操作比MySQL的内存中或磁盘上的主键查询要快很多,所以Memcached用于缓存数据库记录。若是HandlerSocket的查询速度和相应时间能与Memcached媲美,我们就可以考虑替换Memcached缓存记录的架构层。

图片 3

(图1-3 典型MySQL+Memcached架构)

HandlerSocket的优势和缺陷阐述

HandlerSocket的优势和特点:

1) 支持多种查询模式

HandlerSocket目前支持索引查询(主键索引和非主键的普通索引均可),索引范围扫描,LIMIT子句,也即支持增加、删除、修改、查询完整功能,但还不支持无法使用任何索引的操作。另外支持execute_multi() 一次网络传输多个Query请求,节省网络传输时间。

2) 处理大量并发连接

HandlerSocket的连接是轻量级的,因为HandlerSocket采用epoll() 和worker-thread/thread-pooling架构,而MySQL内部线程的数量是有限的(可以由my.cnf中的handlersocket_threads/handlersocket_threads_wr参数控制),所以即使建立上千万的网络连接到HandlerSocket,也不会消耗很多内存,它的稳定性不会受到任何影响(消耗太多的内存,会造成巨大的互斥竞争等其他问题,如bug#26590,bug#33948,bug#49169)。

3) 优秀的性能

HandlerSocket的性能见文章HandlerSocket的性能测试报告描述,相对于其它NoSQL产品,性能表现一点也不逊色,它不仅没有调用与SQL相关的函数,还优化了网络/并发相关的问题:

(1). 更小的网络数据包:和传统 MySQL 协议相比,HandlerSocket 协议更简短,因此整个网络的流量更小。

(2). 运行有限的MySQL内部线程数:参考上面的内容。

(3). 将客户端请求分组:当大量的并发请求到达HandlerSocket时,每个工作线程尽可能多地聚集请求,然后同时执行聚集起来的请求和返回结果。这样,通过牺牲一点响应时间,而大大地提高性能。例如,可以减少fsync()调用的次数,减少复制延迟。

4) 无重复缓存

当使用Memcached缓存MySQL/InnoDB记录时,在Memcached和InnoDB Buffer Pool中均缓存了这些记录,因此效率非常低(实际上有两份数据,Memcached本身可能还需要做HA支持),而采用 HandlerSocket插件, 它直接访问 InnoDB 存储引擎,记录缓存在InnoDB Buffer Pool,于是其它SQL语句还可以重复使用缓存的数据。

5) 无数据不一致的现象

由于数据只存储在一个地方(InnoDB存储引擎缓存区内),不像使用Memcached时,需要在Memcached和MySQL之间维护数据一致性。

6) 崩溃安全

后端存储是InnoDB引擎,支持事务的ACID特性,能确保事务的安全性,即使设置innodb_flush_log_at_trx_commit=2,若数据库服务器崩溃时,也只会丢掉<= 1s的数据。

7) SQL/NOSQL并存

在许多情况下,我们仍然希望使用SQL(例如复杂的报表查询),而大多数NoSQL产品都不支持SQL接口,HandlerSocket仅仅是一个 MySQL 插件,我们依然可以通过MySQL客户端发送SQL语句,但当需要高吞吐量和快速响应时,则使用 HandlerSocket。

8) 继承MySQL的功能

因为HandlerSocket运行于MySQL,因此所有MySQL的功能依然被支持,例如:SQL、在线备份、复制、HA、监控等等。

9) 不需要修改/重建MySQL

因为HandlerSocket是一个插件并且开源,所以它支持从任何MySQL源码、甚至是第三方版本(例如Percona)构建,而无需对MySQL做出任何修改。

10) 独立于存储引擎

虽然我们只测试了MySQL-EnterpriseInnoDB和Percona XtraDB插件,但HandlerSocket理论上可以和任何存储引擎交互。MyISAM通过简单的修改也是可以被支持的,但是从数据缓存而利用内存的角度看这个意义不大。

HandlerSocket的缺陷和注意事项

1) 协议不兼容

HandlerSocket API与Memcached API并不兼容,尽管它很容易使用,但仍然需要一点学习来学会如何与HandlerSocket交互。不过我们可以通过重载Memecached函数来翻译到HandlerSocket API。

2) 没有安全功能

与其它NoSQL数据库类似,HandlerSocket不支持安全功能,HandlerSocket的工作线程以系统用户权限运行,因此应用程序可以通过HandlerSocket协议访问所有的表对象,但是可以通过简单的修改协议,在my.cnf中增加一个配置项为密码,连接时通过这个配置的密码验证,当然也可以通过网络防火墙来过滤数据包。

3) 对于磁盘IO密集的场景没有优势

对于IO密集的应用场景,数据库每秒无法执行数千次查询,通常只有1-10%的CPU利用率,在这种情况下,SQL解析不会成为性能瓶颈,因此使用HandlerSocket没有什么优势,应当只在数据完全装载到内存的服务器上使用 HandlerSocket。但是对于PCI-E SSD(例如Fusion-IO)设备,每秒可以提供4w+ IOPS,并且IO设备本身消耗CPU比较大,使用HandlerSocket依然具有优势。

HandlerSocket的性能测试

HandlerSocket Oprofile测试报告

图片 4

(MySQL通过SQL执行K/V查询的Oprofile信息)

MySQL执行SQL语句,首先要经过SQL解析阶段,调用MYSQLparse() 和MYSQLlex() 进行语法和词法解析;然后进入查询优化阶段,调用make_join_statistics() 和JOIN::optimize() 获得统计信息和生成执行计划,可以清洗第发现,主要耗资源的是SQL解析和优化层,而不是InnoDB存储层,row_search_for_mysql只消耗了很少的时间。

因此我们对比Memcached/NoSQL,知道MySQL除了数据操作,还要很多额外的步骤需要完成:

1 Parsing SQL statements【解析SQL】

2 Opening, locking tables【打开并锁定表】

3 Making SQL execution plans SQL【解析SQL并生成执行计划】

4 Unlocking, closing tables【解锁并关闭表】

另外,MySQL 还必须要做大量的并发控制,比如在发送/接收网络数据包的时候,fcntl() 就要被调用很多次;Global mutexes比如LOCK_open,LOCK_thread_count也被频繁地取得/释放。所以在Oprofile的输出中,排在第二位的是my_pthread_fastmutex_lock()。并且Mutex的竞争带来的上下文切换,导致%system占用CPU使用比例相当高(>20%)。

其实, MySQL 开发团队和外围的开发团体早已意识到大量并发控制对性能的影响,MySQL 5.5中已经解决了一些问题,Percona也对Mutex做了一些拆分处理,未来的MySQL版本中,也应该会越来越好。

在完全内存操作的情况时,CPU的效率非常重要。如果只有一小部分数据进入内存,那么SQL语句带来的消耗可以忽略不计。很简单,因为机械磁盘IO操作的时间消耗远比CPU解析SQL语句的时间消耗多,这种情况下,就不需要过分考虑SQL语句所带来的消耗。但是对于SSD盘,尤其是PCI-E SSD盘,响应时间在微秒级(Fusion I/O为30us左右),就必须考虑SQL带来的消耗了。

在大多数的MySQL 服务器中,大部分的热点数据都缓存在内存中,因而访问变得只受CPU的限制。Profiling 的结果就类似上所述的情况:SQL 层消耗了大量的资源。假设需要做大量的PK查询(例如:SELECT x FROM t WHERE id=?)或者是做LIMIT的范围查询,即使有70-80%都是在同一张表中做PK查询(仅仅只是查询条件中给定的值不同,即value不同而已), MySQL 还是每次需要去做 parse/open/lock/unlock/close, 这对我们来说是非常影响效率的事情。

图片 5

(MySQL通过HandlerSocket执行K/V查询的Oprofile信息)

HandlerSocket性能测试报告:

【测试主机】

机型:R510

CPU:Intel(R) Xeon(R) CPU E5520 @ 2.27GHz

内存:4G*6

磁盘:146G*2(OS) + 300G*12 RAID10(data)

1) 完全随机测试

图片 6

测试场景描述:

单实例MySQL 5.1.48 InnoDB Plugin

测试SQL:INSERT INTO table (key, value) VALUES(#key#, #value#) / SELECT value FROM table WHERE key=#key#

HS API:execute_single

2) 重复获取同一条数据

图片 7

测试场景描述:

1 单实例Percona 5.1.57-12.8 XtraDB

2 测试SQL:SELECT value FROM table WHERE key=#key#

3 HS API:execute_single

4 MC API:get

安装 HandlerSocket

  HandlerSocket具体安装步骤请参考这里,基本步骤如下:

1 下载HandlerSocket
2 编译 HandlerSocket(客户端和服务端)

[[email protected] handlersocket]# ./configure --with-mysql-source=mysql-source-dir --with-mysql-bindir=mysql-server-bin-dir
[[email protected] handlersocket]# make
[[email protected] handlersocket]# make install

3 安装 HandlerSocket

mysql> INSTALL PLUGIN 'handlersocket' soname 'handlersocket.so';

  因为 HandlerSocket是 MySQL 插件,所以可以象使用其它插件,如 InnoDB, Q4M 和 Spider 那样使用它,即不需要修改 MySQL 源代码,MySQL 最好是 5.1 或更高版本,编译 HandlerSocket 时需要 MySQL 源码和 MySQL 库。

书写 HandlerSocket 客户端代码

  目前已提供 C++ 和 perl 调用的客户端库,下面是使用 perl 调用的实例代码:

#!/usr/bin/perl  

use strict;
use warnings;
use Net::HandlerSocket;  

#1. establishing a connection
my $args = { host => 'ip_to_remote_host', port => 9998 };
my $hs = new Net::HandlerSocket($args);  

#2. initializing an index so that we can use in main logics.
# MySQL tables will be opened here (if not opened)
my $res = $hs->open_index(0, 'test', 'user', 'PRIMARY',
    'user_name,user_email,created');
die $hs->get_error() if $res != 0;  

#3. main logic
#fetching rows by id
#execute_single (index id, cond, cond value, max rows, offset)
$res = $hs->execute_single(0, '=', [ '101' ], 1, 0);
die $hs->get_error() if $res->[0] != 0;
shift(@$res);
for (my $row = 0; $row < 1; ++$row) {
  my $user_name= $res->[$row + 0];
  my $user_email= $res->[$row + 1];
  my $created= $res->[$row + 2];
  print "$user_name\t$user_email\t$created\n";
}  

#4. closing the connection
$hs->close()

#!/usr/bin/perl  

use strict;
use warnings;
use Net::HandlerSocket;  

#1. establishing a connection
my $args = { host => 'ip_to_remote_host', port => 9998 };
my $hs = new Net::HandlerSocket($args);  

#2. initializing an index so that we can use in main logics.
# MySQL tables will be opened here (if not opened)
my $res = $hs->open_index(0, 'test', 'user', 'PRIMARY',
    'user_name,user_email,created');
die $hs->get_error() if $res != 0;  

#3. main logic
#fetching rows by id
#execute_single (index id, cond, cond value, max rows, offset)
$res = $hs->execute_single(0, '=', [ '101' ], 1, 0);
die $hs->get_error() if $res->[0] != 0;
shift(@$res);
for (my $row = 0; $row < 1; ++$row) {
  my $user_name= $res->[$row + 0];
  my $user_email= $res->[$row + 1];
  my $created= $res->[$row + 2];
  print "$user_name\t$user_email\t$created\n";
}  

#4. closing the connection
$hs->close();

  上面代码是通过 user_id=101 条件在 user 表获取用户 user_name, user_email和 created 信息,得到的结果应该和之前在 MySQL client 查询出来的结果一样。

[[email protected] ~]$ perl sample.pl
Yukari Takeba   [email protected]   2010-02-03 11:22:33

  对于大多数Web应用程序而言,保持轻量级的 HandlerSocket 连接是一个很好的做法(持续连接),让大量的请求可以集中于主要逻辑(上面代码中的#3部分)。

   HandlerSocket 协议是一个小尺寸的基于文本的协议,和 Memcached 文本协议类似,可以使用 telnet 通过 HandlerSocket 获取数据。

[[email protected] ~]$ telnet 192.168.1.2 9998
Trying 192.168.1.2...
Connected to xxx.dena.jp (192.168.1.2).
Escape character is '^]'.
P       0       test    user    PRIMARY user_name,user_email,created
0       1
0       =       1       101
0       3       Yukari Takeba   [email protected]   2010-02-03 11:22:33
(Green lines are request packets, fields must be separated by TAB)

  绿色表示请求数据包,字段必须用Tab键分隔。

  现在是时候展示基准测试结果,使用上面的 user 表,从多线程远程客户端测试了执行主键查询操作的次数,所有用户数据都装入到内存中(我测试了 100 万行),也用类似的数据测试了 Memcached(我使用 libMemcached 和 Memcached_get() 获取用户数据),在 MySQL SQL 测试中,我使用了的是传统的 SELECT 语句: “SELECT user_name, user_email, created FROM user WHERE user_id=?”, Memcached 和 HandlerSocket 客户端代码均使用 C/C++ 编写,所有客户端程序都位于远程主机上,通过 TCP/IP 连接到 MySQL/Memcached。最高的吞吐量情况如下:

                            approx qps     server CPU util
MySQL via SQL               105,000      %us 60%  %sy 28%
Memcached                   420,000      %us  8%  %sy 88%
MySQL via HandlerSocket     750,000      %us 45%  %sy 53%

  HandlerSocket的吞吐量比使用传统 SQL 时高出 7.5, 而且 %us 也只有使用传统 SQL 时的3/4, 这说明 MySQL 的 SQL 层是非常耗资源的,如果能跳过这一层,性能肯定会大大提升。有趣的是,MySQL 使用 HandlerSocket 时的速度比使用 Memcached 也要快 178%,并且 Memcached 消耗的 %sy 资源也更多。所以虽然 Memcached 是一个很好的产品,但仍然有优化的空间。

  下面是oprofile输出内容,是在 MySQL HandlerSocket 测试期间收集到的,在核心操作,如网络数据包处理,获取数据等的 CPU 资源消耗(bnx2是一个网络设备驱动程序)。

samples  %        app name                 symbol name
984785    5.9118  bnx2                     /bnx2
847486    5.0876  ha_innodb_plugin.so.0.0.0 ut_delay
545303    3.2735  ha_innodb_plugin.so.0.0.0 btr_search_guess_on_hash
317570    1.9064  ha_innodb_plugin.so.0.0.0 row_search_for_mysql
298271    1.7906  vmlinux                  tcp_ack
291739    1.7513  libc-2.5.so              vfprintf
264704    1.5891  vmlinux                  .text.super_90_sync 

248546    1.4921  vmlinux                  blk_recount_segments
244474    1.4676  libc-2.5.so              _int_malloc
226738    1.3611  ha_innodb_plugin.so.0.0.0 _ZL14build_template  P19row_prebuilt_structP3THDP8st_tablej
206057    1.2370  HandlerSocket.so         dena::hstcpsvr_worker::run_one_ep()
183330    1.1006  ha_innodb_plugin.so.0.0.0 mutex_spin_wait
175738    1.0550  HandlerSocket.so         dena::dbcontext::  cmd_find_internal(dena::dbcallback_i&, dena::prep_stmt const&,   ha_rkey_function, dena::cmd_exec_args const&)
169967    1.0203  ha_innodb_plugin.so.0.0.0 buf_page_get_known_nowait
165337    0.9925  libc-2.5.so              memcpy
149611    0.8981  ha_innodb_plugin.so.0.0.0 row_sel_store_mysql_rec
148967    0.8943  vmlinux                  generic_make_request

  因为 HandlerSocket 是运行于 MySQL 内部,直接与 InnoDB 交互,所以,可以使用常见的 SQL 命令,如 SHOW GLOBAL STATUS 获得统计信息,Innodb_rows_read 达到了 750000+ 是值得一看的。

$ mysqladmin extended-status -uroot -i 1 -r | grep "InnoDB_rows_read"
...
| Innodb_rows_read                      | 750192     |
| Innodb_rows_read                      | 751510     |
| Innodb_rows_read                      | 757558     |
| Innodb_rows_read                      | 747060     |
| Innodb_rows_read                      | 748474     |
| Innodb_rows_read                      | 759344     |
| Innodb_rows_read                      | 753081     |
| Innodb_rows_read                      | 754375     |
...

  测试用机的详细信息如下:

型号 戴尔PowerEdge R710
CPU Nehalem 8核,[email protected]
内存 32GB(所有数据都装入缓冲池)
MySQL 5.1.50 InnoDB
Memcached/libMemcached 1.4.5(Memcached),0.44(libMemcached)
Network Boradcom NetXtreme II BCM5709 1000Base-T(内建四端口,使用了其中三个)

  Memcached 和 HandlerSocket 都做了网络 I/O 限制,当我测试单个端口时,HandlerSocket 的 QPS 为 260000,而 Memcached 为 220000。 

  如下所述,HandlerSocket 有其自己的特点和优势,而其中一些对我们来说, 是真的很给力.

支持多种查询模式

  HandlerSocket 目前支持 主键/唯一性查询,非唯一性索引查询,范围扫描,LIMIT 和 INSERT/UPDATE/DELETE,但还不支持未使用任何索引的操作。另外,multi_get()(类似于in(1,2,3), 只需一次网络往返)还可获取多行数据。到这里可查询详细信息。

处理大量并发连接

  HandlerSocket 连接是轻量级的,因为 HandlerSocket 采用epoll()和 worker-thread/thread-pooling 架构,而 MySQL 内部线程的数量是有限的(可以由 my.cnf中的 handlersocket_threads参数控制),所以即使建立上千万的网络连接到 HandlerSocket,它的稳定性也不会受到任何影响(消耗太多的内存,会造成巨大的互斥竞争等其他问题,如bug#26590,bug#33948,bug#49169)。

及其优秀的性能

  HandlerSocket,如上所描述, 相对于其它 NoSQL 阵容,性能表现一点也不逊色。事实上,我还未曾见过哪个 NoSQL 产品在一台普通服务器上可达到 750000+ 次查询。它不仅没有调用与 SQL 相关的函数,还优化了网络/并发相关的问题。

更小的网络数据包

   和传统 MySQL 协议相比,HandlerSocket 协议更简短,因此整个网络的流量更小。

运行有限的 MySQL 内部线程数

   参考上面的内容。

将客户端请求分组

   当大量的并发请求抵达 HandlerSocket 时,每个工作线程尽可能多地聚集请求,然后同时执行聚集起来的请求和返回结果。这样,通过牺牲一点响应时间,而大大地提高性能。例如,你可以得到以下好处,如果有人感兴趣,我会在今后的文章中对它们加以深入的解释。

   减少fsync()调用的次数.

   减少复制延迟.

无重复缓存

  当使用 Memcached 缓存 MySQL/InnoDB 记录时,在 Memcached 和 InnoD B缓冲池中均缓存了这些记录,因此效率非常低(内存仍然很贵). 而采用 HandlerSocket插件, 由于它访问 InnoDB 存储引擎,记录缓存在 InnoDB 缓冲池中,这样,其它 SQL 语句就可以重复使用它。

无数据不一致的现象

  由于数据只存储在一个地方(InnoDB 内),不像使用 Memcached 时,需要在 Memcached 和 MySQL 之间检查数据一致性。