數(shù)據(jù)存儲，其實說的就是數(shù)據(jù)庫，也就是在高并發(fā)的業(yè)務(wù)場景下，我們的數(shù)據(jù)庫如何架構(gòu)設(shè)計。

知道有哪些數(shù)據(jù)庫

關(guān)系型數(shù)據(jù)庫

是建立在關(guān)系模型基礎(chǔ)上的數(shù)據(jù)庫，其借助于集合代數(shù)等數(shù)學(xué)概念和方法來處理數(shù)據(jù)庫中的數(shù)據(jù)，幾句簡單的SQL語句就能快速的實現(xiàn)小規(guī)模數(shù)據(jù)的讀寫、查詢統(tǒng)計，對于程序猿來說真是爽歪歪呀。

[[211234]]

MySQL

目前互聯(lián)網(wǎng)企業(yè)基本都用它來做數(shù)據(jù)存儲。愿意很簡單，它是免費的，輕量級的，其他關(guān)系型數(shù)據(jù)庫能做他他一樣能做。用起來爽爽的。并且能基于Mycat的中間件的幫助，一樣完成大規(guī)模數(shù)據(jù)的存儲，滿足高并發(fā)下的數(shù)據(jù)讀寫。關(guān)于MyCat，國內(nèi)開源的項目，從它的版本更新計劃，還是有很多讓人值得期待的地方。

Oracle

應(yīng)該說是***的關(guān)系數(shù)據(jù)庫，容量大，數(shù)據(jù)安全。比如金融行業(yè)，實時交易系統(tǒng)較多，在對數(shù)據(jù)的聯(lián)機事務(wù)處理（OLTP）上也就要求很高。但做大規(guī)模的數(shù)據(jù)存儲，擴展性不好且價格昂貴。

SQL Server

如果還有人在用SQL Server，說明這個企業(yè)的信息化水平很Low。SQL Server幾乎沒人在用了。

NoSQL數(shù)據(jù)庫

也叫是“Not Only Sql”，指的是非關(guān)系型的數(shù)據(jù)庫。這類數(shù)據(jù)庫主要有這些特點：非關(guān)系型的、分布式、開源的、水平可擴展的。

memcached-臨時性鍵值存儲

是一個自由開源的，高性能，分布式內(nèi)存對象緩存系統(tǒng)。數(shù)據(jù)全部放在內(nèi)存中，在架構(gòu)設(shè)計中使用memcached能減少對磁盤數(shù)據(jù)的讀寫操作。

比如可以提高用戶對空節(jié)點數(shù)據(jù)查詢的性能，頁面上查不到數(shù)據(jù)，用戶還在狂點，我不可能不停的查邊系統(tǒng)中的每個節(jié)點。需要對空節(jié)點數(shù)據(jù)進行緩存。

還有一個就是減少對數(shù)據(jù)庫的讀寫，比如對查詢***率很高的能否做緩存。對寫操作能否所隊列緩存。人家是對象緩存系統(tǒng)，所以啥對象都 是可以放的。

Redis-***性鍵值存儲

Redis和memcached在功能上發(fā)揮的作用和使用場景基本是一樣的。只是Redis更像是一個對象數(shù)據(jù)庫，它不僅做內(nèi)存對象緩存，還可以做對象磁盤緩存。也就是最終的數(shù)據(jù)是被放到了磁盤上的。功能上比memcached要豐富一些，在企業(yè)中Redis用的更多一些。

MongoDB面向文檔的數(shù)據(jù)庫

輕量的分布式文件存儲系統(tǒng)，MongoDB的功能很強大，在大規(guī)模數(shù)據(jù)的讀寫方面不亞于HBASE。MongoDB對數(shù)據(jù)的存儲是透明的?，F(xiàn)在一般企業(yè)通過MongoDB存一下非格式的文件，比如圖片，視頻，各種文件等。MongoDB在數(shù)據(jù)查詢上比HBase方面，但在數(shù)據(jù)分析處理上不及HBase。

HBase面向列的數(shù)據(jù)庫

面向列的新型的數(shù)據(jù)存儲方式，這也是HBase在超大規(guī)模數(shù)據(jù)量中能毫秒級讀寫數(shù)據(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”一個表的數(shù)據(jù)能支持的數(shù)據(jù)結(jié)構(gòu)是上億行 乘以 百萬列，這是HBase官方的描述。也就是說你一個HBase表沒有上億條數(shù)據(jù)，都對不起使用HBase。牛逼吧。哈哈。之前我們卡弗卡大數(shù)據(jù)課堂的一個學(xué)生親自測過，確實可能達(dá)到上億行 乘以 百萬列的這個結(jié)構(gòu)。

雖然HBase的維護成本比較高，但在數(shù)據(jù)分析上妥妥的，因為他是基于HDFS的，跟MapReduce、Hive、spark等都能很好的整合，達(dá)到數(shù)據(jù)的計算分析。

關(guān)系型數(shù)據(jù)庫特點

優(yōu)點：

1. 保持?jǐn)?shù)據(jù)的一致性
2. 可以進行復(fù)雜查詢，操作簡單。
3. 通用并且技術(shù)成熟。

缺點:

1. 數(shù)據(jù)讀寫必須經(jīng)過sql解析，大量數(shù)據(jù)高并發(fā)下讀寫性能不足。
2. 對數(shù)據(jù)做讀寫，或修改數(shù)據(jù)結(jié)構(gòu)時需要加鎖，影響并發(fā)操作。
3. 無法適應(yīng)非結(jié)構(gòu)化存儲。
4. 擴展困難。
5. 昂貴、復(fù)雜。

