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

創(chuàng)新互聯(lián)建站-云計算及IDC服務提供商，涵蓋公有云、IDC機房租用、成都天府聯(lián)通服務器托管、等保安全、私有云建設等企業(yè)級互聯(lián)網基礎服務，歡迎咨詢：18980820575

作者：Rene

---

mysql 查詢緩存

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

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

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

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

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

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

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

ProxySQL 查詢緩存

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

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

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

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

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

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

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

查詢緩存基準測試

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

已知Mysql Query Cache 不能進行很好的擴展。我找到的關于 Mysql Query Cache 不能很好擴展的基準測試 是 Szymon Komendera（亞馬遜極光(Amazon Aurora)數據庫工程師） 發(fā)表的博客(需要×××)。在博客中，帶有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%的提升考慮是波動導致的。

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

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

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

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

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

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

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

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

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

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

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

結論

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

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

      

另外有需要云服務器可以了解下創(chuàng)新互聯(lián)cdcxhl.cn，海內外云服務器15元起步，三天無理由+7*72小時售后在線，公司持有idc許可證，提供“云服務器、裸金屬服務器、高防服務器、香港服務器、美國服務器、虛擬主機、免備案服務器”等云主機租用服務以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡單易用、服務可用性高、性價比高”等特點與優(yōu)勢，專為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應用場景需求。

標題名稱：使用ProxySQL查詢緩存進行擴展-創(chuàng)新互聯(lián)
文章URL：http://aaarwkj.com/article0/dpipio.html

成都網站建設公司_創(chuàng)新互聯(lián)，為您提供網站策劃、移動網站建設、網站營銷、軟件開發(fā)、標簽優(yōu)化、自適應網站

廣告

聲明：本網站發(fā)布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創(chuàng)新互聯(lián)