目錄

這份目錄與左側章節樹、頁末順序導航共享同一閱讀順序；章內標題直接來自各頁的穩定錨點。選擇任意條目即可進入對應章節或小節。

插圖目錄

全書編號插圖使用穩定圖號和錨點；正文中的“圖 N-N”引用會同時連結到這裡列出的目標。

1. 圖 1-1 — 一個可能的組合使用多個元件的資料系統架構
2. 圖 1-2 — 推特主頁時間線的關係型模式簡單實現
3. 圖 1-3 — 用於分發推特至關注者的資料流水線，2012 年 11 月的負載引數【16】
4. 圖 1-4 — 展示了一個服務 100 次請求響應時間的均值與百分位數
5. 圖 1-5 — 當一個請求需要多個後端請求時，單個後端慢請求就會拖慢整個終端使用者的請求
6. 圖 2-1 — 使用關係型模式來表示領英簡介
7. 圖 2-2 — 一對多關係構建了一個樹結構
8. 圖 2-3 — 公司名不僅是字串，還是一個指向公司實體的連結（LinkedIn 截圖）
9. 圖 2-4 — 使用多對多關係擴充套件簡歷
10. 圖 2-5 — 圖資料結構示例（框代表頂點，箭頭代表邊）
11. 圖 2-6 — 使用示例 2-11 中的 Datalog 規則來確定愛達荷州在北美。
12. 圖 3-1 — 以類 CSV 格式儲存鍵值對的日誌，並使用記憶體雜湊對映進行索引。
13. 圖 3-2 — 鍵值更新日誌（統計貓咪影片的播放次數）的壓縮，只保留每個鍵的最近值
14. 圖 3-3 — 同時執行壓縮和分段合併
15. 圖 3-4 — 合併幾個 SSTable 段，只保留每個鍵的最新值
16. 圖 3-5 — 具有記憶體索引的 SSTable
17. 圖 3-6 — 使用 B 樹索引查詢一個鍵
18. 圖 3-7 — 透過分割頁面來生長 B 樹
19. 圖 3-8 — ETL 至資料倉儲的簡化提綱
20. 圖 3-9 — 用於資料倉儲的星型模式的示例
21. 圖 3-10 — 按列儲存關係型資料，而不是行
22. 圖 3-11 — 壓縮的點陣圖索引儲存佈局
23. 圖 3-12 — 資料立方的兩個維度，透過求和聚合
24. 圖 4-1 — 使用 MessagePack 編碼的記錄（例 4-1）
25. 圖 4-2 — 使用 Thrift 二進位制協議編碼的記錄
26. 圖 4-3 — 使用 Thrift 壓縮協議編碼的記錄
27. 圖 4-4 — 使用 Protobuf 編碼的記錄
28. 圖 4-5 — 使用 Avro 編碼的記錄
29. 圖 4-6 — 一個 Avro Reader 解決讀寫模式的差異
30. 圖 4-7 — 當較舊版本的應用程式更新以前由較新版本的應用程式編寫的資料時，如果不小心，資料可能會丟失。
31. 圖 II-1 — 一個資料庫切分為兩個分割槽，每個分割槽都有兩個副本
32. 圖 5-1 — 基於領導者的（主/從）複製
33. 圖 5-2 — 基於領導者的複製：一個同步從庫和一個非同步從庫
34. 圖 5-3 — 使用者寫入後從舊副本中讀取資料。需要寫後讀 (read-after-write) 的一致性來防止這種異常
35. 圖 5-4 — 使用者首先從新副本讀取，然後從舊副本讀取。時間看上去回退了。為了防止這種異常，我們需要單調的讀取。
36. 圖 5-5 — 如果某些分割槽的複製速度慢於其他分割槽，那麼觀察者可能會在看到問題之前先看到答案。
37. 圖 5-6 — 跨多個資料中心的多主複製
38. 圖 5-7 — 兩個主庫同時更新同一記錄引起的寫入衝突
39. 圖 5-8 — 三種可以在多主複製中使用的拓撲示例。
40. 圖 5-9 — 使用多主複製時，寫入可能會以錯誤的順序到達某些副本。
41. 圖 5-10 — 法定寫入，法定讀取，並在節點中斷後讀修復。
42. 圖 5-11 — 如果 $w + r > n$，讀取 r 個副本，至少有一個副本必然包含了最近的成功寫入。
43. 圖 5-12 — 併發寫入 Dynamo 風格的資料儲存：沒有明確定義的順序。
44. 圖 5-13 — 在同時編輯購物車時捕獲兩個客戶端之間的因果關係。
45. 圖 5-14 — 圖 5-13 中的因果依賴關係圖。
46. 圖 6-1 — 組合使用複製和分割槽：每個節點充當某些分割槽的主庫，其他分割槽充當從庫。
47. 圖 6-2 — 印刷版百科全書按照關鍵字範圍進行分割槽
48. 圖 6-3 — 按雜湊鍵分割槽
49. 圖 6-4 — 基於文件的次級索引進行分割槽
50. 圖 6-5 — 基於關鍵詞對次級索引進行分割槽
51. 圖 6-6 — 將新節點新增到每個節點具有多個分割槽的資料庫叢集。
52. 圖 6-7 — 將請求路由到正確節點的三種不同方式。
53. 圖 6-8 — 使用 ZooKeeper 跟蹤分割槽分配給節點。
54. 圖 7-1 — 兩個客戶之間的競爭狀態同時遞增計數器
55. 圖 7-2 — 違反隔離性：一個事務讀取另一個事務的未被執行的寫入（“髒讀”）。
56. 圖 7-3 — 原子性確保發生錯誤時，事務先前的任何寫入都會被撤消，以避免狀態不一致
57. 圖 7-4 — 沒有髒讀：使用者 2 只有在使用者 1 的事務已經提交後才能看到 x 的新值。
58. 圖 7-5 — 如果存在髒寫，來自不同事務的衝突寫入可能會混淆在一起
59. 圖 7-6 — 讀取偏差：Alice 觀察資料庫處於不一致的狀態
60. 圖 7-7 — 使用多版本物件實現快照隔離
61. 圖 7-8 — 寫入偏差導致應用程式錯誤的示例
62. 圖 7-9 — 互動式事務和儲存過程之間的區別（使用圖 7-8 的示例事務）
63. 圖 7-10 — 檢測事務何時從 MVCC 快照讀取過時的值
64. 圖 7-11 — 在可序列化快照隔離中，檢測一個事務何時修改另一個事務的讀取。
65. 圖 8-1 — 如果傳送請求並沒有得到響應，則無法區分（a）請求是否丟失，（b）遠端節點是否關閉，或（c）響應是否丟失。
66. 圖 8-2 — 如果有多臺機器將網路流量傳送到同一目的地，則其交換機佇列可能會被填滿。在這裡，埠 1,2 和 4 都試圖傳送資料包到埠 3
67. 圖 8-3 — 客戶端 B 的寫入比客戶端 A 的寫入要晚，但是 B 的寫入具有較早的時間戳。
68. 圖 8-4 — 分散式鎖的實現不正確：客戶端 1 認為它仍然具有有效的租約，即使它已經過期，從而破壞了儲存中的檔案
69. 圖 8-5 — 只允許以增加防護令牌的順序進行寫操作，從而保證儲存安全
70. 圖 9-1 — 這個系統是非線性一致的，導致了球迷的困惑
71. 圖 9-2 — 如果讀取請求與寫入請求併發，則可能會返回舊值或新值
72. 圖 9-3 — 任何一個讀取返回新值後，所有後續讀取（在相同或其他客戶端上）也必須返回新值。
73. 圖 9-4 — 將讀取和寫入看起來已經生效的時間點進行視覺化。客戶端 B 的最後一次讀取不是線性一致的
74. 圖 9-5 — Web 伺服器和影象縮放器透過檔案儲存和訊息佇列進行通訊，開啟競爭條件的可能性。
75. 圖 9-6 — 非線性一致的執行，儘管使用了嚴格的法定人數
76. 圖 9-7 — 網路中斷迫使在線性一致性和可用性之間做出選擇。
77. 圖 9-8 — Lamport 時間戳提供了與因果關係一致的全序。
78. 圖 9-9 — 兩階段提交（2PC）的成功執行
79. 圖 9-10 — 參與者投贊成票後，協調者崩潰。資料庫 1 不知道是否提交或中止
80. 圖 10-1 — 具有三個 Mapper 和三個 Reducer 的 MapReduce 任務
81. 圖 10-2 — 使用者行為日誌與使用者檔案的連線
82. 圖 10-3 — 在使用者 ID 上進行的 Reduce 端連線。如果輸入資料集分割槽為多個檔案，則每個分割槽都會被多個 Mapper 並行處理
83. 圖 11-1 — （a）負載平衡：在消費者間共享消費主題；（b）扇出：將每條訊息傳遞給多個消費者。
84. 圖 11-2 — 在處理 m3 時消費者 2 崩潰，因此稍後重傳至消費者 1
85. 圖 11-3 — 生產者透過將訊息追加寫入主題分割槽檔案來傳送訊息，消費者依次讀取這些檔案
86. 圖 11-4 — 在資料庫中 X 首先被設定為 A，然後被設定為 B，而在搜尋索引處，寫入以相反的順序到達
87. 圖 11-5 — 將資料按順序寫入一個資料庫，然後按照相同的順序將這些更改應用到其他系統
88. 圖 11-6 — 應用當前狀態與事件流之間的關係
89. 圖 11-7 — 按處理時間分窗，會因為處理速率的變動引入人為因素
90. 圖 12-1 — 在搜尋索引中，寫（文件更新）遇上讀（查詢）