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