因為個人興趣，想學學分布式方面的知識，然后找到了這本《數據密集型應用系統設計》，確實非常的不錯，無論對于以前的工程還是現在的科研都有啟迪和感悟，所以就寫份讀書筆記記錄一下，里面提到的知識非常之多，有些如需詳細研究需要花大量時間，僅記錄下自己感興趣或者不太熟悉的部分。

目錄

• 第一部分 數據系統基礎
• • 第一章
  • 第二章
  • 第三章
  • • 數據庫索引
    • • 哈希索引
      • LSM-Tree
      • B-tree
    • OLTP與OLAP
    • 列式存儲

---

數據密集型與計算密集型是當今兩大典型的負載類型，前者以大數據為代表，后者以深度學習為代表，其中大數據是開展深度學習的重要前提，本書主要介紹的是數據密集型系統。

第一部分 數據系統基礎

第一章

作者將數據庫、隊列、高速緩存等等用于數據處理的系統均歸為數據系統(data system)，書中主要介紹影響數據系統設計的三大要素：可靠性，可擴展性和可維護性。

可靠性(reliability)：
可靠性意味著及時發生故障，系統也可以正常工作。其中故障包括硬件、軟件以及人為方面。

可擴展性(scalability)：
可擴展性是指負載增加時，有效保持系統性能的相關技術策略。

可維護性(maintainability)：
可維護性是指，讓維護變得更簡單、輕松。可維護性需要特別關注軟件系統的三個設計原則：可運維性，簡單性和可演化性。

第二章

第二章主要討論了三種數據存儲模型以及它們的查詢語言，三種數據模型分別是關系模型，文檔模型以及圖模型。

---

關系模型
現在網絡上大部分用的還是關系型數據庫，在存儲數據時需要定義所有數據的格式，關系（表）只是元組（行）的集合而已，在關系數據庫中，由查詢優化器自動決定以何種順序執行查詢。

文檔模型
文檔數據庫是某種方式的層次模型，即在其父記錄中保存了嵌套記錄，而不是存儲在單獨的表中。如果應用數據具有類似文檔的結構（一對多關系樹），那么使用文檔模型更為合適。

圖模型
圖數據庫更適用于表示多對多關系的數據，例如社交網絡，web圖，公路鐵路網等。圖數據庫有neo4j等。

數據查詢語言
最知名的就是sql了，還有類似于cypher這種用于圖數據庫的查詢語言

---

其實這三種模型都可以相互模擬，例如，關系型也可以表示多對多的關系，不過在進行查詢時處理起來需要寫更多的sql語句，所以不同的系統應用于不同的目的，所使用的數據存儲方案也是不一樣的。

第三章

有兩大類存儲引擎家族，分別是日志結構的存儲引擎和面向頁的存儲引擎（例如B-tree）

數據庫索引

哈希索引

哈希索引通常使用hash map這一結構作為數據存儲結構，數據存儲全部采用追加式文件組成，內存中保存hash map結構，把每個鍵映射到數據文件中特定的字節偏移量，這樣就可以找到每個鍵的值。存儲實例如下表：

鍵字節量偏移

123	0
124	32

寫入記錄：
每次寫入時，直接在文件中追加，不過可能會使文件超出大小，一個好的解決方案是將日志分成一定大小的段，當文件達到一定大小時就關閉，然后將后續寫入到新的段文件中。一定時間可以執行壓縮操作，將重復的鍵進行合并。

段合并操作實例：

數據文件段1

keyvalue

url1	1003
url2	514
url1	1004
url1	1005
url2	515

數據文件段2

keyvalue

url1	1006
url1	1007
url1	1008
url2	515
url1	1009

壓縮合并后的段

keyvalue

url1	1009
url2	515

刪除記錄：
如果要刪除記錄，必須在數據文件中追加一個特殊的刪除記錄。當合并日志段時，一旦發現標記，就會丟棄該值。