NoSQL數(shù)據(jù)庫的特點

優(yōu)點：

1. 高并發(fā)，大數(shù)據(jù)下讀寫能力較強。
2. 基本支持分布式，易于擴展，可伸縮。
3. 簡單，弱結(jié)構(gòu)化存儲。

缺點:

1. 不能操作復(fù)雜的查詢。
2. 事務(wù)支持較弱。

理解分布式系統(tǒng)的CAP理論

前面我們說了關(guān)系型數(shù)據(jù)庫和NoSQL數(shù)據(jù)庫的種類以及他們的特點。如何能很好的在實際項目中的合理的應(yīng)用，我們應(yīng)該要了解CAP理論。

CAP的含義是Consistency, Availability, Partition-tolerance也就是一致性、可用性以及分區(qū)容錯性。

1. Consistency：一致性（C）
2. Availability：可用性（A）
3. Partition tolerance：分區(qū)容錯性（P）

• 一致性在多并發(fā)訪問更新過的數(shù)據(jù)時，提供給用戶的數(shù)據(jù)是否一致。對于關(guān)系型數(shù)據(jù)庫，要求更新過的數(shù)據(jù)能被后續(xù)的訪問都能看到，這是強一致性。如果能容忍后續(xù)的部分或者全部訪問不到，則是弱一致性。如果經(jīng)過一段時間后要求能訪問到更新后的數(shù)據(jù)，則是最終一致性。
• 可用性某一節(jié)點的服務(wù)器掛了，集群整體還能響應(yīng)客戶端的讀寫請求。
• 分區(qū)容錯性如果由于節(jié)點通訊的問題不能達(dá)成數(shù)據(jù)一致性，必須在一致性和可用性中做出選擇。

所以說任何分布式系統(tǒng)只可同時滿足二點，沒法三者兼顧。例如：

• CA應(yīng)用：傳統(tǒng)上的關(guān)系型數(shù)據(jù)庫(RMDB).
• CP應(yīng)用：基于HDFS的牛叉的HBase分布式數(shù)據(jù)庫
• AP應(yīng)用：面向文檔的分布式系統(tǒng)的數(shù)據(jù)庫MongoDB。

那么我們說CAP理論提出就是針對分布式數(shù)據(jù)庫環(huán)境的，所以，P這個屬性是必須具備的。P就是在分布式環(huán)境中，由于網(wǎng)絡(luò)的問題可能導(dǎo)致某個節(jié)點和其它節(jié)點失去聯(lián)系，節(jié)點之間互相無法知道對方的狀態(tài)，這在分布式環(huán)境下是非常常見的。所以就形成了P(partition)。那么當(dāng)P發(fā)生時，你要么考慮A（Availability），失去聯(lián)系的節(jié)點依然可以向系統(tǒng)提供服務(wù)給客戶端，只不過它的數(shù)據(jù)就不能保證是同步的了（失去了C（Consistency）屬性），但至少服務(wù)及時做了響應(yīng)。要么考慮C，選擇一致性C（Consistency）為了保證數(shù)據(jù)庫的一致性，我們必須等待失去聯(lián)系的節(jié)點恢復(fù)過來，在這個過程中，那個節(jié)點是不允許對外提供服務(wù)的，這時候系統(tǒng)處于不可用狀態(tài)(失去了A（Availability）屬性)。

最常見的例子是讀寫分離，某個節(jié)點負(fù)責(zé)寫入數(shù)據(jù)，然后將數(shù)據(jù)同步到其它節(jié)點，其它節(jié)點提供讀取的服務(wù)，當(dāng)兩個節(jié)點出現(xiàn)通信問題時，你就面臨著選擇A（繼續(xù)提供服務(wù)，但是數(shù)據(jù)不保證準(zhǔn)確）或者C（用戶處于等待狀態(tài)，一直等到數(shù)據(jù)同步完成）。

AP和CP該如何取舍呢？ 我覺得可以根據(jù)不同的業(yè)務(wù)場景做不同的處理。CP對系統(tǒng)的一致性要求較高如ERP系統(tǒng)，OA系統(tǒng)。AP系統(tǒng)可以允許不一致。比如微博系統(tǒng)。

結(jié)論

懂得CAP理論，在實際業(yè)務(wù)需求中我們能很好的來做數(shù)據(jù)的存儲的架構(gòu)設(shè)計。

所以，高并發(fā)下的大數(shù)據(jù)讀寫，盡可能的交給NoSQL,HBase或者MongoDB數(shù)據(jù)庫。雖然他們不能像關(guān)系型數(shù)據(jù)庫那樣很爽的讓你查詢，但他們確實彪悍。因為專業(yè)就是干這個的。對于強事務(wù)的數(shù)據(jù)操作，NoSQL數(shù)據(jù)庫就不要跟人家搶。當(dāng)然，MySQL不是不好，表數(shù)據(jù)超過500W，就不要像幾十條數(shù)據(jù)那樣的修改、刪除。這時候應(yīng)該考慮是否需要讀寫分離，從業(yè)務(wù)上是否需要考慮分割哪些數(shù)據(jù)經(jīng)常修改，哪些數(shù)據(jù)會頻繁被查詢，是否有大量的數(shù)據(jù)寫入，是否有大量隨機的數(shù)據(jù)讀取。

看似操作差不多，但在高并發(fā)的大數(shù)據(jù)面前，這些都是我們需要慎重考慮的。