MySQL痿了，放不下這麼多數據！

精彩文章。

《微服務不是所有，只是特定領域的子集》

《「分庫分表" ？選型和流程要慎重，不然會失控》

這麼多監控組件，總有一款適合你

《Linux生產環境上，最經常使用的一套「vim「技巧》

《使用Netty，咱們到底在開發些什麼？》

Linux五件套之類的。

《Linux之《荒島餘生》（一）準備篇》

《Linux之《荒島餘生》（二）CPU篇》

《Linux之《荒島餘生》（三）內存篇》

《Linux之《荒島餘生》（四）I/O篇》

《Linux之《荒島餘生》（五）網絡篇》

更多請關注。固然也能夠關注公衆號。

---

調研不表明實踐，謹慎採納，結論後續實踐後放出。本文主題:【存儲上雲】TiDB和Polardb。

MySQL在達到必定數據量（個人經驗是3T、單表1億）時，複雜查詢會有明顯的延遲。繼續分庫分表，會嚴重增長業務複雜性，尤爲對不少非互聯網產品來講，急需一個分佈式存儲。

MySQL自己也作了一些努力，那就是基於Paxos協議的MGR。但它沒有Sharding的解決方案，須要藉助其餘中間件。在《「分庫分表" ？選型和流程要慎重，不然會失控》 一文中，咱們可以看到Sharding這個過程的複雜性。若是一個DB，自己自帶這些光環，就耀眼的多。

這樣的DB已經有不少，其中，以Aurora爲表明的雲數據庫進入視野。根據其流行度，僅對PorlarDB和TiDB進行了調研。

其餘產品，包括但不限於：

Greenplum
Druid
Aurora
Taurus
Spanner
NuoDB
Oracle Exadata
Oracle RAC
複製代碼

若是你時間有限，直接看初步結論便可。下面的內容能夠忽略。

初步結論

它們都支持MySQL協議，現有業務遷移起來會比較平滑，但對硬件的要求都較高。部分一致性都有Raft協議的參與，可靠性都有保證。

TiDB是開源的，某些組件強制要求SSD，且需配備DBA，形成了總體成本的上升。可是使用案例較多，經歷過較大規模的應用。

PolarDB。阿里新的明星產品，價格相對合理，但使用案例有限，也沒法窺視其源碼，只有零星宣傳文檔。鑑於阿里喜愛誇大的尿性，需試用後進行深刻評價。但云端優點太明顯，已被優先考慮。

經過諮詢已有經驗的實踐者，廣泛吐槽會遇到不少奇怪的問題，並不像宣傳中的那麼美好。

如下。

---

TiDB

1、簡介

TiDB 是 PingCAP 公司設計的開源分佈式 HTAP (Hybrid Transactional and Analytical Processing) 數據庫，結合了傳統的 RDBMS 和 NoSQL 的最佳特性。TiDB 兼容 MySQL，支持無限的水平擴展，具有強一致性和高可用性。TiDB 的目標是爲 OLTP (Online Transactional Processing) 和 OLAP (Online Analytical Processing) 場景提供一站式的解決方案。

特性

TiDB 具有以下特性：

高度兼容 MySQL

大多數狀況下，無需修改代碼便可從 MySQL 輕鬆遷移至 TiDB，分庫分表後的 MySQL 集羣亦可經過 TiDB 工具進行實時遷移。

水平彈性擴展

經過簡單地增長新節點便可實現 TiDB 的水平擴展，按需擴展吞吐或存儲，輕鬆應對高併發、海量數據場景。

分佈式事務

TiDB 100% 支持標準的 ACID 事務。

真正金融級高可用

相比於傳統主從 (M-S) 複製方案，基於 Raft 的多數派選舉協議能夠提供金融級的 100% 數據強一致性保證，且在不丟失大多數副本的前提下，能夠實現故障的自動恢復 (auto-failover)，無需人工介入。

一站式 HTAP 解決方案

TiDB 做爲典型的 OLTP 行存數據庫，同時兼具強大的 OLAP 性能，配合 TiSpark，可提供一站式 HTAP 解決方案，一份存儲同時處理 OLTP & OLAP，無需傳統繁瑣的 ETL 過程。

雲原生 SQL 數據庫

