數據存儲，其實說的就是數據庫，也就是在高併發的業務場景下，咱們的數據庫如何架構設計。sql 知道有哪些數據庫數據庫 關係型數據庫後端 是創建在關係模型基礎上的數據庫，其藉助於集合代數等數學概念和方法來處理數據庫中的數據，幾句簡單的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等都能很好的整合，達到數據的計算分析。 大數據 關係型數據庫特色 優勢： 保持數據的一致性 能夠進行復雜查詢，操做簡單。 通用而且技術成熟。 缺點: 數據讀寫必須通過sql解析，大量數據高併發下讀寫性能不足。 對數據作讀寫，或修改數據結構時須要加鎖，影響併發操做。 沒法適應非結構化存儲。 擴展困難。 昂貴、複雜。 NoSQL數據庫的特色 優勢： 高併發，大數據下讀寫能力較強。 基本支持分佈式，易於擴展，可伸縮。 簡單，弱結構化存儲。 缺點: 不能操做複雜的查詢。 事務支持較弱。 大數據 理解分佈式系統的CAP理論 前面咱們說了關係型數據庫和NoSQL數據庫的種類以及他們的特色。如何能很好的在實際項目中的合理的應用，咱們應該要了解CAP理論。 CAP的含義是Consistency, Availability, Partition-tolerance也就是一致性、可用性以及分區容錯性。 Consistency：一致性（C） Availability：可用性（A） 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，就不要像幾十條數據那樣的修改、刪除。這時候應該考慮是否須要讀寫分離，從業務上是否須要考慮分割哪些數據常常修改，哪些數據會頻繁被查詢，是否有大量的數據寫入，是否有大量隨機的數據讀取。 看似操做差很少，但在高併發的大數據面前，這些都是咱們須要慎重考慮的。 |
本文分享自微信公衆號 - 互聯網後端架構（fullstack888）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。