分庫(kù)分表 vs NewSQL，如何取舍？
不點(diǎn)藍(lán)字，我們哪來(lái)故事？
每天 11 點(diǎn)更新文章，餓了點(diǎn)外賣，點(diǎn)擊 ??《無(wú)門檻外賣優(yōu)惠券，每天免費(fèi)領(lǐng)！》
最近與同行科技交流，經(jīng)常被問到分庫(kù)分表與分布式數(shù)據(jù)庫(kù)如何選擇，網(wǎng)上也有很多關(guān)于中間件+傳統(tǒng)關(guān)系數(shù)據(jù)庫(kù)（分庫(kù)分表）與NewSQL分布式數(shù)據(jù)庫(kù)的文章，但有些觀點(diǎn)與判斷是我覺得是偏激的，脫離環(huán)境去評(píng)價(jià)方案好壞其實(shí)有失公允。
本文通過對(duì)兩種模式關(guān)鍵特性實(shí)現(xiàn)原理對(duì)比，希望可以盡可能客觀、中立的闡明各自真實(shí)的優(yōu)缺點(diǎn)以及適用場(chǎng)景。
NewSQL數(shù)據(jù)庫(kù)先進(jìn)在哪兒？
首先關(guān)于“中間件+關(guān)系數(shù)據(jù)庫(kù)分庫(kù)分表”算不算NewSQL分布式數(shù)據(jù)庫(kù)問題，國(guó)外有篇論文pavlo-newsql-sigmodrec，如果根據(jù)該文中的分類，Spanner、TiDB、OB算是第一種新架構(gòu)型，Sharding-Sphere、Mycat、DRDS等中間件方案算是第二種（文中還有第三種云數(shù)據(jù)庫(kù)，本文暫不詳細(xì)介紹）。
NewSQL數(shù)據(jù)庫(kù)相比中間件+分庫(kù)分表的先進(jìn)在哪兒？畫一個(gè)簡(jiǎn)單的架構(gòu)對(duì)比圖：
傳統(tǒng)數(shù)據(jù)庫(kù)面向磁盤設(shè)計(jì)，基于內(nèi)存的存儲(chǔ)管理及并發(fā)控制，不如NewSQL數(shù)據(jù)庫(kù)那般高效利用。 中間件模式SQL解析、執(zhí)行計(jì)劃優(yōu)化等在中間件與數(shù)據(jù)庫(kù)中重復(fù)工作，效率相比較低； NewSQL數(shù)據(jù)庫(kù)的分布式事務(wù)相比于XA進(jìn)行了優(yōu)化，性能更高； 新架構(gòu)NewSQL數(shù)據(jù)庫(kù)存儲(chǔ)設(shè)計(jì)即為基于paxos（或Raft）協(xié)議的多副本，相比于傳統(tǒng)數(shù)據(jù)庫(kù)主從模式（半同步轉(zhuǎn)異步后也存在丟數(shù)問題），在實(shí)現(xiàn)了真正的高可用、高可靠（RTO<30s，RPO=0） NewSQL數(shù)據(jù)庫(kù)天生支持?jǐn)?shù)據(jù)分片，數(shù)據(jù)的遷移、擴(kuò)容都是自動(dòng)化的，大大減輕了DBA的工作，同時(shí)對(duì)應(yīng)用透明，無(wú)需在SQL指定分庫(kù)分表鍵。
這些大多也是NewSQL數(shù)據(jù)庫(kù)產(chǎn)品主要宣傳的點(diǎn)，不過這些看起來(lái)很美好的功能是否真的如此？接下來(lái)針對(duì)以上幾點(diǎn)分別闡述下的我的理解。
分布式事務(wù)
這是把雙刃劍。
CAP限制
想想更早些出現(xiàn)的NoSQL數(shù)據(jù)庫(kù)為何不支持分布式事務(wù)（最新版的mongoDB等也開始支持了），是缺乏理論與實(shí)踐支撐嗎？并不是，原因是CAP定理依然是分布式數(shù)據(jù)庫(kù)頭上的頸箍咒，在保證強(qiáng)一致的同時(shí)必然會(huì)犧牲可用性A或分區(qū)容忍性P。為什么大部分NoSQL不提供分布式事務(wù)？
那么NewSQL數(shù)據(jù)庫(kù)突破CAP定理限制了嗎？并沒有。NewSQL數(shù)據(jù)庫(kù)的鼻主Google Spanner（目前絕大部分分布式數(shù)據(jù)庫(kù)都是按照Spanner架構(gòu)設(shè)計(jì)的）提供了一致性和大于5個(gè)9的可用性，宣稱是一個(gè)“實(shí)際上是CA”的，其真正的含義是系統(tǒng)處于 CA 狀態(tài)的概率非常高，由于網(wǎng)絡(luò)分區(qū)導(dǎo)致的服務(wù)停用的概率非常小，究其真正原因是其打造私有全球網(wǎng)保證了不會(huì)出現(xiàn)網(wǎng)絡(luò)中斷引發(fā)的網(wǎng)絡(luò)分區(qū)，另外就是其高效的運(yùn)維隊(duì)伍,這也是cloud spanner的賣點(diǎn)。詳細(xì)可見CAP提出者Eric Brewer寫的《Spanner, TrueTime 和CAP理論》
推薦一篇關(guān)于分布式系統(tǒng)有趣的文章，站在巨人的分布式肩膀上，其中提到：分布式系統(tǒng)中，您可以知道工作在哪里，或者您可以知道工作何時(shí)完成，但您無(wú)法同時(shí)了解兩者；兩階段協(xié)議本質(zhì)上是反可用性協(xié)議。
完備性：
兩階段提交協(xié)議是否嚴(yán)格支持ACID，各種異常場(chǎng)景是不是都可以覆蓋？2PC在commit階段發(fā)送異常，其實(shí)跟最大努力一階段提交類似也會(huì)有部分可見問題，嚴(yán)格講一段時(shí)間內(nèi)并不能保證A原子性和C一致性（待故障恢復(fù)后recovery機(jī)制可以保證最終的A和C）。
完備的分布式事務(wù)支持并不是一件簡(jiǎn)單的事情，需要可以應(yīng)對(duì)網(wǎng)絡(luò)以及各種硬件包括網(wǎng)卡、磁盤、CPU、內(nèi)存、電源等各類異常，通過嚴(yán)格的測(cè)試。之前跟某友商交流，他們甚至說目前已知的NewSQL在分布式事務(wù)支持上都是不完整的，他們都有案例跑不過，圈內(nèi)人士這么篤定，也說明了分布式事務(wù)的支持完整程度其實(shí)是層次不齊的。分布式事務(wù)的四種解決方案，推薦看下。
但分布式事務(wù)又是這些NewSQL數(shù)據(jù)庫(kù)的一個(gè)非常重要的底層機(jī)制，跨資源的DML、DDL等都依賴其實(shí)現(xiàn)，如果這塊的性能、完備性打折扣，上層跨分片SQL執(zhí)行的正確性會(huì)受到很大影響。
性能
傳統(tǒng)關(guān)系數(shù)據(jù)庫(kù)也支持分布式事務(wù)XA，但為何很少有高并發(fā)場(chǎng)景下用呢？因?yàn)閄A的基礎(chǔ)兩階段提交協(xié)議存在網(wǎng)絡(luò)開銷大，阻塞時(shí)間長(zhǎng)、死鎖等問題，這也導(dǎo)致了其實(shí)際上很少大規(guī)模用在基于傳統(tǒng)關(guān)系數(shù)據(jù)庫(kù)的OLTP系統(tǒng)中。
NewSQL數(shù)據(jù)庫(kù)的分布式事務(wù)實(shí)現(xiàn)也仍然多基于兩階段提交協(xié)議，例如google percolator分布式事務(wù)模型， 采用原子鐘+MVCC+ Snapshot Isolation（SI），這種方式通過TSO(Timestamp Oracle)保證了全局一致性，通過MVCC避免了鎖，另外通過primary lock和secondary lock將提交的一部分轉(zhuǎn)為異步，相比XA確實(shí)提高了分布式事務(wù)的性能。
SI是樂觀鎖，在熱點(diǎn)數(shù)據(jù)場(chǎng)景，可能會(huì)大量的提交失敗。另外SI的隔離級(jí)別與RR并非完全相同，它不會(huì)有幻想讀，但會(huì)有寫傾斜。
但不管如何優(yōu)化，相比于1PC，2PC多出來(lái)的GID獲取、網(wǎng)絡(luò)開銷、prepare日志持久化還是會(huì)帶來(lái)很大的性能損失，尤其是跨節(jié)點(diǎn)的數(shù)量比較多時(shí)會(huì)更加顯著，例如在銀行場(chǎng)景做個(gè)批量扣款，一個(gè)文件可能上W個(gè)賬戶，這樣的場(chǎng)景無(wú)論怎么做還是吞吐都不會(huì)很高。
Spanner給出的分布式事務(wù)測(cè)試數(shù)據(jù)
嘗試將一致性要求弱化，便是柔性事務(wù)，放棄ACID(Atomicity,Consistency, Isolation, Durability)，轉(zhuǎn)投BASE(Basically Available,Soft state,Eventually consistent)，例如Saga、TCC、可靠消息保證最終一致等模型，對(duì)于大規(guī)模高并發(fā)OLTP場(chǎng)景，我個(gè)人更建議使用柔性事務(wù)而非強(qiáng)一致的分布式事務(wù)。關(guān)于柔性事務(wù)，筆者之前也寫過一個(gè)技術(shù)組件，最近幾年也涌現(xiàn)出了一些新的模型與框架（例如阿里剛開源的Fescar），限于篇幅不再贅述，有空再單獨(dú)寫篇文章。
解決分布式事務(wù)是否只能用兩階段提交協(xié)議？?oceanbase1.0中通過updateserver避免分布式事務(wù)的思路很有啟發(fā)性 ，不過2.0版后也變成了2PC。業(yè)界分布式事務(wù)也并非只有兩階段提交這一解，也有其它方案its-time-to-move-on-from-two-phase(國(guó)內(nèi)有翻譯版https://www.jdon.com/51588)
HA與異地多活
主從模式并不是最優(yōu)的方式，就算是半同步復(fù)制，在極端情況下（半同步轉(zhuǎn)異步）也存在丟數(shù)問題，目前業(yè)界公認(rèn)更好的方案是基于paxos分布式一致性協(xié)議或者其它類paxos如raft方式，Google Spanner、TiDB、cockcoachDB、OB都采用了這種方式，基于Paxos協(xié)議的多副本存儲(chǔ)，遵循過半寫原則，支持自動(dòng)選主，解決了數(shù)據(jù)的高可靠，縮短了failover時(shí)間，提高了可用性，特別是減少了運(yùn)維的工作量，這種方案技術(shù)上已經(jīng)很成熟，也是NewSQL數(shù)據(jù)庫(kù)底層的標(biāo)配。
當(dāng)然這種方式其實(shí)也可以用在傳統(tǒng)關(guān)系數(shù)據(jù)庫(kù)，阿里、微信團(tuán)隊(duì)等也有將MySQL存儲(chǔ)改造支持paxos多副本的，MySQL也推出了官方版MySQL Group Cluster，預(yù)計(jì)不遠(yuǎn)的未來(lái)主從模式可能就成為歷史了。
分布式一致性算法本身并不難，但具體在工程實(shí)踐時(shí)，需要考慮很多異常并做很多優(yōu)化，實(shí)現(xiàn)一個(gè)生產(chǎn)級(jí)可靠成熟的一致性協(xié)議并不容易。例如實(shí)際使用時(shí)必須轉(zhuǎn)化實(shí)現(xiàn)為multi-paxos或multi-raft，需要通過batch、異步等方式減少網(wǎng)絡(luò)、磁盤IO等開銷。
需要注意的是很多NewSQL數(shù)據(jù)庫(kù)廠商宣傳基于paxos或raft協(xié)議可以實(shí)現(xiàn)【異地多活】，這個(gè)實(shí)際上是有前提的，那就是異地之間網(wǎng)絡(luò)延遲不能太高。以銀行“兩地三中心”為例，異地之間多相隔數(shù)千里，延時(shí)達(dá)到數(shù)十毫秒，如果要多活，那便需異地副本也參與數(shù)據(jù)庫(kù)日志過半確認(rèn)，這樣高的延時(shí)幾乎沒有OLTP系統(tǒng)可以接受的。
數(shù)據(jù)庫(kù)層面做異地多活是個(gè)美好的愿景，但距離導(dǎo)致的延時(shí)目前并沒有好的方案。
之前跟螞蟻團(tuán)隊(duì)交流，螞蟻異地多活的方案是在應(yīng)用層通過MQ同步雙寫交易信息，異地DC將交易信息保存在分布式緩存中，一旦發(fā)生異地切換，數(shù)據(jù)庫(kù)同步中間件會(huì)告之?dāng)?shù)據(jù)延遲時(shí)間，應(yīng)用從緩存中讀取交易信息，將這段時(shí)間內(nèi)涉及到的業(yè)務(wù)對(duì)象例如用戶、賬戶進(jìn)行黑名單管理，等數(shù)據(jù)同步追上之后再將這些業(yè)務(wù)對(duì)象從黑名單中剔除。由于雙寫的不是所有數(shù)據(jù)庫(kù)操作日志而只是交易信息，數(shù)據(jù)延遲只影響一段時(shí)間內(nèi)數(shù)據(jù)，這是目前我覺得比較靠譜的異地度多活方案。
另外有些系統(tǒng)進(jìn)行了單元化改造，這在paxos選主時(shí)也要結(jié)合考慮進(jìn)去，這也是目前很多NewSQL數(shù)據(jù)庫(kù)欠缺的功能。
Scale橫向擴(kuò)展與分片機(jī)制
paxos算法解決了高可用、高可靠問題，并沒有解決Scale橫向擴(kuò)展的問題，所以分片是必須支持的。NewSQL數(shù)據(jù)庫(kù)都是天生內(nèi)置分片機(jī)制的，而且會(huì)根據(jù)每個(gè)分片的數(shù)據(jù)負(fù)載(磁盤使用率、寫入速度等)自動(dòng)識(shí)別熱點(diǎn)，然后進(jìn)行分片的分裂、數(shù)據(jù)遷移、合并，這些過程應(yīng)用是無(wú)感知的，這省去了DBA的很多運(yùn)維工作量。以TiDB為例，它將數(shù)據(jù)切成region，如果region到64M時(shí)，數(shù)據(jù)自動(dòng)進(jìn)行遷移。
分庫(kù)分表模式下需要應(yīng)用設(shè)計(jì)之初就要明確各表的拆分鍵、拆分方式（range、取模、一致性哈?；蛘咦远x路由表）、路由規(guī)則、拆分庫(kù)表數(shù)量、擴(kuò)容方式等。相比NewSQL數(shù)據(jù)庫(kù)，這種模式給應(yīng)用帶來(lái)了很大侵入和復(fù)雜度，這對(duì)大多數(shù)系統(tǒng)來(lái)說也是一大挑戰(zhàn)。
分庫(kù)分表模式也能做到在線擴(kuò)容，基本思路是通過異步復(fù)制先追加數(shù)據(jù)，然后設(shè)置只讀完成路由切換，最后放開寫操作，當(dāng)然這些需要中間件與數(shù)據(jù)庫(kù)端配合一起才能完成。
這里有個(gè)問題是NewSQL數(shù)據(jù)庫(kù)統(tǒng)一的內(nèi)置分片策略（例如tidb基于range）可能并不是最高效的，因?yàn)榕c領(lǐng)域模型中的劃分要素并不一致，這導(dǎo)致的后果是很多交易會(huì)產(chǎn)生分布式事務(wù)。
舉個(gè)例子，銀行核心業(yè)務(wù)系統(tǒng)是以客戶為維度，也就是說客戶表、該客戶的賬戶表、流水表在絕大部分場(chǎng)景下是一起寫的，但如果按照各表主鍵range進(jìn)行分片，這個(gè)交易并不能在一個(gè)分片上完成，這在高頻OLTP系統(tǒng)中會(huì)帶來(lái)性能問題。
分布式SQL支持
常見的單分片SQL，這兩者都能很好支持。NewSQL數(shù)據(jù)庫(kù)由于定位與目標(biāo)是一個(gè)通用的數(shù)據(jù)庫(kù)，所以支持的SQL會(huì)更完整，包括跨分片的join、聚合等復(fù)雜SQL。
中間件模式多面向應(yīng)用需求設(shè)計(jì)，不過大部分也支持帶拆分鍵SQL、庫(kù)表遍歷、單庫(kù)join、聚合、排序、分頁(yè)等。但對(duì)跨庫(kù)的join以及聚合支持就不夠了。
NewSQL數(shù)據(jù)庫(kù)一般并不支持存儲(chǔ)過程、視圖、外鍵等功能，而中間件模式底層就是傳統(tǒng)關(guān)系數(shù)據(jù)庫(kù)，這些功能如果只是涉及單庫(kù)是比較容易支持的。
NewSQL數(shù)據(jù)庫(kù)往往選擇兼容MySQL或者PostgreSQL協(xié)議，所以SQL支持僅局限于這兩種，中間件例如驅(qū)動(dòng)模式往往只需做簡(jiǎn)單的SQL解析、計(jì)算路由、SQL重寫，所以可以支持更多種類的數(shù)據(jù)庫(kù)SQL。
SQL支持的差異主要在于分布式SQL執(zhí)行計(jì)劃生成器，由于NewSQL數(shù)據(jù)庫(kù)具有底層數(shù)據(jù)的分布、統(tǒng)計(jì)信息，因此可以做CBO，生成的執(zhí)行計(jì)劃效率更高，而中間件模式下沒有這些信息，往往只能基于規(guī)則RBO（Rule-Based-Opimization），這也是為什么中間件模式一般并不支持跨庫(kù)join，因?yàn)閷?shí)現(xiàn)了效率也往往并不高，還不如交給應(yīng)用去做。
這里也可以看出中間件+分庫(kù)分表模式的架構(gòu)風(fēng)格體現(xiàn)出的是一種妥協(xié)、平衡，它是一個(gè)面向應(yīng)用型的設(shè)計(jì)；而NewSQL數(shù)據(jù)庫(kù)則要求更高、“大包大攬”，它是一個(gè)通用底層技術(shù)軟件，因此后者的復(fù)雜度、技術(shù)門檻也高很多。
存儲(chǔ)引擎
傳統(tǒng)關(guān)系數(shù)據(jù)庫(kù)的存儲(chǔ)引擎設(shè)計(jì)都是面向磁盤的，大多都基于B+樹。B+樹通過降低樹的高度減少隨機(jī)讀、進(jìn)而減少磁盤尋道次數(shù)，提高讀的性能，但大量的隨機(jī)寫會(huì)導(dǎo)致樹的分裂，從而帶來(lái)隨機(jī)寫，導(dǎo)致寫性能下降。NewSQL的底層存儲(chǔ)引擎則多采用LSM，相比B+樹LSM將對(duì)磁盤的隨機(jī)寫變成順序?qū)?，大大提高了寫的性能。不過LSM的的讀由于需要合并數(shù)據(jù)性能比B+樹差，一般來(lái)說LSM更適合應(yīng)在寫大于讀的場(chǎng)景。
當(dāng)然這只是單純數(shù)據(jù)結(jié)構(gòu)角度的對(duì)比，在數(shù)據(jù)庫(kù)實(shí)際實(shí)現(xiàn)時(shí)還會(huì)通過SSD、緩沖、bloom filter等方式優(yōu)化讀寫性能，所以讀性能基本不會(huì)下降太多。NewSQL數(shù)據(jù)由于多副本、分布式事務(wù)等開銷，相比單機(jī)關(guān)系數(shù)據(jù)庫(kù)SQL的響應(yīng)時(shí)間并不占優(yōu)，但由于集群的彈性擴(kuò)展，整體QPS提升還是很明顯的，這也是NewSQL數(shù)據(jù)庫(kù)廠商說分布式數(shù)據(jù)庫(kù)更看重的是吞吐，而不是單筆SQL響應(yīng)時(shí)間的原因。
成熟度與生態(tài)
分布式數(shù)據(jù)庫(kù)是個(gè)新型通用底層軟件，準(zhǔn)確的衡量與評(píng)價(jià)需要一個(gè)多維度的測(cè)試模型，需包括發(fā)展現(xiàn)狀、使用情況、社區(qū)生態(tài)、監(jiān)控運(yùn)維、周邊配套工具、功能滿足度、DBA人才、SQL兼容性、性能測(cè)試、高可用測(cè)試、在線擴(kuò)容、分布式事務(wù)、隔離級(jí)別、在線DDL等等。
雖然NewSQL數(shù)據(jù)庫(kù)發(fā)展經(jīng)過了一定時(shí)間檢驗(yàn)，但多集中在互聯(lián)網(wǎng)以及傳統(tǒng)企業(yè)非核心交易系統(tǒng)中，目前還處于快速迭代、規(guī)模使用不斷優(yōu)化完善的階段。相比而言，傳統(tǒng)關(guān)系數(shù)據(jù)庫(kù)則經(jīng)過了多年的發(fā)展，通過完整的評(píng)測(cè)，在成熟度、功能、性能、周邊生態(tài)、風(fēng)險(xiǎn)把控、相關(guān)人才積累等多方面都具有明顯優(yōu)勢(shì)，同時(shí)對(duì)已建系統(tǒng)的兼容性也更好。?
對(duì)于互聯(lián)網(wǎng)公司，數(shù)據(jù)量的增長(zhǎng)壓力以及追求新技術(shù)的基因會(huì)更傾向于嘗試NewSQL數(shù)據(jù)庫(kù)，不用再考慮庫(kù)表拆分、應(yīng)用改造、擴(kuò)容、事務(wù)一致性等問題怎么看都是非常吸引人的方案。
對(duì)于傳統(tǒng)企業(yè)例如銀行這種風(fēng)險(xiǎn)意識(shí)較高的行業(yè)來(lái)說，NewSQL數(shù)據(jù)庫(kù)則可能在未來(lái)一段時(shí)間內(nèi)仍處于探索、審慎試點(diǎn)的階段?；谥虚g件+分庫(kù)分表模式架構(gòu)簡(jiǎn)單，技術(shù)門檻更低，雖然沒有NewSQL數(shù)據(jù)庫(kù)功能全面，但大部分場(chǎng)景最核心的訴求也就是拆分后SQL的正確路由，而此功能中間件模式應(yīng)對(duì)還是綽綽有余的，可以說在大多數(shù)OLTP場(chǎng)景是夠用的。
限于篇幅，其它特性例如在線DDL、數(shù)據(jù)遷移、運(yùn)維工具等特性就不在本文展開對(duì)比。
總結(jié)
如果看完以上內(nèi)容，您還不知道選哪種模式，那么結(jié)合以下幾個(gè)問題，先思考下NewSQL數(shù)據(jù)庫(kù)解決的點(diǎn)對(duì)于自身是不是真正的痛點(diǎn)：
強(qiáng)一致事務(wù)是否必須在數(shù)據(jù)庫(kù)層解決？ 數(shù)據(jù)的增長(zhǎng)速度是否不可預(yù)估的？ 擴(kuò)容的頻率是否已超出了自身運(yùn)維能力？ 相比響應(yīng)時(shí)間更看重吞吐？ 是否必須做到對(duì)應(yīng)用完全透明？ 是否有熟悉NewSQL數(shù)據(jù)庫(kù)的DBA團(tuán)隊(duì)？
如果以上有2到3個(gè)是肯定的，那么你可以考慮用NewSQL數(shù)據(jù)庫(kù)了，雖然前期可能需要一定的學(xué)習(xí)成本，但它是數(shù)據(jù)庫(kù)的發(fā)展方向，未來(lái)收益也會(huì)更高，尤其是互聯(lián)網(wǎng)行業(yè)，隨著數(shù)據(jù)量的突飛猛進(jìn)，分庫(kù)分表帶來(lái)的痛苦會(huì)與日俱增。當(dāng)然選擇NewSQL數(shù)據(jù)庫(kù)你也要做好承擔(dān)一定風(fēng)險(xiǎn)的準(zhǔn)備。如果你還未做出抉擇，不妨再想想下面幾個(gè)問題：
最終一致性是否可以滿足實(shí)際場(chǎng)景？ 數(shù)據(jù)未來(lái)幾年的總量是否可以預(yù)估？ 擴(kuò)容、DDL等操作是否有系統(tǒng)維護(hù)窗口？ 對(duì)響應(yīng)時(shí)間是否比吞吐更敏感？ 是否需要兼容已有的關(guān)系數(shù)據(jù)庫(kù)系統(tǒng)？ 是否已有傳統(tǒng)數(shù)據(jù)庫(kù)DBA人才的積累？ 是否可容忍分庫(kù)分表對(duì)應(yīng)用的侵入？
如果這些問題有多數(shù)是肯定的，那還是分庫(kù)分表吧。在軟件領(lǐng)域很少有完美的解決方案，NewSQL數(shù)據(jù)庫(kù)也不是數(shù)據(jù)分布式架構(gòu)的銀彈。相比而言分庫(kù)分表是一個(gè)代價(jià)更低、風(fēng)險(xiǎn)更小的方案，它最大程度復(fù)用傳統(tǒng)關(guān)系數(shù)據(jù)庫(kù)生態(tài)，通過中間件也可以滿足分庫(kù)分表后的絕大多數(shù)功能，定制化能力更強(qiáng)。
在當(dāng)前NewSQL數(shù)據(jù)庫(kù)還未完全成熟的階段，分庫(kù)分表可以說是一個(gè)上限低但下限高的方案，尤其傳統(tǒng)行業(yè)的核心系統(tǒng)，如果你仍然打算把數(shù)據(jù)庫(kù)當(dāng)做一個(gè)黑盒產(chǎn)品來(lái)用，踏踏實(shí)實(shí)用好分庫(kù)分表會(huì)被認(rèn)為是個(gè)穩(wěn)妥的選擇。
很多時(shí)候軟件選型取決于領(lǐng)域特征以及架構(gòu)師風(fēng)格，限于筆者知識(shí)與所屬行業(yè)特點(diǎn)所限，以上僅為個(gè)人粗淺的一些觀點(diǎn)，歡迎討論。
往期推薦
下方二維碼關(guān)注我
技術(shù)草根，堅(jiān)持分享?編程，算法，架構(gòu)
看完文章，餓了點(diǎn)外賣，點(diǎn)擊 ??《無(wú)門檻外賣優(yōu)惠券，每天免費(fèi)領(lǐng)！》