【編者按】本文主要介紹 Pl.NETScale 是如何通過 MySQL 的水平分片支撐每秒一百萬個查詢（QPS）的。
原文鏈接：https://planetscale.com/media/one-million-queries-per-second-with-mysql
作者 | Jonah Berquist 譯者 | 明明如月
責編 | 夏萌
出品 | CSDN（ID：CSDNnews）
本文主要介紹 PlanetScale 是如何通過 MySQL 的水平分片支撐每秒一百萬個查詢（QPS）的。
如果你使用的數(shù)據(jù)庫擁有良好的擴展性，用起來會更省心。我們推出了基于 Vitess 的 PlanetScale，旨在最大程度上利用其出色的可擴展性。水平分片是他們在擴展性方面的一個重要優(yōu)勢。為了展示水平分片的實力，我們決定做一些基準測試。
我們設(shè)定了一個 PlanetScale 數(shù)據(jù)庫，開始運行一些常見的 sysbench-tpcc 工作負載的基準測試。我們此次的目標并不是追求嚴格的學術(shù)基準，而是想使用一個廣泛知曉且實際的工作負載進行測試。在將來，我們會發(fā)布更多基準測試的文章，并且我們已經(jīng)開始和一家學術(shù)機構(gòu)合作，他們不久后將公布自己的研究成果。
這篇文章的目標有兩個：一是展示 PlanetScale 處理大規(guī)模查詢的能力。為此，我們設(shè)定了每秒處理一百萬次查詢的目標。從 Vitess 的視角來看，這并不是個大集群。雖然有許多 Vitess 集群的查詢量更大，但我們認為這是個合理的基準。二是通過水平擴展來展示可預見的擴展性。提高吞吐量的能力就像添加更多機器一樣簡單。
增加分片數(shù)量實現(xiàn)拓展
我們的初始數(shù)據(jù)庫并未進行分片，隨后我們設(shè)定了一個虛擬模式并開始分片操作。我們傾向于選擇 2 的冪作為初始的分片數(shù)量，因此我們選擇了從兩個分片開始，并在接下來的操作中逐步翻倍分片數(shù)量。在每個分片級別，我們都會運行若干次 sysbench，每次運行時的線程數(shù)量也會逐漸增加。在每一輪的迭代過程中，我們觀察到一個現(xiàn)象：超過一定程度后，線程數(shù)量的增加不再引導吞吐量的增長，反而當吞吐量達到上限后，查詢的延遲會有所提升。
在下圖，你能看到的是對一個含有 16 個分片的數(shù)據(jù)庫進行操作的結(jié)果。你可以看到，隨著 sysbench 線程數(shù)量的增加，連接數(shù)量也同步上升。同時，隨著線程數(shù)量的提升，每秒的查詢吞吐量也相應增長。
達到極限
然而，當每個分片所占用的資源逐漸達到其容量上限時，我們開始觀察到系統(tǒng)的性能提升效果逐漸減弱。這一點在比較 1024 線程與 2048 線程間以及 2048 線程與 4096 線程間的 QPS 增長時尤為突出。同樣，在下面展示的 vtgate 指標中，當我們的吞吐量接近峰值時，我們觀察到查詢的延遲開始升高 ，尤其是在 p99 延遲中尤為明顯。
到了這一步，我們就知道是時候要增加更多的分片進一步提高吞吐量了。
增加更多分片
在下面數(shù)據(jù)中，你可以看到，隨著我們翻倍增加分片數(shù)量，每秒的查詢數(shù)量也大體上成倍增長。當我們擁有 16 個分片時，我們的最大 QPS 約為 42萬。而當我們增加到 32 個分片時，我們達到了 84 萬QPS。盡管我們有能力無限地增加分片數(shù)量，但我們設(shè)定了一個目標，那就是實現(xiàn)每秒一百萬次查詢的能力。
實現(xiàn)每秒一百萬次查詢
需要強調(diào)的是，雖然我們更偏向選擇 2 的冪作為分片數(shù)量，但這并非硬性規(guī)定，我們完全可以采用其他數(shù)量的分片?？紤]到我們在擁有 32 個分片時，QPS 剛好超過 80萬，我們推算出，大約 40 個分片應該能滿足我們 100萬QPS 的需求。當我們啟動該數(shù)據(jù)庫并使用并行的 sysbench 客戶端對其進行測試時，結(jié)果如我們所期待一樣：在運行 5 分鐘的時間內(nèi)，每秒查詢量超過了一百萬次。
我們在一個單租戶環(huán)境下進行了這項基準測試，基準測試中使用的資源級別是針對企業(yè)級客戶準備的。為了適應這個 sysbench 工作負載，我們還進行了一些非標準的配置調(diào)整，包括調(diào)高一些查詢和事務(wù)的超時設(shè)置。