TiDB 是爲雲而設計的數據庫，支持公有云、私有云和混合雲，使部署、配置和維護變得十分簡單。

座標：pingcap.com/docs-cn/ove…

2、總體架構圖

3、詳細原理

TiKV 詳細解讀 t.cn/RTKRRWv

TiDB 詳細解讀 t.cn/RTKRkBh （查詢流程）

PD 詳細解讀 t.cn/RTKEZ0U

4、兼容性（不支持特性列表）

github.com/pingcap/doc…

5、FAQ

github.com/pingcap/doc…

6、硬件需求

TiDB：解析，處理sql邏輯，經過PD獲取數據地址，訪問TiKV撈數據，返回結果（需負載均衡，高耗u，高內存，高網絡）

PD：集羣管理，存儲元數據信息，tikv負載均衡，分配全局事務id

TiKV：分佈式且提供事務的 Key-Value 存儲引擎。（高耗u，高內存，高網絡，高硬盤）

費用（1年）：TiDB節點=14749*2 = 29498

PD節點=3794*3 = 11382
TiKV節點=30049*3 = 59547 （500G SSD）
監控節點=7446
合計：107873
複製代碼

7、其餘問題

一、 對硬盤要求高，啓動會檢測硬盤是否爲SSD，若否沒法啓動

二、 不支持分區，刪除數據是個大坑。（3.0支持）

解決方案：

set @@session.tidb_batch_delete=1;
複製代碼

三、 批量插數據問題

解決方案：

set @@session.tidb_batch_insert=1; 
複製代碼

四、 刪除表數據時不支持別名

delete from 表名 表別名 where 表別名.col = '1' 會報錯

五、 內存使用問題，GO語言致使不知道回收機制何時運做。內存使用過多會致使TIDB當機（這點徹底不像MYSQL）測試狀況是，32G內存，在10分鐘後纔回收一半。

六、 數據寫入的時候，tidb壓力很大, tikv的CPU也佔用很高

七、 不支持GBK

八、 不支持存儲過程

九、 列數支持太少，只支持100列

引用：blog.csdn.net/yajie_12/ar…

polardb

1、簡介、成本

POLARDB是阿里巴巴自主研發的下一代關係型分佈式雲原生數據庫，目前兼容三種數據庫引擎：MySQL、Oracle、PostgreSQL。計算能力最高可擴展至1000核以上，存儲容量最高可達 100T。POLARDB採用存儲和計算分離的架構，全部計算節點共享一份數據，提供分鐘級的配置升降級、秒級的故障恢復、全局數據一致性和免費的數據備份容災服務。POLARDB既融合了商業數據庫穩定可靠、高性能、可擴展的特徵，又具備開源雲數據庫簡單開放、自我迭代的優點，例如POLARDB for MySQL性能最高能夠提高至MySQL的6倍，而成本只有商用數據庫的1/10

2、集羣架構，計算與存儲分離

POLARDB採用多節點集羣的架構，集羣中有一個Writer節點（主節點）和多個Reader節點（讀節點），各節點經過分佈式文件系統（PolarFileSystem）共享底層的存儲（PolarStore）。

3、讀寫分離

應用程序使用集羣地址時，POLARDB for MySQL經過內部的代理層（Proxy）對外提供服務，應用程序的請求都先通過代理，而後才訪問到數據庫節點。代理層不只能夠作安全認證和保護，還能夠解析SQL，把寫操做（好比事務、UPDATE、INSERT、DELETE、DDL等）發送到主節點，把讀操做（好比SELECT）均衡地分發到多個只讀節點，實現自動的讀寫分離。對於應用程序來講，就像使用一個單點的MySQL數據庫同樣簡單。內部的代理層（Proxy）後續將支持POLARDB for PostgreSQL/Oracle。

4、產品優點

容量大

最高100TB，您再也不須要由於單機容量的天花板而去購買多個實例作分片，由此簡化應用開發，下降運維負擔。

高性價比

POLARDB的計算與存儲分離，每增長一個只讀節點只收取計算資源的費用，而傳統的只讀節點同時包含計算和存儲資源，每增長一個只讀節點須要支付相應的存儲費用。

分鐘級彈性

存儲與計算分離的架構，配合共享存儲，使得快速升級成爲現實。

讀一致性

