hive hbase handler_handler:function_handlersocket

- 在一台Commodity Server上实现超过750000 QPS的故事

QPS：Queries Per Second意思是“每秒查询率”，是一台服务器每秒能够相应的查询次数，是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准。

Oracle官方已经发布memcached守护程序插件，用于InnoDB，我很高兴地看到，NoSQL + MySQL已经成为一个正式的解决方案。这将是非常有前途的。让我们尝试它，使其更好地发展。

由于mysql的局限性，很多站点都采用了mysql+memcached的架构。

另外一些站点放弃了mysql，采用了NoSQL，比如TokyoCabinet/Tyrant等等。

不可否认，在做一些简单查询（尤其是primary key 查询）的时候，NoSQL比mysql要快很多很多。而且网站上的绝大多数查询都是这样的简单查询。

但是DeNA公司却一直使用mysql和memcached，并且在单台普通服务器上创造了每秒750,000次简单查询的记录。

或许你们不会相信单台mysql可以做到750,000 qps，但这是事实，下面就来详细说说。

SQL真的适合做primary key 查询么？

DeNA 公司的应用经常要进行primary key(PK)查询。比如根据user id取出userinfo，根据diary id取出日志内容， memcached和NoSQL很适合做这种事情。

如果进行memcached 的测试，很有可能每秒可以进行400,000次get操作,即使memcached和client位于不同的服务器。

在一台2.5GHz8核Nehalem 3块千M网卡的服务器上，libmemcached和memcached每秒可以进行420,000次get 操作。

mysql5呢？每秒可以做多少次PK查询？

innodb:

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

此外也可以使用 sysbench或者super-smack等工具进行benchmark。

新开一个shell看一下：

[matsunobu@host ~]$ 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 | 108115 |
...

100,000 qps 大概是memcached的1/4左右。

为什么会慢这么多呢？

服务器内存足够，这些数据应该都在内存中。

同样是内存操作，为什么mysql比memcached慢这么多？

vmstat数据如下：

[matsunobu@host ~]$ 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

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/jisuanjixue/article-27117-1.html