使用ProxySQL查詢緩存進(jìn)行擴(kuò)展

原文：http://proxysql.com/blog/scaling-with-proxysql-query-cache

作者：Rene      

---

mysql 查詢緩存

在寫(xiě)關(guān)于ProxySQL 查詢緩存之前，讓我們先看一下MySQL 查詢緩存。

MySQL 查詢緩存是一個(gè)非常有趣的特性，引用官檔：

將SELECT語(yǔ)句的文本與發(fā)送到客戶端的結(jié)果存儲(chǔ)在一起。之后如果接收到一個(gè)相同的語(yǔ)句，服務(wù)層從查詢緩存中返回結(jié)果，而不是再次解析和執(zhí)行該語(yǔ)句

它是一個(gè)緩存，旨在提升性能。然而，他不是‘靈丹妙藥’，并時(shí)不時(shí)的能看到嚴(yán)重的性能下降或隨機(jī)凍結(jié) (random freezes)。為什么？

Peter Zaitsev 寫(xiě)了一系列的文章來(lái)介紹 MySQL 查詢緩存是什么(MySQL Query Cache is) 和 一系列關(guān)于給它第二次機(jī)會(huì)的觀點(diǎn)(second chance).

但事實(shí)是，由于鎖定和失效算法MySQL查詢緩存很難進(jìn)行擴(kuò)展。這里不會(huì)重復(fù)為什么不能擴(kuò)展的技術(shù)細(xì)節(jié)，提到的這些文章很好的描述了原因。

如果你想優(yōu)化你的MySQL Query Cache， 我強(qiáng)烈推薦 Domas Mituzas 的 query cache tuner（注: 網(wǎng)絡(luò)沒(méi)有問(wèn)題，就是 0）

ProxySQL 查詢緩存

ProxySQL 查詢緩存與 MySQL 查詢緩存完全不同。

它是一個(gè) 存儲(chǔ)在內(nèi)存中的 鍵/值 ，使用：

• key 是用戶名，庫(kù)名和查詢文本的結(jié)合

• value 是后端返回的結(jié)果集（mysqld，或者另一個(gè)proxysql）

使ProxySQL中條目失效的唯一方法需要通過(guò)以毫秒為單位的生存時(shí)間(time-to-live)。一些人認(rèn)為通過(guò)生存時(shí)間失效是有限制的，但對(duì)于多數(shù)的應(yīng)用不會(huì)有這種情況。如果應(yīng)用需要絕對(duì)正確的數(shù)據(jù)，透明緩存可能不是正確的解決方案。

任何可以接受 從slave 讀取稍微過(guò)時(shí)數(shù)據(jù)的應(yīng)用都可以從QC（query cache）受益。

這個(gè)概念已經(jīng)不是新的了，驅(qū)動(dòng)程序本身就有查詢緩存的實(shí)現(xiàn)：例如mysqlnd。

查詢緩存基準(zhǔn)測(cè)試

我描述MySQL Query Cache 和  ProxySQL Query Cache 的原因是他們的性質(zhì)不同，因此意味著比較它們兩個(gè)不是微不足道的，它們無(wú)法進(jìn)行同類(lèi)比較。

已知Mysql Query Cache 不能進(jìn)行很好的擴(kuò)展。我找到的關(guān)于 Mysql Query Cache 不能很好擴(kuò)展的基準(zhǔn)測(cè)試 是 Szymon Komendera（亞馬遜極光(Amazon Aurora)數(shù)據(jù)庫(kù)工程師） 發(fā)表的博客(需要×××)。在博客中，帶有4GB 查詢緩存的Aurora  能提升MySQL性能達(dá)3.1倍（此處為Aurora QC 與 Mysql QC的對(duì)比） 。

我將按照同樣的方法進(jìn)行基準(zhǔn)測(cè)試，觀察用MySQL Query Cache能否得到相似的結(jié)果并且觀察Proxy Query Cache能提升多少性能。

初始化設(shè)置

• 2個(gè)帶有sysbench 0.5的客戶端。

使用兩個(gè)客戶端的原因：在目前硬件的條件下，一個(gè)客戶端不能生成足夠的流量，使Proxy Query Cache 到達(dá)極限。

sysbench命令：       

