【編者按】本文主要介紹 PlanetScale 是如何通過(guò) MySQL 的水平分片支撐每秒一百萬(wàn)個(gè)查詢(xún)（QPS）的。

原文鏈接：https://planetscale.com/media/one-million-queries-per-second-with-mysql

【資料圖】

未經(jīng)允許，禁止轉(zhuǎn)載！

作者 | Jonah Berquist 譯者 | 明明如月責(zé)編 | 夏萌出品 | CSDN（ID：CSDNnews）

本文主要介紹 PlanetScale 是如何通過(guò) MySQL 的水平分片支撐每秒一百萬(wàn)個(gè)查詢(xún)（QPS）的。

如果你使用的數(shù)據(jù)庫(kù)擁有良好的擴(kuò)展性，用起來(lái)會(huì)更省心。我們推出了基于 Vitess 的 PlanetScale，旨在最大程度上利用其出色的可擴(kuò)展性。水平分片是他們?cè)跀U(kuò)展性方面的一個(gè)重要優(yōu)勢(shì)。為了展示水平分片的實(shí)力，我們決定做一些基準(zhǔn)測(cè)試。

我們?cè)O(shè)定了一個(gè) PlanetScale 數(shù)據(jù)庫(kù)，開(kāi)始運(yùn)行一些常見(jiàn)的 sysbench-tpcc 工作負(fù)載的基準(zhǔn)測(cè)試。我們此次的目標(biāo)并不是追求嚴(yán)格的學(xué)術(shù)基準(zhǔn)，而是想使用一個(gè)廣泛知曉且實(shí)際的工作負(fù)載進(jìn)行測(cè)試。在將來(lái)，我們會(huì)發(fā)布更多基準(zhǔn)測(cè)試的文章，并且我們已經(jīng)開(kāi)始和一家學(xué)術(shù)機(jī)構(gòu)合作，他們不久后將公布自己的研究成果。

這篇文章的目標(biāo)有兩個(gè)：一是展示 PlanetScale 處理大規(guī)模查詢(xún)的能力。為此，我們?cè)O(shè)定了每秒處理一百萬(wàn)次查詢(xún)的目標(biāo)。從 Vitess 的視角來(lái)看，這并不是個(gè)大集群。雖然有許多 Vitess 集群的查詢(xún)量更大，但我們認(rèn)為這是個(gè)合理的基準(zhǔn)。二是通過(guò)水平擴(kuò)展來(lái)展示可預(yù)見(jiàn)的擴(kuò)展性。提高吞吐量的能力就像添加更多機(jī)器一樣簡(jiǎn)單。

增加分片數(shù)量實(shí)現(xiàn)拓展

我們的初始數(shù)據(jù)庫(kù)并未進(jìn)行分片，隨后我們?cè)O(shè)定了一個(gè)虛擬模式并開(kāi)始分片操作。我們傾向于選擇 2 的冪作為初始的分片數(shù)量，因此我們選擇了從兩個(gè)分片開(kāi)始，并在接下來(lái)的操作中逐步翻倍分片數(shù)量。在每個(gè)分片級(jí)別，我們都會(huì)運(yùn)行若干次 sysbench，每次運(yùn)行時(shí)的線(xiàn)程數(shù)量也會(huì)逐漸增加。在每一輪的迭代過(guò)程中，我們觀察到一個(gè)現(xiàn)象：超過(guò)一定程度后，線(xiàn)程數(shù)量的增加不再引導(dǎo)吞吐量的增長(zhǎng)，反而當(dāng)吞吐量達(dá)到上限后，查詢(xún)的延遲會(huì)有所提升。

在下圖，你能看到的是對(duì)一個(gè)含有 16 個(gè)分片的數(shù)據(jù)庫(kù)進(jìn)行操作的結(jié)果。你可以看到，隨著 sysbench 線(xiàn)程數(shù)量的增加，連接數(shù)量也同步上升。同時(shí)，隨著線(xiàn)程數(shù)量的提升，每秒的查詢(xún)吞吐量也相應(yīng)增長(zhǎng)。

達(dá)到極限

然而，當(dāng)每個(gè)分片所占用的資源逐漸達(dá)到其容量上限時(shí)，我們開(kāi)始觀察到系統(tǒng)的性能提升效果逐漸減弱。這一點(diǎn)在比較 1024 線(xiàn)程與 2048 線(xiàn)程間以及 2048 線(xiàn)程與 4096 線(xiàn)程間的 QPS 增長(zhǎng)時(shí)尤為突出。同樣，在下面展示的 vtgate 指標(biāo)中，當(dāng)我們的吞吐量接近峰值時(shí)，我們觀察到查詢(xún)的延遲開(kāi)始升高 ，尤其是在 p99 延遲中尤為明顯。

到了這一步，我們就知道是時(shí)候要增加更多的分片進(jìn)一步提高吞吐量了。

增加更多分片

在下面數(shù)據(jù)中，你可以看到，隨著我們翻倍增加分片數(shù)量，每秒的查詢(xún)數(shù)量也大體上成倍增長(zhǎng)。當(dāng)我們擁有 16 個(gè)分片時(shí)，我們的最大 QPS 約為 42萬(wàn)。而當(dāng)我們?cè)黾拥?32 個(gè)分片時(shí)，我們達(dá)到了 84 萬(wàn)QPS。盡管我們有能力無(wú)限地增加分片數(shù)量，但我們?cè)O(shè)定了一個(gè)目標(biāo)，那就是實(shí)現(xiàn)每秒一百萬(wàn)次查詢(xún)的能力。

實(shí)現(xiàn)每秒一百萬(wàn)次查詢(xún)

需要強(qiáng)調(diào)的是，雖然我們更偏向選擇 2 的冪作為分片數(shù)量，但這并非硬性規(guī)定，我們完全可以采用其他數(shù)量的分片?？紤]到我們?cè)趽碛?32 個(gè)分片時(shí)，QPS 剛好超過(guò) 80萬(wàn)，我們推算出，大約 40 個(gè)分片應(yīng)該能滿(mǎn)足我們 100萬(wàn)QPS 的需求。當(dāng)我們啟動(dòng)該數(shù)據(jù)庫(kù)并使用并行的 sysbench 客戶(hù)端對(duì)其進(jìn)行測(cè)試時(shí)，結(jié)果如我們所期待一樣：在運(yùn)行 5 分鐘的時(shí)間內(nèi)，每秒查詢(xún)量超過(guò)了一百萬(wàn)次。

我們?cè)谝粋€(gè)單租戶(hù)環(huán)境下進(jìn)行了這項(xiàng)基準(zhǔn)測(cè)試，基準(zhǔn)測(cè)試中使用的資源級(jí)別是針對(duì)企業(yè)級(jí)客戶(hù)準(zhǔn)備的。為了適應(yīng)這個(gè) sysbench 工作負(fù)載，我們還進(jìn)行了一些非標(biāo)準(zhǔn)的配置調(diào)整，包括調(diào)高一些查詢(xún)和事務(wù)的超時(shí)設(shè)置。

標(biāo)簽：