NoSQL 小故事：?jiǎn)畏?wù)器如何應(yīng)付每秒75萬(wàn)次查詢【51CTO 經(jīng)典譯文】大多數(shù)大規(guī)模Web 應(yīng)用程序都使用MySQL Memcached架構(gòu)，其中許多應(yīng)用也同時(shí)使用了NoSQL 數(shù)據(jù)庫(kù)，如Toky

NoSQL 小故事：?jiǎn)畏?wù)器如何應(yīng)付每秒75萬(wàn)次查詢

【51CTO 經(jīng)典譯文】大多數(shù)大規(guī)模Web 應(yīng)用程序都使用MySQL Memcached架構(gòu)，其中許多應(yīng)用也同時(shí)使用了NoSQL 數(shù)據(jù)庫(kù)，如TokyoCabinet/Tyrant，也有一些人全部放棄MySQL ，轉(zhuǎn)投NoSQL 的懷抱，曾經(jīng)有人將這稱為NoSQL 運(yùn)動(dòng)，因?yàn)镹oSQL 數(shù)據(jù)庫(kù)在處理一些簡(jiǎn)單訪問(wèn)模式，如主鍵查找時(shí)，比MySQL 的表現(xiàn)更好，大多數(shù)Web 應(yīng)用程序的查詢都很簡(jiǎn)單，因此這看上去是一個(gè)很合理的決定。

和許多其它大規(guī)模網(wǎng)站一樣，我們的DeNA （我于2010年8月離開(kāi)Oracle ，加盟了日本最大的社交游戲平臺(tái)提供商DeNA ）多年來(lái)都存在類似的問(wèn)題，但我們得出了不同的結(jié)論，最終我們?nèi)渴褂昧薓ySQL ，當(dāng)然一如既往地使用Memcached 作為前端緩存（如預(yù)處理的HTML ，計(jì)數(shù)/摘要信息），但我們沒(méi)有使用

Memcached 緩存數(shù)據(jù)行，我們也沒(méi)有使用NoSQL ，因?yàn)槲覀儚腗ySQL 獲得的性能比其它NoSQL 產(chǎn)品更好，在我們的基準(zhǔn)測(cè)試中，我們?cè)谝慌_(tái)普通的MySQL/InnoDB 5.1服務(wù)器上獲得了750000 QPS的成績(jī)，在生產(chǎn)環(huán)境中的性能更優(yōu)秀。（QPS 每秒查詢率，每秒查詢率QPS 是對(duì)一個(gè)特定的查詢服務(wù)器在規(guī)定時(shí)間內(nèi)所處理流量多少的衡量標(biāo)準(zhǔn)，在因特網(wǎng)上，作為域名系統(tǒng)服務(wù)器的機(jī)器的性能經(jīng)常用每秒查詢率來(lái)衡量。） 也許你不相信這個(gè)成績(jī)，但我說(shuō)的是真的，在這篇文章中，我將分享一下我們是如何做到的。

SQL 主鍵查詢真得能很快嗎？

每秒你可以運(yùn)行多少次主鍵查詢？DeNA 的應(yīng)用程序需要執(zhí)行大量的主鍵查詢，如通過(guò)用戶id 獲取用戶信息，通過(guò)日記id 獲取日志信息，Memcached 和NoSQL 都能很好地適應(yīng)這種需求，當(dāng)你運(yùn)行簡(jiǎn)單的多線程“memcached get”基準(zhǔn)測(cè)試時(shí)，每秒大約可以執(zhí)行400000 次get 操作，即使Memcached 客戶端位于遠(yuǎn)程服務(wù)器上，當(dāng)我使用最新的libmemcached 和memcached 測(cè)試時(shí)，在一臺(tái)2.5GHz 8核Nehalem 處理器，四個(gè)Broadcom 千兆以太網(wǎng)卡的服務(wù)器上，測(cè)試成績(jī)是每秒執(zhí)行420000次get 操作。

MySQL 執(zhí)行主鍵查詢需要多長(zhǎng)時(shí)間？通過(guò)基準(zhǔn)測(cè)試很容易找到答案，只需要從sysbench ，super-smack 和mysqlslap 等運(yùn)行并行查詢即可。

1. [matsunobu@host ~]$ mysqlslap --query="select user_name,..

2. from test.user where user_id=1"

3. --number-of-queries=10000000 --concurrency=30 --host=xxx –uroot

你可以使用下面的命令檢查每秒讀取了多少InnoDB 行：

1. [matsunobu@host ~]$ mysqladmin extended-status -i 1 -r -uroot

2. | grep -e "Com_select"

3. ...

4. | Com_select | 107069 |

5. | Com_select | 108873 |

6. | Com_select | 108921 |

7. | Com_select | 109511 |

8. | Com_select | 108084 |

9. | Com_select | 108483 |

10.

11.

