一天入門redis-為什麼要學nosql
早年的單機mysql架構
應用層-資料訪問層-資料庫
當前的網際網路時代:3V+3高
Volume+Variety+Veloctiy,高併發+高可擴+高效能
出現瓶頸:索引、資料過大一臺伺服器放不下,讀寫沒有分離,資料庫壓力過大
Memcached的出現
通過mysql的垂直拆分,使用快取技術緩解資料庫壓力,優化資料庫結構和索引。使用Memcached的出現解決檔案快取共享的問題以及大量小檔案快取的問題。
主從讀寫分離
Memcached只能緩解讀壓力,開始使用master-slave模式(也就是主從複製,redis裡面有加強版的哨兵模式)來達到讀寫分離。
資料增長問題
資料增長過程中,出現了分表分庫+水平拆分+mysql Cluster叢集,一定程度上緩解了這種壓力
大文字資料問題
mysql有事會面臨儲存大文字欄位的場景,如果資料出現問題,恢復會非常的慢,而且此時想要更改表結構也會非常困難。
NOSQL的興起
NoSQL(NoSQL = Not Only SQL ),意即“不僅僅是SQL”,泛指非關係型的資料庫。
在超大規模和高併發的SNS型別的web2.0純動態網站發展的情況下,有些資料儲存不需要固定的模式,無需多餘操作就可以橫向擴充套件。
那麼顯而易見,NOSQL的特點就有:
易擴充套件:資料之間無關係,架構層面有有擴充套件可能性
資料量時的高讀寫效能:對比MySQL使用Query Cache,nosql的cache是記錄級的,力度更小,效能更高
無需定義資料模型:增刪欄位更加自由
架構發展歷程
第四代架構解決了效能和海量資料問題(Memcached叢集、KV、CDN,資料切分,分散式儲存)
第五代架構:敏捷、開發、體驗
大型網際網路應用(大資料、高併發、多樣資料型別)的難點和解決方案(阿里):UDSL
傳統RDBMS VS NOSQL
傳統RDBMS
- 高度組織化結構化資料
- 結構化查詢語言(SQL)
- 資料和關係都儲存在單獨的表中。
- 資料操縱語言,資料定義語言
- 嚴格的一致性
- 基礎事務
NoSQL
- 代表著不僅僅是SQL
- 沒有宣告性查詢語言
- 沒有預定義的模式
-鍵 - 值對儲存,列儲存,文件儲存,圖形資料庫 - 最終一致性,而非ACID屬性
- 非結構化和不可預知的資料
- CAP定理
- 高效能,高可用性和可伸縮性
nosql相關介紹
NOSQL的聚合模型以及相對應資料庫
KV鍵值
類似map結構的kv,對應於redis
Bson
json的一種二進位制形式的儲存格式,對應MongoDB
列族
儲存結構化和半結構化資料,方便做資料壓縮,對應HBase
圖形
專注於構建關係圖譜,對應InfoGrid
什麼是cap?
先來看看什麼是傳統的acid
- A (Atomicity) 原子性
- C (Consistency) 一致性
- I (Isolation) 獨立性
- D (Durability) 永續性
下面是CAP
- C:Consistency(強一致性)
- A:Availability(可用性)
- P:Partition tolerance(分割槽容錯性)
CAP三選二
CAP就是說在分散式儲存系統中,最多隻能實現上面的兩點。
當前的網路硬體肯定會出現延遲丟包等問題,分割槽容忍性是我們必須需要實現的。所以我們只能在一致性和可用性之間進行權衡,目前沒有NoSQL系統能同時保證這三點。
- CA 單點叢集,滿足一致性,可用性的系統,通常在可擴充套件性上不太強大。傳統Oracle資料庫
- AP 滿足可用性,分割槽容忍性的系統,通常可能對一致性要求低一些。大多數網站架構的選擇。Redis、Mongodb。
- CP 滿足一致性,分割槽容忍必的系統,通常效能不是特別高。
分散式產品主流方向:犧牲C換取P
原因:
- 很多web對讀一致性的要求很低,有些場合對寫一致性要求並不高
- 對於很多web應用來說,並不要求這麼高的寫讀實時性
- 對複雜的SQL查詢,特別是多表關聯查詢的需求
什麼是BASE
BASE就是為了解決關係資料庫強一致性引起的問題而引起的可用性降低而提出的解決方案。通過讓系統放鬆對某一時刻資料一致性的要求來換取系統整體伸縮性和效能上改觀。
BASE其實是下面三個術語的縮寫:
- 基本可用(Basically Available)
- 軟狀態(Soft state)
- 最終一致(Eventually consistent)
分散式概念
通過rpc、rmi通訊呼叫、不同伺服器上不同的服務對外提供組內組外協作
叢集概念
不同的多臺伺服器上部署相同的服務,通過分散式排程軟體進行統一排程,對提供服務