集羣地址利用LSN（Log Sequence Number）確保讀取數據時的全局一致性，避免由於主備延遲引發的不一致。

毫秒級延遲（物理複製）

利用基於Redo的物理複製代替基於Binlog的邏輯複製，提高主備複製的效率和穩定性。即便對大表進行加索引、加字段等DDL操做，也不會形成數據庫的延遲。

無鎖備份

利用存儲層的快照，能夠在60秒內完成對2TB數據量大小的數據庫的備份，並且備份過程不會對數據庫加鎖，對應用程序幾乎無影響，全天24小時都可進行備份。

複雜SQL查詢加速

內置並行查詢引擎，對執行時長超過1分鐘的複雜分析類SQL加速效果明顯。本功能須要使用額外的鏈接地址。

5、架構

雲數據庫POLARDB基於Cloud Native設計理念，其架構示意圖及特色以下：

一寫多讀

POLARDB採用分佈式集羣架構，一個集羣包含一個主節點和最多15個只讀節點（至少一個，用於保障高可用）。主節點處理讀寫請求，只讀節點僅處理讀請求。主節點和只讀節點之間採用Active-Active的Failover方式，提供數據庫的高可用服務。

計算與存儲分離

POLARDB採用計算與存儲分離的設計理念，知足公共雲計算環境下用戶業務彈性擴展的剛性需求。數據庫的計算節點（DB Server）僅存儲元數據，而將數據文件、Redo Log等存儲於遠端的存儲節點（Chunk Server）。各計算節點之間僅需同步Redo Log相關的元數據信息，極大下降了主節點和只讀節點間的延遲，並且在主節點故障時，只讀節點能夠快速切換爲主節點。

讀寫分離

讀寫分離是POLARDB for MySQL集羣默認免費提供的一個透明、高可用、自適應的負載均衡能力。經過集羣地址，SQL請求自動轉發到POLARDB集羣的各個節點，提供聚合、高吞吐的併發SQL處理能力。具體請參見讀寫分離。

高速鏈路互聯

數據庫的計算節點和存儲節點之間採用高速網絡互聯，並經過RDMA協議進行數據傳輸，使I/O性能再也不成爲瓶頸。

RDMA是一種遠端內存直接訪問技術，至關於傳統的socket協議軟硬件架構相比較，高速，超低延時，極低的CPU使用率的RDMA主導了RDMA的高速發展。

共享分佈式存儲

多個計算節點共享一份數據，而不是每一個計算節點都存儲一份數據，極大下降了用戶的存儲成本。基於全新打造的分佈式塊設備和文件系統，存儲容量能夠在線平滑擴展，不會受到單機服務器配置的影響，可應對上百TB級別的數據規模。

數據多副本、Parallel-Raft協議

數據庫存儲節點的數據採用多副本形式，確保數據的可靠性，並經過Parallel-Raft協議保證數據的一致性。

6、18年進化

此前，POLARDB核心賣點是100%向下兼容MySQL 5.6，100TB存儲容量，性能是官方MySQL的6倍，跑分超越AWS Aurora。

一、在寫性能方面，再度提高近2倍，去年13萬QPS，今年達到了25萬QPS；POLARDB還支持多達16個節點，其聚合讀性能超過1000萬QPS；在相同測試流程下，POLARDB寫性能比AWS Aurora快了近兩倍；

二、在讀寫分離方面，提供了會話一致性的讀寫分離支持。雖然讀寫分寫是經常使用技術，但一般讀節點會有必定程度的延遲問題，對此，POLARDB新增了智能網關技術，用戶能夠在主節點上完成寫，再從分節點實現讀，知足了用戶的讀寫一致性的需求。

三、SQL加速能力，經過使用MPP技術，可以讓一條SQL同時在16個節點上執行，從而把一條複雜SQL的查詢時間縮短了8-20倍。

四、在數據庫穩定性上，POLARDB是目前全球惟一一家在生產環節大規模使用Optane技術的雲服務商，3D XPoint技術能像寫內存同樣，從物理上消除QOS抖動，數據庫跑起來寫請求會更平穩。

End

無論是阿里，仍是華爲，都發布了本身的分佈式存儲，性能測試都是遙遙領先。無論是實際水平，仍是帶有水分。都但願國產數據庫可以大放異彩。