并發控制：
只能有一個寫進程，不過可以被多個線程同時讀取

優點：

• 非常適用于每個鍵的值更新頻繁的場景。例如key是某個視頻的url，而值是它的播放次數，每次播放就會增加播放量，對于類似這種工作，有很多的寫操作，但是沒有太多的key。
• 追加和分段合并主要是順序寫，比隨機寫入快得多
• 如果段文件是追加或者不可變的，并發和崩潰恢復要簡單得多

局限性：

• 哈希表必須全部放入內存，如果存在大量的鍵，性能表現不是那么好
• 區間查詢效率不高，例如不能簡單掃描1-100內所有的鍵，只能使用逐個查找的方式

LSM-Tree

在介紹LSM-Tree之前先介紹下SSTable

SSTables(Sorted String Tables)
從名字就可以看出它的特點，sorted，在前面哈希索引的基礎上，要求key-value對的順序按照key排序。

工作流程：

• 寫入時，將數據添加到內存中的平衡樹（例如紅黑樹）中。這個樹也叫內存表
• 當內存表大于某個閾值時，將樹作為SSTable文件寫入磁盤。
• 讀請求：首先在內存表中查找鍵，然后在最新的磁盤段文件中查找，接下去是次新的磁盤段文件，直到找到或為空
• 后臺進程周期性執行合并與壓縮

優點：

• 合并段更加簡單高效，合并的方法類似于歸并排序
• 因為鍵有了順序，不再需要在內存中保存所有鍵的索引。將一個范圍內的多個鍵值對保存到一個塊中并壓縮，然后稀疏內存索引的每個條目指向壓縮塊的開頭。這樣可以節省磁盤空間并減少I/O帶寬占用。
  這種基于合并和壓縮排序文件原理的存儲引擎通常被稱為LSM存儲引擎。（LSM-Tree,Log-Structured Merge-Tree）

B-tree

B-tree是一種數據庫中廣泛使用的索引結構。

B-tree的特點是將數據庫分解為固定大小的塊或者頁，頁是內部讀/寫的最小單元。（之前的數據存儲形式相當于每個節點擁有一個數據，而B-tree中每個節點存儲一個頁面，頁中擁有一定數量的數據）

B-tree的構建方式不在這里詳細介紹，可以查看wiki B-tree

比較
根據經驗，LSM-tree通常對于寫入更快，而B-tree被認為對于讀取更快。

---

OLTP與OLAP

OLTP，在線事務處理(online transaction processing)，其基本訪問模式于處理業務交易類似，應用程序通常使用索引中的某些鍵查找少量記錄，或根據用戶的輸入插入或更新記錄。例如博客的評論、游戲的動作、通訊錄中的聯系人等等。

OLAP，在線事務分析(online analytic processing)，用于數據分析的數據庫具有不同的訪問模式，分析數據時需要掃描大量數據，每個記錄只讀取其中的幾列，并計算匯總中的統計信息。例如，分析銷售記錄表。

屬性OLTPOLAP

主要讀特征	基于鍵，每次查詢返回少量的記錄	對大量記錄進行匯總
主要寫特征	隨機訪問，低延遲寫入用戶的輸入	批量導入（ETL）或事件流
典型使用場景	終端用戶，通過網絡應用程序	內部分析師，為決策提供支持
數據表征	最新的數據狀態（當前時間點）	隨著時間而變化的所有事件歷史
數據規模	GB到TB	TB到PB

列式存儲

如果字段數量很多，數據量非常大，但每次查詢只訪問4或5個字段用于分析，如何能高效執行這一查詢？

面向列存儲的想法就是：不是將一行中的所有值存放在一起，而是將每列中所有值存儲在一起。每個列存放在一個單獨的文件中，在查詢時只要讀取和解析對應的列即可。

總結

以上是生活随笔為你收集整理的《数据密集型应用系统设计》读书笔记——数据系统基础的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。