每秒有100000 次查詢似乎還不錯(cuò)，但卻遠(yuǎn)遠(yuǎn)低于Memcached 的結(jié)果，MySQL 實(shí)際上做了些什么？從vmstat 輸出可以看出，user和system都很高。 | Com_select | 108115 | ...

1. [matsunobu@host ~]$ vmstat 1

2. r b swpd free buff cache in cs us sy id wast

3. 23 0 0 963004 224216 29937708 58242 163470 59 28 12 0 0

4. 24 0 0 963312 224216 29937708 57725 164855 59 28 13 0 0

5. 19 0 0 963232 224216 29937708 58127 164196 60 28 12 0 0

6. 16 0 0 963260 224216 29937708 58021 165275 60 28 12 0 0

7. 20 0 0 963308 224216 29937708 57865 165041 60 28 12 0 0

Oprofile 輸出顯示了更多關(guān)于CPU 資源消耗的情況。

1. samples app name symbol name

2. 259130 4.5199 mysqldMYSQLparse(void*)

3. 196841 3.4334 mysqldmy_pthread_fastmutex_lock

4. 106439 1.8566 libc-2.5.so _int_malloc

5. 94583 1.6498 bnx2 /bnx2

6. 84550 1.4748 ha_innodb_plugin.so.0.0.0 ut_delay

7. 67945 1.1851 mysqld _ZL20make_join_statistics

8. P4JOINP10TABLE_LISTP4ItemP16st_dynamic_array

9. 63435 1.1065 mysqld JOIN::optimize()

10.

11.

12.

13.

14.

15.

16.

46499 0.8111 libc-2.5.so malloc 46957 0.8190 vmlinux .text.elf_core_dump 47518 0.8288 libc-2.5.so memcpy 49602 0.8652 ha_innodb_plugin.so.0.0.0 row_search_for_mysql 50833 0.8867 libpthread-2.5.so pthread_mutex_trylock 55054 0.9603 mysqldMYSQLlex(void*, void*) 55825 0.9737 vmlinuxwakeup_stack_begin

在SQL 解析階段調(diào)用了MYSQLparse()和MYSQLlex()，在查詢優(yōu)化階段調(diào)用了make_join_statistics()和JOIN::optimize()，這些都是SQL 開(kāi)銷，很明顯，性能下降主要是由SQL 層，而不是InnoDB （存儲(chǔ)）層造成的，MySQL 做了很多Memcached/NoSQL不需要做的事情，如：

1. λ解析SQL 語(yǔ)句

2. λ打開(kāi)，鎖住表

3. λ創(chuàng)建SQL 執(zhí)行計(jì)劃

4. λ解鎖

5. λ關(guān)閉表

MySQL 也做了許多并發(fā)控制，例如，在發(fā)送/接收網(wǎng)絡(luò)數(shù)據(jù)包時(shí)多次調(diào)用了fcntl()，全局互斥，如LOCK_open，LOCK_thread_count很頻繁地創(chuàng)建/釋放，這就是為什么oprofile 輸出中

my_pthread_fastmutex_lock()排名第二，system也不小的原因。

MySQL 開(kāi)發(fā)團(tuán)隊(duì)和外部社區(qū)都知道并發(fā)問(wèn)題，有些問(wèn)題在5.5中已經(jīng)得到解決，我很高興地看到，大量的修復(fù)工作已經(jīng)完成，但同樣重要的是user也達(dá)到了60，互斥競(jìng)爭(zhēng)導(dǎo)致system上升，而不是user上升。雖然MySQL 中的所有互斥問(wèn)題都得到了解決，但不要指望每秒超過(guò)30萬(wàn)次查詢。

你可能聽(tīng)說(shuō)過(guò)HANDLER 語(yǔ)句，遺憾的是，HANDLER 語(yǔ)句對(duì)提高吞吐量并不會(huì)有太多幫助，因?yàn)椴樵兘馕?，打開(kāi)/關(guān)閉表等操作仍然是需要的。

CPU 效率對(duì)內(nèi)存中的工作負(fù)載非常重要

如果內(nèi)存中沒(méi)有合適的活動(dòng)數(shù)據(jù)，SQL 開(kāi)銷相對(duì)來(lái)說(shuō)可以忽略不計(jì)，很簡(jiǎn)單，因?yàn)榇疟PI/O成本是非常高的，在這種情況下，我們不需要太關(guān)心SQL 成本。

但在我們的熱點(diǎn)MySQL 服務(wù)器上，幾乎所有數(shù)據(jù)都裝入到內(nèi)存中了，它們完全變成CPU 限制，分析結(jié)果和上面類似：SQL 層消耗了大部分資源。我們需要執(zhí)行大量的主鍵查詢（如SELECT x FROM t WHERE id=?）或限制范圍的掃描，即使70-80的查詢是對(duì)相同表的簡(jiǎn)單主鍵查詢（不同的只是Where 子句中的值），每次MySQL 都要解析/打開(kāi)/鎖住/解鎖/關(guān)閉，這對(duì)我們來(lái)說(shuō)效率是很低的。

