mysql의 한계로 인해 많은 사이트가 mysql+memcached 아키텍처를 채택합니다.
TokyoCabinet/Tyrant 등 일부 다른 사이트에서는 mysql을 포기하고 NoSQL을 채택했습니다.
일부 간단한 쿼리(특히 기본 키 쿼리)를 수행할 때 NoSQL이 mysql보다 훨씬 빠르다는 것은 부인할 수 없습니다. 그리고 웹사이트에 있는 대부분의 쿼리는 이와 같은 간단한 쿼리입니다.
그런데 DeNA는 mysql과 memcached를 이용해 단일 일반 서버에서 초당 75만 건의 단순 쿼리 기록을 만들어냈다.
단 하나의 mysql이 750,000qps를 달성할 수 있다는 사실이 믿기지 않을 수도 있지만, 이는 아래에서 자세히 이야기해 보겠습니다.
DeNA 회사의 애플리케이션에는 기본 키(PK) 쿼리가 필요한 경우가 많습니다. 예를 들어, userinfo는 user id를 기반으로 하고, log content는 Diary id를 기반으로 검색하는데, Memcached와 NoSQL이 이런 일에 매우 적합합니다.
memcached를 테스트하면 memcached와 클라이언트가 다른 서버에 있더라도 초당 400,000개의 가져오기 작업을 수행할 가능성이 높습니다.
2.5GHz 8코어 Nehalem 3킬로M 네트워크 카드가 있는 서버에서 libmemcached 및 memcached는 초당 420,000개의 가져오기 작업을 수행할 수 있습니다.
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- 벤치마킹을 위해 헤로인합니다.
새 쉘을 열고 살펴보세요:
[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,000qps는 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
% user 및 %system이 차지하는 CPU가 상당히 높습니다.
oprofile의 통계 정보를 살펴보세요.
ps: 이 도구는 커널 수준에서 훌륭합니다.
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 /bnx2 84550 1.4748 ha_innodb_plugin.so.0.0.0 ut_delay 67945 1.1851 mysqld _ZL20make_join_statistics P4JOINP10TABLE_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
MYSQLparse는 버전 5.x이고 YYparse는 4.x입니다
mysql이 sql 문을 구문 분석할 때 MYSQLparse() 및 MYSQLlex()가 호출됩니다.
make_join_statistics() 및 JOIN::optimize()는 쿼리 최적화 단계에서 호출됩니다.
이러한 추가 부담이 있는 것은 바로 SQL 문을 사용하기 때문입니다.
oprofile의 출력에서 다음과 같은 결론을 도출할 수 있습니다.
SQL 계층은 mysql 쿼리 성능에 심각한 영향을 미칩니다.
memcached 및 SQL과 비교할 때 mysql은 몇 가지 추가 작업을 수행해야 합니다.
* SQL 문 구문 분석 sql 문 구문 분석
* 테이블 열기, 잠금 테이블 열기 및 잠금
* SQL 실행 계획 세우기 ???
* 테이블 잠금 해제, 닫기 테이블 잠금 해제 및 닫기
Hua Rong의 메모: SQL 문 구문 분석을 방지하려면 mysqli에서 준비된 문 API를 사용하세요.
Mysql도 동시성 제어를 많이 해야 합니다. 예를 들어 네트워크 데이터 패킷을 보내고 받을 때 fcntl()이 여러 번 호출됩니다.
전역 뮤텍스: LOCK_open LOCK_thread_count도 자주 호출됩니다.
그래서 oprofile의 출력에서 두 번째는 my_pthread_fastmutex_lock()입니다. 그리고 %system이 차지하는 CPU도 꽤 높습니다(28%).
실제로 MySQL 개발팀과 일부 주변 개발 그룹은 수많은 동시성 제어가 성능에 미치는 영향을 이해하고 있습니다.
그들은 MySQL 5.5의 특정 문제를 해결했습니다. 미래의 mysql에서는 %system이 점점 더 적은 CPU를 차지하게 될 것입니다.
그런데 %user가 점유하고 있는 CPU의 60%를 어떻게 해야 할까요?
rree동시성 문제를 모두 해결하더라도 30만qps 달성은 어려울 것으로 추정된다.
아마도 HANDLER 문의 성능도 좋다는 이야기를 들어보셨을 것입니다.
그러나 HANDLER 문에는 쿼리 구문 분석과 테이블 열기/닫기가 필요합니다.
별로 도움이 되지 않습니다.
아주 작은 부분의 데이터만 들어갈 수 있다면 메모리, SQL 문 구문 분석에 대한 추가 부담은 없습니다.
디스크 IO 작업이 더 오래 걸리기 때문입니다.
저희 mysql 서버는 메모리 용량이 커서 거의 모든 데이터를 메모리에 담을 수 있습니다.
SQL 계층은 추가 부담이 되고 CPU 리소스를 많이 차지합니다.
在线上的应用中，我们要进行大量的PK查询。即使70-80%的查询都是在同一张表上进行的， mysql还是每次都要parse/open/lock/unlock/close，看起来就感觉效率低下。
We needed to execute lots of primary key lookups(i.e. SELECT x FROM t WHERE id=?) or limited range scans. Even though 70-80% of queries were simple PK lookups from the same table (difference was just values in WHERE), every time MySQL had to parse/open/lock/unlock/close, which seemed not efficient for us.
花荣注：难道说mysql中的table_open_cache不是用来减少table open的次数的么。。
有没有办法在sql层进行优化呢？
http://dev.mysql.com/doc/ndbapi/en/index.html
如果你使用mysql cluster, NDBAPI会是最佳解决方案。
It’s recommended using NDBAPI for frequent access patterns, and using SQL + MySQL + NDB for ad-hoc or infrequent query patterns.
这就是我们想要的：
1 faster access API.
2 sql语句仍然要可用,以处理一些特定的或者复杂的查询。
但是，把innodb转化成ndb可不是一件轻松的事情。
最好的办法是在mysql内部实现一个NoSQL的网络服务。daemon plugin。
它监听在某个端口，接受NoSQL 协议/API的数据包，使用Mysql internal storage engine API直接在innodb数据表上进行操作，并且返回相应的数据。
关于mysql internal storage engine API可以看这个文档：
//m.sbmmt.com/
这个概念首先被Cybozu Labs 的Kazuho Oku 提出，然后他写了一个MyCached UDF，用的是memcached的协议。
http://developer.cybozu.co.jp/kazuho/2009/08/mycached-memcac.html
随后，Akira Higuchi 写了另外一个plugin: HandlerSocket。
http://github.com/ahiguti/HandlerSocket-Plugin-for-MySQL
从图中可以看到，客户端既可以使用普通的mysql api来操作mysql(3306端口)，
也可以使用HandlerSocket API对数据库进行PK查询，以及INSERT/UPDATE/DELETE操作(9998与9999端口)。
在使用HandlerSocket操作的时候，省去了SQL parsing, Opening table, Making Query Plans, Closing table等步骤。
而且数据都是保存在原来的INNODB表中的。
在HandlerSocket操作innodb数据表的时候，显然也需要open/close table。
但它只打开一次，然后会reuse。
由于open/close table非常耗时，并且会带来严重的mutex竞争，所以这种改进，极大地提升了性能。
Of course HandlerSocket closes tables when traffics become small etc so that it won’t block administrative commands (DDL) forever.
memcached主要用来缓存数据集(database records)。
因为memcached的get操作比mysql的PK查询要快得多。
如果HandlerSocket获取数据的速度比memcached还要快，那么我们就没必要再使用memcached来缓存数据集了。做做其它缓存还是可以的。比如生成出来的HTML代码，还有一些统计数据等等。
花荣注：貌似我从来没有直接把mysql的数据集扔到memcached中。一直都是把中间结果保存到里面。难道走偏了？
看下面这张user表：
CREATE TABLE user ( user_id INT UNSIGNED PRIMARY KEY, user_name VARCHAR(50), user_email VARCHAR(255), created DATETIME ) ENGINE=InnoDB;
在mysql中取出数据的方法如下：
mysql> SELECT user_name, user_email, created FROM user WHERE user_id=101; +---------------+-----------------------+---------------------+ | user_name | user_email | created | +---------------+-----------------------+---------------------+ | Yukari Takeba | yukari.takeba@dena.jp | 2010-02-03 11:22:33 | +---------------+-----------------------+---------------------+
在HandlerSocket中怎样操作呢？
详细文档看这里：
http://github.com/ahiguti/HandlerSocket-Plugin-for-MySQL/blob/master/docs-en/installation.en.txt
大概安装步骤如下：
1 下载
http://github.com/ahiguti/HandlerSocket-Plugin-for-MySQL
2 编译 HandlerSocket客户端和服务器端程序：
./configure --with-mysql-source=... --with-mysql-bindir=... ; make; make install
3 安装插件
mysql> INSTALL PLUGIN 'HandlerSocket' SONAME 'HandlerSocket.so';
安装完毕。不需要修改mysql的源代码。
mysql需要5.1或者以后版本。
目前HandlerSocket客户端只有C++ 和 Perl的库。还没有php和C的。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 로그인 후 복사 |
#!/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表中取出来了 user_name, user_email 和created字段。
[matsunobu@host ~]$ perl sample.pl Yukari Takeba yukari.takeba@dena.jp 2010-02-03 11:22:33
对于HandlerSocket，推荐使用persistent connection。以减少数据库连接的次数。
HandlerSocket协议 is a small-sized text based protocol。
与memcached类似，可以使用telnet来获取数据。
[matsunobu@host ~]$ 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 yukari.takeba@dena.jp 2010-02-03 11:22:33
测试环境：
CPU: Nehalem 8 cores, E5540 @ 2.53GHz RAM: 32GB (all data fit in the buffer pool) MySQL Version: 5.1.50 with InnoDB Plugin memcached/libmemcached version: 1.4.5(memcached), 0.44(libmemcached) Network: Broadcom NetXtreme II BCM5709 1000Base-T x 3
仍然使用上面的user表，数据大概100w行。
SQL语句为：
SELECT user_name, user_email, created FROM user WHERE userid=?
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% HandlerSocket 750,000 %us 45% %sy 53%
HandlerScket比传统的mysql快了7.5倍,而且%us的cpu使用率为mysql的3/4。
说明SQL层还是相当耗时的。避开SQL层之后，性能得到了明显的提升。
HandlerSocket比memcached快了78%。而且%sy占用的cpu比memcached要少得多。
虽然memcached是一个优秀的产品，但是还有很大的提升空间。
花荣注：比如七夜就改写了memcached的部分代码。
再来看一下HandlerSocket测试的时候oprofile的输出：
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
大部分的CPU用在了网络数据包的处理，取出数据，等。
排在首位的bnx2是网卡驱动程序。
由于HandlerSocket只是一个插件，最终还会调用innodb引擎的函数去取数据，
所以我们仍然可以使用mysql命令来获取到统计数据。
$ mysqladmin extended-status -uroot -i 1 -r -p| 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 |
作者注：memcached和HandlerSocket的性能都会受到网络IO的限制。
上面的测试是在3块千M网卡的环境下进行的。如果换成单网卡，HandlerSocket大概每秒处理260,000次查询，memcached每秒处理220,000次查询。
PK肯定没问题
unique key也可以。
普通key也可以。
limit 语句也可以。
IN 也没问题。
INSERT/UPDATE/DELETE也没问题。
不过，一定要用到索引才行。
不使用索引的操作不被支持。 Operations that do not use any index are not supported。
详细说明看这里：//m.sbmmt.com/
HandlerSocket employs epoll() and worker-thread/thread-pooling architecture,the number of MySQL internal threads is limited 。
所以放心地使用persistent connection吧。不会导致mysql connection太高的。
Not only HandlerSocket eliminates SQL related function calls, but also it optimizes around network/concurrency issues
HandlerSocket不仅避开了SQL层，而且优化了网络层，并解决了并发的一些问题。
与mysql协议相比，HandlerSocket协议的数据包更简单更小。
从总体上来看，网络传输的数据量会减少。
不会导致mysql connection太高。
当HandlerSocket接受到请求的时候，每一个处理线程都会收集尽可能多的请求，
然后一次把这些请求执行完毕，并返回数据。
看起来没什么神奇的，但是却可以大大地提升性能。
代价是每个请求的响应时间略微变长。
*** Can reduce the number of fsync() calls
*** Can reduce replication delay
至于详细情况，作者会再写其它文章。很期待。
我们使用memcached的时候，数据会同时缓存到innodb的buffer pool与memcached中。
算是重复的cache吧。
HandlerSocket自身没有缓存，它完全听从InnoDB storage engine。
缓存的一大问题就是数据何时过期。
HandlerSocket没有缓存，也就不存在这种问题。
InnoDB还是相当可靠的。
innodb-flush-log-at-trx-commit=1 加上这句就更保险了。
最多会丢失死机前1秒内的数据。
我们仍然可以使用SQL语句进行复杂的查询。
确实方便很多啊。
HandlerSocket作为插件运行于mysql内部，所以mysql的操作，比如SQL, 热备份，主从，Nagios监视等等，都是支持的。
通过 show global status, show engine innodb status , show processlist 这些都可以看到HandlerSocket的状态。
无需改动mysql的源代码或者重新编译mysql。
线上的环境可以直接使用HandlerSocket。
理论上讲，HandlerSocket支持任何的存储引擎，比如myisam,memory?
不过目前只在mysql5.1 5.5 InnoDB的环境下进行过测试和应用。
目前只有C++和PERL库可用。以后肯定会有php扩展出现。
就像其它的NoSQL数据一样，HandlerSocket没有任何安全方面的功能。比如权限控制之类的。
HandlerSocket的工作线程使用system权限，所以你的应用可以存取所有的表。
当然可以使用防火墙来限制访问。
如果你的内存不够大，内存要与硬盘交换数据，那么HandlerSocket的优势就体现不出来了。
We use HandlerSocket on servers that almost all data fit in memory.
DeNA公司已经在生产环境上使用HandlerSocket了。
The results are great!
有了HandlerSocket可以省掉很大一批memcached服务器与mysql从服务器。
而且带宽占用也得到了缓解。
We’ve been very satisfied with the results。 Since HandlerSocket plugin is Open Source, feel free to try. We’d be appreciated if you give us any feedback.
以上就是[转]Mysql的HandlerSocket插件 的内容，更多相关内容请关注PHP中文网（m.sbmmt.com）！
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
