NoSQL小故事：單服務器如何應付每秒75萬次查詢
原創【51CTO經典譯文】大多數大規模Web應用程序都使用MySQL+Memcached架構，其中許多應用也同時使用了NoSQL數據庫，如TokyoCabinet/Tyrant，也有一些人全部放棄MySQL，轉投NoSQL的懷抱，曾經有人將這稱為NoSQL運動，因為NoSQL數據庫在處理一些簡單訪問模式，如主鍵查找時，比MySQL的表現更好，大多數Web應用程序的查詢都很簡單，因此這看上去是一個很合理的決定。
和許多其它大規模網站一樣，我們的DeNA（我于2010年8月離開Oracle，加盟了日本最大的社交游戲平臺提供商DeNA）多年來都存在類似的問題，但我們得出了不同的結論，最終我們全部使用了MySQL，當然一如既往地使用Memcached作為前端緩存（如預處理的HTML，計數/摘要信息），但我們沒有使用Memcached緩存數據行，我們也沒有使用NoSQL，因為我們從MySQL獲得的性能比其它NoSQL產品更好，在我們的基準測試中，我們在一臺普通的MySQL/InnoDB 5.1服務器上獲得了750000+QPS的成績，在生產環境中的性能更優秀。（QPS每秒查詢率，每秒查詢率QPS是對一個特定的查詢服務器在規定時間內所處理流量多少的衡量標準，在因特網上，作為域名系統服務器的機器的性能經常用每秒查詢率來衡量。）
也許你不相信這個成績，但我說的是真的，在這篇文章中，我將分享一下我們是如何做到的。
SQL主鍵查詢真得能很快嗎？
每秒你可以運行多少次主鍵查詢？DeNA的應用程序需要執行大量的主鍵查詢，如通過用戶id獲取用戶信息，通過日記id獲取日志信息，Memcached和NoSQL都能很好地適應這種需求，當你運行簡單的多線程“memcached get”基準測試時，每秒大約可以執行400000+次get操作，即使Memcached客戶端位于遠程服務器上，當我使用最新的libmemcached和memcached測試時，在一臺2.5GHz 8核Nehalem處理器，四個Broadcom千兆以太網卡的服務器上，測試成績是每秒執行420000次get操作。
MySQL執行主鍵查詢需要多長時間？通過基準測試很容易找到答案，只需要從sysbench，super-smack和mysqlslap等運行并行查詢即可。
- [matsunobu@host ~]$ mysqlslap --query="select user_name,..
- from test.user where user_id=1" \
- --number-of-queries=10000000 --concurrency=30 --host=xxx –uroot
你可以使用下面的命令檢查每秒讀取了多少InnoDB行：
- [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 | 108483 |
- | Com_select | 108115 |
- ...
每秒有100000+次查詢似乎還不錯，但卻遠遠低于Memcached的結果，MySQL實際上做了些什么？從vmstat輸出可以看出，%user和%system都很高。
- [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
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 /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
在SQL解析階段調用了MYSQLparse()和MYSQLlex()，在查詢優化階段調用了make_join_statistics()和JOIN::optimize()，這些都是SQL開銷，很明顯，性能下降主要是由SQL層，而不是InnoDB（存儲）層造成的，MySQL做了很多Memcached/NoSQL不需要做的事情，如：
- 解析SQL語句
- 打開，鎖住表
- 創建SQL執行計劃
- 解鎖
- 關閉表
MySQL也做了許多并發控制，例如，在發送/接收網絡數據包時多次調用了fcntl()，全局互斥，如LOCK_open，LOCK_thread_count很頻繁地創建/釋放，這就是為什么oprofile輸出中my_pthread_fastmutex_lock()排名第二，%system也不小的原因。
MySQL開發團隊和外部社區都知道并發問題，有些問題在5.5中已經得到解決，我很高興地看到，大量的修復工作已經完成，但同樣重要的是%user也達到了60%，互斥競爭導致%system上升，而不是%user上升。雖然MySQL中的所有互斥問題都得到了解決，但不要指望每秒超過30萬次查詢。
你可能聽說過HANDLER語句，遺憾的是，HANDLER語句對提高吞吐量并不會有太多幫助，因為查詢解析，打開/關閉表等操作仍然是需要的。
CPU效率對內存中的工作負載非常重要
如果內存中沒有合適的活動數據，SQL開銷相對來說可以忽略不計，很簡單，因為磁盤I/O成本是非常高的，在這種情況下，我們不需要太關心SQL成本。
但在我們的熱點MySQL服務器上，幾乎所有數據都裝入到內存中了，它們完全變成CPU限制，分析結果和上面類似：SQL層消耗了大部分資源。我們需要執行大量的主鍵查詢（如SELECT x FROM t WHERE id=?）或限制范圍的掃描，即使70-80%的查詢是對相同表的簡單主鍵查詢（不同的只是Where子句中的值），每次MySQL都要解析/打開/鎖住/解鎖/關閉，這對我們來說效率是很低的。
#p#
你聽說過NDBAPI嗎？
在MySQL的SQL層有什么好的解決辦法可以減少CPU資源爭用嗎？如果你使用的是MySQL集群，NDBAPI可能是最好的解決方案，我在MySQL/Sun/Oracle擔任顧問時，我看到許多客戶對SQL節點+NDB的性能表現很失望，當使用NDBAPI客戶端性能提高N倍后，他們高興極了，你可以在MySQL集群中同時使用NDBAPI和SQL，建議頻繁訪問模式使用NDBAPI，即席查詢或非頻繁模式使用SQL+MySQL+NDB。
這正是我們想要的，我們希望更快速地訪問API，我們也希望對即席查詢或復雜查詢使用SQL，但DeNA使用的是InnoDB，和許多其它Web服務一樣，切換到NDB不是小事，嵌入式InnoDB不支持SQL也不沒有網絡接口，因此它不適合我們。
HandlerSocket插件，一個懂NoSQL網絡協議的MySQL插件
我們認為最好的辦法是在MySQL內部實現一個NoSQL網絡服務器，也就是說，寫一個網絡服務器作為MySQL插件（守護進程插件）監聽指定端口，接受NoSQL協議/API，然后使用MySQL內部存儲引擎API直接訪問InnoDB。這個方法和NDBAPI類似，但它可以和InnoDB交互，這個概念最初是由Kazuho Oku去年在Cybozu實驗室提出并創建了原型，他編寫了使用memcached協議的MyCached UDF，我的同事Akira Higuchi實現了另一個插件：HandlerSocket，下圖顯示了HandlerSocket可以做的事情。
圖 1 Hanldersocket是什么？
Hanldersocket是一個MySQL守護進程插件，它讓應用程序可以將MySQL當NoSQL使，Hanldersocket的主要目的是與存儲引擎，如InnoDB交互，而不需要SQL相關的開銷。訪問MySQL表時，Hanldersocket仍然需要打開和關閉表，但不是每次訪問都要求打開和關閉，因此減少了互斥爭奪，極大地提高了系統性能，當流量變小時，Hanldersocket會關閉表，因此它永遠不會阻止管理命令（DDL）。
它和使用MySQL+Memcached有什么不同？比較圖1和圖2，我想你會發現很多差異的，圖2顯示了典型的Memcached和MySQL用法，Memcached用于緩存數據庫記錄，這是因為Memcached的get操作比MySQL的內存中/磁盤上的主鍵查詢要快很多，如果HandlerSocket的查詢速度和Memcached一樣快，我們就不用Memcached緩存記錄了。
圖 2 MySQL+Memcached的常見架構模式
使用HandlerSocket
舉一個例子，假設有一個“user”表，我們需要通過user_id獲取用戶信息。
- CREATE TABLE user (
- user_id INT UNSIGNED PRIMARY KEY,
- user_name VARCHAR(50),
- user_email VARCHAR(255),
- created DATETIME
- ) ENGINE=InnoDB;
在MySQL中，可以通過SELECT語句獲取用戶信息。
- 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 |
- +---------------+-----------------------+---------------------+
- 1 row in set (0.00 sec)
下面我們來看看如何使用HandlerSocket完成同樣的事情。
首先需要安裝HandlerSocket，具體安裝步驟請參考這里，基本步驟如下：
1、從這里下載HandlerSocket；
2、生成HandlerSocket（客戶端和服務器端）；
- ./configure --with-mysql-source=... --with-mysql-bindir=... ; make; 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();
上面的代碼從user表查詢user_name，user_email和created列，查詢條件是user_id=101，因此查詢結果和前面的SELECT語句一樣。
- [matsunobu@host ~]$ perl sample.pl
- Yukari Takeba yukari.takeba@dena.jp 2010-02-03 11:22:33
對于大多數Web應用程序而言，保持輕量級的HandlerSocket連接是一個很好的做法（持續連接），讓大量的請求可以集中于主要邏輯（上面代碼中的#3部分）。
HandlerSocket協議是一個小尺寸的基于文本的協議，和Memcached文本協議類似，你可以使用telnet通過HandlerSocket獲取數據。
- [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
綠色表示請求數據包，字段必須用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倍，這說明了MySQL的SQL層是非常耗資源的，如果能跳過這一層性能肯定會大大提升。有趣的是，MySQL使用HandlerSocket時的速度比使用Memcached快178%，并且Memcached消耗的%system資源也更多，雖然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核，E5540@2.53GHz
內存：32GB（所有數據都裝入緩沖池）
MySQL版本：5.1.50，InnoDB插件
Memcached/libmemcached版本：1.4.5（Memcached），0.44（libmemcached）
網絡：Boradcom NetXtreme II BCM5709 1000Base-T（內建四端口，使用了其中三個）
Memcached和HandlerSocket都做了網絡I/O限制，當我測試單個端口時，HandlerSocket的成績是260000qps，Memcached的成績是220000qps。
HandlerSocket的特點和優勢
HandlerSocket有許多特點和優勢，其中有一些是對我們真正有益的。
1、支持大量的查詢模式
HandlerSocket支持主鍵/唯一性查詢，非唯一性索引查詢，范圍掃描，LIMIT和INSERT/UPDATE/DELETE，不支持未使用任何索引的操作，multi_get操作（類似于in(1,2,3)） - 通過單一網絡往返獲取多行數據 – 也是支持的。
2、可以處理大量并發連接
HandlerSocket連接是輕量級的，因為HandlerSocket采用了epoll()和工作線程/線程池架構，MySQL內部線程的數量是有限的（可以由my.cnf中的handlersocket_threads參數控制），因此你可以建立上千或上萬的網絡連接，穩定性不會受到任何影響（消耗太多的內存，造成巨大的互斥競爭等，如bug#26590，bug#33948，bug#49169）。
3、極好的性能
HandlerSocket相對于其它NoSQL陣容性能表現一點也不遜色，事實上，我還沒有看到哪個NoSQL產品在一臺普通服務器上可以執行750000+次查詢。
HandlerSocket不僅消除了SQL相關的函數調用，也優化了網絡/并發相關的問題。
***更小的網絡數據包
HandlerSocket協議和傳統MySQL協議相比更簡單，更小，因此整個網絡的流量也更小。
***運行有限的MySQL內部線程數
參考上面的內容。
***客戶端請求分組
當大量的并發請求抵達HandlerSocket時，每個工作線程盡可能多地聚集請求，然后同時執行聚集起來的請求和返回結果，這樣可以大大地提高性能，只是要犧牲一點響應時間，例如，你可以得到以下好處，如果有人感興趣，我會在今后的文章中對它們加以深入的解釋。
減少fsync()調用的次數
減少復制延遲
4、沒有重復的緩存
當你使用Memcached緩存MySQL/InnoDB記錄時，在Memcached和InnoDB緩沖池中均緩存了這些記錄，因此效率非常低（內存仍然很貴！），由于HandlerSocket插件訪問InnoDB存儲引擎，記錄可以緩存在InnoDB緩沖池中，這樣其它SQL語句就可以重復使用它。
5、沒有數據不一致的現象
由于數據只存儲在一個地方（InnoDB內），不需要在Memcached和MySQL之間檢查數據一致性。
6、崩潰安全
后端存儲是InnoDB，它是事務性和崩潰安全的，即使你設置innodb-flush-log-at-trx-commit!=1，在服務器崩潰時也只會丟掉<1秒內的數據。
7、可以從MySQL客戶端使用SQL
在許多情況下，人們仍然希望使用SQL（如生產摘要報告），這就是為什么我們不能使用嵌入式InnoDB的原因，大多數NoSQL產品都不支持SQL接口，HandlerSocket僅僅是一個MySQL插件，你可以從MySQL客戶端發送SQL語句，當你需要高吞吐量時最好使用HandlerSocket協議。
8、MySQL所有操作都將受益
因為HandlerSocket在MySQL內部運行，因此所有MySQL操作，如SQL，在線備份，復制，通過Nagios/EnterpriseMonitor監控等都是支持的，HandlerSocket獲得可以通過普通的MySQL命令監控，如SHOW GLOBAL STAUTS，SHOW ENGINE INNODB STATUS和SHOW PROCESSLIST等。
9、不需要修改/重建MySQL
因為HandlerSocket是一個插件，它支持MySQL社區版和企業服務器版，無需對MySQL做出任何修改就可以使用。
10、獨立于存儲引擎
雖然我們只測試了5.1和5.5 InnoDB插件，但HandlerSocket可以和任何存儲引擎交互。
注意事項和限制
1、需要學習HandlerSocket API
盡管它很容易使用，但你仍然需要學習如何與HandlerSocket交互，我們提供了C++ API和Perl綁定。
2、沒有安全功能
和其它NoSQL數據庫類似，HandlerSocket不支持安全功能，HandlerSocket的工作線程以系統用戶權限運行，因此應用程序可以訪問通過HandlerSocket協議的所有表，當然，你可以象其它NoSQL產品一樣使用防火墻過濾數據包。
3、對于HDD綁定工作負載沒有優勢
對于HDD I/O綁定工作負載，數據庫每秒無法執行數千次查詢，通常只有1-10%的CPU利用率，在這種情況下，SQL執行層不會成為瓶頸，因此使用HandlerSocket沒有什么優勢，我們只在數據完全裝載到內存的服務器上使用HandlerSocket。
DeNA在生產環境中使用HandlerSocket
我們已經在生產環境中使用了HandlerSocket插件，效果是很明顯的，最終我們減少了許多Memcached和MySQL從屬服務器，整個網絡流量也減少了，目前我們還沒有發現任何性能問題（如響應時間慢，延遲等）。
我認為MySQL完全被NoSQL/數據庫社區低估了，MySQL的歷史悠久，我的前同事們也在不斷改進它，從NDBAPI可以看出MySQL有成為NoSQL的潛力，存儲引擎API和守護進程接口是完全獨立的，使得Akira和DeNA開發HandlerSocket成為可能，作為MySQL一名前員工和對MySQL長期的了解，我想看到MySQL變得更好，更受歡迎，不只作為一個RDBMS，也應該成為NoSQL陣營中的一員。
HandlerSocket插件是開源的，可以免費使用，歡迎你下載和使用，并希望聽到你的反饋。
原文出處：Using MySQL as a NoSQL - A story for exceeding 750,000 qps on a commodity server
【編輯推薦】
