第九章雲原生資料架構

9.1 關係型資料庫尚能飯否

在大資料、nosql以及newsql等新技術的輪番轟炸後，依然是主流

9.1.1 優勢

開發優勢：sql查詢靈活度非常高，方便的進行聯機事務處理。jdbc完善。orm完善。

orm是為了解決物件導向和關係型資料庫阻抗不匹配的問題的：

（阻抗不匹配：比如乙個opprotunity下面有多個lineitems, 物件導向很好表示這種關係，opp物件下有乙個lineitems的list；但是在關係型資料庫中，就有兩張表，關聯之後才能表示乙個opportunity.）

運維優勢：dba

系統優勢:成熟。acid事務。在程式設計中使用事務並非難事，spring等各類開發框架已經在面向切面層面做的非常好了。

9.1.2 不足

單節點的併發訪問量受到限制：資料越多，索引深度越深。i/o訪問次數多。

單節點資料承載量受限：

分布式事務效能衰減嚴重：將資料庫拆分之後，需要使用分布式事務代替本地事務。

9.2 未達預期的nosql

not only sql,並不是為為了取代關係型資料庫。

9.2.1 鍵值資料庫

代表是redis: 在很多情況下當做快取使用,但同樣提供了落盤（磁碟持久化）。通過主鍵進行查詢的場景，redis效率非常高，但對於內容查詢則無能為力。

redis提供了集群處理能力（3.0之後支援），可以將資料分散到不同的節點，有效解決了單一節點訪問量瓶頸。如果資料量過大，導致redis資料不能全部載入到記憶體，需要落盤，redis效能會下降，因此在資料量大的時，將redis的資料根據主鍵進行分片是不錯的方案。

9.2.2 文件資料庫

代表是mongodb：文件模型與物件導向的資料表示式更加接近，它有自由度極高的schema模型，可以方便地與json資料進行對映。

文件資料資料庫的設計理念與關係型資料庫的設計理念完全不同，它沒有靜態定義的表結構，使用文件資料庫時，可以靈活地在文件中隨意增減屬性，嵌入文件和陣列。文件資料庫設計應用程式是以物件本身為主的，而不是優先考慮資料庫表結構如何定義。

mongodb查詢十分靈活，可以建立索引，提公升效率。

mongodb在分布式的表現上也遠強於關係型資料庫，它可以將資料自動分片，並且能夠透明化分片之間的負載均衡和失效轉移。

從4.0開始，支援acid事務，以前是最終一致性。但是acid還需考察，關鍵業務不能用。

9.2.3 列族資料庫

代表是hadoop, hbase 它是專門用於處理海量資料庫的分布式資料庫。

圖資料庫用於處理圖關係的資料庫，這裡不介紹。

nosql適合於海量資料和高併發的場景，效能強於傳統的關係型資料庫。

nosql有自己的查詢語言，介面標準不統一。無法提供acid事務能力，不能用於核心系統。

nosql是sql的補充而不是代替。　

9.3 冉冉公升起的newsql

9.3.1 新架構

9.3.2 透明化分片中介軟體

9.3.3 雲資料庫

9.4 雲原生資料庫中介軟體的核心功能

9.4.1 資料分片

9.4.2 分布式事務

9.4.3 資料庫治理

第九章 雲原生資料架構