數(shù)據(jù)存儲(chǔ)，其實(shí)說的就是數(shù)據(jù)庫(kù)，也就是在高并發(fā)的業(yè)務(wù)場(chǎng)景下，我們的數(shù)據(jù)庫(kù)如何架構(gòu)設(shè)計(jì)。
知道有哪些數(shù)據(jù)庫(kù)
關(guān)系型數(shù)據(jù)庫(kù)
是建立在關(guān)系模型基礎(chǔ)上的數(shù)據(jù)庫(kù)，其借助于集合代數(shù)等數(shù)學(xué)概念和方法來處理數(shù)據(jù)庫(kù)中的數(shù)據(jù)，幾句簡(jiǎn)單的SQL語句就能快速的實(shí)現(xiàn)小規(guī)模數(shù)據(jù)的讀寫、查詢統(tǒng)計(jì)，對(duì)于程序猿來說真是爽歪歪呀。
- MySQL
目前互聯(lián)網(wǎng)企業(yè)基本都用它來做數(shù)據(jù)存儲(chǔ)。愿意很簡(jiǎn)單，它是免費(fèi)的，輕量級(jí)的，其他關(guān)系型數(shù)據(jù)庫(kù)能做他他一樣能做。用起來爽爽的。并且能基于Mycat的中間件的幫助，一樣完成大規(guī)模數(shù)據(jù)的存儲(chǔ)，滿足高并發(fā)下的數(shù)據(jù)讀寫。關(guān)于MyCat，國(guó)內(nèi)開源的項(xiàng)目，從它的版本更新計(jì)劃，還是有很多讓人值得期待的地方。
- Oracle
應(yīng)該說是最好的關(guān)系數(shù)據(jù)庫(kù)，容量大，數(shù)據(jù)安全。比如金融行業(yè)，實(shí)時(shí)交易系統(tǒng)較多，在對(duì)數(shù)據(jù)的聯(lián)機(jī)事務(wù)處理（OLTP）上也就要求很高。但做大規(guī)模的數(shù)據(jù)存儲(chǔ)，擴(kuò)展性不好且價(jià)格昂貴。
- SQL Server
如果還有人在用SQL Server，說明這個(gè)企業(yè)的信息化水平很Low。SQL Server幾乎沒人在用了。
NoSQL數(shù)據(jù)庫(kù)
也叫是“Not Only Sql”，指的是非關(guān)系型的數(shù)據(jù)庫(kù)。這類數(shù)據(jù)庫(kù)主要有這些特點(diǎn)：非關(guān)系型的、分布式、開源的、水平可擴(kuò)展的。
- memcached-臨時(shí)性鍵值存儲(chǔ)
是一個(gè)自由開源的，高性能，分布式內(nèi)存對(duì)象緩存系統(tǒng)。數(shù)據(jù)全部放在內(nèi)存中，在架構(gòu)設(shè)計(jì)中使用memcached能減少對(duì)磁盤數(shù)據(jù)的讀寫操作。
比如可以提高用戶對(duì)空節(jié)點(diǎn)數(shù)據(jù)查詢的性能，頁面上查不到數(shù)據(jù)，用戶還在狂點(diǎn)，我不可能不停的查邊系統(tǒng)中的每個(gè)節(jié)點(diǎn)。需要對(duì)空節(jié)點(diǎn)數(shù)據(jù)進(jìn)行緩存。
還有一個(gè)就是減少對(duì)數(shù)據(jù)庫(kù)的讀寫，比如對(duì)查詢命中率很高的能否做緩存。對(duì)寫操作能否所隊(duì)列緩存。人家是對(duì)象緩存系統(tǒng)，所以啥對(duì)象都 是可以放的。
- Redis-永久性鍵值存儲(chǔ)
Redis和memcached在功能上發(fā)揮的作用和使用場(chǎng)景基本是一樣的。只是Redis更像是一個(gè)對(duì)象數(shù)據(jù)庫(kù)，它不僅做內(nèi)存對(duì)象緩存，還可以做對(duì)象磁盤緩存。也就是最終的數(shù)據(jù)是被放到了磁盤上的。功能上比memcached要豐富一些，在企業(yè)中Redis用的更多一些。
- MongoDB面向文檔的數(shù)據(jù)庫(kù)
輕量的分布式文件存儲(chǔ)系統(tǒng)，MongoDB的功能很強(qiáng)大，在大規(guī)模數(shù)據(jù)的讀寫方面不亞于HBASE。MongoDB對(duì)數(shù)據(jù)的存儲(chǔ)是透明的�，F(xiàn)在一般企業(yè)通過MongoDB存一下非格式的文件，比如圖片，視頻，各種文件等。MongoDB在數(shù)據(jù)查詢上比HBase方面，但在數(shù)據(jù)分析處理上不及HBase。
- HBase面向列的數(shù)據(jù)庫(kù)
面向列的新型的數(shù)據(jù)存儲(chǔ)方式，這也是HBase在超大規(guī)模數(shù)據(jù)量中能毫秒級(jí)讀寫數(shù)據(jù)的原因。超大的什么級(jí)別呢，“This project’s goal is the hosting of very large tables — billions of rows X millions of columns，billions of rows X millions of columns”一個(gè)表的數(shù)據(jù)能支持的數(shù)據(jù)結(jié)構(gòu)是上億行 乘以 百萬列，這是HBase官方的描述。也就是說你一個(gè)HBase表沒有上億條數(shù)據(jù)，都對(duì)不起使用HBase。牛逼吧。哈哈。之前我們卡弗卡大數(shù)據(jù)課堂的一個(gè)學(xué)生親自測(cè)過，確實(shí)可能達(dá)到上億行 乘以 百萬列的這個(gè)結(jié)構(gòu)。
雖然HBase的維護(hù)成本比較高，但在數(shù)據(jù)分析上妥妥的，因?yàn)樗腔贖DFS的，跟MapReduce、Hive、spark等都能很好的整合，達(dá)到數(shù)據(jù)的計(jì)算分析。
關(guān)系型數(shù)據(jù)庫(kù)特點(diǎn)
- 優(yōu)點(diǎn)：
1.保持?jǐn)?shù)據(jù)的一致性
2.可以進(jìn)行復(fù)雜查詢，操作簡(jiǎn)單。
3.通用并且技術(shù)成熟。
- 缺點(diǎn):
1.數(shù)據(jù)讀寫必須經(jīng)過sql解析，大量數(shù)據(jù)高并發(fā)下讀寫性能不足。
2.對(duì)數(shù)據(jù)做讀寫，或修改數(shù)據(jù)結(jié)構(gòu)時(shí)需要加鎖，影響并發(fā)操作。
3.無法適應(yīng)非結(jié)構(gòu)化存儲(chǔ)。
4.擴(kuò)展困難。
5.昂貴、復(fù)雜。
NoSQL數(shù)據(jù)庫(kù)的特點(diǎn)
- 優(yōu)點(diǎn)：
1.高并發(fā)，大數(shù)據(jù)下讀寫能力較強(qiáng)。
2.基本支持分布式，易于擴(kuò)展，可伸縮。
3.簡(jiǎn)單，弱結(jié)構(gòu)化存儲(chǔ)。
- 缺點(diǎn):
1.不能操作復(fù)雜的查詢。
2.事務(wù)支持較弱。
理解分布式系統(tǒng)的CAP理論
前面我們說了關(guān)系型數(shù)據(jù)庫(kù)和NoSQL數(shù)據(jù)庫(kù)的種類以及他們的特點(diǎn)。如何能很好的在實(shí)際項(xiàng)目中的合理的應(yīng)用，我們應(yīng)該要了解CAP理論。
CAP的含義是Consistency， Availability， Partition-tolerance也就是一致性、可用性以及分區(qū)容錯(cuò)性。
1.Consistency：一致性（C）
2.Availability：可用性（A）
3.Partition tolerance：分區(qū)容錯(cuò)性（P）
- 一致性在多并發(fā)訪問更新過的數(shù)據(jù)時(shí)，提供給用戶的數(shù)據(jù)是否一致。對(duì)于關(guān)系型數(shù)據(jù)庫(kù)，要求更新過的數(shù)據(jù)能被后續(xù)的訪問都能看到，這是強(qiáng)一致性。如果能容忍后續(xù)的部分或者全部訪問不到，則是弱一致性。如果經(jīng)過一段時(shí)間后要求能訪問到更新后的數(shù)據(jù)，則是最終一致性。
- 可用性某一節(jié)點(diǎn)的服務(wù)器掛了，集群整體還能響應(yīng)客戶端的讀寫請(qǐng)求。
- 分區(qū)容錯(cuò)性如果由于節(jié)點(diǎn)通訊的問題不能達(dá)成數(shù)據(jù)一致性，必須在一致性和可用性中做出選擇。
所以說任何分布式系統(tǒng)只可同時(shí)滿足二點(diǎn)，沒法三者兼顧。例如：
- CA應(yīng)用：傳統(tǒng)上的關(guān)系型數(shù)據(jù)庫(kù)(RMDB).
- CP應(yīng)用：基于HDFS的牛叉的HBase分布式數(shù)據(jù)庫(kù)
- AP應(yīng)用：面向文檔的分布式系統(tǒng)的數(shù)據(jù)庫(kù)MongoDB。
那么我們說CAP理論提出就是針對(duì)分布式數(shù)據(jù)庫(kù)環(huán)境的，所以，P這個(gè)屬性是必須具備的。P就是在分布式環(huán)境中，由于網(wǎng)絡(luò)的問題可能導(dǎo)致某個(gè)節(jié)點(diǎn)和其它節(jié)點(diǎn)失去聯(lián)系，節(jié)點(diǎn)之間互相無法知道對(duì)方的狀態(tài)，這在分布式環(huán)境下是非常常見的。所以就形成了P(partition)。那么當(dāng)P發(fā)生時(shí)，你要么考慮A（Availability），失去聯(lián)系的節(jié)點(diǎn)依然可以向系統(tǒng)提供服務(wù)給客戶端，只不過它的數(shù)據(jù)就不能保證是同步的了（失去了C（Consistency）屬性），但至少服務(wù)及時(shí)做了響應(yīng)。要么考慮C，選擇一致性C（Consistency）為了保證數(shù)據(jù)庫(kù)的一致性，我們必須等待失去聯(lián)系的節(jié)點(diǎn)恢復(fù)過來，在這個(gè)過程中，那個(gè)節(jié)點(diǎn)是不允許對(duì)外提供服務(wù)的，這時(shí)候系統(tǒng)處于不可用狀態(tài)(失去了A（Availability）屬性)。
最常見的例子是讀寫分離，某個(gè)節(jié)點(diǎn)負(fù)責(zé)寫入數(shù)據(jù)，然后將數(shù)據(jù)同步到其它節(jié)點(diǎn)，其它節(jié)點(diǎn)提供讀取的服務(wù)，當(dāng)兩個(gè)節(jié)點(diǎn)出現(xiàn)通信問題時(shí)，你就面臨著選擇A（繼續(xù)提供服務(wù)，但是數(shù)據(jù)不保證準(zhǔn)確）或者C（用戶處于等待狀態(tài)，一直等到數(shù)據(jù)同步完成）。
AP和CP該如何取舍呢？ 我覺得可以根據(jù)不同的業(yè)務(wù)場(chǎng)景做不同的處理。CP對(duì)系統(tǒng)的一致性要求較高如ERP系統(tǒng)，OA系統(tǒng)。AP系統(tǒng)可以允許不一致。比如微博系統(tǒng)。
結(jié)論
懂得CAP理論，在實(shí)際業(yè)務(wù)需求中我們能很好的來做數(shù)據(jù)的存儲(chǔ)的架構(gòu)設(shè)計(jì)。
所以，高并發(fā)下的大數(shù)據(jù)讀寫，盡可能的交給NoSQL，HBase或者M(jìn)ongoDB數(shù)據(jù)庫(kù)。雖然他們不能像關(guān)系型數(shù)據(jù)庫(kù)那樣很爽的讓你查詢，但他們確實(shí)彪悍。因?yàn)閷I(yè)就是干這個(gè)的。對(duì)于強(qiáng)事務(wù)的數(shù)據(jù)操作，NoSQL數(shù)據(jù)庫(kù)就不要跟人家搶。當(dāng)然，MySQL不是不好，表數(shù)據(jù)超過500W，就不要像幾十條數(shù)據(jù)那樣的修改、刪除。這時(shí)候應(yīng)該考慮是否需要讀寫分離，從業(yè)務(wù)上是否需要考慮分割哪些數(shù)據(jù)經(jīng)常修改，哪些數(shù)據(jù)會(huì)頻繁被查詢，是否有大量的數(shù)據(jù)寫入，是否有大量隨機(jī)的數(shù)據(jù)讀取。
看似操作差不多，但在高并發(fā)的大數(shù)據(jù)面前，這些都是我們需要慎重考慮的。
轉(zhuǎn)載請(qǐng)注明出處：拓步ERP資訊網(wǎng)http://www.ezxoed.cn/
本文標(biāo)題：架構(gòu)設(shè)計(jì)——高并發(fā)下的數(shù)據(jù)存儲(chǔ)方案
本文網(wǎng)址：http://www.ezxoed.cn/html/consultation/10839320635.html
相關(guān)文章
