建站
咨詢
售后
建站咨詢
新聞中心
數(shù)據(jù)庫為什么要分庫分表
1 基本思想之什么是分庫分表？
成都創(chuàng)新互聯(lián)是一家專注網(wǎng)站建設(shè)、網(wǎng)絡(luò)營銷策劃、微信小程序定制開發(fā)、電子商務(wù)建設(shè)、網(wǎng)絡(luò)推廣、移動互聯(lián)開發(fā)、研究、服務(wù)為一體的技術(shù)型公司。公司成立十年以來，已經(jīng)為上1000+成都軟裝設(shè)計各業(yè)的企業(yè)公司提供互聯(lián)網(wǎng)服務(wù)?，F(xiàn)在，服務(wù)的上1000+客戶與我們一路同行，見證我們的成長；未來，我們一起分享成功的喜悅。
從字面上簡單理解，就是把原本存儲于一個庫的數(shù)據(jù)分塊存儲到多個庫上，把原本存儲于一個表的數(shù)據(jù)分塊存儲到多個表上。
2 基本思想之為什么要分庫分表？
數(shù)
據(jù)庫中的數(shù)據(jù)量不一定是可控的，在未進(jìn)行分庫分表的情況下，隨著時間和業(yè)務(wù)的發(fā)展，庫中的表會越來越多，表中的數(shù)據(jù)量也會越來越大，相應(yīng)地，數(shù)據(jù)操作，增
刪改查的開銷也會越來越大；另外，由于無法進(jìn)行分布式式部署，而一臺服務(wù)器的資源（CPU、磁盤、內(nèi)存、IO等）是有限的，最終數(shù)據(jù)庫所能承載的數(shù)據(jù)量、
數(shù)據(jù)處理能力都將遭遇瓶頸。
3 分庫分表的實施策略。
分庫分表有垂直切分和水平切分兩種。
3.1
何謂垂直切分，即將表按照功能模塊、關(guān)系密切程度劃分出來，部署到不同的庫上。例如，我們會建立定義數(shù)據(jù)庫workDB、商品數(shù)據(jù)庫payDB、用戶數(shù)據(jù)
庫userDB、日志數(shù)據(jù)庫logDB等，分別用于存儲項目數(shù)據(jù)定義表、商品定義表、用戶數(shù)據(jù)表、日志數(shù)據(jù)表等。
3.2
何謂水平切分，當(dāng)一個表中的數(shù)據(jù)量過大時，我們可以把該表的數(shù)據(jù)按照某種規(guī)則，例如userID散列，進(jìn)行劃分，然后存儲到多個結(jié)構(gòu)相同的表，和不同的庫
上。例如，我們的userDB中的用戶數(shù)據(jù)表中，每一個表的數(shù)據(jù)量都很大，就可以把userDB切分為結(jié)構(gòu)相同的多個userDB：part0DB、
part1DB等，再將userDB上的用戶數(shù)據(jù)表userTable，切分為很多userTable：userTable0、userTable1等，
然后將這些表按照一定的規(guī)則存儲到多個userDB上。
3.3 應(yīng)該使用哪一種方式來實施數(shù)據(jù)庫分庫分表，這要看數(shù)據(jù)庫中數(shù)據(jù)量的瓶頸所在，并綜合項目的業(yè)務(wù)類型進(jìn)行考慮。
如果數(shù)據(jù)庫是因為表太多而造成海量數(shù)據(jù)，并且項目的各項業(yè)務(wù)邏輯劃分清晰、低耦合，那么規(guī)則簡單明了、容易實施的垂直切分必是首選。
而
如果數(shù)據(jù)庫中的表并不多，但單表的數(shù)據(jù)量很大、或數(shù)據(jù)熱度很高，這種情況之下就應(yīng)該選擇水平切分，水平切分比垂直切分要復(fù)雜一些，它將原本邏輯上屬于一體
的數(shù)據(jù)進(jìn)行了物理分割，除了在分割時要對分割的粒度做好評估，考慮數(shù)據(jù)平均和負(fù)載平均，后期也將對項目人員及應(yīng)用程序產(chǎn)生額外的數(shù)據(jù)管理負(fù)擔(dān)。
在現(xiàn)實項目中，往往是這兩種情況兼而有之，這就需要做出權(quán)衡，甚至既需要垂直切分，又需要水平切分。我們的游戲項目便綜合使用了垂直與水平切分，我們首先對數(shù)據(jù)庫進(jìn)行垂直切分，然后，再針對一部分表，通常是用戶數(shù)據(jù)表，進(jìn)行水平切分。
4 分庫分表存在的問題。
4.1 事務(wù)問題。
在執(zhí)行分庫分表之后，由于數(shù)據(jù)存儲到了不同的庫上，數(shù)據(jù)庫事務(wù)管理出現(xiàn)了困難。如果依賴數(shù)據(jù)庫本身的分布式事務(wù)管理功能去執(zhí)行事務(wù)，將付出高昂的性能代價；如果由應(yīng)用程序去協(xié)助控制，形成程序邏輯上的事務(wù)，又會造成編程方面的負(fù)擔(dān)。
4.2 跨庫跨表的join問題。
在執(zhí)行了分庫分表之后，難以避免會將原本邏輯關(guān)聯(lián)性很強的數(shù)據(jù)劃分到不同的表、不同的庫上，這時，表的關(guān)聯(lián)操作將受到限制，我們無法join位于不同分庫的表，也無法join分表粒度不同的表，結(jié)果原本一次查詢能夠完成的業(yè)務(wù)，可能需要多次查詢才能完成。
4.3 額外的數(shù)據(jù)管理負(fù)擔(dān)和數(shù)據(jù)運算壓力。
額
外的數(shù)據(jù)管理負(fù)擔(dān)，最顯而易見的就是數(shù)據(jù)的定位問題和數(shù)據(jù)的增刪改查的重復(fù)執(zhí)行問題，這些都可以通過應(yīng)用程序解決，但必然引起額外的邏輯運算，例如，對于
一個記錄用戶成績的用戶數(shù)據(jù)表userTable，業(yè)務(wù)要求查出成績最好的100位，在進(jìn)行分表之前，只需一個order
by語句就可以搞定，但是在進(jìn)行分表之后，將需要n個order
by語句，分別查出每一個分表的前100名用戶數(shù)據(jù)，然后再對這些數(shù)據(jù)進(jìn)行合并計算，才能得出結(jié)果。
分庫分表 VS newsql數(shù)據(jù)庫
最近與同行 科技 交流，經(jīng)常被問到分庫分表與分布式數(shù)據(jù)庫如何選擇，網(wǎng)上也有很多關(guān)于中間件+傳統(tǒng)關(guān)系數(shù)據(jù)庫（分庫分表）與NewSQL分布式數(shù)據(jù)庫的文章，但有些觀點與判斷是我覺得是偏激的，脫離環(huán)境去評價方案好壞其實有失公允。
本文通過對兩種模式關(guān)鍵特性實現(xiàn)原理對比，希望可以盡可能客觀、中立的闡明各自真實的優(yōu)缺點以及適用場景。
首先關(guān)于“中間件+關(guān)系數(shù)據(jù)庫分庫分表”算不算NewSQL分布式數(shù)據(jù)庫問題，國外有篇論文pavlo-newsql-sigmodrec，如果根據(jù)該文中的分類，Spanner、TiDB、OB算是第一種新架構(gòu)型，Sharding-Sphere、Mycat、DRDS等中間件方案算是第二種（文中還有第三種云數(shù)據(jù)庫，本文暫不詳細(xì)介紹）。
基于中間件（包括SDK和Proxy兩種形式）+傳統(tǒng)關(guān)系數(shù)據(jù)庫（分庫分表）模式是不是分布式架構(gòu)？我覺得是的，因為存儲確實也分布式了，也能實現(xiàn)橫向擴(kuò)展。但是不是"偽"分布式數(shù)據(jù)庫？從架構(gòu)先進(jìn)性來看，這么說也有一定道理。"偽"主要體現(xiàn)在中間件層與底層DB重復(fù)的SQL解析與執(zhí)行計劃生成、存儲引擎基于B+Tree等，這在分布式數(shù)據(jù)庫架構(gòu)中實際上冗余低效的。為了避免引起真?zhèn)畏植际綌?shù)據(jù)庫的口水戰(zhàn)，本文中NewSQL數(shù)據(jù)庫特指這種新架構(gòu)NewSQL數(shù)據(jù)庫。
NewSQL數(shù)據(jù)庫相比中間件+分庫分表的先進(jìn)在哪兒？畫一個簡單的架構(gòu)對比圖：
這些大多也是NewSQL數(shù)據(jù)庫產(chǎn)品主要宣傳的點，不過這些看起來很美好的功能是否真的如此？接下來針對以上幾點分別闡述下的我的理解。
這是把雙刃劍。
CAP限制
想想更早些出現(xiàn)的NoSQL數(shù)據(jù)庫為何不支持分布式事務(wù)（最新版的mongoDB等也開始支持了），是缺乏理論與實踐支撐嗎？并不是，原因是CAP定理依然是分布式數(shù)據(jù)庫頭上的頸箍咒，在保證強一致的同時必然會犧牲可用性A或分區(qū)容忍性P。為什么大部分NoSQL不提供分布式事務(wù)？
那么NewSQL數(shù)據(jù)庫突破CAP定理限制了嗎？并沒有。NewSQL數(shù)據(jù)庫的鼻主Google Spanner（目前絕大部分分布式數(shù)據(jù)庫都是按照Spanner架構(gòu)設(shè)計的）提供了一致性和大于5個9的可用性，宣稱是一個“實際上是CA”的，其真正的含義是 系統(tǒng)處于 CA 狀態(tài)的概率非常高，由于網(wǎng)絡(luò)分區(qū)導(dǎo)致的服務(wù)停用的概率非常小 ，究其真正原因是其打造私有全球網(wǎng)保證了不會出現(xiàn)網(wǎng)絡(luò)中斷引發(fā)的網(wǎng)絡(luò)分區(qū)，另外就是其高效的運維隊伍,這也是cloud spanner的賣點。詳細(xì)可見CAP提出者Eric Brewer寫的《Spanner, TrueTime 和CAP理論》。
完備性 ：
兩階段提交協(xié)議是否嚴(yán)格支持ACID，各種異常場景是不是都可以覆蓋？
2PC在commit階段發(fā)送異常，其實跟最大努力一階段提交類似也會有部分可見問題，嚴(yán)格講一段時間內(nèi)并不能保證A原子性和C一致性（待故障恢復(fù)后recovery機制可以保證最終的A和C）。完備的分布式事務(wù)支持并不是一件簡單的事情，需要可以應(yīng)對網(wǎng)絡(luò)以及各種硬件包括網(wǎng)卡、磁盤、CPU、內(nèi)存、電源等各類異常，通過嚴(yán)格的測試。之前跟某友商交流，他們甚至說目前已知的NewSQL在分布式事務(wù)支持上都是不完整的，他們都有案例跑不過，圈內(nèi)人士這么篤定，也說明了 分布式事務(wù)的支持完整程度其實是層次不齊的。
但分布式事務(wù)又是這些NewSQL數(shù)據(jù)庫的一個非常重要的底層機制，跨資源的DML、DDL等都依賴其實現(xiàn)，如果這塊的性能、完備性打折扣，上層跨分片SQL執(zhí)行的正確性會受到很大影響。
性能
傳統(tǒng)關(guān)系數(shù)據(jù)庫也支持分布式事務(wù)XA，但為何很少有高并發(fā)場景下用呢？ 因為XA的基礎(chǔ)兩階段提交協(xié)議存在網(wǎng)絡(luò)開銷大，阻塞時間長、死鎖等問題，這也導(dǎo)致了其實際上很少大規(guī)模用在基于傳統(tǒng)關(guān)系數(shù)據(jù)庫的OLTP系統(tǒng)中。
NewSQL數(shù)據(jù)庫的分布式事務(wù)實現(xiàn)也仍然多基于兩階段提交協(xié)議，例如google percolator分布式事務(wù)模型，
采用原子鐘+MVCC+ Snapshot Isolation（SI），這種方式通過TSO(Timestamp Oracle)保證了全局一致性，通過MVCC避免了鎖，另外通過primary lock和secondary lock將提交的一部分轉(zhuǎn)為異步，相比XA確實提高了分布式事務(wù)的性能。
但不管如何優(yōu)化，相比于1PC，2PC多出來的GID獲取、網(wǎng)絡(luò)開銷、prepare日志持久化還是會帶來很大的性能損失，尤其是跨節(jié)點的數(shù)量比較多時會更加顯著，例如在銀行場景做個批量扣款，一個文件可能上W個賬戶，這樣的場景無論怎么做還是吞吐都不會很高。
雖然NewSQL分布式數(shù)據(jù)庫產(chǎn)品都宣傳完備支持分布式事務(wù)，但這并不是說應(yīng)用可以完全不用關(guān)心數(shù)據(jù)拆分，這些數(shù)據(jù)庫的最佳實踐中仍然會寫到，應(yīng)用的大部分場景盡可能避免分布式事務(wù)。
既然強一致事務(wù)付出的性能代價太大，我們可以反思下是否真的需要這種強一致的分布式事務(wù)？尤其是在做微服務(wù)拆分后，很多系統(tǒng)也不太可能放在一個統(tǒng)一的數(shù)據(jù)庫中。嘗試將一致性要求弱化，便是柔性事務(wù)，放棄ACID(Atomicity,Consistency, Isolation, Durability)，轉(zhuǎn)投BASE(Basically Available,Soft state,Eventually consistent)，例如Saga、TCC、可靠消息保證最終一致等模型，對于大規(guī)模高并發(fā)OLTP場景，我個人更建議使用柔性事務(wù)而非強一致的分布式事務(wù)。關(guān)于柔性事務(wù)，筆者之前也寫過一個技術(shù)組件，最近幾年也涌現(xiàn)出了一些新的模型與框架（例如阿里剛開源的Fescar），限于篇幅不再贅述，有空再單獨寫篇文章。
HA與異地多活
主從模式并不是最優(yōu)的方式，就算是半同步復(fù)制，在極端情況下（半同步轉(zhuǎn)異步）也存在丟數(shù)問題，目前業(yè)界公認(rèn)更好的方案是基于paxos分布式一致性協(xié)議或者其它類paxos如raft方式，Google Spanner、TiDB、cockcoachDB、OB都采用了這種方式，基于Paxos協(xié)議的多副本存儲，遵循過半寫原則，支持自動選主，解決了數(shù)據(jù)的高可靠，縮短了failover時間，提高了可用性，特別是減少了運維的工作量，這種方案技術(shù)上已經(jīng)很成熟，也是NewSQL數(shù)據(jù)庫底層的標(biāo)配。
當(dāng)然這種方式其實也可以用在傳統(tǒng)關(guān)系數(shù)據(jù)庫，阿里、微信團(tuán)隊等也有將MySQL存儲改造支持paxos多副本的，MySQL也推出了官方版MySQL Group Cluster，預(yù)計不遠(yuǎn)的未來主從模式可能就成為 歷史 了。
需要注意的是很多NewSQL數(shù)據(jù)庫廠商宣傳基于paxos或raft協(xié)議可以實現(xiàn)【異地多活】，這個實際上是有前提的，那就是異地之間網(wǎng)絡(luò)延遲不能太高 。以銀行“兩地三中心”為例，異地之間多相隔數(shù)千里，延時達(dá)到數(shù)十毫秒，如果要多活，那便需異地副本也參與數(shù)據(jù)庫日志過半確認(rèn)，這樣高的延時幾乎沒有OLTP系統(tǒng)可以接受的。
數(shù)據(jù)庫層面做異地多活是個美好的愿景，但距離導(dǎo)致的延時目前并沒有好的方案。 之前跟螞蟻團(tuán)隊交流，螞蟻異地多活的方案是在應(yīng)用層通過MQ同步雙寫交易信息，異地DC將交易信息保存在分布式緩存中，一旦發(fā)生異地切換，數(shù)據(jù)庫同步中間件會告之?dāng)?shù)據(jù)延遲時間，應(yīng)用從緩存中讀取交易信息，將這段時間內(nèi)涉及到的業(yè)務(wù)對象例如用戶、賬戶進(jìn)行黑名單管理，等數(shù)據(jù)同步追上之后再將這些業(yè)務(wù)對象從黑名單中剔除。由于雙寫的不是所有數(shù)據(jù)庫操作日志而只是交易信息，數(shù)據(jù)延遲只影響一段時間內(nèi)數(shù)據(jù)，這是目前我覺得比較靠譜的異地度多活方案。
另外有些系統(tǒng)進(jìn)行了單元化改造，這在paxos選主時也要結(jié)合考慮進(jìn)去，這也是目前很多NewSQL數(shù)據(jù)庫欠缺的功能。
Scale橫向擴(kuò)展與分片機制
paxos算法解決了高可用、高可靠問題，并沒有解決Scale橫向擴(kuò)展的問題，所以分片是必須支持的。NewSQL數(shù)據(jù)庫都是天生內(nèi)置分片機制的，而且會根據(jù)每個分片的數(shù)據(jù)負(fù)載(磁盤使用率、寫入速度等)自動識別熱點，然后進(jìn)行分片的分裂、數(shù)據(jù)遷移、合并，這些過程應(yīng)用是無感知的，這省去了DBA的很多運維工作量。以TiDB為例，它將數(shù)據(jù)切成region，如果region到64M時，數(shù)據(jù)自動進(jìn)行遷移。
分庫分表模式下需要應(yīng)用設(shè)計之初就要明確各表的拆分鍵、拆分方式（range、取模、一致性哈?；蛘咦远x路由表）、路由規(guī)則、拆分庫表數(shù)量、擴(kuò)容方式等。相比NewSQL數(shù)據(jù)庫，這種模式給應(yīng)用帶來了很大侵入和復(fù)雜度，這對大多數(shù)系統(tǒng)來說也是一大挑戰(zhàn)。
這里有個問題是NewSQL數(shù)據(jù)庫統(tǒng)一的內(nèi)置分片策略（例如tidb基于range）可能并不是最高效的，因為與領(lǐng)域模型中的劃分要素并不一致，這導(dǎo)致的后果是很多交易會產(chǎn)生分布式事務(wù)。 舉個例子，銀行核心業(yè)務(wù)系統(tǒng)是以客戶為維度，也就是說客戶表、該客戶的賬戶表、流水表在絕大部分場景下是一起寫的，但如果按照各表主鍵range進(jìn)行分片，這個交易并不能在一個分片上完成，這在高頻OLTP系統(tǒng)中會帶來性能問題。
分布式SQL支持
常見的單分片SQL，這兩者都能很好支持。NewSQL數(shù)據(jù)庫由于定位與目標(biāo)是一個通用的數(shù)據(jù)庫，所以支持的SQL會更完整，包括跨分片的join、聚合等復(fù)雜SQL。中間件模式多面向應(yīng)用需求設(shè)計，不過大部分也支持帶拆分鍵SQL、庫表遍歷、單庫join、聚合、排序、分頁等。但對跨庫的join以及聚合支持就不夠了。
NewSQL數(shù)據(jù)庫一般并不支持存儲過程、視圖、外鍵等功能，而中間件模式底層就是傳統(tǒng)關(guān)系數(shù)據(jù)庫，這些功能如果只是涉及單庫是比較容易支持的。
NewSQL數(shù)據(jù)庫往往選擇兼容MySQL或者PostgreSQL協(xié)議，所以SQL支持僅局限于這兩種，中間件例如驅(qū)動模式往往只需做簡單的SQL解析、計算路由、SQL重寫，所以可以支持更多種類的數(shù)據(jù)庫SQL。
SQL支持的差異主要在于分布式SQL執(zhí)行計劃生成器，由于NewSQL數(shù)據(jù)庫具有底層數(shù)據(jù)的分布、統(tǒng)計信息，因此可以做CBO，生成的執(zhí)行計劃效率更高，而中間件模式下沒有這些信息，往往只能基于規(guī)則RBO（Rule-Based-Opimization），這也是為什么中間件模式一般并不支持跨庫join，因為實現(xiàn)了效率也往往并不高，還不如交給應(yīng)用去做。
存儲引擎
傳統(tǒng)關(guān)系數(shù)據(jù)庫的存儲引擎設(shè)計都是面向磁盤的，大多都基于B+樹。B+樹通過降低樹的高度減少隨機讀、進(jìn)而減少磁盤尋道次數(shù)，提高讀的性能，但大量的隨機寫會導(dǎo)致樹的分裂，從而帶來隨機寫，導(dǎo)致寫性能下降。NewSQL的底層存儲引擎則多采用LSM，相比B+樹LSM將對磁盤的隨機寫變成順序?qū)?，大大提高了寫的性能。不過LSM的的讀由于需要合并數(shù)據(jù)性能比B+樹差，一般來說LSM更適合應(yīng)在寫大于讀的場景。當(dāng)然這只是單純數(shù)據(jù)結(jié)構(gòu)角度的對比，在數(shù)據(jù)庫實際實現(xiàn)時還會通過SSD、緩沖、bloom filter等方式優(yōu)化讀寫性能，所以讀性能基本不會下降太多。NewSQL數(shù)據(jù)由于多副本、分布式事務(wù)等開銷，相比單機關(guān)系數(shù)據(jù)庫SQL的響應(yīng)時間并不占優(yōu)，但由于集群的彈性擴(kuò)展，整體QPS提升還是很明顯的，這也是NewSQL數(shù)據(jù)庫廠商說分布式數(shù)據(jù)庫更看重的是吞吐，而不是單筆SQL響應(yīng)時間的原因。
成熟度與生態(tài)
分布式數(shù)據(jù)庫是個新型通用底層軟件，準(zhǔn)確的衡量與評價需要一個多維度的測試模型，需包括發(fā)展現(xiàn)狀、使用情況、社區(qū)生態(tài)、監(jiān)控運維、周邊配套工具、功能滿足度、DBA人才、SQL兼容性、性能測試、高可用測試、在線擴(kuò)容、分布式事務(wù)、隔離級別、在線DDL等等，雖然NewSQL數(shù)據(jù)庫發(fā)展經(jīng)過了一定時間檢驗，但多集中在互聯(lián)網(wǎng)以及傳統(tǒng)企業(yè)非核心交易系統(tǒng)中，目前還處于快速迭代、規(guī)模使用不斷優(yōu)化完善的階段。
相比而言，傳統(tǒng)關(guān)系數(shù)據(jù)庫則經(jīng)過了多年的發(fā)展，通過完整的評測，在成熟度、功能、性能、周邊生態(tài)、風(fēng)險把控、相關(guān)人才積累等多方面都具有明顯優(yōu)勢，同時對已建系統(tǒng)的兼容性也更好。
對于互聯(lián)網(wǎng)公司，數(shù)據(jù)量的增長壓力以及追求新技術(shù)的基因會更傾向于嘗試NewSQL數(shù)據(jù)庫，不用再考慮庫表拆分、應(yīng)用改造、擴(kuò)容、事務(wù)一致性等問題怎么看都是非常吸引人的方案。
對于傳統(tǒng)企業(yè)例如銀行這種風(fēng)險意識較高的行業(yè)來說，NewSQL數(shù)據(jù)庫則可能在未來一段時間內(nèi)仍處于 探索 、審慎試點的階段?；谥虚g件+分庫分表模式架構(gòu)簡單，技術(shù)門檻更低，雖然沒有NewSQL數(shù)據(jù)庫功能全面，但大部分場景最核心的訴求也就是拆分后SQL的正確路由，而此功能中間件模式應(yīng)對還是綽綽有余的，可以說在大多數(shù)OLTP場景是夠用的。
限于篇幅，其它特性例如在線DDL、數(shù)據(jù)遷移、運維工具等特性就不在本文展開對比。
總結(jié)
如果看完以上內(nèi)容，您還不知道選哪種模式，那么結(jié)合以下幾個問題，先思考下NewSQL數(shù)據(jù)庫解決的點對于自身是不是真正的痛點：
如果以上有2到3個是肯定的，那么你可以考慮用NewSQL數(shù)據(jù)庫了，雖然前期可能需要一定的學(xué)習(xí)成本，但它是數(shù)據(jù)庫的發(fā)展方向，未來收益也會更高，尤其是互聯(lián)網(wǎng)行業(yè)，隨著數(shù)據(jù)量的突飛猛進(jìn)，分庫分表帶來的痛苦會與日俱增。當(dāng)然選擇NewSQL數(shù)據(jù)庫你也要做好承擔(dān)一定風(fēng)險的準(zhǔn)備。
如果你還未做出抉擇，不妨再想想下面幾個問題：
如果這些問題有多數(shù)是肯定的，那還是分庫分表吧。在軟件領(lǐng)域很少有完美的解決方案，NewSQL數(shù)據(jù)庫也不是數(shù)據(jù)分布式架構(gòu)的銀彈。相比而言分庫分表是一個代價更低、風(fēng)險更小的方案，它最大程度復(fù)用傳統(tǒng)關(guān)系數(shù)據(jù)庫生態(tài)，通過中間件也可以滿足分庫分表后的絕大多數(shù)功能，定制化能力更強。 在當(dāng)前NewSQL數(shù)據(jù)庫還未完全成熟的階段，分庫分表可以說是一個上限低但下限高的方案，尤其傳統(tǒng)行業(yè)的核心系統(tǒng)，如果你仍然打算把數(shù)據(jù)庫當(dāng)做一個黑盒產(chǎn)品來用，踏踏實實用好分庫分表會被認(rèn)為是個穩(wěn)妥的選擇。
很多時候軟件選型取決于領(lǐng)域特征以及架構(gòu)師風(fēng)格，限于筆者知識與所屬行業(yè)特點所限，以上僅為個人粗淺的一些觀點，歡迎討論。
根據(jù)本講要獲得一個好的數(shù)據(jù)庫需要什么
要獲得一個好的數(shù)據(jù)庫需要資源齊全，界面簡便易用，設(shè)計美觀大方。
傳統(tǒng)的數(shù)據(jù)庫方案并不具備強大的彈性伸縮能力，比如說常見的Oracle，MySQL，PostgreSQL等數(shù)據(jù)庫，在面對數(shù)據(jù)量的爆發(fā)性的增長時，往往很容易遇到存儲的瓶頸。
因此，不得不選用一些集群方案，如 Oracle RAC、 MySQL Sharding等，但這些解決方案同云計算的彈性伸縮能力想比，還是會有不小的差距。云時代用戶需要的是可以隨需應(yīng)變，彈性支撐各種業(yè)務(wù)的數(shù)據(jù)庫系統(tǒng)。
企業(yè)的數(shù)據(jù)庫注意
在云時代，因為所有的數(shù)據(jù)庫資源都是分布式存儲的，每個數(shù)據(jù)庫節(jié)點出現(xiàn)問題都是很正常的事情，所以就必須有一種可以實現(xiàn)數(shù)據(jù)一致性的數(shù)據(jù)復(fù)制方式來保證服務(wù)的高可用。
云數(shù)據(jù)庫雖然可以做到彈性擴(kuò)容，但當(dāng)并發(fā)大到一定規(guī)模，云數(shù)據(jù)庫需要在很高的并發(fā)下，依然可以維持系統(tǒng)的穩(wěn)定。因此，云時代的數(shù)據(jù)庫必須有合理的架構(gòu)設(shè)計，才能更好的支持系統(tǒng)的需求。
天翼云TeleDB數(shù)據(jù)庫全面亮劍
數(shù)字時代下，數(shù)據(jù)規(guī)模爆發(fā)性增長，數(shù)據(jù)存儲結(jié)構(gòu)越來越靈活多樣，推動著數(shù)據(jù)庫技術(shù)不斷演進(jìn)，我國數(shù)據(jù)庫產(chǎn)業(yè)進(jìn)入重要發(fā)展機遇期。 天翼云積極順應(yīng)時代趨勢，創(chuàng)新推出 TeleDB 產(chǎn)品， 為企業(yè)提供全方位數(shù)字化轉(zhuǎn)型解決方案，助力企業(yè)上云用數(shù)賦智。
TeleDB 是天翼云在數(shù)據(jù)庫領(lǐng)域豐富實踐經(jīng)驗和先進(jìn)技術(shù)架構(gòu)的有機結(jié)合， 由天翼云自主研發(fā)，具有兼容社區(qū)生態(tài)、全面國產(chǎn)化適配等核心能力。
歷經(jīng)8年打磨， 目前 TeleDB 已研發(fā)核心PaaS技術(shù)20余項，獲得核心專利技術(shù)16項，承載7億+用戶， 穩(wěn)定性得到全面驗證。
TeleDB 數(shù)據(jù)庫采用容器化技術(shù)和分布式塊存儲技術(shù)，通過云原生技術(shù)改造業(yè)務(wù)，使得數(shù)據(jù)庫服務(wù)器的CPU、內(nèi)存能夠快速擴(kuò)容，通過動態(tài)增減節(jié)點提升性能和節(jié)省成本，存儲空間無需手動配置，實現(xiàn)自動彈性伸縮。
面對多元化的業(yè)務(wù)需求，企業(yè)需要服務(wù)提供商能夠提供橫向主流數(shù)據(jù)庫產(chǎn)品和縱向多版本技術(shù)服務(wù)的全覆蓋能力，為此，天翼云還構(gòu)建了 TeleDB 數(shù)據(jù)庫上云全生態(tài)。
在數(shù)據(jù)庫內(nèi)核方面， TeleDB 采用云原生架構(gòu)，高度兼容MySQL、PostgreSQL、openGauss、TiDB， 尋求社區(qū)深度合作，在強化自身能力的同時反哺社區(qū)，提升代碼自主可控能力及數(shù)據(jù)庫團(tuán)隊的社區(qū)影響力。
TeleDB 是一款兼容開源MySQL協(xié)議的企業(yè)級智能化關(guān)系型數(shù)據(jù)庫引擎，適用于在線事務(wù)處理，可為用戶提供穩(wěn)定可靠的企業(yè)級數(shù)據(jù)庫服務(wù)；
TeleDB 兼容開源PostgreSQL協(xié)議，支持SQL規(guī)范的完整實現(xiàn)、豐富多樣的數(shù)據(jù)庫類型，并高度兼容Oracle語法，集成了一系列管理功能，減輕運維壓力；
TeleDB 支持在線事務(wù)處理（TP）和在線分析處理（AP），是一款高性能 HTAP 融合型NewSQL數(shù)據(jù)庫引擎，適用于數(shù)據(jù)規(guī)模大、高可用、高吞吐等業(yè)務(wù)場景。
在建設(shè)層面，TeleDB 聚焦掌握數(shù)據(jù)備份、數(shù)據(jù)遷移、數(shù)據(jù)庫自動駕駛倉、數(shù)據(jù)庫安全網(wǎng)關(guān)等核心生態(tài)產(chǎn)品。 支持HBase、文檔數(shù)據(jù)庫、時序數(shù)據(jù)庫等NoSQL數(shù)據(jù)庫協(xié)議，提供實時分析云服務(wù)，適合PB級，千萬級QPS的分布式計算應(yīng)用場景， 是風(fēng)控、推薦、廣告、物聯(lián)網(wǎng)、車聯(lián)網(wǎng)、Feeds流、數(shù)據(jù)大屏等場景的首選數(shù)據(jù)庫。
此外，TeleDB 借助外部生態(tài)體系夯實完善交付、實施、運營、維護(hù)等過程， 可以實現(xiàn)端到端軟硬件深度的整合和優(yōu)化，提升數(shù)據(jù)存儲效率和訪問效率，進(jìn)一步發(fā)揮網(wǎng)絡(luò)和新介質(zhì)能力，構(gòu)建一站式強體驗生態(tài)體系。
TeleDB 數(shù)據(jù)庫作為中國電信天翼云自主研發(fā)的產(chǎn)品，實現(xiàn)數(shù)據(jù)庫基礎(chǔ)軟件全面自主可控?；?TeleDB 數(shù)據(jù)庫，解決核心基礎(chǔ)軟件卡脖子問題，賦能千行百業(yè)，滿足其多元化的上云需求。未來，天翼云將堅持以創(chuàng)新、高效為目標(biāo)，為用戶提供更安全、更可靠、更智能的云數(shù)據(jù)庫產(chǎn)品和服務(wù)，讓 TeleDB 成為企業(yè)乘云而上的助燃劑。
大數(shù)據(jù)常用哪些數(shù)據(jù)庫
通常數(shù)據(jù)庫分為關(guān)系型數(shù)據(jù)庫和非關(guān)系型數(shù)據(jù)庫，關(guān)系型數(shù)據(jù)庫的優(yōu)勢到現(xiàn)在也是無可替代的，比如MySQL、SQL Server、Oracle、DB2、SyBase、Informix、PostgreSQL以及比較小型的Access等等數(shù)據(jù)庫，這些數(shù)據(jù)庫支持復(fù)雜的SQL操作和事務(wù)機制，適合小量數(shù)據(jù)讀寫場景；但是到了大數(shù)據(jù)時代，人們更多的數(shù)據(jù)和物聯(lián)網(wǎng)加入的數(shù)據(jù)已經(jīng)超出了關(guān)系數(shù)據(jù)庫的承載范圍。
大數(shù)據(jù)時代初期，隨著數(shù)據(jù)請求并發(fā)量大不斷增大，一般都是采用的集群同步數(shù)據(jù)的方式處理，就是將數(shù)據(jù)庫分成了很多的小庫，每個數(shù)據(jù)庫的數(shù)據(jù)內(nèi)容是不變的，都是保存了源數(shù)據(jù)庫的數(shù)據(jù)副本，通過同步或者異步方式保證數(shù)據(jù)的一致性，每個庫設(shè)定特定的讀寫方式，比如主數(shù)據(jù)庫負(fù)責(zé)寫操作，從數(shù)據(jù)庫是負(fù)責(zé)讀操作，等等根據(jù)業(yè)務(wù)復(fù)雜程度以此類推，將業(yè)務(wù)在物理層面上進(jìn)行了分離，但是這種方式依舊存在一定的負(fù)載壓力的問題，企業(yè)數(shù)據(jù)在不斷的擴(kuò)增中，后面就采用分庫分表的方式解決，對讀寫負(fù)載進(jìn)行分離，但是這種實現(xiàn)依舊存在不足，且需要不斷進(jìn)行數(shù)據(jù)庫服務(wù)器擴(kuò)容。
NoSQL數(shù)據(jù)庫大致分為5種類型
1、列族數(shù)據(jù)庫：BigTable、HBase、Cassandra、Amazon SimpleDB、HadoopDB等，下面簡單介紹幾個
（1）Cassandra：Cassandra是一個列存儲數(shù)據(jù)庫，支持跨數(shù)據(jù)中心的數(shù)據(jù)復(fù)制。它的數(shù)據(jù)模型提供列索引，log-structured修改，支持反規(guī)范化，實體化視圖和嵌入超高速緩存。
（2）HBase：Apache Hbase源于Google的Bigtable，是一個開源、分布式、面向列存儲的模型。在Hadoop和HDFS之上提供了像Bigtable一樣的功能。
（3）Amazon SimpleDB：Amazon SimpleDB是一個非關(guān)系型數(shù)據(jù)存儲，它卸下數(shù)據(jù)庫管理的工作。開發(fā)者使用Web服務(wù)請求存儲和查詢數(shù)據(jù)項
（4）Apache Accumulo：Apache Accumulo的有序的、分布式鍵值數(shù)據(jù)存儲，基于Google的BigTable設(shè)計，建立在Apache Hadoop、Zookeeper和Thrift技術(shù)之上。
（5）Hypertable：Hypertable是一個開源、可擴(kuò)展的數(shù)據(jù)庫，模仿Bigtable，支持分片。
（6）Azure Tables：Windows Azure Table Storage Service為要求大量非結(jié)構(gòu)化數(shù)據(jù)存儲的應(yīng)用提供NoSQL性能。表能夠自動擴(kuò)展到TB級別，能通過REST和Managed API訪問。
2、鍵值數(shù)據(jù)庫：Redis、SimpleDB、Scalaris、Memcached等，下面簡單介紹幾個
（1）Riak：Riak是一個開源，分布式鍵值數(shù)據(jù)庫，支持?jǐn)?shù)據(jù)復(fù)制和容錯。（2）Redis：Redis是一個開源的鍵值存儲。支持主從式復(fù)制、事務(wù)，Pub/Sub、Lua腳本，還支持給Key添加時限。
（3）Dynamo：Dynamo是一個鍵值分布式數(shù)據(jù)存儲。它直接由亞馬遜Dynamo數(shù)據(jù)庫實現(xiàn)；在亞馬遜S3產(chǎn)品中使用。
（4）Oracle NoSQL Database：來自O(shè)racle的鍵值NoSQL數(shù)據(jù)庫。它支持事務(wù)ACID（原子性、一致性、持久性和獨立性）和JSON。
（5）Oracle NoSQL Database：具備數(shù)據(jù)備份和分布式鍵值存儲系統(tǒng)。
（6）Voldemort：具備數(shù)據(jù)備份和分布式鍵值存儲系統(tǒng)。
（7）Aerospike：Aerospike數(shù)據(jù)庫是一個鍵值存儲，支持混合內(nèi)存架構(gòu)，通過強一致性和可調(diào)一致性保證數(shù)據(jù)的完整性。
3、文檔數(shù)據(jù)庫：MongoDB、CouchDB、Perservere、Terrastore、RavenDB等，下面簡單介紹幾個
（1）MongoDB：開源、面向文檔，也是當(dāng)下最人氣的NoSQL數(shù)據(jù)庫。
（2）CounchDB：Apache CounchDB是一個使用JSON的文檔數(shù)據(jù)庫，使用Javascript做MapReduce查詢，以及一個使用HTTP的API。
（3）Couchbase：NoSQL文檔數(shù)據(jù)庫基于JSON模型。
（4）RavenDB：RavenDB是一個基于.NET語言的面向文檔數(shù)據(jù)庫。
（5）MarkLogic：MarkLogic NoSQL數(shù)據(jù)庫用來存儲基于XML和以文檔為中心的信息，支持靈活的模式。
4、圖數(shù)據(jù)庫：Neo4J、InfoGrid、OrientDB、GraphDB，下面簡單介紹幾個
（1）Neo4j：Neo4j是一個圖數(shù)據(jù)庫；支持ACID事務(wù)（原子性、獨立性、持久性和一致性）。
（2）InfiniteGraph：一個圖數(shù)據(jù)庫用來維持和遍歷對象間的關(guān)系，支持分布式數(shù)據(jù)存儲。
（3）AllegroGraph：AllegroGraph是結(jié)合使用了內(nèi)存和磁盤，提供了高可擴(kuò)展性，支持SPARQ、RDFS++和Prolog推理。
5、內(nèi)存數(shù)據(jù)網(wǎng)格：Hazelcast、Oracle Coherence、Terracotta BigMemorry、GemFire、Infinispan、GridGain、GigaSpaces，下面簡單介紹幾個
（1）Hazelcast：Hazelcast CE是一個開源數(shù)據(jù)分布平臺，它允許開發(fā)者在數(shù)據(jù)庫集群之上共享和分割數(shù)據(jù)。
（2）Oracle Coherence：Oracle的內(nèi)存數(shù)據(jù)網(wǎng)格解決方案提供了常用數(shù)據(jù)的快速訪問能力，一致性支持事務(wù)處理能力和數(shù)據(jù)的動態(tài)劃分。
（3）Terracotta BigMemory：來自Terracotta的分布式內(nèi)存管理解決方案。這項產(chǎn)品包括一個Ehcache界面、Terracotta管理控制臺和BigMemory-Hadoop連接器。
（4）GemFire：Vmware vFabric GemFire是一個分布式數(shù)據(jù)管理平臺，也是一個分布式的數(shù)據(jù)網(wǎng)格平臺，支持內(nèi)存數(shù)據(jù)管理、復(fù)制、劃分、數(shù)據(jù)識別路由和連續(xù)查詢。
（5）Infinispan：Infinispan是一個基于Java的開源鍵值NoSQL數(shù)據(jù)存儲，和分布式數(shù)據(jù)節(jié)點平臺，支持事務(wù)，peer-to-peer 及client/server 架構(gòu)。
（6）GridGain：分布式、面向?qū)ο蟆⒒趦?nèi)存、SQL+NoSQL鍵值數(shù)據(jù)庫。支持ACID事務(wù)。
（7）GigaSpaces：GigaSpaces內(nèi)存數(shù)據(jù)網(wǎng)格能夠充當(dāng)應(yīng)用的記錄系統(tǒng)，并支持各種各樣的高速緩存場景。
標(biāo)題名稱：postgresql擴(kuò)容的簡單介紹
當(dāng)前路徑：http://www.dlmjj.cn/article/dsccpph.html
