調研不代表實踐,謹慎採納,結論後續實踐後放出。本文主題:【存儲上雲】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

一、簡介

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 是為雲而設計的資料庫,支持公有雲、私有雲和混合雲,使部署、配置和維護變得十分簡單。

坐標:TiDB 簡介

二、整體架構圖

三、詳細原理

TiKV 詳細解讀 t.cn/RTKRRWv

TiDB 詳細解讀 三篇文章了解 TiDB 技術內幕 - 說計算 (查詢流程)

PD 詳細解讀 三篇文章了解 TiDB 技術內幕 - 談調度

四、兼容性(不支持特性列表)

pingcap/docs-cn

五、FAQ

pingcap/docs-cn

六、硬體需求

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

七、其他問題

1、 對硬碟要求高,啟動會檢測硬碟是否為SSD,若否無法啟動

2、 不支持分區,刪除數據是個大坑。(3.0支持)

解決方案:

set @@session.tidb_batch_delete=1;

3、 批量插數據問題

解決方案:

set @@session.tidb_batch_insert=1;

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

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

5、 內存使用問題,GO語言導致不知道回收機制什麼時候運作。內存使用過多會導致TIDB當機(這點完全不像MYSQL)測試情況是,32G內存,在10分鐘後才回收一半。

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

7、 不支持GBK

8、 不支持存儲過程

9、 列數支持太少,只支持100列

引用:blog.csdn.net/yajie_12/

polardb

一、簡介、成本

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

二、集群架構,計算與存儲分離

POLARDB採用多節點集群的架構,集群中有一個Writer節點(主節點)和多個Reader節點(讀節點),各節點通過分散式文件系統(PolarFileSystem)共享底層的存儲(PolarStore)。

三、讀寫分離

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

四、產品優勢

容量大

最高100TB,您不再需要因為單機容量的天花板而去購買多個實例做分片,由此簡化應用開發,降低運維負擔。

高性價比

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

分鐘級彈性

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

讀一致性

集群地址利用LSN(Log Sequence Number)確保讀取數據時的全局一致性,避免因為主備延遲引起的不一致。

毫秒級延遲(物理複製)

利用基於Redo的物理複製代替基於Binlog的邏輯複製,提升主備複製的效率和穩定性。即使對大表進行加索引、加欄位等DDL操作,也不會造成資料庫的延遲。

無鎖備份

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

複雜SQL查詢加速

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

五、架構

雲資料庫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協議保證數據的一致性。

六、18年進化

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

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

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

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

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

End

不管是阿里,還是華為,都發布了自己的分散式存儲,性能測試都是遙遙領先。不管是實際水平,還是帶有水分。都希望國產資料庫能夠大放異彩。

推薦閱讀:

相关文章