使用ProxySQL查詢緩存進行擴展

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

作者：Rene      

---

mysql 查詢緩存

在寫關于ProxySQL 查詢緩存之前，讓我們先看一下MySQL 查詢緩存。

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

將SELECT語句的文本與發送到客戶端的結果存儲在一起。之后如果接收到一個相同的語句，服務層從查詢緩存中返回結果，而不是再次解析和執行該語句

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

Peter Zaitsev 寫了一系列的文章來介紹 MySQL 查詢緩存是什么(MySQL Query Cache is) 和 一系列關于給它第二次機會的觀點(second chance).

但事實是，由于鎖定和失效算法MySQL查詢緩存很難進行擴展。這里不會重復為什么不能擴展的技術細節，提到的這些文章很好的描述了原因。

如果你想優化你的MySQL Query Cache， 我強烈推薦 Domas Mituzas 的 query cache tuner（注: 網絡沒有問題，就是 0）

ProxySQL 查詢緩存

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

它是一個 存儲在內存中的 鍵/值 ，使用：

• key 是用戶名，庫名和查詢文本的結合

• value 是后端返回的結果集（mysqld，或者另一個proxysql）

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

任何可以接受 從slave 讀取稍微過時數據的應用都可以從QC（query cache）受益。

這個概念已經不是新的了，驅動程序本身就有查詢緩存的實現：例如mysqlnd。

查詢緩存基準測試

我描述MySQL Query Cache 和  ProxySQL Query Cache 的原因是他們的性質不同，因此意味著比較它們兩個不是微不足道的，它們無法進行同類比較。

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

我將按照同樣的方法進行基準測試，觀察用MySQL Query Cache能否得到相似的結果并且觀察Proxy Query Cache能提升多少性能。

初始化設置

• 2個帶有sysbench 0.5的客戶端。

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

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個mysql數據庫(Percona Server 5.6.25) 和 proxysql(1.4.0)

在整個測試過程中，所有的數據已經緩存在InnoDB buffer pool (在內存中，沒有涉及IO)，測試前重置Query Cache。

上圖的結果表明，mysql QC確實無法擴展，并且使用它能導致性能下降84%。另一方面，ProxySQL QC 提升性能3.3倍

另一個有趣的結果是，根據測試時長不同得到的不同結果。

使用Mysql QC，基準測試時間越長，吞吐量越低（明顯降低）。

使用ProxySQL QC，吞吐量沒有下降，但1%的提升考慮是波動導致的。

上述結果需要注意的是：這個環境下可以生成一千萬條不同的SELECT 語句，因此Query Cache中有一千萬條目，因為表的大小有一千萬。

較小的 --oltp-table-size 將導致 MySQL no QC 和 ProxySQL QC 有更高的結果。事實上，出于好奇，使用 --oltp-table-size=1000000 一個單實例ProxySQL 可以返回超過一百萬的QPS。

移動查詢緩存，使離應用更近

目前為止，我將ProxySQL 與 MySQL 運行在一起。Why？ 這樣做是為了模擬當前查詢緩存在數據本身之前的期望。

雖然我相信對于大多數的工作負載，緩存層不應該靠近數據存儲的位置（后端），應該靠近數據消耗的地方（前端）。例如，mysqlnd。

如果我們使用前面的測試環境，將ProxySQL 從數據庫服務器移動到應用服務器，會發生什么呢？

我們現在有兩個ProxySQL實例。

 

不足為奇，它擴展的更好。數據庫服務器目前只需執行查詢緩存中沒有的sql。

ProxySQL使用在數據庫服務器，QC提升3.3倍性能。

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

我們能否得到更好的結果？可能會的。因為QC可以移動并分散（不再需要在數據庫服務器中），我們也能創建更復雜的配置，分離緩存層本身。例如，能夠創建兩個分片，每個分片處理和緩存一半的查詢，或者也可以創建多層的緩存系統。

結論

盡管MySQL 查詢緩存 旨在提升性能，但它有嚴重的可擴展性問題并容易成為嚴重的瓶頸。

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