去分库分表的亿级数据NewSQL实践之旅
http://dbaplus.cn/news-11-1931-1.html
背景?
?
2017 年初，公司用戶中心體系面臨迭代和重構(gòu)，當(dāng)時(shí)數(shù)據(jù)庫(kù)有數(shù)億多的核心數(shù)據(jù)通過(guò) HashKey?分為了 1024 張表在 64 個(gè)數(shù)據(jù)庫(kù)中來(lái)存儲(chǔ)，使用自研的代碼框架來(lái)進(jìn)行對(duì)應(yīng) HashKey?的 seek 操作。
?
這時(shí)，非 HashKey 的查詢、DDL 變更等業(yè)務(wù)需求、分表分庫(kù)邏輯代碼框架的局限讓研發(fā)和運(yùn)維都面臨較高的數(shù)據(jù)庫(kù)使用成本，數(shù)據(jù)庫(kù)不能靈活高效的支撐業(yè)務(wù)需求。
?
圖1：分庫(kù)分表方案架構(gòu)圖
?
為了解決上述問(wèn)題，我們的技術(shù)團(tuán)隊(duì)急需一套同時(shí)滿足如下的條件的數(shù)據(jù)庫(kù)分布式集群：
-
能夠提供實(shí)時(shí)的 OLTP 的一致性數(shù)據(jù)存儲(chǔ)服務(wù)；
-
彈性的分布式架構(gòu)；
-
配套的監(jiān)控備份方案；
-
穩(wěn)定的高可用性；
-
較低的遷移重構(gòu)成本。
?
前期選擇?
?
最開(kāi)始先考察了幾個(gè)方案，但都有相對(duì)來(lái)說(shuō)的不足：
?
1方案一：
?
將整個(gè)分表分庫(kù)邏輯剝離到開(kāi)源分表分庫(kù)中間件上：
?
-
基于 2PC 的 XA 弱事務(wù)的一致性保證不盡如人意
-
高可用架構(gòu)更加復(fù)雜，單分片的局部不可用會(huì)對(duì)全局產(chǎn)生影響
-
備份恢復(fù)的復(fù)雜度高
-
這些方案引入了新的 sharding key 和 join key 的設(shè)計(jì)問(wèn)題，整體的遷移難度不降反升
?
2方案二：
?
官方的 MySQL Cluster 集群：
?
-
NDB?引擎不同于 InnoDB，需要修改表引擎，且實(shí)際使用效果未知
-
NDB的高可用有腦裂風(fēng)險(xiǎn)
-
監(jiān)控備份的方案需要另作整理
-
國(guó)內(nèi)生產(chǎn)用例不多、資料缺乏，非企業(yè)版運(yùn)維流程復(fù)雜
?
探索?
?
機(jī)緣巧合下，我們發(fā)現(xiàn)NewSQL特性可以提供很好的支持，于是受 Google Spanner 的論文啟發(fā)設(shè)計(jì)而來(lái)的開(kāi)源分布式 NewSQL 數(shù)據(jù)庫(kù) TiDB 進(jìn)入了我們的視線，它具備如下 NewSQL 特性：
?
-
SQL支持 （TiDB 是 MySQL 兼容的）
-
水平線性彈性擴(kuò)展
-
分布式事務(wù)
-
跨數(shù)據(jù)中心數(shù)據(jù)強(qiáng)一致性保證
-
故障自恢復(fù)的高可用
-
海量數(shù)據(jù)高并發(fā)寫入及實(shí)時(shí)查詢（HTAP 混合負(fù)載）
?
所以說(shuō)，上述的特點(diǎn)非常契合目前我們?cè)跀?shù)據(jù)庫(kù)應(yīng)用設(shè)計(jì)上碰到的問(wèn)題。經(jīng)過(guò)評(píng)估，我們開(kāi)始著手安排部署和測(cè)試，在備份、監(jiān)控、故障恢復(fù)和擴(kuò)展幾個(gè)方面有以下的一些心得：
?
-
官方提供了一套基于 mydumper 和 myloader 的工具套件，是基于邏輯備份的方式，對(duì)于遷移來(lái)說(shuō)是很便捷的；
-
監(jiān)控用的是應(yīng)用內(nèi)置上報(bào) Prometheus 的方案，可以寫腳本與自有的監(jiān)控系統(tǒng)對(duì)接；
-
有狀態(tài)的KV層采用的是 Raft 協(xié)議來(lái)保證高可用，Leader 的選舉機(jī)制滿足了故障自恢復(fù)的需求；
-
無(wú)狀態(tài)的?TiDB-Server 查詢層可以在前段搭建LVS 或HAProxy來(lái)保證故障的切換；
-
KV?層的 Region 分裂保證了集群無(wú)感知的擴(kuò)展。
?
測(cè)試之后發(fā)現(xiàn)數(shù)據(jù)庫(kù)運(yùn)維中比較重要的幾項(xiàng)都已經(jīng)閉環(huán)的解決了，但有得有失，實(shí)測(cè)結(jié)論是：
?
-
TiDB 是分布式結(jié)構(gòu)，有網(wǎng)絡(luò)以及多副本開(kāi)銷，導(dǎo)致 Sysbench OLTP 測(cè)試中 單 server 的讀性能不如 MySQL，但在大數(shù)據(jù)量下性能相較于MySQL不會(huì)產(chǎn)生明顯下滑，且彈性擴(kuò)展能力評(píng)估后可以滿足業(yè)務(wù)的峰值需求；
-
TiDB 的 OLAP 能力在大數(shù)據(jù)量下優(yōu)于 MySQL，且能看到持續(xù)的大幅提升；
-
由于 TiDB-Server 是無(wú)狀態(tài)的，后續(xù)可以添加 Load Balance 來(lái)擴(kuò)展 Server 層的支撐。
?
持續(xù)引入?
?
在性能和需求滿足的前提下，我們開(kāi)始著手業(yè)務(wù)層的接入和改造，因?yàn)榧嫒軲ySQL 協(xié)議，所以遷移成本大大降低，同時(shí) TiDB 官方也提供的工具 Syncer ，部分遷移在業(yè)務(wù)層就是一次 MySQL 的主從切換。
?
于是用戶積分系統(tǒng)的擴(kuò)展便不再采用分表分庫(kù)的方案，分表邏輯回歸到多個(gè)獨(dú)立的單表，數(shù)億的數(shù)據(jù)在 OLTP 的業(yè)務(wù)場(chǎng)景下表現(xiàn)十分出色，沒(méi)有 sharding key 的約束后，整個(gè)使用邏輯在上層看來(lái)和 MySQL 單表沒(méi)有不同，更加靈活的索引也提供了一部分低開(kāi)銷的 OLAP 的查詢能力，總體來(lái)說(shuō)，整體的遷移改造流程比較順利，業(yè)務(wù)契合度也很高。
?
隨著上述系統(tǒng)的成功應(yīng)用后，后面符合場(chǎng)景的 OLTP 項(xiàng)目也開(kāi)始逐漸使用，當(dāng)然在和業(yè)務(wù)結(jié)合的過(guò)程中也需要一些定制和改造，主要涉及登錄態(tài)系統(tǒng)、補(bǔ)包碼系統(tǒng)、用戶軌跡項(xiàng)目和存儲(chǔ)層。
?
-
登錄態(tài)系統(tǒng)：原先是在 MySQL 采用 Replace 保留最后一條數(shù)據(jù)，而遷移到NewSQL ??的模式后，由于表的伸縮能力獲得了很大的提升，故將 Replace 改為了 Insert 保留了所有的登錄情況，單表數(shù)據(jù)量十億以上，業(yè)務(wù)上支持了更多維度的記錄，沒(méi)有碰到性能和擴(kuò)展性問(wèn)題。
-
禮包碼系統(tǒng)：禮包碼的主流程為復(fù)雜度 O(1) 的 hash seek OLTP業(yè)務(wù)，經(jīng)過(guò)改造后，將原來(lái)的 100 個(gè)表的分表模式集中成單表歸檔式管理，單表數(shù)據(jù)預(yù)計(jì)會(huì)達(dá)到 20 億+。
-
用戶軌跡項(xiàng)目：數(shù)據(jù)庫(kù)彈性能力增長(zhǎng)后的新需求，一些重要的用戶行為數(shù)據(jù)的記錄。
?
在KV存儲(chǔ)層沒(méi)有瓶頸時(shí)，采用復(fù)用了集群的KV?層的策略，在無(wú)狀態(tài)的 Server 層做了業(yè)務(wù)隔離，間接的提升了整個(gè)集群的使用率，類似一個(gè) DBaaS 的服務(wù)。如下圖所示：
?
圖2：多套業(yè)務(wù)系統(tǒng) TiDB 部署圖
?
目前的情況和期望?
?
從 RC2.2 版本到 GA1.0，游族平臺(tái)部的生產(chǎn)環(huán)境已經(jīng)有 3 套 TiDB 集群在運(yùn)行，共計(jì)支撐了 6 個(gè) OLTP 業(yè)務(wù)的穩(wěn)定運(yùn)行快一年的時(shí)間。 期間在集群部署策略、BUG 響應(yīng)和修復(fù)、升級(jí)方案協(xié)助、遷移工具方面，廠商和開(kāi)源社區(qū)都可以給予全面的支持。在后期對(duì)于分析型的需求上，我們也會(huì)嘗試使用重 OLAP 需求的 TiSpark 計(jì)算層。
?
NewSQL給了大庫(kù)大表業(yè)務(wù)一個(gè)全新的選擇方向，相信以后能在更多的業(yè)務(wù)選型和設(shè)計(jì)方案上給出新的思路和方向。
轉(zhuǎn)載于:https://www.cnblogs.com/davidwang456/articles/8995041.html
《新程序員》：云原生和全面數(shù)字化實(shí)踐50位技術(shù)專家共同創(chuàng)作，文字、視頻、音頻交互閱讀總結(jié)
以上是生活随笔為你收集整理的去分库分表的亿级数据NewSQL实践之旅的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。
- 上一篇： 利用spring session解决共享
- 下一篇： 大众点评订单分库分表实践之路