./sysbench --num-threads=512 --max-time=900 --max-requests=0 
--test=./tests/db/oltp.lua 
--mysql-user=sbtest 
--mysql-password=sbtest 
--mysql-host=10.1.1.22 
--oltp-table-size=10000000 
--mysql-port=${PORT} 
--mysql-ps-mode=disable 
--oltp-read-only=on 
--oltp-point-selects=25 
--oltp-skip-trx=on 
--oltp-sum-ranges=0 
--oltp-simple-ranges=0 
--oltp-distinct-ranges=0 
--oltp-order-ranges=0 
--oltp-dist-type=uniform run

• 1個(gè)mysql數(shù)據(jù)庫(kù)(Percona Server 5.6.25) 和 proxysql(1.4.0)

在整個(gè)測(cè)試過(guò)程中，所有的數(shù)據(jù)已經(jīng)緩存在InnoDB buffer pool (在內(nèi)存中，沒(méi)有涉及IO)，測(cè)試前重置Query Cache。

上圖的結(jié)果表明，mysql QC確實(shí)無(wú)法擴(kuò)展，并且使用它能導(dǎo)致性能下降84%。另一方面，ProxySQL QC 提升性能3.3倍

另一個(gè)有趣的結(jié)果是，根據(jù)測(cè)試時(shí)長(zhǎng)不同得到的不同結(jié)果。

使用Mysql QC，基準(zhǔn)測(cè)試時(shí)間越長(zhǎng)，吞吐量越低（明顯降低）。

使用ProxySQL QC，吞吐量沒(méi)有下降，但1%的提升考慮是波動(dòng)導(dǎo)致的。

上述結(jié)果需要注意的是：這個(gè)環(huán)境下可以生成一千萬(wàn)條不同的SELECT 語(yǔ)句，因此Query Cache中有一千萬(wàn)條目，因?yàn)楸淼拇笮∮幸磺f(wàn)。

較小的 --oltp-table-size 將導(dǎo)致 MySQL no QC 和 ProxySQL QC 有更高的結(jié)果。事實(shí)上，出于好奇，使用 --oltp-table-size=1000000 一個(gè)單實(shí)例ProxySQL 可以返回超過(guò)一百萬(wàn)的QPS。

移動(dòng)查詢緩存，使離應(yīng)用更近

目前為止，我將ProxySQL 與 MySQL 運(yùn)行在一起。Why？ 這樣做是為了模擬當(dāng)前查詢緩存在數(shù)據(jù)本身之前的期望。

雖然我相信對(duì)于大多數(shù)的工作負(fù)載，緩存層不應(yīng)該靠近數(shù)據(jù)存儲(chǔ)的位置（后端），應(yīng)該靠近數(shù)據(jù)消耗的地方（前端）。例如，mysqlnd。

如果我們使用前面的測(cè)試環(huán)境，將ProxySQL 從數(shù)據(jù)庫(kù)服務(wù)器移動(dòng)到應(yīng)用服務(wù)器，會(huì)發(fā)生什么呢？

我們現(xiàn)在有兩個(gè)ProxySQL實(shí)例。

 

不足為奇，它擴(kuò)展的更好。數(shù)據(jù)庫(kù)服務(wù)器目前只需執(zhí)行查詢緩存中沒(méi)有的sql。

ProxySQL使用在數(shù)據(jù)庫(kù)服務(wù)器，QC提升3.3倍性能。

ProxySQL使用在客戶端，QC提升5.2倍性能！

我們能否得到更好的結(jié)果？可能會(huì)的。因?yàn)镼C可以移動(dòng)并分散（不再需要在數(shù)據(jù)庫(kù)服務(wù)器中），我們也能創(chuàng)建更復(fù)雜的配置，分離緩存層本身。例如，能夠創(chuàng)建兩個(gè)分片，每個(gè)分片處理和緩存一半的查詢，或者也可以創(chuàng)建多層的緩存系統(tǒng)。

結(jié)論

盡管MySQL 查詢緩存 旨在提升性能，但它有嚴(yán)重的可擴(kuò)展性問(wèn)題并容易成為嚴(yán)重的瓶頸。

ProxySQL Query Cache 能大幅提升一些特定工作負(fù)載的性能：讀密集型，能夠被緩存很多的結(jié)果。ProxySQL 仍允許分散緩存層，并且可以將緩存層從數(shù)據(jù)庫(kù)服務(wù)器移動(dòng)到離應(yīng)用層更近的地方。