你聽(tīng)說(shuō)過(guò)NDBAPI 嗎？

在MySQL 的SQL 層有什么好的解決辦法可以減少CPU 資源爭(zhēng)用嗎？如果你使用的是MySQL 集群，NDBAPI 可能是最好的解決方案，我在MySQL/Sun/Oracle擔(dān)任顧問(wèn)時(shí)，我看到許多客戶對(duì)SQL 節(jié)點(diǎn)

NDB的性能表現(xiàn)很失望，當(dāng)使用NDBAPI 客戶端性能提高N 倍后，他們高興極了，你可以在MySQL 集群中同時(shí)使用NDBAPI 和SQL ，建議頻繁訪問(wèn)模式使用NDBAPI ，即席查詢或非頻繁模式使用

SQL MySQL NDB。

這正是我們想要的，我們希望更快速地訪問(wèn)API ，我們也希望對(duì)即席查詢或復(fù)雜查詢使用SQL ，但DeNA 使用的是InnoDB ，和許多其它Web 服務(wù)一樣，切換到NDB 不是小事，嵌入式InnoDB 不支持SQL 也不沒(méi)有網(wǎng)絡(luò)接口，因此它不適合我們。

HandlerSocket 插件，一個(gè)懂NoSQL 網(wǎng)絡(luò)協(xié)議的MySQL 插件

我們認(rèn)為最好的辦法是在MySQL 內(nèi)部實(shí)現(xiàn)一個(gè)NoSQL 網(wǎng)絡(luò)服務(wù)器，也就是說(shuō)，寫一個(gè)網(wǎng)絡(luò)服務(wù)器作為MySQL 插件（守護(hù)進(jìn)程插件）監(jiān)聽(tīng)指定端口，接受NoSQL 協(xié)議/API，然后使用MySQL 內(nèi)部存儲(chǔ)引擎API 直接訪問(wèn)InnoDB 。這個(gè)方法和NDBAPI 類似，但它可以和InnoDB 交互，這個(gè)概念最初是由Kazuho Oku去年在Cybozu 實(shí)驗(yàn)室提出并創(chuàng)建了原型，他編寫了使用memcached 協(xié)議的MyCached UDF，我的同事Akira Higuchi實(shí)現(xiàn)了另一個(gè)插件：HandlerSocket ，下圖顯示了HandlerSocket 可以做的事情。

圖 1 Hanldersocket是什么？

Hanldersocket 是一個(gè)MySQL 守護(hù)進(jìn)程插件，它讓應(yīng)用程序可以將MySQL 當(dāng)NoSQL 使，

Hanldersocket 的主要目的是與存儲(chǔ)引擎，如InnoDB 交互，而不需要SQL 相關(guān)的開(kāi)銷。訪問(wèn)MySQL 表時(shí)，Hanldersocket 仍然需要打開(kāi)和關(guān)閉表，但不是每次訪問(wèn)都要求打開(kāi)和關(guān)閉，因此減少了互斥爭(zhēng)奪，極大地提高了系統(tǒng)性能，當(dāng)流量變小時(shí)，Hanldersocket 會(huì)關(guān)閉表，因此它永遠(yuǎn)不會(huì)阻止管理命令（DDL ）。 它和使用MySQL Memcached有什么不同？比較圖1和圖2，我想你會(huì)發(fā)現(xiàn)很多差異的，圖2顯示了典型的Memcached 和MySQL 用法，Memcached 用于緩存數(shù)據(jù)庫(kù)記錄，這是因?yàn)镸emcached 的get 操作比MySQL 的內(nèi)存中/磁盤上的主鍵查詢要快很多，如果HandlerSocket 的查詢速度和Memcached 一樣快，我們就不用Memcached 緩存記錄了。

圖 2 MySQL Memcached的常見(jiàn)架構(gòu)模式

使用HandlerSocket

舉一個(gè)例子，假設(shè)有一個(gè)“user ”表，我們需要通過(guò)user_id獲取用戶信息。

1. CREATE TABLE user (

2. user_id INT UNSIGNED PRIMARY KEY,

3. user_name VARCHAR(50),

4. user_email VARCHAR(255),

5. created DATETIME

6. ) ENGINE=InnoDB;

在MySQL 中，可以通過(guò)SELECT 語(yǔ)句獲取用戶信息。

1. mysql> SELECT user_name, user_email, created FROM user WHERE user_id=101;

2. --------------- ----------------------- ---------------------

3. | user_name | user_email | created |

4. --------------- ----------------------- ---------------------

5. | Yukari Takeba | yukari.takeba@dena.jp | 2010-02-03 11:22:33 |