設計資料密集型應用（第二版）

• 作者：Martin Kleppmann
• 譯者：馮若航 / Vonng 與 DDIA 中文翻譯貢獻者
• 原作：Designing Data-Intensive Applications, Second Edition

不懂資料庫的全棧工程師不是好架構師。

—— 馮若航 / Vonng

本書從資料模型與儲存引擎出發，逐步進入複製、分片、事務、一致性、批處理與流處理，最後回到技術責任與社會影響。它關注的不是某一款產品，而是設計、實現和評價現代資料系統時可以反覆使用的思維框架。

第二版中文譯文按原書十四章持續校訂。線上版本提供章節樹導航、穩定圖表編號與交叉引用、全文搜尋、順序閱讀、整書列印以及適合工具讀取的 Markdown / llms.txt 輸出。

閱讀本書

• 從序言瞭解全書目標與結構。
• 開啟完整目錄按章、節或圖表定位內容。
• 從第一章開始順序閱讀，並使用每頁末尾的上一章 / 下一章導航。
• 使用頂部版本與語言選單，在第二版、第一版及簡繁中文之間切換。

出版與授權說明

本譯文僅供學習研究參考，不追求任何經濟利益，不得公開傳播發行或用於商業用途。譯者保留譯文署名權，其他權利以原作者與出版社的主張為準。有能力閱讀英文的讀者請購買正版支援作者與出版社。

翻譯校訂與完整貢獻記錄見貢獻者頁面；發現內容或排版問題，可前往 GitHub 提交反饋。

序言

如果近幾年從業於軟體工程，特別是伺服器端和後端系統開發，那麼你很有可能已經被大量關於資料儲存和處理的時髦詞彙轟炸過了： NoSQL！大資料！Web-Scale！分片！最終一致性！ACID！CAP 定理！雲服務！MapReduce！實時！

在最近十年中，我們看到了很多有趣的進展，關於資料庫，分散式系統，以及在此基礎上構建應用程式的方式。這些進展有著各種各樣的驅動力：

• 谷歌、雅虎、亞馬遜、臉書、領英、微軟和推特等網際網路公司正在和巨大的流量 / 資料打交道，這迫使他們去創造能有效應對如此規模的新工具。
• 企業需要變得敏捷，需要低成本地檢驗假設，需要透過縮短開發週期和保持資料模型的靈活性，快速地響應新的市場洞察。
• 免費和開源軟體變得非常成功，在許多環境中比商業軟體和定製軟體更受歡迎。
• 處理器主頻幾乎沒有增長，但是多核處理器已經成為標配，網路也越來越快。這意味著並行化程度只增不減。
• 即使你在一個小團隊中工作，現在也可以構建分佈在多臺計算機甚至多個地理區域的系統，這要歸功於譬如亞馬遜網路服務（AWS）等基礎設施即服務（IaaS）概念的踐行者。
• 許多服務都要求高可用，因停電或維護導致的服務不可用，變得越來越難以接受。

資料密集型應用（data-intensive applications） 正在透過使用這些技術進步來推動可能性的邊界。一個應用被稱為 資料密集型 的，如果 資料是其主要挑戰（資料量，資料複雜度或資料變化速度）—— 與之相對的是 計算密集型，即處理器速度是其瓶頸。

幫助資料密集型應用儲存和處理資料的工具與技術，正迅速地適應這些變化。新型資料庫系統（“NoSQL”）已經備受關注，而訊息佇列，快取，搜尋索引，批處理和流處理框架以及相關技術也非常重要。很多應用組合使用這些工具與技術。

這些生意盎然的時髦詞彙體現出人們對新的可能性的熱情，這是一件好事。但是作為軟體工程師和架構師，如果要開發優秀的應用，我們還需要對各種層出不窮的技術及其利弊權衡有精準的技術理解。為了獲得這種洞察，我們需要深挖時髦詞彙背後的內容。

幸運的是，在技術迅速變化的背後總是存在一些持續成立的原則，無論你使用了特定工具的哪個版本。如果你理解了這些原則，就可以領會這些工具的適用場景，如何充分利用它們，以及如何避免其中的陷阱。這正是本書的初衷。

本書的目標是幫助你在飛速變化的資料處理和資料儲存技術大觀園中找到方向。本書並不是某個特定工具的教程，也不是一本充滿枯燥理論的教科書。相反，我們將看到一些成功資料系統的樣例：許多流行應用每天都要在生產中滿足可伸縮性、效能、以及可靠性的要求，而這些技術構成了這些應用的基礎。

我們將深入這些系統的內部，理清它們的關鍵演算法，討論背後的原則和它們必須做出的權衡。在這個過程中，我們將嘗試尋找 思考 資料系統的有效方式 —— 不僅關於它們 如何 工作，還包括它們 為什麼 以這種方式工作，以及哪些問題是我們需要問的。

閱讀本書後，你能很好地決定哪種技術適合哪種用途，並瞭解如何將工具組合起來，為一個良好應用架構奠定基礎。本書並不足以使你從頭開始構建自己的資料庫儲存引擎，不過幸運的是這基本上很少有必要。你將獲得對系統底層發生事情的敏銳直覺，這樣你就有能力推理它們的行為，做出優秀的設計決策，並追蹤任何可能出現的問題。

本書的目標讀者

如果你開發的應用具有用於儲存或處理資料的某種伺服器 / 後端系統，而且使用網路（例如，Web 應用、移動應用或連線到網際網路的感測器），那麼本書就是為你準備的。

本書是為軟體工程師，軟體架構師，以及喜歡寫程式碼的技術經理準備的。如果你需要對所從事系統的架構做出決策 —— 例如你需要選擇解決某個特定問題的工具，並找出如何最好地使用這些工具，那麼這本書對你尤有價值。但即使你無法選擇你的工具，本書仍將幫助你更好地瞭解所使用工具的長處和短處。

你應當具有一些開發 Web 應用或網路服務的經驗，且應當熟悉關係型資料庫和 SQL。任何你瞭解的非關係型資料庫和其他與資料相關工具都會有所幫助，但不是必需的。對常見網路協議如 TCP 和 HTTP 的大概理解是有幫助的。程式語言或框架的選擇對閱讀本書沒有任何不同影響。

如果以下任意一條對你為真，你會發現這本書很有價值：

• 你想了解如何使資料系統可伸縮，例如，支援擁有數百萬使用者的 Web 或移動應用。
• 你需要提高應用程式的可用性（最大限度地減少停機時間），保持穩定執行。
• 你正在尋找使系統在長期執行過程易於維護的方法，即使系統規模增長，需求與技術也發生變化。
• 你對事物的運作方式有著天然的好奇心，並且希望知道一些主流網站和線上服務背後發生的事情。這本書打破了各種資料庫和資料處理系統的內幕，探索這些系統設計中的智慧是非常有趣的。

有時在討論可伸縮的資料系統時，人們會說：“你又不在谷歌或亞馬遜，別操心可伸縮性了，直接上關係型資料庫”。這個陳述有一定的道理：為了不必要的伸縮性而設計程式，不僅會浪費不必要的精力，並且可能會把你鎖死在一個不靈活的設計中。實際上這是一種 “過早最佳化” 的形式。不過，選擇合適的工具確實很重要，而不同的技術各有優缺點。我們將看到，關聯式資料庫雖然很重要，但絕不是資料處理的終章。

本書涉及的領域

本書並不會嘗試告訴讀者如何安裝或使用特定的軟體包或 API，因為已經有大量文件給出了詳細的使用說明。相反，我們會討論資料系統的基礎 —— 各種原則與利弊權衡，並探討了不同產品所做出的不同設計決策。

在電子書中包含了線上資源全文的連結。所有連結在出版時都進行了驗證，但不幸的是，由於網路的自然規律，連結往往會頻繁地破損。如果你遇到連結斷開的情況，或者正在閱讀本書的列印副本，可以使用搜尋引擎查詢參考文獻。對於學術論文，你可以在 Google 學術中搜尋標題，查詢可以公開獲取的 PDF 檔案。或者，你也可以在 https://github.com/ept/ddia-references 中找到所有的參考資料，我們在那兒維護最新的連結。

我們主要關注的是資料系統的 架構（architecture），以及它們被整合到資料密集型應用中的方式。本書沒有足夠的空間覆蓋部署、運維、安全、管理等領域 —— 這些都是複雜而重要的主題，僅僅在本書中用粗略的註解討論這些對它們很不公平。每個領域都值得用單獨的書去講。

本書中描述的許多技術都被涵蓋在 大資料（Big Data） 這個時髦詞的範疇中。然而 “大資料” 這個術語被濫用，缺乏明確定義，以至於在嚴肅的工程討論中沒有用處。這本書使用歧義更小的術語，如 “單節點” 之於 “分散式系統”，或 “線上 / 互動式系統” 之於 “離線 / 批處理系統”。

本書對 自由和開源軟體（FOSS） 有一定偏好，因為閱讀、修改和執行原始碼是瞭解某事物詳細工作原理的好方法。開放的平臺也可以降低供應商壟斷的風險。然而在適當的情況下，我們也會討論專利軟體（閉源軟體，軟體即服務 SaaS，或一些在文獻中描述過但未公開發行的公司內部軟體）。

本書綱要

本書分為三部分：

1. 在 第一部分 中，我們會討論設計資料密集型應用所賴的基本思想。我們從 第一章 開始，討論我們實際要達到的目標：可靠性、可伸縮性和可維護性；我們該如何思考這些概念；以及如何實現它們。在 第二章 中，我們比較了幾種不同的資料模型和查詢語言，看看它們如何適用於不同的場景。在 第三章 中將討論儲存引擎：資料庫如何在磁碟上擺放資料，以便能高效地再次找到它。第四章 轉向資料編碼（序列化），以及隨時間演化的模式。

2. 在 第二部分 中，我們從討論儲存在一臺機器上的資料轉向討論分佈在多臺機器上的資料。這對於可伸縮性通常是必需的，但帶來了各種獨特的挑戰。我們首先討論複製（第五章）、分割槽 / 分片（第六章）和事務（第七章）。然後我們將探索關於分散式系統問題的更多細節（第八章），以及在分散式系統中實現一致性與共識意味著什麼（第九章）。

3. 在 第三部分 中，我們討論那些從其他資料集派生出一些資料集的系統。派生資料經常出現在異構系統中：當沒有單個資料庫可以把所有事情都做的很好時，應用需要整合幾種不同的資料庫、快取、索引等。在 第十章 中我們將從一種派生資料的批處理方法開始，然後在此基礎上建立在 第十一章 中討論的流處理。最後，在 第十二章 中，我們將所有內容彙總，討論在將來構建可靠、可伸縮和可維護的應用程式的方法。

參考文獻與延伸閱讀

本書中討論的大部分內容已經在其它地方以某種形式出現過了 —— 會議簡報、研究論文、部落格文章、程式碼、BUG 跟蹤器、郵件列表以及工程習慣中。本書總結了不同來源資料中最重要的想法，並在文字中包含了指向原始文獻的連結。如果你想更深入地探索一個領域，那麼每章末尾的參考文獻都是很好的資源，其中大部分可以免費線上獲取。

O‘Reilly Safari

Safari (formerly Safari Books Online) is a membership-based training and reference platform for enterprise, government, educators, and individuals.

Members have access to thousands of books, training videos, Learning Paths, interac‐ tive tutorials, and curated playlists from over 250 publishers, including O’Reilly Media, Harvard Business Review, Prentice Hall Professional, Addison-Wesley Pro‐ fessional, Microsoft Press, Sams, Que, Peachpit Press, Adobe, Focal Press, Cisco Press, John Wiley & Sons, Syngress, Morgan Kaufmann, IBM Redbooks, Packt, Adobe Press, FT Press, Apress, Manning, New Riders, McGraw-Hill, Jones & Bartlett, and Course Technology, among others.

For more information, please visit http://oreilly.com/safari.

聯絡我們

有關本書的評論和問題，請聯絡出版社：

O’Reilly Media, Inc. 1005 Gravenstein Highway North Sebastopol, CA 95472 800-998-9938（美國或加拿大） 707-829-0515（國際或本地） 707-829-0104（傳真）

我們為本書提供了網頁，會在上面列出勘誤、示例以及任何補充資訊。你可以訪問：http://bit.ly/designing-data-intensive-apps。

如需發表評論或提出技術問題，請傳送郵件至：bookquestions@oreilly.com。

有關 O’Reilly 圖書、課程、會議和新聞的更多資訊，請訪問：http://www.oreilly.com。

• Facebook: http://facebook.com/oreilly
• Twitter: http://twitter.com/oreillymedia
• YouTube: http://www.youtube.com/oreillymedia

致謝

本書融合了學術研究和工業實踐的經驗，融合並系統化了大量其他人的想法與知識。在計算領域，我們往往會被各種新鮮花樣所吸引，但我認為前人完成的工作中，有太多值得我們學習的地方了。本書有 800 多處引用：文章、部落格、講座、文件等，對我來說這些都是寶貴的學習資源。我非常感謝這些材料的作者分享他們的知識。

我也從與人交流中學到了很多東西，很多人花費了寶貴的時間與我討論想法並耐心解釋。特別感謝 Joe Adler, Ross Anderson, Peter Bailis, Márton Balassi, Alastair Beresford, Mark Callaghan, Mat Clayton, Patrick Collison, Sean Cribbs, Shirshanka Das, Niklas Ekström, Stephan Ewen, Alan Fekete, Gyula Fóra, Camille Fournier, Andres Freund, John Garbutt, Seth Gilbert, Tom Haggett, Pat Hel‐ land, Joe Hellerstein, Jakob Homan, Heidi Howard, John Hugg, Julian Hyde, Conrad Irwin, Evan Jones, Flavio Junqueira, Jessica Kerr, Kyle Kingsbury, Jay Kreps, Carl Lerche, Nicolas Liochon, Steve Loughran, Lee Mallabone, Nathan Marz, Caitie McCaffrey, Josie McLellan, Christopher Meiklejohn, Ian Meyers, Neha Narkhede, Neha Narula, Cathy O’Neil, Onora O’Neill, Ludovic Orban, Zoran Perkov, Julia Powles, Chris Riccomini, Henry Robinson, David Rosenthal, Jennifer Rullmann, Matthew Sackman, Martin Scholl, Amit Sela, Gwen Shapira, Greg Spurrier, Sam Stokes, Ben Stopford, Tom Stuart, Diana Vasile, Rahul Vohra, Pete Warden, 以及 Brett Wooldridge.

更多人透過審閱草稿並提供反饋意見在本書的創作過程中做出了無價的貢獻。我要特別感謝 Raul Agepati, Tyler Akidau, Mattias Andersson, Sasha Baranov, Veena Basavaraj, David Beyer, Jim Brikman, Paul Carey, Raul Castro Fernandez, Joseph Chow, Derek Elkins, Sam Elliott, Alexander Gallego, Mark Grover, Stu Halloway, Heidi Howard, Nicola Kleppmann, Stefan Kruppa, Bjorn Madsen, Sander Mak, Stefan Podkowinski, Phil Potter, Hamid Ramazani, Sam Stokes, 以及 Ben Summers。當然對於本書中的任何遺留錯誤或難以接受的見解，我都承擔全部責任。

為了幫助這本書落地，並且耐心地處理我緩慢的寫作和不尋常的要求，我要對編輯 Marie Beaugureau，Mike Loukides，Ann Spencer 和 O’Reilly 的所有團隊表示感謝。我要感謝 Rachel Head 幫我找到了合適的術語。我要感謝 Alastair Beresford，Susan Goodhue，Neha Narkhede 和 Kevin Scott，在其他工作事務之外給了我充分地創作時間和自由。

特別感謝 Shabbir Diwan 和 Edie Freedman，他們非常用心地為各章配了地圖。他們提出了不落俗套的靈感，創作了這些地圖，美麗而引人入勝，真是太棒了。

最後我要表達對家人和朋友們的愛，沒有他們，我將無法走完這個將近四年的寫作歷程。你們是最棒的。

I 資料系統基礎

本書前五章介紹了資料系統底層的基礎概念，無論是在單臺機器上執行的單點資料系統，還是分佈在多臺機器上的分散式資料系統都適用。

1. 第一章 將介紹 資料系統架構中的利弊權衡。我們將討論不同型別的資料系統（例如，分析型與事務型），以及它們在雲環境中的執行方式。
2. 第二章 將介紹非功能性需求的定義。可靠性，可伸縮性和可維護性，這些詞彙到底意味著什麼？如何實現這些目標？
3. 第三章 將對幾種不同的 資料模型和查詢語言 進行比較。從程式設計師的角度看，這是資料庫之間最明顯的區別。不同的資料模型適用於不同的應用場景。
4. 第四章 將深入 儲存引擎 內部，研究資料庫如何在磁碟上擺放資料。不同的儲存引擎針對不同的負載進行最佳化，選擇合適的儲存引擎對系統效能有巨大影響。
5. 第五章 將對幾種不同的 資料編碼 進行比較。特別研究了這些格式在應用需求經常變化、模式需要隨時間演變的環境中表現如何。

第二部分 將專門討論在 分散式資料系統 中特有的問題。

1. 資料系統架構中的權衡

• 分析型與事務型系統
• 雲服務與自託管
• 分散式與單節點系統
• 資料系統、法律與社會
• 總結

2. 定義非功能性需求

• 案例研究：社交網路首頁時間線
• 描述效能
• 可靠性與容錯
• 可伸縮性
• 可維護性
• 總結

3. 資料模型與查詢語言

• 關係模型與文件模型
• 圖資料模型
• 事件溯源與 CQRS
• 資料框、矩陣與陣列
• 總結

4. 儲存與檢索

• OLTP 系統的儲存與索引
• 分析型資料儲存
• 多維索引與全文索引
• 總結

5. 編碼與演化

• 編碼資料的格式
• 資料流的模式
• 總結

1 資料系統架構中的權衡

沒有解決方案，只有權衡取捨。[…] 你只能盡力做出最佳權衡，也只能期望如此。

Thomas Sowell，与 Fred Barnes 的訪談（2005 年）

如今，資料是許多應用開發的核心。隨著 Web 應用、移動應用、軟體即服務（SaaS）和雲服務的普及，在共享的伺服器端資料基礎設施中儲存眾多使用者的資料，已經司空見慣。使用者活動、業務交易、裝置和感測器產生的資料都需要儲存下來，以供分析。使用者與應用互動時，既會讀取已儲存的資料，也會產生更多資料。

少量資料可以在單臺機器上儲存和處理，通常比較容易應付。然而，隨著資料量或查詢速率增長，資料就需要分佈到多臺機器上，由此帶來許多挑戰。應用需求變得更加複雜之後，把所有資料放在一個系統裡也不再夠用，往往需要組合多個能力各異的儲存或處理系統。

如果資料管理是開發應用時面臨的主要挑戰之一，我們就稱這種應用為 資料密集型（data-intensive）應用 ¹。計算密集型（compute-intensive）系統的難點在於如何將某項極其龐大的計算並行化；而對資料密集型應用來說，我們通常更關心如何儲存和處理海量資料、如何管理資料變更、如何在故障和併發面前保證一致性，以及如何維持服務的高可用性。

這類應用通常由一些標準構件搭建而成，它們提供各種常用功能。例如，許多應用都需要：

• 儲存資料，以便自己或其他應用日後能夠再次找到（資料庫，database）
• 記住開銷昂貴的操作結果，加快讀取速度（快取，cache）
• 允許使用者按關鍵字搜尋資料，或以各種方式過濾資料（搜尋索引，search index）
• 在事件和資料變更發生後立即處理（流處理，stream processing）
• 定期處理累積的大批次資料（批處理，batch processing）

構建應用時，我們通常會選用幾個軟體系統或服務（例如資料庫和 API），再用應用程式碼把它們拼接起來。如果你的用途恰好是這些資料系統原本就為之設計的，整個過程可能相當容易。

但是，隨著應用要實現的目標越來越高，挑戰也隨之而來。資料庫系統種類繁多，特性各異，適用目的也各不相同——該選擇哪一種？快取有不同的做法，搜尋索引也有多種構建方式，諸如此類——該如何權衡？你必須判斷哪些工具和方法最適合手頭的任務；而當一項工作無法由單個工具獨力完成時，把多個工具組合起來也可能很困難。

本書將幫助你決定採用哪些技術，以及如何組合這些技術。正如你將看到的，並不存在一種從根本上優於其他方案的做法；每種方案都有利有弊。本書會教你提出恰當的問題來評估和比較資料系統，從而找出最能滿足特定應用需求的方案。

我們的旅程從當今組織使用資料的一些典型方式開始。這裡的許多思想源自 企業軟體（enterprise software），也就是大型組織（例如大公司和政府機構）的軟體需求與工程實踐。因為在過去，只有大型組織才擁有如此龐大的資料量，需要複雜的技術方案；只要資料量足夠小，用電子表格儲存就行了！不過近年來，小公司和初創企業管理海量資料、構建資料密集型系統，也已變得十分普遍。

資料系統的一項關鍵挑戰是：不同的人需要用資料做截然不同的事情。在一家公司裡，你和你的團隊有自己的一套優先事項；另一個團隊即使在處理同一份資料，也可能有完全不同的目標。而且，這些目標未必得到明確表達，因而很容易造成誤解，並引發對正確方案的爭論。

為了幫助你瞭解有哪些選擇，本章將比較幾組相對的概念，並探討它們之間的權衡：

• 事務型系統與分析型系統有何區別（“分析型與事務型系統”）；
• 雲服務與自託管系統各有哪些利弊（“雲服務與自託管”）；
• 何時應當從單節點系統轉向分散式系統（“分散式與單節點系統”）；以及
• 如何在業務需求與使用者權利之間取得平衡（“資料系統、法律與社會”）。

此外，本章還會提供閱讀本書其餘部分所需的術語。

分析型與事務型系統

如果你在企業中從事資料系統工作，很可能會遇到幾類與資料打交道的人。第一類是 後端工程師（backend engineer），負責構建處理資料讀取和更新請求的服務。這些服務通常直接面向外部使用者，或透過其他服務間接為外部使用者提供功能（參見“微服務與無伺服器”）；有時也只供組織內其他部門使用。

除了管理後端服務的團隊，通常還有兩類人需要訪問組織的資料：業務分析師（business analyst）根據組織的活動生成報表，幫助管理層做出更好的決策，這就是 商業智慧（BI）；資料科學家（data scientist）則從資料中尋找新的洞見，或者利用資料分析和機器學習/AI 構建面向使用者的產品功能，例如電商網站上“購買了 X 的人也購買了 Y”的推薦、風險評分或垃圾郵件過濾等預測分析，以及搜尋結果排名。

業務分析師和資料科學家使用的工具不同，工作方式也不同，但仍有一些共同之處：兩者都要進行 分析（analytics），也就是檢視使用者和後端服務產生的資料，但通常不會修改這些資料（糾正錯誤或許除外）。他們可能會建立衍生資料集，以某種方式處理原始資料。由此形成了兩類相互分離的系統——本書將始終沿用這種區分：

• 事務型系統（operational system）由建立資料的後端服務和資料基礎設施組成，例如直接為外部使用者提供服務。應用程式碼根據使用者執行的操作，讀取和修改資料庫中的資料。
• 分析型系統（analytical system）服務於業務分析師和資料科學家。它們儲存事務型系統資料的只讀副本，並針對分析所需的資料處理方式進行最佳化。

正如下一節將要說明的，事務型系統與分析型系統往往有充分的理由彼此分離。隨著這兩類系統日趨成熟，又出現了兩個專業角色：資料工程師（data engineer）與 分析工程師（analytics engineer）。資料工程師懂得如何整合事務型系統和分析型系統，並對組織的資料基礎設施承擔更廣泛的責任 ³。分析工程師則對資料進行建模和轉換，使其更便於組織內的業務分析師和資料科學家使用 ⁴。

許多工程師專攻事務型或分析型系統中的一類。不過，本書會同時涵蓋兩者，因為它們都在組織的資料生命週期中扮演重要角色。我們將深入探討為內部和外部使用者提供服務所需的資料基礎設施，幫助你更好地與分界線另一側的同事合作。

事務處理與分析的特徵

在商業資料處理的早期，每次寫入資料庫通常都對應一筆 商業交易：完成一筆銷售、向供應商下訂單、發放員工工資，等等。後來，資料庫的應用擴充套件到不涉及金錢往來的領域，事務（transaction）這個名稱卻沿用下來，用來指構成一個邏輯單元的一組讀寫操作。

儘管資料庫開始處理形形色色的資料——社交媒體帖子、遊戲中的操作、地址簿聯絡人，等等——基本訪問模式仍與處理商業交易相似。事務型系統通常按某個鍵查詢少量記錄（稱為 點查詢，point query），再根據使用者輸入插入、更新或刪除記錄。由於這些應用具有互動性，這種訪問模式稱為 聯機事務處理（OLTP）。

與此同時，資料庫也越來越多地用於分析，而分析的訪問模式與 OLTP 大相徑庭。分析查詢通常會掃描海量記錄，計算計數、總和或平均值等聚合統計量，而不是把一條條記錄返回給使用者。例如，連鎖超市的業務分析師可能想回答下面的問題：

• 我們每家商店在一月份的總收入是多少？
• 在我們最近的促銷期間，我們比平時多賣出了多少香蕉？
• 哪個品牌的嬰兒食品最常與 X 品牌尿布一起購買？

這類查詢產生的報表是商業智慧的重要依據，可以幫助管理層決定下一步行動。為了把這種資料庫使用模式與事務處理區分開來，人們稱之為 聯機分析處理（OLAP）⁵。OLTP 與分析之間的界線並不總是涇渭分明，但表 1-1列出了二者的一些典型特徵。

事務型系統一般不允許使用者自行編寫 SQL 查詢並提交給資料庫執行，否則使用者可能讀取或修改自己無權訪問的資料。使用者也可能寫出執行開銷很高的查詢，影響其他使用者使用資料庫。因此，OLTP 系統主要執行寫在應用程式碼中的一組固定查詢，只在維護或排查故障時偶爾執行一次性自定義查詢。分析資料庫則不同：它通常允許使用者自由手寫任意 SQL 查詢，也可以透過 Tableau、Looker 或 Microsoft Power BI 等資料視覺化或儀表盤工具自動生成查詢。

還有一類系統專為分析型負載（即聚合大量記錄的查詢）而設計，卻嵌入在面向使用者的產品中。這類用途稱為 產品分析（product analytics）或 實時分析（real-time analytics），為此設計的系統包括 Pinot、Druid 和 ClickHouse ⁶。

資料倉儲

起初，同一套資料庫既用於事務處理，也用於分析查詢。事實證明，SQL 在這方面非常靈活，兩類查詢都能勝任。不過到了 20 世紀 80 年代末和 90 年代初，企業開始不再使用 OLTP 系統進行分析，轉而在一個獨立的資料庫系統上執行分析查詢。這個獨立的資料庫稱為 資料倉儲（data warehouse）。

一家大型企業可能擁有幾十乃至上百個聯機事務處理系統：支撐面向客戶的網站，控制實體店的銷售終端（收銀系統），跟蹤倉庫庫存，規劃車輛路線，管理供應商和員工，以及執行許多其他任務。每個系統都很複雜，都需要專門的團隊維護，因此最終大多彼此獨立執行。

通常不宜讓業務分析師和資料科學家直接查詢這些 OLTP 系統，原因有以下幾點：

• 所需資料可能散落在多個事務型系統中，很難透過一條查詢組合這些資料集；這個問題稱為 資料孤島（data silo）。
• 適合 OLTP 的模式和資料佈局不太適合分析（參見“星型與雪花型：分析模式”）。
• 分析查詢的開銷可能很高；在 OLTP 資料庫上執行它們，會影響其他使用者的效能。
• 出於安全或合規方面的考慮，OLTP 系統可能位於一個不允許使用者直接訪問的獨立網路中。

相比之下，資料倉儲 是一個獨立的資料庫，分析師可以盡情查詢，而不會影響 OLTP 系統的執行 ⁷。正如第 4 章將要介紹的，資料倉儲的儲存方式往往與 OLTP 資料庫截然不同，以便針對分析中常見的查詢型別進行最佳化。

資料倉儲儲存著企業各個 OLTP 系統中資料的只讀副本。資料先從 OLTP 資料庫中抽取出來（透過定期轉儲或連續的更新流），再轉換成便於分析的模式並加以清理，最後載入資料倉儲。把資料送入資料倉儲的這一過程稱為 提取—轉換—載入（ETL），如圖 1-1所示。有時也會對調 轉換 與 載入 兩步的順序，即先載入資料，再在資料倉儲內轉換；這便成了 ELT。

有時，ETL 流程的資料來源是外部 SaaS 產品，例如客戶關係管理（CRM）、電子郵件營銷或信用卡處理系統。此時，你無法直接訪問原始資料庫，只能透過軟體供應商的 API 獲取資料。把這些外部系統的資料匯入自己的資料倉儲，就能進行 SaaS API 本身無法支援的分析。針對 SaaS API 的 ETL，通常由 Fivetran、Singer 或 AirByte 等專業資料聯結器服務實現。

有些資料庫系統提供 混合事務/分析處理（HTAP），目標是在單個系統中同時支援 OLTP 和分析，無需透過 ETL 把資料從一個系統送入另一個系統 ^{8 9}。然而，許多 HTAP 系統內部仍由一個 OLTP 系統和一個獨立的分析系統耦合而成，只是共同隱藏在統一介面之後。因此，要理解這類系統的工作原理，二者的區別依然重要。

此外，即使已有 HTAP，由於事務型系統和分析型系統的目標與需求不同，把它們分開依然很常見。特別是，每個事務型系統各自擁有資料庫通常被視為良好實踐（參見“微服務與無伺服器”），這樣可能產生數百個獨立的事務型資料庫；而企業通常只設一個資料倉儲，以便業務分析師在一條查詢中組合多個事務型系統的資料。

因此，HTAP 並不能取代資料倉儲。它適合的是另一類場景：同一個應用既要執行掃描大量資料行的分析查詢，又要低延遲地讀取和更新單條記錄。例如，欺詐檢測就可能具有這樣的工作負載 ¹⁰。

事務型系統與分析型系統的分離，體現了一種更廣泛的趨勢：隨著工作負載要求越來越高，系統也日益專門化，針對特定負載進行最佳化。通用系統應付少量資料綽綽有餘；但規模越大，系統往往越專門化 ¹¹。

從資料倉儲到資料湖

資料倉儲通常採用 關係 資料模型，並透過 SQL 查詢（參見第 3 章），有時還會配合專門的商業智慧軟體。這種模型很適合業務分析師所需的查詢，卻不太適合資料科學家的需求；他們可能需要完成下面的工作：

• 把資料轉換成適合訓練機器學習模型的形式。這通常要把資料庫表中的行列轉換為數值向量或矩陣，其中的數值稱為 特徵（feature）。以儘可能提高訓練後模型效能的方式完成這種轉換，稱為 特徵工程（feature engineering）；它通常需要編寫難以用 SQL 表達的定製程式碼。
• 對文字資料（例如商品評論）應用自然語言處理技術，嘗試從中提取結構化資訊（例如作者表達的情緒，或提到了哪些主題）。同樣，他們也可能要用計算機視覺技術從照片中提取結構化資訊。

儘管人們一直嘗試為 SQL 資料模型加入機器學習運算元 ¹²，也在關係模型的基礎上構建高效的機器學習系統 ¹³，許多資料科學家仍不願在資料倉儲這樣的關聯式資料庫中工作。他們往往更喜歡 pandas、scikit-learn 等 Python 資料分析庫，R 等統計分析語言，以及 Spark 等分散式分析框架 ¹⁴。我們將在“資料框、矩陣與陣列”中進一步討論這些工具。

因此，組織需要以適合資料科學家使用的形式提供資料。解決方案是 資料湖（data lake）：一個集中的資料儲存庫，儲存一切可能對分析有用的資料副本，這些資料透過 ETL 流程從事務型系統取得。資料湖與資料倉儲的區別在於，它只儲存檔案，並不強制規定檔案格式或資料模型。資料湖中的檔案可以是一批資料庫記錄，以 Avro 或 Parquet 等檔案格式編碼（參見第 5 章）；也完全可以是文字、影象、影片、感測器讀數、稀疏矩陣、特徵向量、基因組序列，或任何其他型別的資料 ¹⁵。資料湖不僅更加靈活，而且往往比關係資料儲存更便宜，因為它可以使用物件儲存等廉價通用的檔案儲存（參見“雲原生系統架構”）。

ETL 流程已經泛化為 資料管道（data pipeline）；在某些情況下，資料湖成為事務型系統通往資料倉儲途中的一站。資料湖以事務型系統產生的“原始”形態儲存資料，不把它們轉換成關係資料倉儲的模式。這種做法的好處是，每個資料消費者都可以把原始資料轉換成最適合自己需求的形式。它有一個詼諧的名字——壽司原則（sushi principle）：“原始資料更好”¹⁶。

除了把資料從資料湖載入獨立的資料倉儲，也可以直接針對資料湖中的檔案執行典型的資料倉儲工作負載（SQL 查詢和業務分析），並與資料科學和機器學習工作負載並存。這種架構稱為 資料湖倉（data lakehouse）；它需要在資料湖的檔案儲存之上增加查詢執行引擎和後設資料層（例如模式管理）¹⁷。

Apache Hive、Spark SQL、Presto 和 Trino 都採用了這種方法。

超越資料湖

隨著分析實踐日益成熟，組織也越來越重視分析系統與資料管道的管理和運維，例如 DataOps 宣言就體現了這種趨勢 ¹⁸。其中包括治理、隱私，以及遵守 GDPR、CCPA 等法規的問題；我們將在“資料系統、法律與社會”和“立法與自律”中討論這些問題。

此外，分析資料的提供形式越來越多，不僅包括檔案和關係表，還包括事件流（參見第 12 章）。採用基於檔案的分析時，可以定期（例如每天）重新執行分析，以響應資料的變化；流處理則能讓分析系統快得多，通常在幾秒內便對事件作出響應。具體是否值得采用流處理，要看應用對時效性的要求。例如，它可以用來識別並阻止潛在的欺詐或濫用活動。

有時，分析系統的輸出還會提供給事務型系統，這個過程有時稱為 反向 ETL（reverse ETL）¹⁹。例如，在分析系統中訓練好的機器學習模型可以部署到生產環境，向終端使用者生成“購買了 X 的人也購買了 Y”之類的推薦。分析系統中這類投入實際應用的輸出也稱為 資料產品（data product）²⁰。機器學習模型可以藉助 TFX、Kubeflow 或 MLflow 等專用工具部署到事務型系統。

權威記錄系統與衍生資料

除了區分事務型系統與分析型系統，本書還區分 權威記錄系統（system of record）與 衍生資料系統（derived data system）。這組術語很有用，可以幫助你理清資料在系統中的流向：

權威記錄系統

權威記錄系統也稱 權威資料來源（source of truth），儲存某類資料的權威或 規範（canonical）版本。新資料到來時，例如使用者輸入，首先寫入這裡。每項事實只表示一次，通常採用 正規化（normalized）表示（參見“正規化、反正規化與連線”）。如果其他系統與權威記錄系統的資料不一致，那麼按照定義，應以權威記錄系統中的值為準。

衍生資料系統

衍生系統中的資料，是以另一個系統中的現有資料為基礎，經過某種轉換或處理而得到的結果。衍生資料即使丟失，也可以從原始資料來源重新建立。快取就是一個典型例子：若資料在快取中，便可直接返回；若快取中沒有所需資料，則可以退回底層資料庫讀取。反正規化值、索引、物化檢視、轉換後的資料表示，以及在資料集上訓練的模型，也都屬於這一類。

從技術上講，衍生資料是 冗餘（redundant）的，因為它複製了現有資訊。但是，要讓讀查詢獲得良好效能，這種冗餘往往不可或缺。你可以從同一個資料來源衍生出多個不同的資料集，從不同“視角”觀察資料。

分析型系統通常屬於衍生資料系統，因為它們消費的是在別處建立的資料。事務型服務則可能同時包含權威記錄系統和衍生資料系統：權威記錄系統是資料首先寫入的主資料庫，衍生資料系統則是加快常見讀取操作的索引和快取，尤其適用於權威記錄系統無法高效回答的查詢。

大多數資料庫、儲存引擎和查詢語言，本身並不天然是權威記錄系統或衍生系統。資料庫只是工具，如何使用由你決定。一個系統究竟屬於哪一類，取決於它在應用中的用法，而不是採用了什麼工具。明確哪些資料衍生自哪些其他資料，可以讓原本令人困惑的系統架構變得清晰。

如果一個系統的資料衍生自另一個系統，那麼每當權威記錄系統中的原始資料發生變化，就需要有相應流程更新衍生資料。遺憾的是，許多資料庫在設計時都假定應用只會使用這一個資料庫，因而很難整合多個系統並傳播這類更新。我們將在“資料整合”中討論 資料整合（data integration）的各種方法；藉助這些方法，可以組合多個資料系統，完成單個系統無法獨力完成的任務。

至此，我們對分析與事務處理的比較告一段落。下一節要討論的另一項權衡，你可能已經見過許多人反覆爭論。

雲服務與自託管

無論組織要做什麼，最先遇到的問題之一總是：應當由內部完成，還是外包出去？應當自建，還是購買？

歸根結底，這取決於業務的優先事項。管理學中通常認為，屬於組織核心能力或競爭優勢的事情應當在內部完成；非核心、例行或司空見慣的事情則應交給供應商 ²¹。舉一個極端的例子：大多數公司都不會自行發電（能源公司除外，這裡也不考慮應急備用電源），因為從電網購電更加便宜。

對軟體來說，有兩個重要決定：由誰來構建，又由誰來部署。兩項工作都可以按不同程度外包，從而形成圖 1-2所示的一條連續譜。一個極端是完全定製的軟體，由你自行編寫並在內部執行；另一個極端是廣泛使用的雲服務或軟體即服務（SaaS）產品，由外部供應商開發和運維，你只能透過 Web 介面或 API 使用。

這條連續譜的中間，是由你 自託管（self-hosted）的現成軟體（可以是開源軟體，也可以是商業軟體），也就是由你親自部署。例如，下載 MySQL 並安裝到一臺由你掌控的伺服器上。這臺伺服器可以是你自己的硬體——通常稱為 本地部署（on-premises），即使它實際位於租用的資料中心機架裡，並不真的在你的自有場所——也可以是雲中的虛擬機器，即 基礎設施即服務（IaaS）。這條連續譜上還有更多中間位置，例如採用開源軟體，但執行自己修改過的版本。

與這條連續譜相互獨立的另一個問題是：無論在雲端還是本地，究竟要 如何 部署服務，例如是否採用 Kubernetes 之類的編排框架。不過，部署工具的選擇不在本書討論範圍內，因為還有其他因素對資料系統架構的影響更大。

雲服務的利弊

使用雲服務而不是自行執行同類軟體，本質上就是把軟體的運維外包給雲服務商。採用雲服務既有充分的支援理由，也有充分的反對理由。雲服務商聲稱，與自建基礎設施相比，使用它們的服務能夠節省時間和金錢，還能讓你行動得更快。

雲服務究竟是否比自託管更便宜、更省事，很大程度上取決於你掌握的技能和系統承受的工作負載。如果你已經熟悉所需系統的部署和運維，而且負載相當容易預測（也就是所需機器數量不會劇烈波動），那麼購買自己的機器並自行執行軟體，往往更加便宜 ^{22 23}。

反過來，如果你需要一個自己還不會部署和運維的系統，那麼採用雲服務，通常比從頭學習如何自行管理更加容易、快捷。如果還必須專門招聘和培訓人員來維護、運維這個系統，成本可能會非常高。使用雲服務時仍然需要運維團隊（參見“雲時代的運維”），但把基礎系統管理外包出去，可以讓團隊專注於更高層次的問題。

把系統運維外包給專門經營這項服務的公司，也可能得到更好的服務，因為供應商在服務眾多客戶的過程中積累了豐富的運維經驗。另一方面，如果由你自行運維，就能針對自己的特定工作負載配置和調優服務；雲服務商不太可能願意為你進行這樣的定製。

如果系統負載隨時間大幅波動，雲服務尤其有價值。假如機器按峰值負載配置，但計算資源在大多數時候都處於閒置狀態，系統的成本效益就會很差。在這種情況下，雲服務的優勢在於，可以更加容易地隨著需求變化增加或減少計算資源。

例如，分析型系統的負載通常變化極大：要快速執行一項大型分析查詢，需要同時動用大量計算資源；但查詢完成後，這些資源就會閒置，直到使用者發出下一項查詢。預定義查詢（例如日報）可以排隊並排程執行，從而平滑負載；但對互動式查詢而言，越是希望迅速得到結果，工作負載的波動就越大。如果資料集龐大到必須投入大量計算資源才能快速查詢，使用雲服務可以節省成本，因為閒置資源可以歸還服務商，而不必任其空置。資料集較小時，這種差別就沒那麼顯著。

雲服務最大的缺點是你無法掌控它：

• 如果服務缺少你需要的功能，你只能客氣地詢問供應商是否願意新增；通常無法自己動手實現。
• 如果服務宕機，你只能等它恢復。
• 如果你的某種使用方式觸發了缺陷或效能問題，診斷起來會非常困難。對於自行執行的軟體，你可以從作業系統獲取效能指標和除錯資訊，從而瞭解它的行為，還可以檢視伺服器日誌；但服務由供應商託管時，你通常無法接觸這些內部資訊。
• 如果服務停止運營、價格高到無法接受，或供應商以你不喜歡的方式改動產品，你也只能任其擺佈——繼續執行舊版本通常不可行，因此只能被迫遷移到其他服務 ²⁴。如果存在提供相容 API 的替代服務，這種風險會小一些；但是許多雲服務並沒有標準 API，切換成本很高，因而產生了供應商鎖定問題。
• 你必須相信雲服務商能夠保護資料安全，這會增加遵守隱私和安全法規的難度。

儘管存在這些風險，組織在雲服務之上構建新應用，或者採用只在系統某些部分使用雲服務的混合方案，還是越來越普遍。不過，雲服務不會取代所有內部資料系統：許多老系統誕生在雲端計算之前；只要某項服務有現有雲服務無法滿足的特殊需求，內部系統仍然不可或缺。例如，高頻交易等對延遲極其敏感的應用，就需要完全掌控硬體。

雲原生系統架構

雲端計算不僅採用了不同的經濟模式——訂閱服務，而不是購買硬體和軟體許可證，再自行執行軟體——它的興起也從技術層面深刻影響了資料系統的實現方式。雲原生（cloud-native）一詞用來描述專為利用雲服務優勢而設計的架構。

原則上，幾乎任何可以自託管的軟體都能以雲服務的形式提供；事實上，許多流行的資料系統如今都有相應的託管服務。然而，從一開始就按雲原生思路設計的系統已經展現出若干優勢：在相同硬體上效能更好，故障恢復更快，能夠迅速調整計算資源以匹配負載，並且可以支援更大的資料集 ^{25 26 27}。表 1-2列出了兩類系統的一些例子。

雲服務的分層

許多自託管資料系統對執行環境的要求非常簡單：在 Linux 或 Windows 等常規作業系統上執行，把資料存成檔案系統中的檔案，並透過 TCP/IP 等標準網路協議通訊。少數系統依賴 GPU（用於機器學習）或 RDMA 網絡卡等特殊硬體，但總體而言，自託管軟體使用的都是十分通用的計算資源：CPU、記憶體、檔案系統和 IP 網路。

在雲中，這類軟體可以執行在基礎設施即服務（IaaS）環境裡，使用一臺或多臺虛擬機器（也稱為 例項，instance），每臺例項分配一定數量的 CPU、記憶體、磁碟和網路頻寬。與物理機器相比，雲例項的開通速度更快，可選規格也更多；但除此之外，它們與傳統計算機相似：你可以隨意執行任何軟體，也要自行負責管理。

與之相對，雲原生服務的關鍵思想是：不僅使用作業系統管理的計算資源，還要在低層雲服務的基礎上構建更高層的服務。例如：

• Amazon S3、Azure Blob Storage 和 Cloudflare R2 等 物件儲存（object storage）服務用於儲存大型檔案。它們的 API 比普通檔案系統更受限，只提供基本的檔案讀寫；但好處是隱藏了底層物理機器。服務會自動把資料分佈到許多機器上，你不必擔心其中某臺機器的磁碟空間耗盡。即使某些機器或其磁碟徹底損壞，資料也不會丟失。
• 許多其他服務又建立在物件儲存和其他雲服務之上。例如，Snowflake 是一種雲端分析資料庫（資料倉儲），依靠 S3 儲存資料 ²⁷；還有一些服務進一步構建在 Snowflake 之上。

計算機領域的抽象一向如此：該選擇哪一層，並沒有唯一正確的答案。一般來說，層次越高的抽象，往往越面向特定用例。如果你的需求恰好符合某個高層系統的設計場景，那麼直接使用現成系統，通常比自己用低層系統搭建省心得多，也足以滿足需要。反過來，如果沒有任何高層系統符合需求，那就只能用低層元件自行構建。

儲存與計算的分離

在傳統計算中，磁碟儲存被視為持久儲存：我們假定資料一旦寫入磁碟，就不會丟失。為了容忍單塊硬碟故障，人們通常使用 RAID（獨立磁碟冗餘陣列），在連線到同一臺機器的多塊磁碟上儲存資料副本。RAID 既可以由硬體實現，也可以由作業系統透過軟體實現；對於訪問檔案系統的應用來說，這一切都是透明的。

雲中的計算例項（虛擬機器）也可以連線本地磁碟，但雲原生系統通常更願意把它們當作臨時快取，而不是長期儲存。原因在於：一旦相應例項發生故障，本地磁碟就無法訪問；為了適應負載變化而把例項換成另一臺物理機上的更大或更小規格時，本地磁碟同樣無法訪問。

作為本地磁碟的替代方案，雲服務還提供虛擬磁碟儲存，可以從一個例項解除安裝，再掛載到另一個例項上，例如 Amazon EBS、Azure 託管磁碟和 Google Cloud 持久磁碟。這種虛擬磁碟並不是真正的物理磁碟，而是由另一組機器提供的雲服務，用來模擬磁碟的行為——也就是 塊裝置（block device），其中每個塊通常為 4 KiB。這項技術讓傳統的磁碟軟體可以在雲中執行，但塊裝置模擬會引入額外開銷；如果系統從一開始便針對雲設計，這些開銷本來可以避免 ²⁵。它還使應用對網路異常極為敏感，因為虛擬塊裝置上的每次 I/O 實際上都是一次網路呼叫 ²⁸。

為了解決這個問題，雲原生服務通常避開虛擬磁碟，轉而建立在針對特定工作負載最佳化的專用儲存服務之上。S3 等物件儲存服務適合長期儲存較大的檔案，大小從數百 KB 到數 GB 不等。資料庫中的單行或單個值通常遠小於這個範圍；因此，雲資料庫通常在一個獨立服務中管理較小的值，並把包含許多個值的較大資料塊存入物件儲存 ^{26 29}。我們將在第 4 章介紹相應的實現方法。

在傳統系統架構中，同一臺計算機同時負責儲存（磁碟）和計算（CPU 與記憶體）；而在雲原生系統中，這兩項職責在一定程度上相互分離，或者說被 解耦（decoupled）了 ^{9 27 30 31}。例如，S3 只負責儲存檔案；如果要分析其中的資料，就必須在 S3 之外執行分析程式碼。這也意味著資料需要透過網路傳輸，我們將在“分散式與單節點系統”中進一步討論。

此外，雲原生系統往往採用 多租戶（multitenant）模式：它並不為每個客戶單獨分配一臺機器，而是由同一項服務在共享硬體上處理多個客戶的資料和計算 ³²。

多租戶可以提高硬體利用率，更容易實現可伸縮性，也便於雲服務商管理；但要保證一個客戶的活動不影響其他客戶的效能或安全，就必須經過周密的工程設計 ³³。

雲時代的運維

傳統上，管理組織伺服器端資料基礎設施的人員稱為 資料庫管理員（DBA）或 系統管理員（sysadmin）。近年來，許多組織嘗試把軟體開發與運維角色融入同一個團隊，讓團隊共同負責後端服務和資料基礎設施；DevOps 理念推動了這一趨勢。站點可靠性工程師（SRE）則是 Google 對這一理念的實踐 ³⁴。

運維的職責是確保服務可靠地交付給使用者，包括配置基礎設施和部署應用；同時保障生產環境穩定，包括監控和診斷任何可能影響可靠性的問題。對自託管系統來說，傳統運維有大量工作落在單臺機器上，例如容量規劃（監控可用磁碟空間，並在耗盡前增加磁碟）、開通新機器、在機器之間遷移服務，以及安裝作業系統補丁。

許多雲服務透過 API 隱藏了實際承載服務的一臺臺機器。例如，雲端儲存不再提供固定容量的磁碟，而是採用 按量計費（metered billing）：你無需提前規劃容量，就可以儲存資料，然後按實際佔用的空間付費。此外，即使個別機器發生故障，許多雲服務仍然保持高可用性（參見“可靠性與容錯”）。

關注點從單臺機器轉向服務，也伴隨著運維角色的變化。可靠地提供服務這一高層目標沒有改變，但流程和工具已經演變。DevOps/SRE 理念更強調：

• 自動化——採用可重複的流程，而不是手工執行一次性任務；
• 採用臨時性的虛擬機器和服務，而不是長時間執行的伺服器；
• 支援頻繁更新應用；
• 從事故中吸取教訓；以及
• 即使人員來去更替，也要保留組織對系統的知識 ³⁵。

隨著雲服務興起，運維角色也發生了分化：基礎設施公司的運維團隊專攻如何面向大量客戶提供可靠服務；雲服務客戶則力求把投入基礎設施的時間和精力降到最低 ³⁶。

雲服務的客戶仍然需要運維，只是關注的方面有所不同，例如為一項任務選擇最合適的服務、整合不同服務，以及從一項服務遷移到另一項服務。儘管按量計費消除了傳統意義上的容量規劃，你依然必須清楚哪些資源被用在什麼地方，免得為並不需要的雲資源白白花錢：容量規劃變成了財務規劃，效能最佳化變成了成本最佳化 ³⁷。

而且，雲服務仍有資源上限或 配額（quota），例如併發執行的程序數上限。你必須提前瞭解並做好規劃，不能等到撞上限額才處理 ³⁸。

採用雲服務或許比自行執行基礎設施更加容易、快捷，但學習如何使用仍有成本，有時還得設法繞過它的限制。隨著供應商越來越多，面向各種用例的雲服務層出不窮，如何整合不同服務成了一項格外棘手的挑戰 ^{39 40}。

ETL（參見“資料倉儲”）只是其中一部分，事務型雲服務同樣需要彼此整合。目前還缺少簡化這類整合的標準，因此往往要投入大量手工工作。

還有一些運維工作無法完全外包給雲服務，例如維護應用及其依賴庫的安全，管理自有服務之間的互動，監控服務負載，以及追查效能下降或服務中斷等問題的根源。雲端計算固然正在改變運維的角色，但運維仍與以往任何時候一樣重要。

分散式與單節點系統

由多臺機器透過網路通訊而構成的系統，稱為 分散式系統（distributed system）。參與分散式系統的每個程序稱為一個 節點（node）。採用分散式系統可能出於以下各種原因：

固有的分散式系統

如果一項應用涉及兩個或更多相互互動的使用者，而每個使用者都使用自己的裝置，那麼這個系統不可避免地是分散式的：裝置之間只能透過網路通訊。

雲服務之間的請求

如果資料儲存在一個服務中，卻要由另一個服務處理，就必須透過網路把資料從一個服務傳到另一個服務。

容錯/高可用性

如果應用需要在一臺機器（乃至多臺機器、網路或整個資料中心）發生故障時繼續執行，可以用多臺機器提供冗餘：一臺發生故障後，由另一臺接管。參見“可靠性與容錯”以及第 6 章關於複製的討論。

可伸縮性

如果資料量或計算需求增長到單臺機器無力承擔，或許可以把負載分散到多臺機器上。參見“可伸縮性”。

延遲

如果使用者遍佈世界各地，你可能希望在全球多個區域部署伺服器，讓每個使用者都由地理位置較近的伺服器提供服務。這樣一來，使用者就不必等待網路資料包繞過半個地球才得到響應。參見“描述效能”。

彈性

如果應用有時繁忙、有時空閒，雲端部署可以隨著需求擴大或縮小，讓你只為正在使用的資源付費。這在單臺機器上很難做到：即使大部分時間幾乎沒有負載，仍要按最大負載預先配置機器。

使用專用硬體

系統的各個部分可以採用與各自工作負載相匹配的硬體。例如，物件儲存可以使用磁碟很多、CPU 很少的機器；資料分析系統可以使用 CPU 和記憶體很多、卻沒有磁碟的機器；機器學習系統則可以使用配備 GPU 的機器——訓練深度神經網路及執行其他機器學習任務時，GPU 的效率遠高於 CPU。

法律合規

一些國家制定了資料駐留法律，要求有關本國管轄範圍內人員的資料，必須在該國境記憶體儲和處理 ⁴¹。這類規定的適用範圍不盡相同：有些只針對醫療或金融資料，有些則更加寬泛。因此，如果一項服務的使用者分佈在多個這樣的司法管轄區，就不得不把使用者資料分散到多個地點的伺服器上。

可持續性

如果作業在何時、何地執行具有一定靈活性，就可以選擇可再生電力充足的時間和地點，並避開電網負荷緊張的時候。這樣既能減少碳排放，也能利用價格低廉的電力 ^{42 43}。

這些理由既適用於自行編寫的服務（應用程式碼），也適用於由資料庫等現成軟體組成的服務。

分散式系統的問題

分散式系統也有缺點。每一個經過網路的請求和 API 呼叫，都必須面對失敗的可能：網路可能中斷，服務可能過載或崩潰，任何請求都有可能超時而收不到響應。此時，我們不知道服務究竟有沒有收到請求，貿然重試未必安全。我們將在第 9 章詳細討論這些問題。

儘管資料中心網路很快，呼叫另一個服務仍然遠遠慢於在同一程序中呼叫函式 ⁴⁴。

處理海量資料時，與其把資料從儲存位置傳到另一臺機器上處理，往往不如把計算帶到已經儲存資料的機器上來得快 ⁴⁵。

節點更多也不一定更快：有些情況下，一臺計算機上簡單的單執行緒程式，效能可以顯著勝過擁有 100 多個 CPU 核心的叢集 ⁴⁶。

分散式系統往往很難排查故障：如果系統響應緩慢，怎樣才能找出問題在哪裡？用於診斷分散式系統問題的技術統稱為 可觀測性（observability）^{47 48}。它收集系統的執行資料，並允許人們查詢這些資料，從而既能分析高層指標，也能追查單個事件。OpenTelemetry、Zipkin 和 Jaeger 等 追蹤（tracing）工具可以記錄哪個客戶端為了什麼操作呼叫了哪個伺服器，以及每次呼叫花了多長時間 ⁴⁹。

資料庫提供了多種保證資料一致性的機制，我們將在第 6 章和第 8 章中看到。但是，當每個服務都有自己的資料庫時，如何保持不同服務之間的資料一致，就成了應用自身的問題。分散式事務（參見第 8 章）是一種可能的手段，但很少用於微服務，因為它與服務彼此獨立的目標背道而馳，而且許多資料庫根本不支援分散式事務 ⁵⁰。

出於以上種種原因，只要一項工作能在單臺機器上完成，通常就比搭建分散式系統簡單得多，也便宜得多 ^{23 46 51}。CPU 越來越快，記憶體和磁碟的容量越來越大，硬體也越來越可靠。再加上 DuckDB、SQLite 和 KùzuDB 等單節點資料庫，如今許多工作負載都可以在單個節點上執行。我們將在第 4 章進一步探討這個話題。

微服務與無伺服器

把系統分佈到多臺機器上，最常見的做法是將它劃分為客戶端和伺服器，由客戶端向伺服器傳送請求。這種通訊最常使用 HTTP，我們將在“流經服務的資料流：REST 與 RPC”中進一步討論。同一個程序既可以是伺服器（處理傳入的請求），也可以是客戶端（向其他服務發出請求）。

這種構建應用的方式傳統上稱為 面向服務架構（SOA）；近年來，這一思想又進一步演化為 微服務（microservices）架構 ^{52 53}。在這種架構中，每項服務都有明確的用途（例如 S3 的用途就是檔案儲存）；服務透過 API 向客戶端開放能力，由客戶端經網路呼叫；每項服務還由一個團隊負責維護。這樣一來，複雜應用就可以拆分成多項相互互動的服務，分別由不同團隊管理。

把複雜軟體拆成多項服務有幾個優點：各項服務可以獨立更新，減少團隊之間的協調；每項服務可以獲得符合自身需要的硬體資源；實現細節隱藏在 API 後面，服務負責人可以自由改變實現，而不影響客戶端。在資料儲存方面，通常每項服務都有自己的資料庫，服務之間不共享資料庫。否則，整個資料庫結構實際上都會成為服務 API 的一部分，很難再行修改；而且，一項服務發出的查詢也可能拖累其他服務的效能。

另一方面，服務多了本身也會滋生複雜度：每項服務都需要相應基礎設施，用來部署新版本、根據負載調整硬體資源、收集日誌、監控服務健康狀況，並在出現問題時向值班工程師告警。Kubernetes 等 編排（orchestration）框架為這類基礎設施提供了基礎能力，因此成了部署服務的常用方式。在開發過程中測試一項服務也可能很麻煩，因為它所依賴的其他服務必須一併執行。

微服務 API 也很難演化。呼叫 API 的客戶端會期待其中存在某些欄位；隨著業務需求改變，開發者或許想要增刪 API 欄位，但這可能導致客戶端出錯。更糟的是，這類問題往往要到開發週期後期，更新後的服務 API 部署到預釋出或生產環境時才被發現。OpenAPI 和 gRPC 等 API 描述標準有助於管理客戶端 API 與伺服器 API 之間的關係，我們將在第 5 章中進一步討論。

微服務主要是用技術手段解決人員問題：讓不同團隊無需彼此協調，也能獨立推進工作。這對大公司很有價值；但在團隊不多的小公司裡，微服務很可能只是沒有必要的額外開銷，此時最好採用最簡單的方式實現應用 ⁵²。

無伺服器（serverless），又稱 函式即服務（FaaS），是另一種服務部署方式：它把基礎設施管理進一步外包給雲服務商 ³³。使用虛擬機器時，你必須明確決定何時啟動或關閉例項；無伺服器模型則由雲服務商根據發往服務的請求，自動分配和釋放硬體資源 ⁵⁴。這種部署方式把更多運維負擔轉移給雲服務商，並允許按使用量靈活計費，不再按機器例項收費。為了提供這些好處，許多無伺服器基礎設施會限制函式執行時長和執行時環境，而且函式第一次呼叫時可能啟動緩慢。“無伺服器”這個名稱也容易誤導：每次執行無伺服器函式仍然要用到一臺伺服器，只是下一次執行可能換到另一臺。此外，BigQuery 和各種 Kafka 產品也採用了“無伺服器”這個說法，用來表示服務能夠自動伸縮，並按使用量而不是機器例項收費。

正如雲端儲存用按量計費取代了容量規劃（提前決定購買多少磁碟），無伺服器模式也把按量計費帶到了程式碼執行：你只需為應用程式碼實際執行的時間付費，不必提前配置資源。

雲端計算與超級計算

雲端計算並非構建大規模計算系統的唯一方式，另一條路線是 高效能運算（HPC），也稱為 超級計算（supercomputing）。儘管二者有所重疊，但與雲端計算和企業資料中心繫統相比，HPC 的側重點通常不同，採用的技術也不一樣。差異包括：

• 超級計算機通常用於計算密集型的科學計算任務，例如天氣預報、氣候建模、分子動力學（模擬原子和分子的運動）、複雜最佳化問題，以及求解偏微分方程。雲端計算則更常用於線上服務、業務資料系統，以及其他需要以高可用性響應使用者請求的系統。
• 超級計算機通常執行大型批處理作業，並不時把計算狀態作為檢查點寫入磁碟。如果某個節點發生故障，一種常見做法是直接停止整個叢集的工作負載，修復故障節點，再從最近的檢查點重新開始計算 ^{55 56}。雲服務通常不能這樣停掉整個叢集，因為服務必須持續響應使用者，儘量減少中斷。
• 超級計算機的節點通常透過共享記憶體和遠端直接記憶體訪問（RDMA）通訊，既有高頻寬，又有低延遲，但前提是系統使用者彼此高度信任 ⁵⁷。在雲端計算中，網路和機器常由互不信任的組織共享，因此需要更強的安全機制，例如資源隔離（使用虛擬機器等）、加密和認證。
• 雲資料中心網路通常以 IP 和乙太網為基礎，採用 Clos 拓撲來提供較高的對分頻寬——這是衡量網路整體效能的常用指標 ^{55 58}。超級計算機則常採用專門的網路拓撲，例如多維網格和環面 ⁵⁹；對於通訊模式已知的 HPC 工作負載，這類拓撲可以提供更好的效能。
• 雲端計算允許節點分佈在多個地理區域；超級計算機通常假定所有節點都彼此鄰近。

大規模分析系統有時也具備超級計算的一些特徵；如果你在這個領域工作，瞭解這些技術會很有價值。不過，本書主要關注必須持續可用的服務，正如“可靠性與容錯”所討論的那樣。

資料系統、法律與社會

本章到目前為止已經說明，資料系統架構不僅受技術目標和要求影響，也受其所服務組織中人類需求的影響。越來越多的資料系統工程師開始認識到，只滿足自己所在企業的需求還不夠：我們也對整個社會負有責任。

其中一個特別值得關注的問題，是儲存個人及其行為資料的系統。自 2018 年起，《通用資料保護條例》（GDPR）賦予許多歐洲國家的居民更大的個人資料控制權和更多法律權利；世界各地的不少國家和地區也採用了類似的隱私法規，例如《加州消費者隱私法案》（CCPA）。《歐盟人工智慧法案》 等針對 AI 的法規，又進一步限制了個人資料的使用方式。

即使在沒有直接受到監管的領域，人們也越來越清楚地認識到計算機系統對個人和社會的影響。社交媒體改變了人們獲取新聞的方式，進而影響政治觀點，甚至可能左右選舉結果。自動化系統也越來越多地作出對個人影響深遠的決定，例如誰能獲得貸款或保險，誰能得到工作面試的機會，以及誰會成為犯罪嫌疑人 ⁶⁰。

每一個參與這類系統的人，都有責任考慮它們的倫理影響，並確保系統遵守相關法律。並非人人都要成為法律和倫理專家，但具備基本的法律與倫理常識，與掌握分散式系統的基礎知識同樣重要。

法律因素正在影響資料系統設計最根本的部分 ⁶¹。例如，GDPR 賦予個人要求刪除其資料的權利，有時稱為 被遺忘權（right to be forgotten）。然而，正如本書將要介紹的，許多資料系統的設計依賴僅追加日誌等不可變結構；一個本應不可變的檔案，要怎樣從中間刪除某些資料？如果資料已經納入衍生資料集（參見“權威記錄系統與衍生資料”），例如成為機器學習模型的訓練資料，又該如何刪除？回答這些問題帶來了新的工程挑戰。

目前，還沒有明確指南說明哪些具體技術或系統架構算是“符合 GDPR”。法規有意不規定特定技術，因為技術進步可能很快就會使這些規定過時。法律文字給出的只是有待解釋的高層原則。因此，如何遵守隱私法規並沒有簡單答案；不過，在討論本書的一些技術時，我們會從這個角度加以審視。

一般來說，我們之所以儲存資料，是因為相信它的價值高於儲存成本。但不要忘記，儲存成本不只是付給 Amazon S3 或其他服務的賬單。成本效益分析還應計入這些風險：資料一旦洩露，或遭到攻擊者竊取、破壞，可能承擔法律責任並蒙受聲譽損失；如果資料的儲存和處理不符合法律規定，還可能產生訴訟費用和罰款 ⁵¹。

政府或警方也可能強迫企業交出資料。如果資料可能暴露某些在當地被法律定為犯罪的行為——例如，在一些中東和非洲國家，同性戀會受到刑事處罰；在美國一些州，尋求墮胎也可能受到刑事追究——那麼儲存這些資料會給使用者帶來切實的安全風險。例如，位置資料很容易暴露一個人曾前往墮胎診所；哪怕只是一段使用者 IP 地址的歷史日誌，也可能洩露其大致位置。

把所有風險都考慮在內之後，合理的結論可能是：某些資料根本不值得儲存，因此應當刪除。資料最小化（data minimization）原則（有時也用德語 Datensparsamkeit 表示）與“大資料”理念背道而馳；後者傾向於先存下大量資料，指望它們將來也許會派上用場 ⁶²。不過，資料最小化符合 GDPR：個人資料只能為具體、明確的目的而收集，日後不得用於其他目的，也不得在超出原定目的所需期限後繼續保留 ⁶³。

企業同樣開始重視隱私和安全問題。信用卡公司要求支付處理企業遵守嚴格的支付卡行業（PCI）標準；支付處理商要頻繁接受獨立審計機構的評估，驗證是否持續合規。軟體供應商面臨的審查也日趨嚴格，許多采購方如今要求供應商符合服務組織控制（SOC）第 2 類標準。與 PCI 合規一樣，供應商要透過第三方審計來驗證是否符合要求。

總而言之，必須在業務需求與資料被收集、處理的人們的需求之間取得平衡。這個話題遠不止於此；第 14 章將深入討論倫理與法律合規問題，包括偏見和歧視。

總結

本章的主題是理解權衡：許多問題並沒有唯一正確的答案，而是有幾種不同的做法，各有利弊。我們探討了影響資料系統架構的一些最重要的選擇，也介紹了閱讀本書其餘部分所需的術語。

首先，我們區分了事務型系統（事務處理，即 OLTP）與分析型系統（OLAP），看到兩者不僅管理著訪問模式不同的各類資料，服務的群體也不相同。我們還認識了資料倉儲與資料湖，它們透過 ETL 接收事務型系統送來的資料。第 4 章將會說明，由於要服務的查詢型別不同，事務型系統與分析型系統的內部資料佈局往往大相徑庭。

接著，我們把出現時間較晚的雲服務，與此前長期主導資料系統架構的自託管軟體正規化作了比較。哪種方式成本效益更高，很大程度上取決於具體情況；但不可否認的是，雲原生方法正在深刻改變資料系統的架構，例如將儲存與計算分離。

雲系統天然就是分散式系統，我們也簡要考察了分散式系統與單機方案之間的一些權衡。有些場景無法避免分散式；但只要系統還能保留在一臺機器上，就不宜急著將其分散式化。第 9 章將更詳細地討論分散式系統帶來的挑戰。

最後，我們看到，資料系統架構不僅由部署系統的企業需求決定，也受隱私法規影響；這些法規保護著資料處理所涉及人員的權利，而許多工程師很容易忽視這一點。如何把法律要求轉化為技術實現，目前還沒有得到充分理解；但在閱讀本書後續內容時，務必始終把這個問題放在心上。

參考文獻

2 定義非功能性需求

網際網路做得太好了，以至於大多數人將它看作像太平洋這樣的自然資源，而不是什麼人工產物。上一次出現這種規模且幾乎不出錯的技術，是什麼時候？

艾倫・凱， 接受 Dr Dobb’s Journal 採訪（2012 年）

構建應用程式時，你會面對一張需求清單。其中排在最前面的，很可能是應用必須提供的功能：需要哪些頁面和按鈕，每項操作要完成什麼，才能實現軟體的目的。這些就是 功能需求（functional requirements）。

此外，你可能還有一些 非功能性需求（nonfunctional requirements）：例如，應用應當快速、可靠、安全、符合法律規定，而且易於維護。這些要求未必會明確寫下來，因為它們看似理所當然，但其重要性絲毫不亞於應用的功能：一個慢得讓人無法忍受，或是很不可靠的應用，幾乎等於不存在。

安全性等許多非功能性需求超出了本書的範圍。不過，本章會討論其中幾項，並幫助你準確表述自己的系統需要達到什麼要求：

• 如何定義和衡量系統的 效能（performance；參見“描述效能”）；
• 服務 可靠（reliable）意味著什麼——也就是即使出了問題，仍能繼續正確工作（參見“可靠性與容錯”）；
• 隨著系統負載增長，能否高效增加計算能力，使系統具備 可伸縮性（scalability；參見“可伸縮性”）；以及
• 如何讓系統在長期使用中更易維護（參見“可維護性”）。

後續章節深入討論資料密集型系統的實現細節時，還會用到本章引入的術語。不過，抽象定義讀起來難免枯燥。為了讓這些概念更加具體，我們先從一個社交網路服務的實現案例講起，以此說明效能與可伸縮性在實踐中意味著什麼。

案例研究：社交網路首頁時間線

假設你的任務是實現一個類似 X（原 Twitter）的社交網路，使用者可以發帖，也可以關注其他使用者。這裡的實現會比真實服務簡單得多 ^{1 2 3}，但足以說明大規模系統會遇到的一些問題。

假設使用者每天釋出 5 億條帖子，平均每秒 5,700 條；偶爾，發帖速率會飆升至每秒 150,000 條 ⁴。再假設每位使用者平均關注 200 人，也有 200 名關注者（實際分佈範圍非常廣：大多數人只有寥寥幾名關注者，而巴拉克・奧巴馬等少數名人則有超過一億名關注者）。

表示使用者、帖子與關注關係

假設我們把所有資料都儲存在關聯式資料庫中，如圖 2-1所示：一張表儲存使用者，一張表儲存帖子，還有一張表儲存關注關係。

假設這個社交網路需要支援的主要讀操作是 首頁時間線（home timeline），用來展示你所關注的人最近釋出的帖子（為簡單起見，我們忽略廣告、來自未關注使用者的推薦帖，以及其他擴充套件功能）。可以用下面這條 SQL 查詢來獲取某位使用者的首頁時間線：

SELECT posts.*, users.* FROM posts
    JOIN follows ON posts.sender_id = follows.followee_id
    JOIN users ON posts.sender_id = users.id
    WHERE follows.follower_id = current_user
    ORDER BY posts.timestamp DESC
    LIMIT 1000

執行這條查詢時，資料庫先用 follows 表找出 current_user 關注的所有人，再查詢這些使用者最近釋出的帖子，並按時間戳排序，取出其中最新的 1,000 條。

帖子講究時效，因此假設某人發帖之後，我們希望其關注者能在 5 秒內看到。一個辦法是，只要使用者線上，客戶端就每隔 5 秒重複執行一次上述查詢（這稱為 輪詢（polling））。如果同時線上且已登入的使用者有 1,000 萬，就意味著每秒要執行 200 萬次查詢。即使延長輪詢間隔，這個數字仍然很大。

而且，這條查詢本身開銷不小：如果你關注了 200 人，資料庫就要分別取出這 200 人最近釋出的帖子，再把這些列表合併起來。每秒 200 萬次時間線查詢，意味著資料庫每秒要查詢某個發帖者的近期帖子 4 億次——這是個驚人的數字，而且還只是平均情況。有些使用者關注了數萬個賬戶，為他們執行這條查詢的代價極高，也很難保證速度。

時間線的物化與更新

怎樣才能做得更好？首先，與其讓客戶端輪詢，不如由伺服器把新帖子主動推送給當前線上的關注者。其次，可以預先計算上述查詢的結果，使首頁時間線請求直接由快取提供。

設想我們為每位使用者儲存一個資料結構，其中裝著他們的首頁時間線，也就是他們所關注的人最近釋出的帖子。每當有人發帖，我們就找出他的所有關注者，把這條帖子插入每位關注者的首頁時間線，就像把信投進一個個郵箱。這樣，使用者登入時只需把預先計算好的時間線交給他們即可。若要接收時間線上的新帖通知，客戶端只需訂閱不斷加入其首頁時間線的帖子流。

這種方法的缺點是，每次發帖都要完成更多工作，因為首頁時間線是需要隨之更新的 衍生資料（derived data）。整個過程如圖 2-2所示。當一個初始請求引發多個下游請求時，我們用 扇出（fan-out） 來表示請求數量被放大的倍數。

以每秒 5,700 條帖子的速率計算，如果每條帖子平均要送達 200 名關注者（也就是扇出係數為 200），每秒就要完成略多於 100 萬次首頁時間線寫入。這個數字依然很大，但與另一種方案每秒 4 億次按發帖者查詢近期帖子的操作相比，已經節省了很多工作。

如果某個特殊事件使發帖速率驟增，我們無須立刻完成所有時間線投遞；可以先把投遞任務放入佇列，並接受帖子暫時要過一會兒才會出現在關注者的時間線上。即使出現這種負載高峰，時間線仍然可以快速載入，因為讀取只需訪問快取。

這種預先計算並不斷更新查詢結果的過程稱為 物化（materialization），時間線快取就是一個 物化檢視（materialized view） 的例子（我們會在“維護物化檢視”中進一步討論這個概念）。物化檢視加快了讀取，代價則是寫入時要做更多工作。對大多數使用者而言，寫入成本並不高，但社交網路還必須考慮一些極端情況：

• 如果一位使用者關注了非常多的賬戶，而且這些賬戶發帖頻繁，那麼寫入其物化時間線的速率會很高。不過，這位使用者多半也不會讀完時間線中的所有帖子，因此可以丟棄其中一部分時間線寫入，只向使用者展示所關注賬戶釋出帖子的一個樣本 ⁵。
• 如果一位擁有海量關注者的名人發帖，我們就要完成大量工作，把這條帖子插入數百萬人的首頁時間線。在這種情況下，丟棄部分寫入是不可接受的。一種解決辦法是把名人帖子與其他人的帖子分開處理：不必費力把名人帖子加入數百萬條時間線，而是將其單獨儲存，等讀取時再與物化時間線合併。即使採用這類最佳化，社交網路要承載名人賬戶仍可能需要大量基礎設施 ⁶。

描述效能

討論軟體效能時，通常會考慮兩類主要指標：

響應時間（response time）

從使用者發出請求到收到所需響應所經過的時間。計量單位是秒（或毫秒、微秒）。

吞吐量（throughput）

系統每秒處理的請求數或資料量。對於給定的硬體資源，系統能處理的吞吐量存在上限，也就是 最大吞吐量（maximum throughput）。計量單位通常寫成“每秒多少個……”。

在社交網路案例中，“每秒帖子數”和“每秒時間線寫入數”是吞吐量指標；“載入首頁時間線所需的時間”和“帖子送達關注者所需的時間”則是響應時間指標。

吞吐量和響應時間之間往往存在聯絡，圖 2-3勾勒了線上服務中二者的一種典型關係。請求吞吐量較低時，服務的響應時間也很短；隨著負載增大，響應時間隨之上升。這是 排隊（queueing）造成的：當請求到達負載很高的系統時，CPU 很可能正在處理先前的請求，新來的請求只好等到前一個處理完畢。當吞吐量逐漸逼近硬體的處理極限時，排隊延遲會急劇增加。

在各項效能指標中，使用者通常最關心響應時間；吞吐量則決定了所需的計算資源（例如伺服器數量），從而決定處理特定工作負載的成本。如果吞吐量可能增長到超出當前硬體的處理能力，就需要擴充容量。如果增加計算資源能夠顯著提高系統的最大吞吐量，我們就稱這個系統具有 可伸縮性（scalability）。

本節主要關注響應時間；我們會在“可伸縮性”一節回頭討論吞吐量與可伸縮性。

延遲與響應時間

“延遲”和“響應時間”有時會被混為一談，但本書將按下面的特定含義使用這幾個術語（如圖 2-4所示）：

• 響應時間（response time）是客戶端看到的時間，其中包括系統各處產生的全部延誤。
• 服務時間（service time）是服務真正用於處理使用者請求的時間。
• 排隊延遲（queueing delay）可能發生在流程中的多個位置。例如，請求到達後，也許必須等到 CPU 空閒才能開始處理；如果同一臺機器上的其他任務正在透過出站網路介面傳送大量資料，響應資料包也可能先在緩衝區中等待。
• 延遲（latency）泛指請求沒有得到實際處理的時間，也就是請求處於 潛伏（latent） 狀態的時間。具體來說，網路延遲（network latency）或 網路時延（network delay）是請求和響應在網路中傳輸所花的時間。

在圖 2-4中，時間從左向右流逝；參與通訊的每個節點用一條水平線表示，請求或響應訊息則畫成從一個節點指向另一個節點的粗斜箭頭。本書後面還會經常遇到這種圖示方式。

即使反覆傳送同一個請求，每次的響應時間也可能相差很大。許多因素都會帶來隨機的額外延遲，例如：上下文切換到後臺程序、網路丟包和 TCP 重傳、垃圾回收暫停、缺頁迫使系統從磁碟讀取資料、伺服器機架的機械振動 ¹⁷，等等。我們會在“超時和無界延遲”中進一步討論這個問題。

響應時間的波動很大一部分往往來自排隊延遲。伺服器同時能處理的任務數量有限（例如受 CPU 核數限制），因此只需少數幾個慢請求，就足以阻礙後續請求，這種現象稱為 隊頭阻塞（head-of-line blocking）。即使後續請求本身的服務時間很短，客戶端看到的總體響應時間仍會很長，因為它們要等待先前的請求完成。排隊延遲不屬於服務時間，所以在客戶端測量響應時間十分重要。

平均值、中位數與分位數

由於每次請求的響應時間都不一樣，我們不能只把它看成一個數字，而應將其視為一組可測量數值的 分佈（distribution）。在圖 2-5中，每根灰色柱條代表一次服務請求，柱條的高度表示這次請求所花的時間。大多數請求都相當快，但偶爾會出現耗時長得多的 異常值（outlier）。網路延遲的變化也稱為 抖動（jitter）。

服務通常會報告 平均（mean）響應時間，也就是 算術平均值（arithmetic mean）：把所有響應時間相加，再除以請求數。平均響應時間有助於估算吞吐量的上限 ¹⁸。不過，如果你想知道“典型”的響應時間，平均值就不是很好的指標，因為它沒有告訴你究竟有多少使用者實際經歷了這樣的等待。

通常，採用 分位數（percentile） 更合適。將響應時間從快到慢排列，中位數（median）就是位於正中間的值。例如，如果響應時間的中位數是 200 毫秒，就意味著一半請求用時不到 200 毫秒，另一半則需要更長時間。因此，如果想知道使用者通常要等多久，中位數是個很好的指標。中位數也稱為 第 50 分位數，有時縮寫為 p50。

為了弄清異常值究竟有多糟，可以觀察更高的分位數。常用的有第 95、99 和 99.9 分位數，分別縮寫為 p95、p99 和 p999。它們對應這樣一個響應時間閾值：分別有 95%、99% 或 99.9% 的請求快於這個閾值。例如，如果第 95 分位數的響應時間是 1.5 秒，就意味著每 100 個請求中，有 95 個用時不到 1.5 秒，另外 5 個則需要 1.5 秒或更久。圖 2-5對此作了說明。

響應時間的高分位數也稱為 尾延遲（tail latencies），它們十分重要，因為會直接影響使用者對服務的體驗。例如，亞馬遜用第 99.9 分位數來描述內部服務的響應時間要求，儘管它只影響每 1,000 個請求中的一個。這是因為，響應最慢的客戶往往是在賬戶中積累了最多資料的人——他們購買過很多商品，也就是最有價值的客戶 ¹⁹。確保網站對這些客戶同樣快速，是維持其滿意度的重要手段。

另一方面，亞馬遜認為，針對第 99.99 分位數（每 10,000 個請求中最慢的一個）進行最佳化，成本過高，收益又不足。降低極高分位數處的響應時間非常困難，因為它很容易受到不可控隨機事件的影響，而且越往後收益越小。

響應時間指標的應用

如果後端服務要為一次終端使用者請求執行多次呼叫，那麼高分位數尤其重要。即使這些呼叫並行發出，終端使用者請求仍要等待其中最慢的一次完成。正如圖 2-6所示，只需一個慢呼叫，就足以拖慢整個終端使用者請求。即使後端呼叫中只有很小一部分速度較慢，一次終端使用者請求所需的後端呼叫越多，其中出現慢呼叫的機率也就越大，最終會有更高比例的使用者請求變慢。這種效應稱為 尾部延遲放大（tail latency amplification） ²⁶。

分位數經常出現在 服務級別目標（SLO） 和 服務級別協議（SLA） 中，用來規定服務應達到的效能和可用性 ²⁷。例如，一項 SLO 可能要求服務的中位響應時間低於 200 毫秒、第 99 分位數的響應時間低於 1 秒，並要求至少 99.9% 的有效請求得到非錯誤響應。SLA 則是一份合同，規定未達到 SLO 時會怎樣處理（例如，客戶可能有權獲得退款）。這至少是其基本思路；在實踐中，要為 SLO 和 SLA 定義良好的可用性指標並不簡單 ^{28 29}。

可靠性與容錯

每個人對於一個東西是否可靠，都有直觀的判斷。人們對可靠軟體的典型期望包括：

• 應用程式表現出使用者所期望的功能。
• 允許使用者犯錯，或以出乎意料的方式使用軟體。
• 在預期的負載和資料量下，效能足以滿足所需的使用場景。
• 系統能防止未經授權的訪問和濫用。

如果把這些合在一起稱為“正確工作”，那麼 可靠性（reliability） 可以粗略理解為“即使出了問題，也能繼續正確工作”。為了更準確地描述所謂“出了問題”，我們要區分 故障（fault） 和 失效（failure） ^{35 36 37}：

故障

系統的某個 部分 停止正常工作。例如，單塊硬碟發生故障、單臺機器崩潰，或者系統所依賴的外部服務中斷。

失效

整個系統 停止向使用者提供所需的服務；換言之，系統沒有達到服務級別目標（SLO）。

故障與失效之所以容易混淆，是因為二者其實是同一件事，只是觀察的層次不同。例如，如果一塊硬碟停止工作，我們會說這塊硬碟失效了：若整個系統只有這一塊硬碟，系統也就停止了提供所需服務。然而，如果我們談論的是一個包含許多硬碟的系統，那麼單塊硬碟失效從整個系統的角度看只是一項故障；只要資料在另一塊硬碟上還有副本，整個系統就可能容忍這項故障。

容錯

如果某些故障發生時，系統仍能繼續向使用者提供所需服務，我們就稱它是 容錯的（fault-tolerant）。如果系統無法容忍某個部分出現故障，這個部分就稱為 單點故障（SPOF），因為它一旦發生故障，就會升級為整個系統的失效。

以社交網路案例為例，扇出過程中可能發生這樣一種故障：負責更新物化時間線的某臺機器崩潰或變得不可用。要讓這個過程具備容錯能力，就必須確保另一臺機器能接手這項任務，既不漏掉任何本應投遞的帖子，也不會重複投遞。（這個思想稱為 恰好一次語義（exactly-once semantics），我們會在“資料庫的端到端原則”中詳細討論。）

容錯能力總是針對特定型別、特定數量的故障而言。例如，一個系統也許最多能容忍兩塊硬碟同時失效，或三個節點中有一個崩潰。要求系統容忍任意數量的故障沒有意義：如果所有節點都崩潰了，任何辦法都無濟於事。如果整個地球（以及上面的所有伺服器）都被黑洞吞噬，要容忍這項故障就得把網站託管到太空中——祝你好運，看看這筆預算能不能獲批。

反直覺的是，在這類容錯系統中，透過故意觸發故障來 提高 故障率有時反而是合理的，例如毫無預警地隨機殺死某個程序。這稱為 故障注入（fault injection）。許多嚴重缺陷其實源於糟糕的錯誤處理 ³⁸；故意製造故障，可以讓容錯機制不斷得到演練和檢驗，從而增強我們的信心：當故障自然發生時，系統確實能夠正確處理。混沌工程（chaos engineering） 就是一門透過故障注入等實驗來增強人們對容錯機制信心的學科 ³⁹。

雖然比起預防故障，我們通常更傾向於容忍故障，但有時預防確實勝於治療（例如根本無藥可救時）。安全問題就是如此：如果攻擊者已經攻破系統並獲得敏感資料，這件事無法撤銷。不過，本書主要討論的是能夠補救的故障型別，下面幾節會作進一步說明。

硬體與軟體故障

說到系統失效的原因，人們很容易首先想到硬體故障：

• 每年大約有 2%～5% 的機械硬碟發生故障 ^{40 41}；因此，在擁有 10,000 塊硬碟的儲存叢集中，平均每天應該會有一塊硬碟失效。近期資料表明硬碟越來越可靠，但故障率仍不容忽視 ⁴²。
• 每年大約有 0.5%～1% 的固態硬碟（SSD）發生故障 ⁴³。少量位元錯誤會自動得到糾正 ⁴⁴，但每塊硬碟大約每年仍會發生一次無法糾正的錯誤，即使硬碟相當新（也就是磨損很少）也不例外；這個錯誤率高於機械硬碟 ^{45 46}。
• 電源、RAID 控制器和記憶體模組等其他硬體元件也會發生故障，只是沒有硬碟那麼頻繁 ^{47 48}。
• 大約每 1,000 臺機器中，就有一臺的某個 CPU 核心偶爾會算出錯誤結果，原因很可能是製造缺陷 ^{49 50 51}。錯誤計算有時會導致崩潰，有時卻只是讓程式返回錯誤的結果。
• RAM 中的資料也可能損壞，原因既可能是宇宙射線等隨機事件，也可能是永久性的物理缺陷。即使採用糾錯碼（ECC）記憶體，一年內仍會有超過 1% 的機器遇到無法糾正的錯誤，通常會導致機器崩潰，並且需要更換受影響的記憶體模組 ⁵²。此外，某些病態的記憶體訪問模式很可能導致位元翻轉 ⁵³。
• 整個資料中心可能變得不可用（例如停電或網路配置錯誤），甚至遭到永久摧毀（例如火災、洪水或地震 ⁵⁴）。太陽噴發大量帶電粒子所形成的太陽風暴，會在長距離導線中感應出很強的電流，可能破壞電網和海底網路電纜 ⁵⁵。這類大規模失效雖然少見，但如果服務不能容忍整個資料中心的丟失，後果可能是災難性的 ⁵⁶。

這些事件相當少見，因此在小型系統中，只要故障硬體很容易更換，通常不必為之過分擔心。然而，在大規模系統裡，硬體故障發生得足夠頻繁，已經成了系統正常執行的一部分。

透過冗餘容忍硬體故障

面對不可靠的硬體，我們通常首先想到為各個硬體元件增加冗餘，以降低整個系統的失效率。磁碟可以組成 RAID（把資料分散到同一臺機器的多塊磁碟上，使單塊磁碟失效不至於造成資料丟失）；伺服器可以配備雙路電源和可熱插拔的 CPU；資料中心可以用電池和柴油發電機提供備用電源。這些冗餘措施往往能讓一臺機器連續執行多年而不中斷。

當各個元件的故障彼此獨立時，冗餘最有效；所謂獨立，就是一項故障的發生不會改變另一項故障發生的機率。然而，實踐表明，元件失效之間往往存在顯著的相關性 ^{41 57 58}；整個伺服器機架乃至整個資料中心不可用的情況，仍然比我們希望的更加常見。

硬體冗餘可以提高單臺機器的正常執行時間。不過，正如“分散式與單節點系統”中所述，採用分散式系統還有其他好處，例如能夠容忍整個資料中心中斷。因此，雲系統往往不那麼強調單臺機器的可靠性，而是力求在軟體層面容忍節點故障，讓服務實現高可用。雲提供商用 可用區（availability zone） 來標明哪些資源在物理上位於同一處；與地理位置分散的資源相比，同一地點的資源更可能同時失效。

本書討論的容錯技術，旨在容忍整臺機器、整個機架或整個可用區的丟失。它們通常允許一個資料中心內的機器，在另一個資料中心內的機器發生故障或變得不可達時接替其工作。我們會在第 6 章、第 10 章以及本書其他多處討論這類容錯技術。

能夠容忍整臺機器丟失的系統，在運維上也有優勢。如果需要重啟機器（例如安裝作業系統安全補丁），單伺服器系統必須安排停機；而多節點容錯系統可以逐個重啟節點來安裝補丁，不影響向使用者提供服務。這稱為 滾動升級（rolling upgrade），我們會在第 5 章進一步討論。

軟體故障

儘管硬體失效之間可能存在較弱的相關性，但大體上仍然相互獨立。例如，一塊硬碟失效以後，同一臺機器上的其他硬碟很可能還能繼續正常工作一段時間。相比之下，軟體故障往往高度相關，因為許多節點通常執行同一套軟體，也就帶有同樣的缺陷 ^{59 60}。這類故障更難預見，而且比互不相關的硬體故障更容易造成系統失效 ⁴⁷。例如：

• 一個軟體缺陷在特定情況下導致所有節點同時失效。例如，2012 年 6 月 30 日的一次閏秒觸發了 Linux 核心中的缺陷，使許多 Java 應用程式同時掛起，大量網際網路服務隨之中斷 ⁶¹。另一個例子是，由於韌體缺陷，某些型號的 SSD 會在恰好執行 32,768 小時（不到 4 年）後突然全部失效，盤上的資料再也無法恢復 ⁶²。
• 某個失控程序耗盡 CPU 時間、記憶體、磁碟空間、網路頻寬或執行緒等共享而有限的資源 ⁶³。例如，程序在處理大型請求時消耗了過多記憶體，可能被作業系統殺死；客戶端庫中的缺陷也可能產生遠高於預期的請求量 ⁶⁴。
• 系統所依賴的某項服務變慢、失去響應，或開始返回內容損壞的響應。
• 不同系統之間的互動產生湧現行為，而每個系統單獨測試時都不會出現這種行為 ⁶⁵。
• 發生級聯失效：一個元件的問題導致另一個元件過載並變慢，後者繼而又拖垮下一個元件 ^{66 67}。

引發這類軟體故障的缺陷往往會潛伏很久，直到一組不同尋常的條件將其觸發。這時人們才發現，軟體原來對執行環境作出了某種假設；這個假設通常都成立，卻最終會出於某種原因不再成立 ^{68 69}。

軟體中的系統性故障沒有速效藥，但許多小措施都能有所幫助：認真思考系統中的假設和互動，開展徹底的測試，隔離程序，允許程序崩潰並重啟，避免重試風暴之類的反饋環路（參見“當過載系統無法恢復時”），並在生產環境中度量、監控和分析系統行為。

人類與可靠性

軟體系統由人設計和構建，維持系統執行的運維人員同樣也是人。與機器不同，人類不只是照章行事；他們的長處正是能夠發揮創造力、隨機應變，把工作完成。不過，這一特點也會帶來不可預測性：即使出發點再好，人也會犯錯，有時還會導致系統失效。例如，一項針對大型網際網路服務的研究發現，運維人員修改配置是服務中斷的首要原因，而硬體故障（伺服器或網路）只在 10%～25% 的中斷中起了作用 ⁷⁰。

人們很容易把這類問題歸結為“人為錯誤”，並幻想透過更嚴格的流程和更嚴密的規則來約束人的行為，從而解決問題。然而，把錯誤歸咎於個人往往適得其反。所謂“人為錯誤”其實並不是事故的根本原因，而是人與技術共同構成的 社會技術系統（sociotechnical system）出了問題的一種症狀；身處其中的人只是在竭盡所能地完成工作 ⁷¹。複雜系統也常常表現出湧現行為，元件之間出人意料的互動同樣可能導致失效 ⁷²。

多種技術手段都能減小人為失誤的影響，包括：徹底測試（既包括手寫測試，也包括用大量隨機輸入進行的 屬性測試，property-based testing）³⁸；提供回滾機制，以便迅速撤銷配置變更；逐步釋出新程式碼；提供詳細而清晰的監控，以及用於診斷生產問題的可觀測性工具（參見“分散式系統的問題”）；精心設計介面，使“做正確的事”更加容易，“做錯誤的事”更加困難。

不過，這些措施都要投入時間和金錢。在日常經營的現實壓力下，組織往往優先考慮能夠創造收入的工作，而不是提高自身抵禦失誤能力的措施。如果必須在開發更多功能和開展更多測試之間選擇，許多組織選擇功能也不難理解。既然作出了這樣的選擇，當本可避免的錯誤不可避免地發生時，再去責怪犯錯的人便毫無道理——真正的問題在於組織如何設定優先順序。

越來越多的組織開始形成 無責覆盤（blameless postmortem） 的文化：事故發生後，鼓勵所有參與者毫無保留地講清事情經過，不必擔心受到懲罰；這樣，組織中的其他人才能從中學習，避免今後再發生類似問題 ⁷³。覆盤過程也許會發現，業務優先順序需要調整，長期遭到忽視的領域需要投入，相關人員的激勵機制需要改變，或者還有其他系統性問題需要提請管理層關注。

一般而言，調查事故時應當警惕過分簡單的答案。“鮑勃部署這項變更時應該更加小心”無助於解決問題，“我們必須用 Haskell 重寫後端”同樣如此。管理層應當抓住機會，從每天使用這個社會技術系統的一線人員那裡瞭解它究竟如何運作，再根據這些反饋採取措施加以改進 ⁷¹。

可伸縮性

系統今天能可靠執行，並不意味著將來也一定能夠可靠執行。系統退化的一個常見原因是負載增加：也許併發使用者從 10,000 人增長到了 100,000 人，或者從 100 萬人增長到了 1,000 萬人；也許系統現在處理的資料量比過去大得多。

可伸縮性（scalability） 是描述系統應對負載增長能力的術語。討論可伸縮性時，人們有時會說：“你又不是 Google 或 Amazon。別再擔心規模問題了，用關聯式資料庫就好。”這句話是否適用於你，要看你構建的究竟是哪一類應用。

如果你正在構建一個目前使用者不多的新產品，例如初創公司的新業務，壓倒一切的工程目標通常是讓系統儘可能簡單、靈活；這樣，隨著你逐漸瞭解客戶的需求，就能輕鬆修改和調整產品功能 ⁷⁸。在這種環境中，為將來或許才需要的假想規模憂心忡忡，只會適得其反：往好裡說，對可伸縮性的投入是白費力氣和過早最佳化；往壞裡說，它會把你困在一個不靈活的設計中，讓應用更難演化。

這是因為，可伸縮性並不是一個一維的標籤。簡單地說“X 是可伸縮的”或“Y 無法伸縮”毫無意義。討論可伸縮性，真正要考慮的是下面這些問題：

*“如果系統按某種方式增長，我們有哪些應對選項？” *“我們如何增加計算資源來承載額外負載？” *“按當前的增長預期，什麼時候會達到現有架構的極限？”

如果應用大受歡迎，因而需要處理不斷增長的負載，你會逐漸知道效能瓶頸在哪裡，也就清楚系統需要沿著哪些維度擴充套件。到那時，再開始認真考慮可伸縮性技術也不遲。

描述負載

首先，我們需要簡明地描述系統當前的負載；只有這樣，才能繼續討論增長問題（例如負載翻倍會發生什麼）。這種描述通常是某項吞吐量指標，例如服務每秒收到的請求數、每天新增多少 GB 資料，或每小時完成的購物車結賬次數。有時，我們關心的是某個變數的峰值，例如“案例研究：社交網路首頁時間線”中的同時線上使用者數。

負載往往還有其他統計特徵，它們同樣會影響訪問模式，進而影響系統對可伸縮性的要求。例如，你可能需要知道資料庫的讀寫比例、快取命中率，或每位使用者擁有的資料項數量（例如社交網路案例中的關注者人數）。有時平均情況最重要，有時瓶頸卻由少數極端情況主導。一切都取決於具體應用的細節。

描述好系統負載以後，就可以研究負載增加時會發生什麼。我們可以從兩個角度來看：

• 以某種方式增加負載，而系統資源（CPU、記憶體、網路頻寬等）保持不變，系統效能會受到什麼影響？
• 以某種方式增加負載，而你希望效能保持不變，需要增加多少資源？

通常，我們的目標是在滿足 SLA 效能要求（參見“響應時間指標的應用”）的同時，儘可能降低系統的執行成本。所需的計算資源越多，成本就越高。某些硬體也許比另一些更具價效比，而隨著新型硬體出現，這些因素也會隨時間變化。

如果資源增加一倍，就能在效能不變的情況下處理兩倍負載，我們稱系統具備 線性可伸縮性（linear scalability），這通常是一件好事。偶爾，由於規模經濟或峰值負載分佈得更加均勻，不到兩倍的資源也能處理兩倍的負載 ^{79 80}。更常見的情況是，成本增長得比線性更快，造成這種低效的原因可能有很多。例如，系統擁有大量資料時，即使寫入請求本身大小相同，處理一次寫入所需的工作也可能多於資料量較小時。

共享記憶體、共享磁碟與無共享架構

增加服務硬體資源最簡單的辦法，就是把服務遷移到更強大的機器上。單個 CPU 核心的速度已經不再顯著提高，但你仍可以買到（或在雲上租用）配有更多 CPU 核心、更大 RAM 和更多磁碟空間的機器。這種方法稱為 縱向擴充套件（vertical scaling），也叫 向上擴充套件（scaling up）。

在單臺機器上執行多個程序或執行緒，可以獲得並行處理能力。同一程序中的所有執行緒都能訪問同一塊 RAM，因此這種方法也稱為 共享記憶體架構（shared-memory architecture）。共享記憶體方案的問題在於，成本增長得比線性更快：硬體資源多一倍的高階機器，價格通常遠遠不止兩倍；受各種瓶頸限制，一臺規模翻倍的機器又往往處理不了兩倍的負載。

另一種方案是 共享磁碟架構（shared-disk architecture）：多臺機器分別擁有獨立的 CPU 和 RAM，卻把資料儲存在共同訪問的一組磁碟陣列中，機器與磁碟透過高速網路連線，例如 網路附加儲存（NAS） 或 儲存區域網路（SAN）。這種架構過去常用於本地部署的資料倉儲工作負載，但資源爭用和加鎖開銷限制了共享磁碟方案的可伸縮性 ⁸¹。

相比之下，無共享架構（shared-nothing architecture） ⁸²（也稱為 水平擴充套件（horizontal scaling） 或 向外擴充套件（scaling out））已經廣受歡迎。這種方案採用包含多個節點的分散式系統，每個節點都擁有自己的 CPU、RAM 和磁碟；節點之間的一切協調，都透過普通網路在軟體層完成。

無共享架構的優勢是：它有望實現線性伸縮；可以使用任何價效比最好的硬體，在雲端尤其如此；負載增減時更容易調整硬體資源；還可以把系統分佈到多個資料中心和地域，以獲得更強的容錯能力。缺點則是必須顯式進行分片（參見第 7 章），並且要面對分散式系統的全部複雜性（參見第 9 章）。

一些雲原生資料庫系統把儲存和事務執行拆分成不同的服務（參見“儲存與計算的分離”），讓多個計算節點共享同一項儲存服務。這個模型與共享磁碟架構有幾分相似，但避開了老式系統的可伸縮性問題：儲存服務提供的不是檔案系統（NAS）或塊裝置（SAN）抽象，而是一套針對資料庫具體需求設計的專用 API ⁸³。

可伸縮性原則

大規模系統的架構通常高度依賴具體應用，不存在一套通用、放之四海而皆準的可伸縮架構（俗稱 萬金油（magic scaling sauce））。例如，處理每秒 100,000 個請求、每個請求 1 kB 的系統，與每分鐘只處理 3 個請求、每個請求卻有 2 GB 的系統，看起來會截然不同——儘管二者的資料吞吐量同為 100 MB/s。

而且，適合某個負載水平的架構，多半應付不了十倍於此的負載。如果你正在開發一個快速增長的服務，很可能每當負載增加一個數量級，就需要重新考慮架構。應用需求本身也很可能不斷變化，因此提前為超過一個數量級之後的伸縮需求作規劃，通常並不值得。

可伸縮性有一項很好的通用原則：把系統拆分成較小的元件，使它們大體上能夠彼此獨立地執行。這是微服務（參見“微服務與無伺服器”）、分片（第 7 章）、流處理（第 12 章）和無共享架構背後的共同原則。不過，真正的挑戰在於判斷哪些東西應該放在一起，哪些東西應該拆開。其他書籍介紹了微服務的設計準則 ⁸⁴；本書則會在第 7 章討論無共享系統中的分片。

另一項好原則是，不要讓系統變得比必要的更加複雜。如果單機資料庫足以完成任務，它很可能比複雜的分散式配置更可取。自動伸縮系統會根據需求自動增加或移除資源，的確很酷；但如果負載相當可預測，手動伸縮的系統在運維中也許更少出現意外（參見“運維：自動/手動再平衡”）。由 5 個服務組成的系統比由 50 個服務組成的系統更簡單。優秀的架構通常務實地混合了多種方案。

可維護性

軟體不會磨損，也不會像機械裝置那樣發生材料疲勞，因此它不會以同樣的方式損壞。不過，應用程式的需求經常變化，軟體執行的環境也會變化（例如依賴項和底層平臺），而且軟體中總有缺陷需要修復。

眾所周知，軟體的大部分成本不在最初的開發階段，而在持續的維護階段，包括修復缺陷、保持系統正常執行、調查失效、適配新的平臺、為新的使用場景進行修改、償還技術債和新增新功能 ^{85 86}。

然而，維護工作本身也很困難。一個成功執行多年的系統，很可能仍在使用如今已經沒有多少工程師瞭解的過時技術，例如大型機和 COBOL 程式碼；隨著人員離開組織，關於系統為何如此設計、怎樣設計的組織知識可能已經丟失；維護者也許不得不修正前人留下的錯誤。而且，計算機系統往往與它所支撐的組織緊密交織在一起，這意味著維護這樣的 遺留（legacy） 系統既是人的問題，也是技術問題 ⁸⁷。

我們今天構建的每個系統，只要足夠有價值、能夠長期存續，終有一天都會成為遺留系統。為了儘量減輕以後維護軟體的人所承受的痛苦，我們設計軟體時就應該考慮維護問題。雖然無法事先斷定哪些決定會在未來製造維護難題，但本書會特別關注幾項具有廣泛適用性的原則：

可運維性（operability）

便於組織保持系統平穩執行。

簡單性（simplicity）

採用人們熟知且前後一致的模式和結構，避免不必要的複雜度，使新工程師也能輕鬆理解系統。

可演化性（evolvability）

便於工程師將來修改系統，在需求變化時調整和擴充套件系統，以適應事先沒有預料到的使用場景。

可運維性：讓運維更輕鬆

我們已經在“雲時代的運維”中討論過運維的作用，並且看到，要實現可靠運維，人的流程至少與軟體工具同等重要。事實上，有人認為：“良好的運維往往能繞開糟糕（或不完整）軟體的侷限，但即使軟體很好，糟糕的運維也無法讓它可靠執行” ⁶⁰。

大規模系統由成千上萬臺機器組成，純靠人工維護，成本高得難以承受，因此自動化必不可少。然而，自動化是一把雙刃劍：總會有一些邊緣情況（例如罕見的故障場景）需要運維團隊人工干預。自動化無法處理的恰恰是最複雜的問題，所以自動化程度越高，反而越需要一支技能 更強 的運維團隊來解決這些問題 ⁸⁸。

而且，自動化系統一旦出錯，往往比依靠運維人員手工完成某些操作的系統更難排查。因此，對可運維性而言，自動化並非總是越多越好。一定程度的自動化依然很重要，最佳平衡點則取決於具體應用和組織的情況。

良好的可運維性意味著讓日常工作更加輕鬆，使運維團隊能把精力集中在高價值的任務上。資料系統可以透過多種方式簡化日常工作 ⁸⁹：

• 允許監控工具檢查系統的關鍵指標，並支援可觀測性工具（參見“分散式系統的問題”），以便深入瞭解系統執行時的行為。許多商業工具和開源工具都能在這方面提供幫助 ⁹⁰。
• 避免依賴任何一臺機器，使機器可以下線維護，而整個系統仍能不間斷地執行。
• 提供良好的文件和易於理解的操作模型（“如果我做 X，就會發生 Y”）。
• 提供良好的預設行為，同時允許管理員在必要時覆蓋預設設定。
• 在適當的時候自動修復，同時也允許管理員在必要時手動控制系統狀態。
• 表現出可預測的行為，儘量避免出人意料。

簡單性：管理複雜度

小型軟體專案可以擁有簡單討喜、富有表現力的程式碼；但隨著專案不斷擴大，程式碼往往變得非常複雜，難以理解。這種複雜度拖慢了每一個需要在系統上工作的人，進一步增加了維護成本。一個陷入複雜泥潭的軟體專案有時被稱為 大泥球（big ball of mud） ⁹¹。

當複雜度使維護變得困難時，預算和進度安排往往都會超支。修改複雜軟體也更容易引入缺陷：系統越難理解和推理，開發人員就越容易忽略隱藏的假設、無意的後果和意外的互動 ⁶⁹。反過來，降低複雜度可以極大提高軟體的可維護性，因此簡單性應該成為我們構建系統時的一項關鍵目標。

簡單的系統更容易理解，因此我們應該儘可能用最簡單的辦法解決給定的問題。可惜，說起來容易，做起來卻很難。事物是否簡單往往取決於主觀品味，並不存在衡量簡單性的客觀標準 ⁹²。例如，一個系統可能把複雜實現隱藏在簡單介面背後，另一個系統的實現本身很簡單，卻向使用者暴露了更多內部細節——究竟哪一個更簡單？

人們曾嘗試把複雜度分成 本質複雜度（essential complexity） 和 偶然複雜度（accidental complexity） 兩類，以此對複雜度進行推理 ⁹³。按照這種思路，本質複雜度是應用程式問題領域所固有的，而偶然複雜度只因工具的侷限而產生。不幸的是，這種區分也有缺陷，因為隨著工具不斷演進，本質複雜度與偶然複雜度之間的界限也會發生變化 ⁹⁴。

管理複雜度最好的工具之一是 抽象（abstraction）。一個好的抽象可以把大量實現細節隱藏在乾淨、簡單易懂的外觀之下，也可以廣泛用於各種不同的應用。複用抽象不僅比一遍遍重新實現類似功能更加高效，也能帶來更高質量的軟體，因為抽象元件的質量得到改進，所有使用它的應用都會從中受益。

例如，高階程式語言是一種抽象，隱藏了機器碼、CPU 暫存器和系統呼叫。SQL 也是一種抽象，隱藏了複雜的磁碟和記憶體資料結構、其他客戶端發出的併發請求，以及崩潰後產生的不一致。當然，使用高階語言程式設計時，我們仍然用到了機器碼；只不過沒有 直接 使用它，因為程式語言的抽象讓我們不必考慮這些細節。

為了降低應用程式程式碼的複雜度，可以藉助 設計模式（design pattern）⁹⁵ 和 領域驅動設計（DDD） ⁹⁶ 等方法來構建抽象。本書討論的不是這類應用專用的抽象，而是資料庫事務、索引和事件日誌等通用抽象；你可以在它們之上構建應用。如果你想採用 DDD 等方法，也可以把它們實現於本書所述的基礎之上。

可演化性：讓變化更容易

系統的需求永遠不變，基本是不可能的。更可能的情況是，需求總在變化：你瞭解了新的事實，出現了事先未曾預料的使用場景，業務優先順序發生變化，使用者要求新功能，新平臺取代舊平臺，法律或監管要求改變，系統增長迫使架構發生變化，等等。

在組織流程方面，敏捷（Agile） 工作模式為適應變化提供了框架。敏捷社群還發展出了適合在頻繁變化的環境中開發軟體的技術工具和流程，例如測試驅動開發（TDD）和重構。本書則會尋找一些辦法，在由多個特性各異的應用程式或服務組成的系統層面上提高敏捷性。

修改資料系統、使其適應不斷變化的需求有多容易，與系統的簡單性和抽象密切相關：松耦合、簡單的系統通常比緊耦合、複雜的系統更容易修改。這個概念如此重要，因此我們用一個不同的詞來指代資料系統層面的敏捷性：可演化性（evolvability） ⁹⁷。

大型系統中的某些操作不可逆，因此必須極為謹慎地執行；這是讓變更變得困難的一個主要因素 ⁹⁸。例如，假設你要從一個資料庫遷移到另一個資料庫：如果新系統出了問題卻無法切回舊系統，風險就遠高於能夠輕鬆回退的情況。儘量減少不可逆性，可以提高系統的靈活性。

總結

本章考察了幾種非功能性需求：效能、可靠性、可伸縮性和可維護性。在討論這些主題的過程中，我們還遇到了貫穿全書都要用到的一些原則和術語。本章從社交網路首頁時間線的實現案例入手，說明了系統規模增大時會出現的部分挑戰。

我們討論了如何衡量效能（例如採用響應時間分位數）、如何衡量系統負載（例如採用吞吐量指標），以及怎樣在 SLA 中使用這些指標。可伸縮性與此密切相關：負載增加時，怎樣確保效能保持不變。我們看到了一些關於可伸縮性的通用原則，例如把一項任務拆分成彼此可以獨立執行的較小部分；後續章節還會深入探討實現可伸縮性的技術細節。

為了實現可靠性，可以採用容錯技術，使系統即使有某個元件（例如硬碟、機器或另一項服務）發生故障，仍能繼續提供服務。我們考察了可能發生的各種硬體故障，並把它們與軟體故障區分開來；軟體故障往往高度相關，因此更難處理。提高可靠性的另一方面，是增強系統抵禦人為失誤的能力；我們還看到，無責覆盤可以幫助組織從事故中學習。

最後，我們討論了可維護性的幾個方面，包括為運維團隊的工作提供支援、管理複雜度，以及讓應用程式的功能更容易隨時間演化。實現這些目標沒有簡單的答案，但採用人們熟知、能夠提供實用抽象的構件來搭建應用程式，確實會有所幫助。本書餘下部分將介紹一系列已經在實踐中證明頗有價值的構件。

參考文獻

3 資料模型與查詢語言

我的語言的邊界，意味著我的世界的邊界。

路德維希・維特根斯坦，《邏輯哲學論》（1922）

資料模型可能是軟體開發中最重要的部分了，因為它們的影響如此深遠：不僅僅影響著軟體的編寫方式，而且影響著我們的 解題思路。

多數應用使用層層疊加的資料模型構建。對於每層資料模型的關鍵問題是：它是如何用低一層資料模型來 表示 的？例如：

1. 作為一名應用開發人員，你觀察現實世界（裡面有人員、組織、貨物、行為、資金流向、感測器等），並採用物件或資料結構，以及操控那些資料結構的 API 來進行建模。那些結構通常是特定於應用程式的。
2. 當要儲存那些資料結構時，你可以利用通用資料模型來表示它們，如 JSON 或 XML 文件、關聯式資料庫中的表，或者圖中的頂點和邊。這些資料模型正是本章的主題。
3. 構建資料庫軟體的工程師決定如何以記憶體、磁碟或網路上的位元組來表示文件、關係或圖資料。這類表示形式使資料有可能以各種方式來查詢、搜尋、操縱和處理。我們將在 第 4 章 討論這些儲存引擎的設計。
4. 在更低的層次上，硬體工程師已經想出了使用電流、光脈衝、磁場或者其他東西來表示位元組的方法。

一個複雜的應用程式可能會有更多的中間層次，比如基於 API 的 API，不過基本思想仍然是一樣的：每個層都透過提供一個明確的資料模型來隱藏更低層次中的複雜性。這些抽象允許不同的人群有效地協作，例如資料庫廠商的工程師和使用資料庫的應用程式開發人員。

實踐中廣泛使用著幾種不同的資料模型，通常各有用途。某些型別的資料和查詢在一種模型中很容易表達，在另一種模型中卻很彆扭。本章將比較 關係模型（relational model）、文件模型（document model）、圖資料模型（graph data model）、事件溯源（event sourcing）和 資料框（dataframe），探討其中的權衡。我們還將簡要介紹操作這些模型的查詢語言，幫助你判斷何時應該使用哪種模型。

關係模型與文件模型

如今最廣為人知的資料模型或許是 SQL 所採用的關係模型，它由 Edgar Codd 於 1970 年提出 ³：資料被組織成 關係（relation，SQL 稱之為 表，table），每個關係都是由 元組（tuple，SQL 稱之為 行，row）構成的無序集合。

關係模型最初只是一項理論提議，當時許多人懷疑它能否得到高效實現。然而到了 20 世紀 80 年代中期，對於大多數需要儲存和查詢具有某種規則結構的資料的人來說，關聯式資料庫管理系統（RDBMS）和 SQL 已成為首選工具。幾十年過去，關係資料仍主導著許多資料管理場景，例如商業分析（參見 “星型與雪花型：分析模式”）。

多年來，資料儲存和查詢領域湧現過許多彼此競爭的方法。20 世紀 70 年代至 80 年代初，網狀模型（network model）和 層次模型（hierarchical model）是關係模型的主要對手，但最終都敗下陣來。物件資料庫在 20 世紀 80 年代末至 90 年代初興起後又銷聲匿跡；XML 資料庫於 21 世紀初出現，卻始終只在少數場景中得到採用。關係模型的每個競爭者都曾盛極一時，但無一長久 ⁴。反倒是 SQL 在關係模型這個核心之上不斷吸收其他資料型別，例如增加了對 XML、JSON 和圖資料的支援 ⁵。

到了 2010 年代，NoSQL 成了試圖撼動關聯式資料庫統治地位的最新流行語。NoSQL 並非某項特定技術，而是圍繞新資料模型、模式靈活性、可伸縮性和開源許可模式形成的一組寬泛理念。另一些資料庫則以 NewSQL 自居，力圖在保留傳統關聯式資料庫的資料模型和事務保證的同時，提供 NoSQL 系統的可伸縮性。NoSQL 和 NewSQL 的理念深刻影響了資料系統的設計；不過，隨著這些原則被廣泛吸收，兩個術語本身已漸漸淡出。

NoSQL 運動留下的一項持久影響，是通常以 JSON 表示資料的 文件模型（document model）廣受歡迎。這個模型最初由 MongoDB、Couchbase 等專用文件資料庫推廣，如今大多數關聯式資料庫也已加入 JSON 支援。關係表的模式常被視為嚴格而僵化，相比之下，JSON 文件被認為更加靈活。

文件資料與關係資料孰優孰劣，已經引發過大量爭論。下面來看看其中幾個關鍵問題。

物件關係不匹配

如今，大量應用開發使用物件導向的程式語言，這也引出了針對 SQL 資料模型的一項常見批評：資料若儲存在關係表中，就需要一個笨拙的轉換層，在應用程式碼中的物件與資料庫的表、行、列模型之間來回轉換。兩種模型之間的這種脫節，有時稱為 阻抗不匹配（impedance mismatch）。

物件關係對映（ORM）

ActiveRecord、Hibernate 等物件關係對映（ORM）框架減少了轉換層所需的樣板程式碼，但也時常遭到批評 ⁶。常見問題包括：

• ORM 本身很複雜，也無法徹底掩蓋兩種模型的差異，開發者最終仍得同時考慮資料的關係表示和物件表示。
• ORM 一般只用於開發 OLTP 應用（參見 “事務處理與分析的特徵”）。為了讓資料可供分析，資料工程師仍須面對底層的關係表示，因此採用 ORM 並不意味著關係模式的設計不再重要。
• 許多 ORM 只面向關係型 OLTP 資料庫。若組織還使用搜尋引擎、圖資料庫、NoSQL 系統等多種資料系統，ORM 提供的支援可能遠遠不夠。
• 有些 ORM 會自動生成關係模式，但生成的模式對直接訪問關係資料的使用者未必友好，在底層資料庫上也可能效率不佳。要定製 ORM 生成模式與查詢的方式，往往相當複雜，甚至會抵消採用 ORM 原本想獲得的好處。
• 使用 ORM 很容易在無意中寫出低效查詢，例如觸發 N+1 查詢問題（N+1 query problem）⁷。假設你要在頁面上顯示使用者評論列表：先用一條查詢取回 N 條評論，每條都含有作者 ID；為了顯示作者姓名，還要用這個 ID 查詢使用者表。手寫 SQL 時，你大概會直接在查詢中連線使用者表，讓每條評論連同作者姓名一起返回；使用 ORM 時，卻可能對 N 條評論逐條查詢使用者表，最終一共執行 N+1 條資料庫查詢。這比在資料庫內完成連線要慢得多。為避免這個問題，你可能必須明確要求 ORM 在獲取評論的同時一併取回作者資訊。

不過，ORM 也自有其優勢：

• 對適合關係模型的資料來說，持久化的關係表示與記憶體中的物件表示之間總要進行某種轉換，ORM 可以減少這類轉換所需的樣板程式碼。複雜查詢或許仍須繞開 ORM 處理，但簡單、重複的場景正適合交給它。
• 有些 ORM 可以快取資料庫查詢結果，從而減輕資料庫負載。
• ORM 還可以協助管理模式遷移和其他資料庫管理工作。

用於一對多關係的文件資料模型

並非所有資料都適合用關係形式表示。下面用一個例子看看關係模型的侷限。圖 3-1 展示了如何用關係模式表示一份簡歷（LinkedIn 個人資料）。整份資料由唯一識別符號 user_id 標識；first_name 和 last_name 等欄位對每位使用者只出現一次，因此可以建模為 users 表中的列。

大多數人的職業生涯中都不止有一份工作（即多個職位），每個人的教育經歷數量也不相同，聯絡方式更可能有任意多項。這些 一對多關係（one-to-many relationship）可以這樣表示：把職位、教育經歷和聯絡資訊分別放在單獨的表中，再透過外來鍵引用 users 表，如 圖 3-1 所示。

同一份資訊還可以表示為 JSON 文件，如 示例 3-1 所示。這種形式可能更為自然，也更貼近應用程式碼中的物件結構。

{
    "user_id": 251,
    "first_name": "Barack",
    "last_name": "Obama",
    "headline": "Former President of the United States of America",
    "region_id": "us:91",
    "photo_url": "/p/7/000/253/05b/308dd6e.jpg",
    "positions": [
        {"job_title": "President", "organization": "United States of America"},
        {"job_title": "US Senator (D-IL)", "organization": "United States Senate"}
    ],
    "education": [
        {"school_name": "Harvard University", "start": 1988, "end": 1991},
        {"school_name": "Columbia University", "start": 1981, "end": 1983}
    ],
    "contact_info": {
        "website": "https://barackobama.com",
        "twitter": "https://twitter.com/barackobama"
    }
}

一些開發者認為，JSON 模型減輕了應用程式碼與儲存層之間的阻抗不匹配。不過，正如我們將在 第 5 章 看到的，JSON 用作資料編碼格式時也有不少問題。沒有模式常被視為它的一項優勢，我們將在 “文件模型中的模式靈活性” 進一步討論。

與 圖 3-1 的多表模式相比，JSON 表示具有更好的 區域性（參見 “讀寫的資料區域性”）。在關係模型的例子中，要取回一份個人資料，要麼執行多次查詢（按 user_id 分別查詢每張表），要麼在 users 表及其下屬表之間進行繁瑣的多路連線 ⁸。而在 JSON 表示中，所有相關資訊都集中在一處，查詢既簡單又快捷。

個人資料與職位、教育經歷、聯絡資訊之間的一對多關係，在資料中形成了一棵樹；JSON 表示則明確呈現了這種樹狀結構（見 圖 3-2）。

正規化、反正規化與連線

前一節的 示例 3-1 用 ID 表示 region_id，而沒有直接寫成純文字字串 "Washington, DC, United States"。為什麼要這樣做？

如果使用者介面提供自由文字框讓使用者填寫地區，那麼把輸入直接存成文字字串很合理。不過，預先提供標準化的地理區域列表，讓使用者透過下拉選單或自動補全來選擇，也有不少好處：

• 所有個人資料中的格式和拼寫保持一致
• 避免同名地點造成歧義（若字串只有 “Washington”，究竟是指華盛頓特區，還是華盛頓州？）
• 便於更新——名稱只儲存在一處，將來如有變動（例如因政治事件而更改城市名稱），只改一處便能全域性生效
• 支援本地化——網站翻譯成其他語言時，可以本地化這份標準列表，讓地區名稱以瀏覽者使用的語言顯示
• 改善搜尋——例如，地區列表可以記錄華盛頓位於美國東海岸這一事實（單看 "Washington, DC" 字串無法得知），於是搜尋美國東海岸的人時也能匹配這份資料

選擇儲存 ID 還是文字字串，實質上是在決定是否 正規化（normalization）。使用 ID 時，資料更加正規化：對人有意義的資訊（如 Washington, DC 這段文字）只儲存一份，其他地方都用僅在資料庫內有意義的 ID 來引用它。若直接儲存文字，這段有意義的資訊就會複製到每條使用它的記錄中；這樣的表示便是 反正規化（denormalized）的。

ID 的好處在於，它本身對人沒有意義，因而永遠不必改變：即使 ID 所標識的資訊發生了變化，ID 仍可保持不變。凡是對人有意義的資訊，將來都有可能需要修改；一旦這類資訊被複制，所有冗餘副本就都得隨之更新。這不僅需要更多程式碼、寫入操作和磁碟空間，還會帶來不一致的風險——有些副本已經更新，另一些卻沒有。

正規化表示也有代價：每次顯示含有 ID 的記錄時，都要多做一次查詢，把 ID 解析成人能讀懂的資訊。在關係資料模型中，這項工作透過 連線（join）完成，例如：

SELECT users.*, regions.region_name
    FROM users
    JOIN regions ON users.region_id = regions.id
    WHERE users.id = 251;

文件資料庫既能儲存正規化資料，也能儲存反正規化資料，但人們往往把它與反正規化聯絡在一起。一方面，JSON 資料模型很容易加入額外的反正規化欄位；另一方面，許多文件資料庫對連線支援較弱，採用正規化表示很不方便。有些文件資料庫完全不支援連線，只能在應用程式碼中自行完成：先取回含有 ID 的文件，再發起第二次查詢，用 ID 找到另一個文件。MongoDB 也可以透過聚合管道中的 $lookup 運算元執行連線：

db.users.aggregate([
    { $match: { _id: 251 } },
    { $lookup: {
        from: "regions",
        localField: "region_id",
        foreignField: "_id",
        as: "region"
    } }
])

正規化的權衡

在簡歷示例中，region_id 欄位引用了標準化的地區集合，organization（任職的公司或政府機構）和 school_name（就讀的學校）卻只是字串。這是一種反正規化表示：許多人或許曾在同一家公司工作，但這些記錄並沒有透過 ID 關聯起來。

那麼，是否應該把組織和學校也建模為實體，讓個人資料引用其 ID，而不是直接寫下名稱？主張用 ID 引用地區的理由在這裡同樣成立。比如，假設除了名稱之外，我們還想顯示學校或公司的徽標：

• 採用反正規化表示時，每個人的個人資料都要包含徽標圖片的 URL。這樣固然讓 JSON 文件自給自足，但徽標一旦更換，就必須找出舊 URL 出現的每個地方並逐一更新，十分麻煩 ⁹。
• 採用正規化表示時，可以建立一個代表組織或學校的實體，只在其中儲存一次名稱、徽標 URL，也許再加上簡介、動態訊息等屬性。所有提及該組織的簡歷只引用其 ID，更新徽標便易如反掌。

一般來說，正規化資料寫入較快（因為只有一個副本），查詢卻較慢（因為需要連線）；反正規化資料通常讀取較快（連線更少），寫入代價卻更高（要更新更多副本，也佔用更多磁碟空間）。把反正規化看作一種衍生資料或許很有幫助（參見 “權威記錄系統與衍生資料”），因為你必須建立相應流程來更新那些冗餘的資料副本。

除了更新本身的成本，還要考慮程序在更新中途崩潰時，資料庫能否保持一致。支援原子事務的資料庫（參見 “原子性”）更容易維護一致性，但並非所有資料庫都能為跨多個文件的操作提供原子性。也可以利用流處理來保證一致性，我們將在 “保持系統同步” 討論這種方法。

正規化往往更適合讀寫都要迅速完成的 OLTP 系統；分析系統通常更適合反正規化資料，因為它們會批次更新，首要關心的是隻讀查詢的效能。此外，中小規模系統通常也更適合正規化資料模型：既不必費心維持多個副本的一致，執行連線的成本也還可以接受。不過到了超大規模，連線的代價就可能成為問題。

社交網路案例研究中的反正規化

在 “案例研究：社交網路首頁時間線” 中，我們比較了正規化表示（圖 2-1）和反正規化表示（預計算並物化的時間線）。在那個例子裡，連線 posts 與 follows 的成本太高，於是物化時間線充當了連線結果的快取；把新帖子扇出到關注者的時間線，正是維持這種反正規化表示一致的手段。

不過，X（原 Twitter）的物化時間線實際上並不儲存每條帖子的正文。每個條目只儲存帖子 ID、發帖使用者的 ID，以及少量用於識別轉帖和回覆的附加資訊 ¹¹。換句話說，它大致相當於預先算好了下面這條查詢的結果：

SELECT posts.id, posts.sender_id
    FROM posts
    JOIN follows ON posts.sender_id = follows.followee_id
    WHERE follows.follower_id = current_user
    ORDER BY posts.timestamp DESC
    LIMIT 1000

因此，每次讀取時間線時，服務仍要做兩次連線：按帖子 ID 取回正文，以及點贊數、回覆數等統計資訊；再按發帖使用者 ID 取回其使用者名稱、頭像和其他資料。這個把 ID 補全為人類可讀資訊的過程稱為 補全 ID（hydrating IDs），本質上就是在應用程式碼中完成連線 ¹¹。

預計算時間線之所以只存 ID，是因為 ID 所指向的資料變化很快：熱門帖子的點贊數和回覆數每秒都可能變化多次，有些使用者也會經常更換使用者名稱或頭像。時間線在展示時應呈現最新的點贊數和頭像，所以把這些資訊反正規化到物化時間線中並不合理，而且還會大幅增加儲存成本。

這個例子說明，讀取資料時需要執行連線，並不像有些說法所稱的那樣，會妨礙我們構建高效能、可伸縮的服務。補全帖子 ID 和使用者 ID 其實相當容易伸縮：這項工作很適合並行執行，而且成本既不取決於你關注了多少賬戶，也不取決於有多少人關注你。

如果要判斷應用中的某項資料是否應該反正規化，社交網路案例表明答案並不顯而易見：可伸縮性最好的方案，可能是把一部分資料反正規化，同時讓另一部分保持正規化。你必須仔細權衡資訊的變化頻率與讀寫成本；而成本又可能由極端情況主導，例如社交網路中關注或被關注人數異常多的使用者。正規化與反正規化本身無所謂好壞，不過是在讀寫效能和實現成本之間作取捨。

多對一與多對多關係

圖 3-1 中的 positions 和 education 是一對多（或一對少）關係：一份簡歷有多個職位，但每個職位只屬於一份簡歷。相比之下，region_id 欄位表示 多對一（many-to-one）關係：許多人住在同一個地區，而我們假設任一時刻每個人只住在一個地區。

如果進一步把組織和學校建模為實體，讓簡歷透過 ID 引用它們，就會出現 多對多（many-to-many）關係：一個人曾在多個組織任職，一個組織也有多名現任或前任員工。在關係模型中，這類關係通常用 關聯表（associative table，也稱 連線表，join table）表示，如 圖 3-3 所示：每個職位把一個使用者 ID 與一個組織 ID 關聯起來。

多對一和多對多關係很難塞進一個自包含的 JSON 文件，它們更適合正規化表示。示例 3-2 給出了文件模型中的一種方案，圖 3-4 則以圖示說明：每個虛線框內的資料可以組成一份文件，但指向組織和學校的連結最好表示為對其他文件的引用。

{
    "user_id": 251,
    "first_name": "Barack",
    "last_name": "Obama",
    "positions": [
        {"start": 2009, "end": 2017, "job_title": "President", "org_id": 513},
        {"start": 2005, "end": 2008, "job_title": "US Senator (D-IL)", "org_id": 514}
    ],
    ...
}

多對多關係通常需要從“兩個方向”查詢：既要找出某人任職過的所有組織，也要找出曾在某組織任職的所有人。一種做法是在關係兩端都儲存 ID 引用：簡歷列出此人任職過的各個組織 ID，組織文件也列出提及該組織的簡歷 ID。由於同一關係儲存了兩份，這是一種反正規化表示，兩邊可能彼此不一致。

正規化表示只在一處儲存關係，再依靠 二級索引（secondary index；將在 第 4 章 討論）從兩個方向高效查詢。圖 3-3 的關係模式中，可以讓資料庫分別為 positions 表的 user_id 列和 org_id 列建立索引。

在 示例 3-2 的文件模型中，資料庫則需要索引 positions 陣列內各物件的 org_id 欄位。許多文件資料庫以及支援 JSON 的關聯式資料庫，都能為文件內部的值建立這種索引。

星型與雪花型：分析模式

資料倉儲（參見 “資料倉儲”）通常採用關係模型，其表結構有幾種廣泛使用的慣例：星型模式（star schema）、雪花模式（snowflake schema）、維度建模（dimensional modeling）¹²，以及 一張大表（OBT）。這些結構針對業務分析師的需求進行了最佳化，ETL 過程則負責把事務型系統中的資料轉換成這種模式。

圖 3-5 中的示例模式，可能出現在一家食品零售商的資料倉儲中。模式的中心是所謂的 事實表（fact table；本例中名為 fact_sales）。事實表的每一行代表在特定時間發生的事件；在這裡，每行代表客戶購買了一件產品。如果分析的是網站流量而不是零售量，那麼每行可能代表一次頁面瀏覽或一次使用者點選。

通常會把每項事實記錄為獨立事件，因為這樣能為日後的分析保留最大的靈活性。不過，這也意味著事實表可能變得極其龐大。大型企業的資料倉儲可能儲存著許多 PB 的交易歷史，其中大部分都以事實表表示。

事實表中的一些列是屬性，例如產品的售價和從供應商處購入的成本（據此可以計算利潤率）。另一些列是指向其他表的外來鍵引用，這些表稱為 維度表（dimension table）。由於事實表的每一行表示一個事件，各個維度便代表事件發生的物件、內容、地點、時間、方式和原因。

例如，圖 3-5 中的一個維度是售出的產品。dim_product 表中的每一行代表一種待售產品，包括庫存單位（SKU）、產品描述、品牌名稱、類別、脂肪含量、包裝尺寸等。fact_sales 表的每一行都用外來鍵表明該筆交易售出了哪種產品。查詢往往要連線多個維度表。

甚至日期和時間也常用維度表表示，以便編碼公共假期等額外資訊，讓查詢可以區分節假日與平日的銷售情況。

圖 3-5 展示的便是星型模式。這個名稱源自表關係的視覺化形狀：事實表位於中央，周圍環繞著維度表；連線這些表的線條就像星星的光芒。

這個模板的變體稱為 雪花模式，其中的維度會進一步分解成子維度。例如，可以為品牌和產品類別分別建表，讓 dim_product 的每一行以外來鍵引用品牌與類別，而不再把它們作為字串直接存入 dim_product 表。雪花模式比星型模式更正規化，但星型模式通常更受青睞，因為分析師使用起來更簡單 ¹²。

典型資料倉儲中的表通常非常寬：事實表往往超過 100 列，有時甚至有數百列。維度表也可能很寬，因為它們會收錄所有可能與分析相關的後設資料。例如，dim_store 表可能記錄每家商店提供哪些服務、是否設有店內麵包房、店面面積、首次開業日期、最近一次改造時間，以及離最近的高速公路有多遠，等等。

星型模式和雪花模式主要由多對一關係構成，例如許多筆銷售對應同一種產品、同一家商店。這些關係表現為事實表指向維度表的外來鍵，或維度表指向子維度表的外來鍵。原則上也可以存在其他型別的關係，但為了簡化查詢，通常會把它們反正規化。例如，顧客一次買了幾種不同產品時，這筆多商品交易不會得到顯式表示；事實表只是為每件商品各存一行，而這些事實恰好具有相同的顧客 ID、商店 ID 和時間戳。

有些資料倉儲模式更進一步，完全省去維度表，把維度資訊放進事實表的反正規化列中——實質上就是預先計算事實表與維度表的連線。這種方法稱為 一張大表（OBT）；它雖然佔用更多儲存空間，有時卻能讓查詢更快 ¹³。

在分析場景中，這樣反正規化通常不成問題，因為資料往往是一份不會再改變的歷史記錄（偶爾糾正錯誤除外）。反正規化在 OLTP 系統中帶來的資料一致性問題和寫入開銷，在分析系統裡沒有那麼緊迫。

何時使用哪種模型

支援文件資料模型的主要論據是模式靈活性、因區域性而擁有更好的效能，以及對於某些應用程式而言，它更接近應用程式使用的物件模型。關係模型則以更好地支援連線、多對一和多對多關係作為回應。下面逐一詳細考察這些論點。

如果應用程式中的資料具有類似文件的結構（即一對多關係樹，通常一次性載入整棵樹），那麼使用文件模型可能是個好主意。把類似文件的結構 拆散 到多個表中（如 圖 3-1 中的 positions、education 和 contact_info），可能導致繁瑣的模式和不必要的複雜應用程式程式碼。

文件模型有一定的侷限性：例如，不能直接引用文件中的巢狀專案，而是需要說“使用者 251 的職位列表中的第二項”。如果確實需要引用巢狀專案，關係模型更合適，因為任何專案都能透過自身 ID 被直接引用。

有些應用允許使用者自行安排專案順序。例如，在待辦事項清單或問題跟蹤器中，使用者可以拖放任務來重新排序。文件模型很適合這類應用，只需把專案（或專案 ID）按順序存入 JSON 陣列即可。關聯式資料庫沒有表示這種可重新排序列表的標準方式，只能藉助各種技巧：按整數列排序（在中間插入時需要重新編號）、用 ID 構成連結串列，或者使用分數索引 ^{14 15 16}。

文件模型中的模式靈活性

大多數文件資料庫以及關聯式資料庫中的 JSON 支援，都不會強制文件中的資料採用何種模式。關聯式資料庫的 XML 支援通常帶有可選的模式驗證。沒有模式意味著可以向文件中新增任意鍵和值；讀取時，客戶端也無法確定文件究竟會包含哪些欄位。

文件資料庫有時稱為 無模式（schemaless），但這具有誤導性，因為讀取資料的程式碼通常假定某種結構——即存在隱式模式，只是不由資料庫強制執行 ¹⁷。一個更準確的術語是 讀時模式（schema-on-read，資料結構是隱含的，只有讀取時才會解釋），與之相對的是 寫時模式（schema-on-write，關聯式資料庫的傳統做法：模式是明確的，資料庫確保寫入的所有資料都符合模式）¹⁸。

讀時模式類似於程式語言中的動態（執行時）型別檢查，而寫時模式類似於靜態（編譯時）型別檢查。就像靜態與動態型別檢查孰優孰劣一直爭議不斷 ¹⁹，資料庫是否應該強制執行模式也是個見仁見智的問題，通常並沒有絕對的對錯。

當應用程式想要改變資料格式時，兩種方法的區別尤其明顯。例如，假設原先把每位使用者的全名儲存在一個欄位中，現在想把名和姓分開儲存 ²⁰。在文件資料庫中，只需開始寫入帶有新欄位的文件，並在應用程式中加入程式碼來處理舊文件即可。例如：

if (user && user.name && !user.first_name) {
    // 2023 年 12 月 8 日之前寫入的文件沒有 first_name
    user.first_name = user.name.split(" ")[0];
}

這種方法的缺點是，應用中每個讀取資料庫的部分，從此都必須處理可能在很久以前寫入的舊格式文件。另一方面，在寫時模式資料庫中，通常會執行下面這樣的 遷移：

ALTER TABLE users ADD COLUMN first_name text DEFAULT NULL;
UPDATE users SET first_name = split_part(name, ' ', 1); -- PostgreSQL
UPDATE users SET first_name = substring_index(name, ' ', 1); -- MySQL

在大多數關聯式資料庫中，即使面對大表，新增帶預設值的列也又快又穩妥。不過，在大表上執行 UPDATE 可能很慢，因為每一行都必須重寫；其他模式操作（例如修改某列的資料型別）通常也需要複製整張表。

有多種工具可以在後臺完成這類模式變更而無須停機 ^{21 22 23 24}，但在大型資料庫上進行這種遷移，運維起來依然頗具挑戰。要避開複雜遷移，可以只快速新增一個預設值為 NULL 的 first_name 列，然後在讀取時填充它，就像使用文件資料庫那樣。

如果集合中的專案因為某種原因並不都具有相同結構（即資料是異構的），讀時模式更具優勢。例如：

• 存在許多不同型別的物件，將每種物件分別放進一張表並不現實。
• 資料結構由你無法控制、且隨時可能改變的外部系統決定。

在上述情況下，模式可能弊大於利，無模式文件反而是更自然的資料模型。但是，如果所有記錄都應具有相同結構，那麼模式就是記錄並強制這種結構的有效機制。我們將在 第 5 章 更詳細地討論模式和模式演化。

讀寫的資料區域性

文件通常以單個連續字串的形式儲存，編碼為 JSON、XML 或其二進位制變體（如 MongoDB 的 BSON）。如果應用程式經常需要訪問整個文件（例如把它渲染到網頁上），這種 儲存區域性 會帶來效能優勢。如果資料像 圖 3-1 那樣分散在多張表中，就需要多次查詢索引才能檢索完整，可能產生更多磁碟尋道並花費更長時間。

區域性優勢只適用於同時需要文件絕大部分內容的情況。即使只訪問大型文件的一小部分，資料庫通常也要載入整個文件，這會造成浪費；更新時一般還要重寫整個文件。因此，通常建議讓文件保持較小，並避免頻繁地對文件做小幅更新。

不過，為了區域性而把相關資料儲存在一起，並非文件模型的專利。例如，Google 的 Spanner 資料庫在關係模型中也提供同樣的區域性屬性，允許模式宣告某張表的行應交錯（巢狀）在父表之中 ²⁵。Oracle 也用名為 多表索引叢集表（multi-table index cluster table）的功能提供類似能力 ²⁶。由 Google Bigtable 推廣、並被 HBase 和 Accumulo 等系統採用的 寬列（wide-column）資料模型，則以 列族（column family）概念達到相似的區域性管理目的 ²⁷。

文件的查詢語言

關聯式資料庫和文件資料庫的另一個區別，在於查詢所用的語言或 API。大多數關聯式資料庫使用 SQL，文件資料庫則五花八門：有些只允許按主鍵進行鍵值訪問，有些還提供二級索引來查詢文件內部的值，還有些配有功能豐富的查詢語言。

XML 資料庫通常使用 XQuery 和 XPath；它們支援包括跨文件連線在內的複雜查詢，還能把結果格式化為 XML ²⁸。JSON Pointer ²⁹ 和 JSONPath ³⁰ 則為 JSON 提供了與 XPath 相當的功能。

MongoDB 的聚合管道就是一種面向 JSON 文件集合的查詢語言；我們在 “正規化、反正規化與連線” 中已經見過它用於連線的 $lookup 運算元。

再看一個例子來體會這種語言，這次考察分析中尤為常見的聚合。假設你是一名海洋生物學家，每當在海中看到動物，就向資料庫新增一條觀察記錄。現在你想生成一份報告，說明每個月觀察到多少條鯊魚。在 PostgreSQL 中，可以像這樣表述查詢：

SELECT date_trunc('month', observation_timestamp) AS observation_month, ❶
    sum(num_animals) AS total_animals
FROM observations
WHERE family = 'Sharks'
GROUP BY observation_month;

❶：date_trunc('month', timestamp) 函式確定 timestamp 所在的日曆月份，並返回代表該月起點的另一個時間戳。換句話說，它把時間戳向下舍入到最近的月份。

這個查詢首先過濾觀察記錄，只保留鯊魚科的物種；然後按觀察發生的日曆月份分組；最後，把該月所有觀察記錄中的動物數量相加。同一個查詢可以用 MongoDB 的聚合管道表示如下：

db.observations.aggregate([
    { $match: { family: "Sharks" } },
    { $group: {
    _id: {
        year: { $year: "$observationTimestamp" },
        month: { $month: "$observationTimestamp" }
    },
    totalAnimals: { $sum: "$numAnimals" }
    } }
]);

聚合管道語言的表達能力與 SQL 的一個子集相當，不過它採用基於 JSON 的語法，而不是 SQL 那種接近英語句式的語法；這種差異或許只是口味問題。

文件和關聯式資料庫的融合

文件資料庫和關聯式資料庫最初採用截然不同的資料管理方法，但隨著時間推移，兩者變得越來越相似 ³¹。關聯式資料庫增加了對 JSON 型別和查詢運算元的支援，也能夠為文件內部的屬性建立索引；MongoDB、Couchbase、RethinkDB 等文件資料庫，則增加了連線、二級索引和宣告式查詢語言。

這種融合對應用程式開發人員來說是件好事，因為關係模型和文件模型能夠在同一個資料庫中結合使用時，最能發揮各自所長。許多文件資料庫需要以關係模型的方式引用其他文件，許多關聯式資料庫也有些部分會受益於模式靈活性。關係模型與文件模型的混合是一種強大的組合。

圖資料模型

如我們之前所見，關係的型別是區分不同資料模型的一項重要特徵。如果應用程式中的關係大多是一對多關係（樹狀結構資料），而記錄之間很少存在其他關係，那麼文件模型是合適的。

但是，如果多對多關係在資料中十分常見呢？關係模型可以處理簡單的多對多關係，但隨著資料之間的連線變得越來越複雜，將資料建模為圖就顯得更加自然。

一個圖由兩種物件組成：頂點（vertices，也稱為 節點，即 nodes，或 實體，即 entities）和 邊（edges，也稱為 關係，即 relationships，或 弧，即 arcs）。多種資料都可以建模為圖，典型的例子包括：

社交圖

頂點是人，邊表示哪些人相互認識。

網頁圖

頂點是網頁，邊表示指向其他頁面的 HTML 連結。

道路或鐵路網路

頂點是交叉點，邊表示它們之間的道路或鐵路線。

可以把許多眾所周知的演算法運用到這些圖上。例如，地圖導航應用會搜尋道路網路中兩點之間的最短路徑；PageRank 可以用在網頁圖上，判斷網頁的流行程度，進而決定它在搜尋結果中的排名 ³²。

圖可以用幾種不同的方式表示。在 鄰接表（adjacency list）模型中，每個頂點都儲存與它相隔一條邊的相鄰頂點 ID。另一種方式是 鄰接矩陣（adjacency matrix）：這是一個二維陣列，每行、每列各對應一個頂點；行頂點與列頂點之間沒有邊時，值為 0，有邊時則為 1。鄰接表適合圖遍歷，鄰接矩陣則適合機器學習（參見 “資料框、矩陣與陣列”）。

在剛才給出的例子中，圖裡的所有頂點都表示同一種事物，分別是人、網頁或道路交叉口。不過，圖並不侷限於這種 同質（homogeneous）資料：圖還有一項同樣強大的用途，就是以一致的方式在單個資料庫中儲存截然不同的物件。例如：

• Facebook 維護著一個包含許多不同型別頂點和邊的圖：頂點表示人、地點、事件、簽到和使用者評論；邊表示哪些人是朋友、某次簽到發生在哪裡、誰評論了哪篇帖子、誰參加了哪場活動，等等 ³³。
• 搜尋引擎用知識圖譜來記錄查詢中經常出現的組織、人物、地點等實體的事實 ³⁴。這些資訊來自對網站的抓取與文字分析；Wikidata 等網站也會以結構化形式釋出圖資料。

有幾種不同但彼此相關的方式，可以用來組織和查詢圖中的資料。本節將討論 屬性圖（property graph）模型（由 Neo4j、Memgraph、KùzuDB ³⁵ 等系統實現 ³⁶）和 三元組儲存（triple store）模型（由 Datomic、AllegroGraph、Blazegraph 等系統實現）。兩種模型的表達能力相當接近，Amazon Neptune 等圖資料庫還同時支援二者。

我們還將介紹四種圖查詢語言（Cypher、SPARQL、Datalog 和 GraphQL），以及 SQL 對圖查詢的支援。其他圖查詢語言還有 Gremlin 等 ³⁷，不過這裡選取的幾種已足以給出一幅有代表性的全景。

為了說明這些語言和模型，本節將以 圖 3-6 為貫穿全節的例子。它可以取自社交網路或家譜資料庫：圖中有兩個人，來自愛達荷州的 Lucy 和來自法國聖洛的 Alain。他們已經結婚，現居倫敦。每個人和每個地點都表示為頂點，彼此之間的關係則表示為邊。這個例子將展示一些在圖資料庫中很容易、在其他模型中卻很難表達的查詢。

屬性圖

在 屬性圖（也稱 帶標籤屬性圖，labeled property graph）模型中，每個頂點包括：

• 唯一識別符號
• 一個標籤（字串），描述該頂點所表示的物件型別
• 一組出邊
• 一組入邊
• 一組屬性（鍵值對）

每條邊包括：

• 唯一識別符號
• 邊的起點（尾部頂點，即 tail vertex）
• 邊的終點（頭部頂點，即 head vertex）
• 一個標籤，描述兩個頂點之間的關係型別
• 一組屬性（鍵值對）

可以把圖儲存看成兩個關係表：一張儲存頂點，另一張儲存邊，如 示例 3-3 所示（該模式使用 PostgreSQL 的 jsonb 資料型別儲存每個頂點或每條邊的屬性）。每條邊都儲存頭部頂點和尾部頂點；如果想找出某個頂點的所有入邊或出邊，可以分別按 head_vertex 或 tail_vertex 查詢 edges 表。

CREATE TABLE vertices (
    vertex_id integer PRIMARY KEY,
    label text,
    properties jsonb
);

CREATE TABLE edges (
    edge_id integer PRIMARY KEY,
    tail_vertex integer REFERENCES vertices (vertex_id),
    head_vertex integer REFERENCES vertices (vertex_id),
    label text,
    properties jsonb
);

CREATE INDEX edges_tails ON edges (tail_vertex);
CREATE INDEX edges_heads ON edges (head_vertex);

這個模型有幾個重要特點：

1. 任何頂點都可以透過邊連線到任何其他頂點。沒有模式限制哪些事物可以關聯，哪些不可以。
2. 給定任意頂點，都能高效地找到它的入邊和出邊，從而雙向 遍歷 圖——即沿著一系列頂點構成的路徑前後移動。（這正是 示例 3-3 同時為 tail_vertex 和 head_vertex 列建立索引的原因。）
3. 為不同型別的頂點和關係使用不同的標籤，就可以在一個圖中儲存多種不同的資訊，同時仍保持清晰的資料模型。

邊表就像我們在 “多對一與多對多關係” 看到的多對多關聯表（連線表），只不過經過了泛化，可以在同一張表中儲存許多不同型別的關係。標籤和屬性也可以建立索引，以便高效查詢具有某種屬性的頂點或邊。

這些特性為資料建模提供了很大的靈活性，如 圖 3-6 所示。圖中有一些傳統關係模式難以表達的事物，例如不同國家採用不同的行政區劃結構（法國有 省 和 大區，美國有 縣 和 州）、國中之國這樣的歷史怪事（暫且忽略主權國家與民族錯綜複雜的關係），以及粒度不一的資料（Lucy 現在的住所具體到城市，而出生地只記錄到州）。

可以想象，這個圖還能夠擴充套件出關於 Lucy、Alain 或其他人的許多事實。例如，可以用它表示食物過敏：為每種過敏原增加一個頂點，用人與過敏原之間的邊表示過敏，再把過敏原連線到一組說明哪些食物含有哪些物質的頂點。這樣就能寫一條查詢，找出每個人可以安全食用的東西。圖在可演化性方面很有優勢：隨著應用程式不斷增加功能，可以輕鬆擴充套件圖來適應資料結構的變化。

Cypher 查詢語言

Cypher 是屬性圖的查詢語言，最初為 Neo4j 圖資料庫而創，後來以 openCypher 之名發展為開放標準 ³⁸。除了 Neo4j，Memgraph、KùzuDB ³⁵、Amazon Neptune、Apache AGE（資料儲存在 PostgreSQL 中）等系統也支援 Cypher。它以電影《駭客帝國》中的角色命名，與密碼學中的密碼並無關係 ³⁹。

示例 3-4 展示了把 圖 3-6 左側部分插入圖資料庫的 Cypher 查詢，圖的其餘部分也可以用同樣方式加入。每個頂點都有一個 usa 或 idaho 之類的符號名稱。該名稱不會存入資料庫，只在查詢內部用來建立頂點之間的邊。箭頭記法 (idaho) -[:WITHIN]-> (usa) 會建立一條標籤為 WITHIN 的邊，以 idaho 為尾節點、usa 為頭節點。

CREATE
    (namerica :Location {name:'North America', type:'continent'}),
    (usa :Location {name:'United States', type:'country' }),
    (idaho :Location {name:'Idaho', type:'state' }),
    (lucy :Person {name:'Lucy' }),
    (idaho) -[:WITHIN ]-> (usa) -[:WITHIN]-> (namerica),
    (lucy) -[:BORN_IN]-> (idaho)

把 圖 3-6 的所有頂點和邊加入資料庫後，就可以提出一些有趣的問題。例如：找出所有從美國移居歐洲的人的姓名。更確切地說，我們要找出同時具有一條指向美國境內某地的 BORN_IN 邊，以及一條指向歐洲境內某地的 LIVES_IN 邊的頂點，並返回這些頂點的 name 屬性。

示例 3-5 展示了如何用 Cypher 表述這個查詢。MATCH 子句使用同樣的箭頭記法在圖中尋找模式：(person) -[:BORN_IN]-> () 匹配由一條 BORN_IN 邊相連的任意兩個頂點；這條邊的尾部頂點繫結到變數 person，頭部頂點則不命名。

MATCH
    (person) -[:BORN_IN]-> () -[:WITHIN*0..]-> (:Location {name:'United States'}),
    (person) -[:LIVES_IN]-> () -[:WITHIN*0..]-> (:Location {name:'Europe'})
RETURN person.name

這條查詢可以這樣解讀：

找出滿足以下 兩個 條件的所有頂點（稱為 person）：

1. person 頂點有一條指向某個頂點的 BORN_IN 出邊。從那裡沿著一系列 WITHIN 出邊前進，最終能到達一個型別為 Location、name 屬性為 "United States" 的頂點。
2. 同一個 person 頂點還有一條 LIVES_IN 出邊。沿著該邊，再沿一系列 WITHIN 出邊前進，最終能到達一個型別為 Location、name 屬性為 "Europe" 的頂點。

對每個這樣的 person 頂點，返回其 name 屬性。

執行這條查詢有幾種可行的方式。上面的描述暗示，可以先掃描資料庫中的所有人，逐一檢查出生地和居住地，只返回符合條件的人。

等價地，也可以從兩個 Location 頂點開始反向查詢。如果 name 屬性建有索引，就能高效找到代表美國和歐洲的兩個頂點。然後沿著所有 WITHIN 入邊，分別找出美國和歐洲境內的所有地點（州、地區、城市等）。最後，再沿這些地點頂點的 BORN_IN 或 LIVES_IN 入邊找到相應的人。

SQL 中的圖查詢

示例 3-3 表明，可以在關聯式資料庫中表示圖資料。但是，如果圖資料採用關係結構儲存，還能使用 SQL 查詢它嗎？

答案是肯定的，但有些困難。圖查詢每遍歷一條邊，實際上都相當於與 edges 表連線一次。在關聯式資料庫中，通常事先就知道查詢需要哪些連線；而在圖查詢中，找到目標頂點之前可能要遍歷數量不定的邊，也就是說，連線次數無法預先確定。

在我們的例子中，Cypher 查詢裡的 () -[:WITHIN*0..]-> () 模式便是如此。一個人的 LIVES_IN 邊可能指向任何層級的地點：街道、城市、區、地區、州，等等。城市可能 WITHIN 某個地區，地區又 WITHIN 某個州，州再 WITHIN 某個國家。LIVES_IN 邊可能直接指向待查地點，也可能還隔著好幾層地點層次。

Cypher 用 :WITHIN*0.. 非常簡潔地表達了這一點：“沿著 WITHIN 邊走零次或多次”。它類似於正規表示式中的 * 運算子。

從 SQL:1999 開始，可以用所謂的 遞迴公用表表示式（recursive common table expression，WITH RECURSIVE 語法）在查詢中表示長度可變的遍歷路徑。示例 3-6 用這種技術在 SQL 中寫出了同一個查詢——查詢從美國移居歐洲者的姓名。只不過，與 Cypher 相比，它的語法十分笨拙。

WITH RECURSIVE

    -- in_usa 是美國境內所有位置的頂點 ID 集合
    in_usa(vertex_id) AS (
        SELECT vertex_id FROM vertices
            WHERE label = 'Location' AND properties->>'name' = 'United States' ❶
      UNION
        SELECT edges.tail_vertex FROM edges ❷
            JOIN in_usa ON edges.head_vertex = in_usa.vertex_id
            WHERE edges.label = 'within'
    ),

    -- in_europe 是歐洲境內所有位置的頂點 ID 集合
    in_europe(vertex_id) AS (
        SELECT vertex_id FROM vertices
            WHERE label = 'location' AND properties->>'name' = 'Europe' ❸
      UNION
        SELECT edges.tail_vertex FROM edges
            JOIN in_europe ON edges.head_vertex = in_europe.vertex_id
            WHERE edges.label = 'within'
    ),

    -- born_in_usa 是所有在美國出生的人的頂點 ID 集合
    born_in_usa(vertex_id) AS ( ❹
        SELECT edges.tail_vertex FROM edges
            JOIN in_usa ON edges.head_vertex = in_usa.vertex_id
            WHERE edges.label = 'born_in'
    ),

    -- lives_in_europe 是所有居住在歐洲的人的頂點 ID 集合
    lives_in_europe(vertex_id) AS ( ❺
        SELECT edges.tail_vertex FROM edges
            JOIN in_europe ON edges.head_vertex = in_europe.vertex_id
            WHERE edges.label = 'lives_in'
    )

    SELECT vertices.properties->>'name'
    FROM vertices
    -- 連線以找到那些既在美國出生 *又* 居住在歐洲的人
    JOIN born_in_usa ON vertices.vertex_id = born_in_usa.vertex_id ❻
    JOIN lives_in_europe ON vertices.vertex_id = lives_in_europe.vertex_id;

❶：首先找到 name 屬性為 "United States" 的頂點，把它作為 in_usa 頂點集的第一個元素。

❷：從 in_usa 集合中的頂點出發，沿所有 within 入邊反向前進，把到達的頂點加入同一集合，直到所有 within 入邊都被訪問。

❸：從 name 屬性為 "Europe" 的頂點出發，執行同樣的操作，建立 in_europe 頂點集。

❹：對 in_usa 集合中的每個頂點，沿 born_in 入邊找到出生在美國境內某地的人。

❺：同理，對 in_europe 集合中的每個頂點，沿 lives_in 入邊找到居住在歐洲的人。

❻：最後，透過連線讓“出生在美國的人”與“居住在歐洲的人”兩個集合取交集。

同一個查詢用 Cypher 只需 4 行，用 SQL 卻要寫 31 行，這恰恰說明選對資料模型和查詢語言會帶來多大差別。而這還只是開始；還有更多細節需要考慮，例如如何處理環，以及選擇廣度優先還是深度優先遍歷 ⁴⁰。

Oracle 為遞迴查詢提供了另一套 SQL 擴充套件，稱為 層次查詢（hierarchical query）⁴¹。

不過，情況可能正在改善：在本書寫作時，已有計劃把一種名為 GQL 的圖查詢語言加入 SQL 標準 ^{42 43}，其語法借鑑了 Cypher、GSQL ⁴⁴ 和 PGQL ⁴⁵。

三元組儲存與 SPARQL

三元組儲存模型大體上與屬性圖模型相同，只是用不同的詞彙描述同樣的思想。不過它仍然值得單獨討論，因為三元組儲存有許多現成的工具和語言，可以成為構建應用程式時的寶貴補充。

在三元組儲存中，所有資訊都以非常簡單的三部分陳述來儲存：（主語、謂語、賓語）。例如，在三元組（Jim、喜歡、香蕉）中，Jim 是主語，喜歡 是謂語（動詞），香蕉 是賓語。

三元組的主語相當於圖中的一個頂點，賓語則是以下兩者之一：

1. 字串、數字等原始資料型別的值。這時，三元組的謂語和賓語相當於主語頂點上某項屬性的鍵和值。例如，沿用 圖 3-6 的例子，三元組（lucy、birthYear、1989）相當於頂點 lucy 擁有屬性 {"birthYear": 1989}。
2. 圖中的另一個頂點。這時，謂語相當於圖中的邊，主語是尾部頂點，賓語是頭部頂點。例如，在（lucy、marriedTo、alain）中，lucy 和 alain 都是頂點，謂語 marriedTo 則是連線二者的邊標籤。

示例 3-7 把 示例 3-4 中的同一份資料寫成了三元組，使用的格式稱為 Turtle，它是 Notation3（N3）的一個子集 ⁴⁸。

@prefix : <urn:example:>.
_:lucy a :Person.
_:lucy :name "Lucy".
_:lucy :bornIn _:idaho.
_:idaho a :Location.
_:idaho :name "Idaho".
_:idaho :type "state".
_:idaho :within _:usa.
_:usa a :Location.
_:usa :name "United States".
_:usa :type "country".
_:usa :within _:namerica.
_:namerica a :Location.
_:namerica :name "North America".
_:namerica :type "continent".

在這個例子中，圖的頂點寫成 _:someName。名稱在當前檔案之外沒有任何意義；之所以需要它，只是為了分辨哪些三元組引用了同一個頂點。當謂語表示邊時，賓語是另一個頂點，如 _:idaho :within _:usa；當謂語表示屬性時，賓語則是字串字面量，如 _:usa :name "United States"。

一遍遍重複同一個主語顯得相當囉嗦，好在可以用分號連續陳述關於同一主語的多件事。這使 Turtle 格式頗為清晰易讀，如 示例 3-8 所示。

@prefix : <urn:example:>.
_:lucy a :Person; :name "Lucy"; :bornIn _:idaho.
_:idaho a :Location; :name "Idaho"; :type "state"; :within _:usa.
_:usa a :Location; :name "United States"; :type "country"; :within _:namerica.
_:namerica a :Location; :name "North America"; :type "continent".

RDF 資料模型

示例 3-8 使用的 Turtle 語言，實際上是對 資源描述框架（RDF，Resource Description Framework）資料進行編碼的一種方式 ⁵⁵；RDF 是專為 語義網（Semantic Web）設計的資料模型。RDF 資料也可以採用其他編碼，例如用更為冗長的 XML 表示，如 示例 3-9 所示。Apache Jena 等工具可以在不同 RDF 編碼之間自動轉換。

<rdf:RDF xmlns="urn:example:"
         xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">

    <Location rdf:nodeID="idaho">
        <name>Idaho</name>
        <type>state</type>
        <within>
            <Location rdf:nodeID="usa">
                <name>United States</name>
                <type>country</type>
                <within>
                    <Location rdf:nodeID="namerica">
                        <name>North America</name>
                        <type>continent</type>
                    </Location>
                </within>
            </Location>
        </within>
    </Location>

    <Person rdf:nodeID="lucy">
        <name>Lucy</name>
        <bornIn rdf:nodeID="idaho"/>
    </Person>
</rdf:RDF>

RDF 有一些奇特之處，因為它是為網際網路範圍的資料交換而設計的。三元組的主語、謂語和賓語通常都是 URI。例如，謂語可能寫成 <http://my-company.com/namespace#within> 或 <http://my-company.com/namespace#lives_in>，而不只是 WITHIN 或 LIVES_IN。這樣設計是為了讓不同來源的資料可以合併：即使別人賦予 within 或 lives_in 不同含義，也不會發生衝突，因為對方的謂語實際是 <http://other.org/foo#within> 和 <http://other.org/foo#lives_in>。

從 RDF 的角度看，URL <http://my-company.com/namespace> 不一定真能解析出什麼內容，它不過是個名稱空間。為避免與 http:// URL 混淆，本節示例使用 urn:example:within 之類不可解析的 URI。好在只須在檔案開頭宣告一次字首，後面便不必再操心。

SPARQL 查詢語言

SPARQL 是一種面向 RDF 資料模型的三元組儲存查詢語言 ⁵⁶。（它是 SPARQL Protocol and RDF Query Language 的縮寫，讀作 “sparkle”。）SPARQL 早於 Cypher；Cypher 的模式匹配借鑑了 SPARQL，因此兩者看起來十分相似。

之前那條查詢從美國移居歐洲者的查詢，用 SPARQL 表示時和用 Cypher 一樣簡潔（見 示例 3-10）。

PREFIX : <urn:example:>

SELECT ?personName WHERE {
 ?person :name ?personName.
 ?person :bornIn / :within* / :name "United States".
 ?person :livesIn / :within* / :name "Europe".
}

二者結構十分相似。下面兩個表示式是等價的（SPARQL 中的變數以問號開頭）：

(person) -[:BORN_IN]-> () -[:WITHIN*0..]-> (location) # Cypher

?person :bornIn / :within* ?location. # SPARQL

因為 RDF 不區分屬性與邊，而是把二者都當作謂語，所以匹配屬性也可以使用同一種語法。在下面的表示式中，變數 usa 會繫結到任意 name 屬性為字串 "United States" 的頂點：

(usa {name:'United States'}) # Cypher

?usa :name "United States". # SPARQL

Amazon Neptune、AllegroGraph、Blazegraph、OpenLink Virtuoso、Apache Jena 以及其他多種三元組儲存都支援 SPARQL ³⁶。

Datalog：遞迴關係查詢

Datalog 是比 SPARQL 和 Cypher 更古老的語言，源自 20 世紀 80 年代的學術研究 ^{57 58 59}。它在軟體工程師中不太知名，主流資料庫也很少支援；但它表達能力很強，尤其擅長複雜查詢，理應得到更多關注。Datomic、LogicBlox、CozoDB 以及 LinkedIn 的 LIquid ⁶⁰ 等幾種小眾資料庫，都使用 Datalog 作為查詢語言。

Datalog 實際上基於關係資料模型，而不是圖模型；之所以把它放在圖資料庫一節，是因為 Datalog 尤其擅長對圖進行遞迴查詢。

Datalog 資料庫由 事實 組成，每項事實對應關係表中的一行。假設有一張儲存地點的 location 表，包含 ID、name 和 type 三列；“美國是一個國家”這項事實就可以寫成 location(2, "United States", "country")，其中 2 是美國的 ID。一般來說，table(val1, val2, …​) 表示 table 中有這樣一行：第一列為 val1，第二列為 val2，依此類推。

示例 3-11 展示了如何用 Datalog 寫出 圖 3-6 左側的資料。圖中的邊（within、born_in 和 lives_in）表示為兩列的連線表。例如，Lucy 的 ID 是 100，愛達荷州的 ID 是 3，因此“Lucy 出生在愛達荷州”這項關係表示為 born_in(100, 3)。

location(1, "North America", "continent").
location(2, "United States", "country").
location(3, "Idaho", "state").

within(2, 1). /* 美國在北美 */
within(3, 2). /* 愛達荷州在美國 */

person(100, "Lucy").
born_in(100, 3). /* Lucy 出生在愛達荷州 */

定義好資料之後，就可以寫出與之前相同的查詢，如 示例 3-12 所示。它看起來與 Cypher 或 SPARQL 中的等價查詢頗為不同，但不必因此望而卻步。Datalog 是 Prolog 的一個子集；如果學過電腦科學，你或許見過這種程式語言。

within_recursive(LocID, PlaceName) :- location(LocID, PlaceName, _). /* 規則 1 */

within_recursive(LocID, PlaceName) :- within(LocID, ViaID), /* 規則 2 */
 within_recursive(ViaID, PlaceName).

migrated(PName, BornIn, LivingIn) :- person(PersonID, PName), /* 規則 3 */
 born_in(PersonID, BornID),
 within_recursive(BornID, BornIn),
 lives_in(PersonID, LivingID),
 within_recursive(LivingID, LivingIn).

us_to_europe(Person) :- migrated(Person, "United States", "Europe"). /* 規則 4 */
/* us_to_europe 包含行 "Lucy"。 */

Cypher 和 SPARQL 一上來便使用 SELECT，Datalog 卻每次只向前邁一小步。我們透過定義 規則，從底層事實派生出新的虛擬表。這些派生表類似於（虛擬的）SQL 檢視：它們並不儲存在資料庫中，卻可以像儲存事實的表一樣接受查詢。

示例 3-12 定義了三個派生表：within_recursive、migrated 和 us_to_europe。每條規則中 :- 符號之前的部分，定義了虛擬表的名稱與各列。例如，migrated(PName, BornIn, LivingIn) 是一張三列表，分別包含姓名、出生地名稱和居住地名稱。

虛擬表的內容由規則中 :- 符號之後的部分定義，它會嘗試在各表中找出匹配特定模式的行。例如，person(PersonID, PName) 可以匹配 person(100, "Lucy") 這一行，此時變數 PersonID 繫結為 100，PName 繫結為 "Lucy"。只要系統能為 :- 右側的 所有 模式找到匹配，規則便可以應用。應用規則的效果，就好像把 :- 左側的內容加入資料庫，並將其中的變數替換為各自匹配的值。

因此，可以按下面的方式應用規則（如 圖 3-7 所示）：

1. 資料庫中存在 location(1, "North America", "continent")，所以規則 1 可以應用，生成 within_recursive(1, "North America")。
2. 資料庫中存在 within(2, 1)，上一步又生成了 within_recursive(1, "North America")，所以規則 2 可以應用，生成 within_recursive(2, "North America")。
3. 資料庫中存在 within(3, 2)，上一步又生成了 within_recursive(2, "North America")，所以再次應用規則 2，生成 within_recursive(3, "North America")。

反覆應用規則 1 和規則 2，within_recursive 虛擬表就能告訴我們，資料庫中的哪些地點位於北美（或任何其他地點）之內。

圖 3-7. 使用 示例 3-12 中的 Datalog 規則確定愛達荷州在北美。

接下來，規則 3 可以找出出生在 BornIn、現居 LivingIn 的人。規則 4 以 BornIn = 'United States' 和 LivingIn = 'Europe' 呼叫規則 3，只返回符合條件者的姓名。最後查詢虛擬表 us_to_europe，Datalog 系統便會給出與先前 Cypher 和 SPARQL 查詢相同的答案。

Datalog 需要一種不同於本章其他查詢語言的思維方式。它允許逐條規則地搭建複雜查詢，讓一條規則引用其他規則，就像把程式碼拆成彼此呼叫的函式。函式可以遞迴，Datalog 規則也同樣可以呼叫自身；示例 3-12 的規則 2 正是如此，由此實現了 Datalog 查詢中的圖遍歷。

GraphQL

GraphQL 也是一種查詢語言，但它在設計上比本章介紹的其他語言限制更多。GraphQL 的用途，是讓執行在使用者裝置上的客戶端軟體（例如移動應用或 JavaScript Web 應用的前端）請求一份特定結構的 JSON 文件，其中恰好包含渲染使用者介面所需的欄位。藉助 GraphQL 介面，開發者可以迅速修改客戶端程式碼中的查詢，而無須改動服務端 API。

GraphQL 的靈活性並非沒有代價。採用 GraphQL 的組織通常需要一套工具，把 GraphQL 查詢轉換成對內部服務的請求，而這些內部服務往往使用 REST 或 gRPC（參見 第 5 章）。此外還要應對授權、限流和效能等問題 ⁶¹。GraphQL 查詢來自不受信任的來源，因此查詢語言本身也受到嚴格限制：它不允許任何執行成本可能很高的操作，否則使用者就能大量提交昂貴查詢，對伺服器發動拒絕服務攻擊。具體來說，GraphQL 不允許遞迴查詢（Cypher、SPARQL、SQL 和 Datalog 都允許），也不能隨意給出“查詢出生在美國、現居歐洲的人”這樣的搜尋條件，除非服務所有者特意提供了相應搜尋功能。

儘管如此，GraphQL 仍然很有用。示例 3-13 展示了如何用它實現 Discord 或 Slack 這類群聊應用。查詢請求使用者有權訪問的所有頻道，並取回每個頻道的名稱和最近 50 條訊息。對每條訊息，它請求時間戳、正文，以及傳送者姓名和頭像 URL。若某條訊息是對另一條訊息的回覆，查詢還會請求原訊息的正文與傳送者姓名；介面可以用較小字號把這些內容顯示在回覆上方，作為上下文。

query ChatApp {
    channels {
        name
        recentMessages(latest: 50) {
            timestamp
            content
        sender {
            fullName
            imageUrl
        }
    replyTo {
        content
        sender {
            fullName
        }
    }
    }
    }
}

示例 3-14 給出了 示例 3-13 中查詢的一種可能響應。響應是一份與查詢結構相呼應的 JSON 文件：請求了哪些屬性，它就不多不少地返回哪些屬性。這樣一來，伺服器無須預先知道客戶端渲染介面需要什麼；客戶端直接提出所需內容即可。例如，這條查詢沒有請求 replyTo 訊息傳送者的頭像 URL。若介面後來要顯示該頭像，客戶端只需在查詢中加入 imageUrl 屬性，無須修改伺服器。

{
"data": {
    "channels": [
        {
        "name": "#general",
        "recentMessages": [
        {
        "timestamp": 1693143014,
        "content": "Hey! How are y'all doing?",
        "sender": {"fullName": "Aaliyah", "imageUrl": "https://..."},
        "replyTo": null
        },
        {
            "timestamp": 1693143024,
            "content": "Great! And you?",
            "sender": {"fullName": "Caleb", "imageUrl": "https://..."},
            "replyTo": {
            "content": "Hey! How are y'all doing?",
            "sender": {"fullName": "Aaliyah"}
        }
},
...

示例 3-14 把訊息傳送者的姓名和頭像 URL 直接嵌入訊息物件。同一個使用者若傳送多條訊息，這些資訊會在每條訊息中重複。原則上當然可以減少這種重複，但 GraphQL 選擇接受更大的響應，以換取根據資料渲染介面時更加簡單。

replyTo 欄位也是如此：示例 3-14 中的第二條訊息回覆了第一條，因此第一條訊息的內容（“Hey!…”）和傳送者 Aaliyah 又在 replyTo 下重複了一遍。也可以只返回被回覆訊息的 ID，但如果該 ID 不在這次返回的最近 50 條訊息之中，客戶端就得向伺服器再發一次請求。直接複製內容，處理起來簡單得多。

伺服器端資料庫可以用更加正規化的形式儲存資料，並在處理查詢時執行必要的連線。例如，伺服器可以把訊息正文與傳送者的使用者 ID、被回覆訊息的 ID 存在一起；收到上述查詢時，再解析這些 ID，找出它們引用的記錄。不過，客戶端只能要求伺服器執行 GraphQL 模式中明確開放的連線。

儘管 GraphQL 的響應看起來很像文件資料庫返回的結果，而且名稱中還帶有 “graph”，它其實可以構建在任何資料庫之上，無論是關聯式資料庫、文件資料庫還是圖資料庫。

事件溯源與 CQRS

在我們迄今討論過的所有資料模型中，資料都以寫入時的形式接受查詢——無論它是 JSON 文件、表中的行，還是圖中的頂點和邊。然而在複雜應用中，有時很難找到一種資料表示，能夠滿足所有查詢和展現資料的需求。在這種情況下，可以用一種形式寫入資料，再從中派生出多種針對不同讀取方式最佳化的表示。

我們在 “權威記錄系統與衍生資料” 中已經見過這種思路，ETL（參見 “資料倉儲”）就是一種派生過程。現在讓我們再往前走一步。既然無論如何都要由一種資料表示派生出另一種，那就可以分別選用針對寫入和讀取最佳化的表示。如果只需最佳化資料寫入，絲毫不必考慮查詢效率，你會如何對資料建模？

也許，寫入資料最簡單、最快且表意最清楚的方式，就是寫入 事件日誌（event log）：每次寫入資料時，都將它編碼成一個自包含的字串（也許是 JSON），其中帶有時間戳，再追加到事件序列中。日誌中的事件是 不可變的（immutable）：你永遠不會修改或刪除它們，只會向日志追加更多事件（後來的事件可以取代早先事件的效力）。事件可以包含任意屬性。

圖 3-8 給出了一個可能來自會議管理系統的例子。會議管理是一個複雜的業務領域：不僅個人參會者可以報名並用信用卡付款，企業也可以批次預訂座位，以發票結算，再把座位分配給個人。演講者、贊助商和志願者等人可能要佔用一些預留座位。預訂還可能取消；與此同時，會議組織者又可能因為更換場地，而改變活動的容量。這些事情疊加在一起，哪怕只是計算還有多少空餘座位，也會變成一項頗具挑戰的查詢。

在 圖 3-8 中，會議狀態的每次變化（例如組織者開放報名，或參會者報名和取消報名），首先都會被儲存為事件。每當日誌追加一個事件，幾個 物化檢視（materialized view，也稱為 投影，projection，或 讀模型，read model）也會隨之更新，以反映該事件帶來的影響。在這個會議示例中，可以有一個物化檢視彙總每筆預訂狀態的所有相關資訊，另一個計算會議組織者儀表盤所需的圖表，第三個則為製作參會者胸牌的印表機生成檔案。

以事件作為權威資料來源，並把每次狀態變化都表達為事件，這種思路稱為 事件溯源（event sourcing）^{62 63}。維護獨立的讀取最佳化表示，並從寫入最佳化的表示中派生它們，這種原則稱為 命令查詢責任分離（Command Query Responsibility Segregation，CQRS）⁶⁴。這些術語源自領域驅動設計（DDD）社群，不過類似的思路由來已久，例如 狀態機複製（state machine replication；參見 “使用共享日誌”）。

當來自使用者的請求剛到達時，它還是一個 命令（command），首先需要驗證。只有在命令已經執行且確認有效之後（例如，請求的預訂有足夠的空餘座位），它才會成為事實，相應的事件也才會追加到日誌中。因此，事件日誌中應當只有有效事件；消費事件日誌來構建物化檢視的元件，不允許拒絕事件。

以事件溯源的方式對資料建模時，建議用過去時來命名事件（例如“座位已預訂”），因為事件記錄的是已經發生的事實。即使使用者後來更改或取消預訂，他們曾經預訂過的事實依然成立；更改或取消是之後另行追加的事件。

事件溯源與星型模式的事實表（參見 “星型與雪花型：分析模式”）有一個相似之處：它們都是過去所發生事件的集合。不過，事實表中每一行的列都相同，事件溯源中則可以有許多型別不同、屬性各異的事件。此外，事實表是無序集合，而事件溯源中事件的先後順序很重要：如果一筆預訂先成立、後取消，顛倒順序處理這兩個事件就毫無意義。

事件溯源和 CQRS 有幾個優點：

• 對系統開發者來說，事件能更清楚地表達某件事 為什麼 發生。例如，理解“預訂已取消”這個事件，要比理解“bookings 表第 4001 行的 active 列已設為 false，seat_assignments 表中與該預訂相關的三行已被刪除，payments 表中又插入了一行表示退款”容易得多。物化檢視處理取消事件時，依然可能會對這些行執行修改；但由事件驅動這些更新，其原因就清楚得多。
• 事件溯源的一項關鍵原則，是物化檢視應以可重現的方式從事件日誌中派生：你應當隨時能夠刪除物化檢視，然後用同一套程式碼，按同樣的順序處理同樣的事件，從而重新計算出檢視。如果檢視維護程式碼存在錯誤，只需刪除檢視，再用修正後的程式碼重算。錯誤也更容易查詢，因為你可以反覆重新執行檢視維護程式碼，並檢查它的行為。
• 你可以維護多個物化檢視，分別針對應用所需的特定查詢進行最佳化。它們可以與事件儲存在同一個資料庫中，也可以根據需要存入不同的資料庫。這些檢視可以使用任何資料模型，也可以透過反正規化來加快讀取。只要服務重啟時可以從事件日誌重算檢視，甚至可以只把它保留在記憶體中，根本不做持久化。
• 如果決定以新方式展現現有資訊，可以很容易地根據現有事件日誌構建新的物化檢視。新增新的事件型別，或給現有事件型別新增新屬性（舊事件保持不變），就能讓系統演化並支援新功能。還可以在現有事件後觸發新的行為，例如參會者取消預訂後，將座位提供給等候名單中的下一個人。
• 如果誤寫了某個事件，可以把它刪除，再重建不包含該事件的檢視。相比之下，在直接更新和刪除資料的資料庫中，已經提交的事務往往很難撤銷。因此，事件溯源可以減少系統中不可逆操作的數量，讓變更更容易（參見 “可演化性：讓變化更容易”）。
• 事件日誌還可以作為審計日誌，記錄系統中發生的一切。在必須提供審計能力的受監管行業中，這一點很有價值。

然而，事件溯源和 CQRS 也有缺點：

• 涉及外部資訊時必須小心。例如，假設事件中有一個以某種貨幣計價的價格，而某個檢視需要把它兌換成另一種貨幣。由於匯率會波動，處理事件時再從外部資料來源獲取匯率就有問題：換一天重新計算物化檢視，得到的結果就可能不同。為了讓事件處理邏輯具有確定性，要麼把匯率寫入事件本身，要麼提供一種方法，能查詢事件時間戳所對應的歷史匯率，並確保同一時間戳始終返回同一結果。
• 事件不可變這一要求，在事件包含使用者個人資料時會帶來問題，因為使用者可能行使自己的權利（例如 GDPR 規定的權利），要求刪除個人資料。如果每個使用者各有一份事件日誌，只需刪除該使用者的整份日誌；但如果日誌中的事件關係到多個使用者，這種做法就行不通。可以嘗試把個人資料存在事件之外，或者用一把金鑰加密，以便日後刪除金鑰；但這也會讓按需重算派生狀態變得更困難。
• 如果處理事件會帶來外部可見的副作用，那麼重新處理事件時必須小心。例如，你大概不會希望每次重建物化檢視時，都再發一遍確認郵件。

事件溯源可以構建在任何資料庫之上，不過也有一些系統是專為這種模式設計的，例如 EventStoreDB、MartenDB（基於 PostgreSQL）和 Axon Framework。也可以使用 Apache Kafka 之類的訊息代理來儲存事件日誌，並透過流處理器使物化檢視保持最新；我們將在 “變更資料捕獲與事件溯源” 中再次討論這些主題。

唯一一項重要要求是：事件儲存系統必須保證，所有物化檢視都以事件在日誌中出現的順序處理它們。正如我們將在 第 10 章 中看到的，這在分散式系統中並不總是一件容易的事。

資料框、矩陣與陣列

本章迄今介紹的資料模型，通常既用於事務處理，也用於分析（參見 “分析型與事務型系統”）。還有一些資料模型常見於分析或科學場景，卻很少出現在 OLTP 系統中：資料框（dataframe），以及矩陣等多維數值陣列。

R 語言、Python 的 pandas 庫、Apache Spark、ArcticDB 和 Dask 等系統，都支援資料框這種資料模型。資料科學家經常用它為訓練機器學習模型準備資料；它也廣泛用於資料探索、統計分析和資料視覺化等場景。

乍看之下，資料框很像關聯式資料庫中的表，也像電子表格。它支援一系列類似關係運算子的批次操作：例如，對所有行應用某個函式，按條件篩選行，按某些列分組並聚合其他列，以及按某個鍵連線兩個資料框中的行（關聯式資料庫中的 連線，在資料框中通常稱為 合併，merge）。

資料框通常不是透過 SQL 之類的宣告式查詢來操作，而是透過一系列命令逐步修改其結構和內容。這恰好符合資料科學家的典型工作流程：一點點地“整理”資料，直至它變成一種適合回答當前問題的形式。這些操作通常在資料科學傢俬有的資料集副本上進行，而且往往就在本機上；不過最終結果也可能會分享給其他使用者。

資料框 API 提供的許多操作遠遠超出關聯式資料庫的能力，其使用方式也往往與典型的關係資料建模大不相同 ⁶⁵。例如，資料框的一種常見用途，是把資料從類似關係模型的表示轉換為矩陣或多維陣列，而許多機器學習演算法期望的輸入正是這種形式。

圖 3-9 展示了一個簡單的轉換示例。左側是一張關係表，記錄不同使用者給各種電影打出的分數（1 到 5 分）；右側則把這些資料轉換成了矩陣，每一列代表一部電影，每一行代表一位使用者（類似電子表格中的 資料透視表，pivot table）。這個矩陣是 稀疏（sparse）的，也就是說，很多使用者與電影的組合都沒有資料，但這並不礙事。矩陣可能有成千上萬列，不太適合放在關聯式資料庫中；資料框以及 Python 的 NumPy 等支援稀疏陣列的庫，卻能輕鬆處理這類資料。

矩陣只能包含數字，因此需要用各種技術把非數值資料轉換為矩陣中的數字。例如：

• 日期（圖 3-9 的示例矩陣中省略了日期）可以按比例縮放為某個合適範圍內的浮點數。
• 對於只能從一小組固定值中取值的列（例如電影資料庫中的電影型別），通常採用 獨熱編碼（one-hot encoding）：為每個可能的值建立一列（“喜劇”一列、“劇情”一列、“恐怖”一列，依此類推）；對於代表某部電影的每一行，在對應其型別的列中填 1，其餘列填 0。這種表示也很容易推廣到同時屬於多種型別的電影。

資料一旦變成數值矩陣，就適合進行線性代數運算，而線性代數正是許多機器學習演算法的基礎。例如，圖 3-9 中的資料可以用在向使用者推薦其可能喜歡的電影的系統中。資料框十分靈活，可以讓資料從關係形式逐步演變為矩陣表示，同時讓資料科學家自行掌控哪種表示最適合達成資料分析或模型訓練的目標。

還有一些資料庫專門儲存大型多維數值陣列，例如 TileDB ⁶⁶。這類系統稱為 陣列資料庫（array database），最常用於科學資料集，例如地理空間測量資料（規則間隔網格上的柵格資料）、醫學影像或天文望遠鏡的觀測結果 ⁶⁷。金融行業也用資料框表示 時間序列資料（time-series data），例如資產價格以及按時間記錄的交易 ⁶⁸。

總結

資料模型是一個巨大的課題，本章只是快速瀏覽了各種不同的模型。我們沒有足夠的篇幅詳述每個模型，但希望這份概覽足以引起你的興趣，促使你進一步瞭解最適合應用需求的模型。

關係模型 儘管已有半個多世紀的歷史，但對許多應用來說仍然是一種重要的資料模型——尤其是在資料倉儲和商業分析領域，關係型星型或雪花型模式與 SQL 查詢無處不在。不過，關係資料的幾種替代方案也在其他領域流行起來：

• 文件模型 主要關注自包含的 JSON 資料文件，而且文件之間的關係非常稀少。
• 圖資料模型 用於相反的場景：任意事物都可能與其他一切事物相關，查詢可能需要跨越多跳才能找到感興趣的資料（這類查詢可以用 Cypher、SPARQL 或 Datalog 中的遞迴查詢來表達）。
• 資料框 把關係資料推廣到擁有大量列的情形，在資料庫與多維陣列之間架起了橋樑；而多維陣列正是許多機器學習、統計分析和科學計算的基礎。

一個模型可以用另一個模型來模擬——例如，圖資料可以在關聯式資料庫中表示——但結果往往很彆扭，正如 SQL 對遞迴查詢的支援所表明的那樣。

因此，人們為每種資料模型開發了各式各樣的專用資料庫，提供針對該模型最佳化的查詢語言和儲存引擎。另一方面，資料庫也在不斷加入對其他資料模型的支援，向相鄰領域擴充套件：例如，關聯式資料庫透過 JSON 列支援文件資料，文件資料庫加入類似關係模型的連線，而 SQL 對圖資料的支援也在逐步改善。

我們還討論了 事件溯源：它把資料表示為不可變事件的僅追加日誌，這種形式可能很適合為複雜業務領域中的活動建模。僅追加日誌有利於資料寫入（正如我們將在 第 4 章 中看到的）；為了支援高效查詢，CQRS 會把事件日誌轉換為針對讀取最佳化的物化檢視。

非關係資料模型的一個共同點是，它們通常不會將儲存的資料強制約束為特定模式，這可以使應用更容易適應不斷變化的需求。但是應用很可能仍會假定資料具有一定的結構；區別僅在於模式是 明確的（寫入時強制）還是 隱含的（讀取時假定）。

雖然我們已經覆蓋了很多層面，但仍有一些資料模型沒有提到。舉幾個簡單的例子：

• 研究基因組資料的研究人員通常需要執行 序列相似性搜尋，這意味著取一個很長的字串（代表一個 DNA 分子），在一個包含大量相似但不完全相同的字串的資料庫中尋找匹配。這裡描述的資料庫都不能處理這種用法，這就是研究人員編寫了 GenBank ⁶⁹ 等專用基因組資料庫軟體的原因。
• 許多金融系統以採用複式記賬法的 賬本 作為資料模型。這類資料可以用關聯式資料庫表示，但也有 TigerBeetle 這樣專攻此類資料模型的資料庫。加密貨幣和區塊鏈通常基於分散式賬本，並把價值轉移也內建在資料模型之中。
• 全文檢索 可以說是一種經常與資料庫配合使用的資料模型。資訊檢索是一個很大的專業課題，本書不會深入介紹，但我們將在 “全文檢索” 中談到搜尋索引與向量搜尋。

我們暫且說到這裡。在下一章中，我們將討論在 實現 本章描述的資料模型時會遇到的一些權衡。

參考文獻

4 儲存與檢索

人生的苦惱之一，就是每個人給事物起的名字總有那麼一點不對。於是，世上的一切都變得比換個名字時更難理解。計算機最主要的用途，並不是通常所謂做算術的“計算”。[……] 它們主要是檔案系統。

理查德・費曼， 特立獨行的思考 研討會（1985 年）

一個資料庫在最基礎的層次上需要完成兩件事情：當你把資料交給資料庫時，它應當把資料儲存起來；而後當你向資料庫要資料時，它應當把資料返回給你。

在 第 3 章 中，我們討論了資料模型和查詢語言，即你將資料交給資料庫時採用的格式，以及日後向資料庫取回資料時使用的介面。在本章中，我們會從資料庫的視角來討論同樣的問題：資料庫如何儲存我們提供的資料，以及如何在我們需要時重新找到資料。

作為應用開發者，為什麼要關心資料庫內部儲存與檢索的機理？你可能不會從頭開始實現自己的 儲存引擎（storage engine），但是你 確實 需要從許多可用的儲存引擎中選擇一個適合應用的。為了讓儲存引擎能在你的工作負載上執行良好，你也需要大致瞭解它在底層究竟做了什麼。

尤其需要注意，針對事務型工作負載（OLTP）最佳化的儲存引擎，與針對分析型工作負載最佳化的儲存引擎之間存在巨大差異（這種區別已在 “分析型與事務型系統” 中介紹）。本章首先考察 OLTP 儲存引擎的兩大類：寫出不可變資料檔案的 日誌結構（log-structured）儲存引擎，以及像 B 樹 這樣就地更新資料的儲存引擎。鍵值儲存（key-value store）和 二級索引（secondary index）都可以採用這兩類結構。

稍後在 “分析型資料儲存” 中，我們會討論一類針對分析最佳化的儲存引擎；在 “多維索引與全文索引” 中，還會簡要介紹用於文字檢索等複雜查詢的索引。

OLTP 系統的儲存與索引

世界上最簡單的資料庫可以用兩個 Bash 函式實現：

#!/bin/bash

db_set () {
  echo "$1,$2" >> database
}

db_get () {
  grep "^$1," database | sed -e "s/^$1,//" | tail -n 1
}

這兩個函式實現了鍵值儲存。呼叫 db_set key value，會將 key 和 value 存入資料庫。鍵和值（幾乎）可以是任意內容，例如值可以是一個 JSON 文件。隨後呼叫 db_get key，就會查詢與這個鍵關聯的最新值並將其返回。

麻雀雖小，五臟俱全：

$ db_set 12 '{"name":"London","attractions":["Big Ben","London Eye"]}'

$ db_set 42 '{"name":"San Francisco","attractions":["Golden Gate Bridge"]}'

$ db_get 42
{"name":"San Francisco","attractions":["Golden Gate Bridge"]}

底層儲存格式非常簡單：一個文字檔案，每行包含一條以逗號分隔的鍵值對（忽略轉義問題的話，大致與 CSV 檔案類似）。每次呼叫 db_set 都會向檔案末尾追加記錄。多次更新一個鍵時，舊版本的值不會被覆蓋——因而要找到最新值，就必須檢視這個鍵在檔案中最後一次出現的位置（所以 db_get 中使用了 tail -n 1）：

$ db_set 42 '{"name":"San Francisco","attractions":["Exploratorium"]}'

$ db_get 42
{"name":"San Francisco","attractions":["Exploratorium"]}

$ cat database
12,{"name":"London","attractions":["Big Ben","London Eye"]}
42,{"name":"San Francisco","attractions":["Golden Gate Bridge"]}
42,{"name":"San Francisco","attractions":["Exploratorium"]}

db_set 函式對於如此簡單的實現其實有著相當不錯的效能，因為在檔案末尾追加寫入通常非常高效。與 db_set 所做的事情類似，許多資料庫在內部使用 日誌（log），也就是僅追加的資料檔案。真正的資料庫還要處理更多問題（例如併發寫入、回收磁碟空間以免日誌無限增長，以及崩潰恢復時處理只寫了一部分的記錄），但基本原理是一樣的。日誌極其有用，我們還會在本書中多次遇到它。

另一方面，如果資料庫中有大量記錄，db_get 函式的效能就會非常糟糕。每次查詢一個鍵，db_get 都必須從頭到尾掃描整個資料庫檔案，尋找這個鍵。用演算法的語言來說，查詢開銷是 O(n)：如果資料庫中的記錄數 n 翻了一倍，查詢時間也要翻一倍。這就不好了。

為了高效查詢資料庫中特定鍵的值，我們需要一種資料結構：索引（index）。本章將介紹一系列索引結構，並比較它們之間的差異。索引背後的大致思想，是以某種特定方式組織資料（例如按某個鍵排序），從而更快地定位想要的資料。如果想以幾種不同的方式搜尋同一份資料，那麼也許需要在資料的不同部分建立多個索引。

索引是從主資料衍生出的 額外 結構。許多資料庫允許新增和刪除索引，這不會影響資料庫的內容，只會影響查詢效能。維護額外結構會產生開銷，特別是在寫入時。寫入效能很難超過簡單地向檔案末尾追加，因為追加是最簡單的寫入操作。任何型別的索引通常都會拖慢寫入速度，因為每次寫入資料時還必須更新索引。

這是儲存系統中一項重要的權衡：精心選擇的索引能加快讀查詢，但每個索引都會佔用額外的磁碟空間，並拖慢寫入速度，有時影響還相當顯著 ¹。因此，資料庫通常不會預設索引所有內容，而是要求編寫應用程式或管理資料庫的人，根據自己對典型查詢模式的瞭解手動選擇索引。這樣便可以選出給應用帶來最大收益的索引，同時避免不必要的寫入開銷。

日誌結構儲存

首先假設你仍想把資料儲存在 db_set 寫入的僅追加檔案中，只是希望加快讀取速度。最簡單的索引策略是保留一個記憶體中的雜湊對映，其中每個鍵都對映到資料檔案裡的一個位元組偏移量，指明該鍵最新的值位於何處，如 圖 4-1 所示。

每當向檔案追加新的鍵值對時，還要更新雜湊對映，使它指向剛剛寫入的資料。查詢一個值時，先用雜湊對映找到日誌檔案中的偏移量，再尋道至該位置讀取即可。如果資料檔案的這一部分已經在檔案系統快取中，讀取甚至完全不需要磁碟 I/O。

這種方法快得多，但仍有幾個問題：

• 被新值覆蓋的舊日誌條目仍佔著磁碟空間，始終得不到釋放；只要繼續寫入資料庫，磁碟空間遲早會耗盡。
• 雜湊對映沒有持久化，資料庫重啟時必須重建。例如，可以掃描整個日誌檔案，找出每個鍵最新的位元組偏移量。如果資料量很大，重啟就會十分緩慢。
• 雜湊表必須能放進記憶體。原則上可以在磁碟上維護雜湊表，可惜磁碟雜湊表很難有良好的效能：它需要大量隨機訪問 I/O，裝滿後的擴容代價很高，而且解決雜湊衝突需要煩瑣的邏輯 ²。
• 範圍查詢效率不高。例如，無法輕鬆掃描 10000 到 19999 之間的所有鍵，只能在雜湊對映中逐個查詢。

SSTable 檔案格式

實踐中，資料庫索引很少採用雜湊表，更常見的做法是把資料儲存在 按鍵排序 的結構中 ³。排序字串表（Sorted String Table，簡稱 SSTable）便是一例，如 圖 4-2 所示。這種檔案格式同樣儲存鍵值對，但保證鍵值對按鍵排序，而且每個鍵在檔案中只出現一次。

這樣便不必在記憶體中保留所有鍵。可以把 SSTable 中的鍵值對分成若干個幾千位元組大小的 塊（block），索引只儲存每個塊的第一個鍵。這種只收錄部分鍵的索引稱為 稀疏索引（sparse index）。索引儲存在 SSTable 的一個獨立區域中，可以採用不可變 B 樹、字典樹或其他能快速查詢特定鍵的資料結構 ⁴。

以 圖 4-2 為例，一個塊的第一個鍵是 handbag，下一個塊的第一個鍵是 handsome。假設要查詢沒有出現在稀疏索引中的 handiwork。根據排序關係可知，handiwork 必定在 handbag 與 handsome 之間。因此，可以尋道至 handbag 的偏移量，再從那裡開始掃描檔案，直到找到 handiwork；如果一直掃到下一個塊仍未找到，就說明檔案中沒有這個鍵。幾千位元組的資料塊很快就能掃描完。

此外，每個記錄塊都可以壓縮（圖 4-2 中的陰影區域）。除了節省磁碟空間，壓縮還能減少 I/O 頻寬的使用，代價只是多耗費一點 CPU 時間。

構建和合並 SSTable

SSTable 檔案格式比僅追加日誌更利於讀取，卻讓寫入變得困難。不能直接向檔案末尾追加，否則檔案就不再有序（除非鍵碰巧按升序寫入）。如果每次在檔案中間插入一個鍵都要重寫整個 SSTable，寫入成本又會高得無法接受。

解決辦法是採用 日誌結構 方法，將僅追加日誌與排序檔案結合起來：

1. 收到寫入時，將其加入記憶體中的有序對映資料結構，例如紅黑樹、跳錶 ⁵ 或字典樹 ⁶。這類資料結構可以按任意順序插入鍵、高效查詢鍵，並按排序順序讀出鍵。這個記憶體資料結構稱為 記憶體表（memtable）。
2. 當記憶體表超過某個閾值（通常為幾兆位元組）時，按排序順序將它寫成磁碟上的 SSTable 檔案。這個新的 SSTable 檔案稱為資料庫最新的 段（segment），它與較舊的段分別存放在獨立檔案中，每個段都有自己的索引。向磁碟寫出新段期間，資料庫可以繼續向新的記憶體表例項寫入；SSTable 寫完後，舊記憶體表佔用的記憶體即可釋放。
3. 讀取某個鍵的值時，先在記憶體表和磁碟上最新的段中查詢。如果沒有找到，就依次檢視更舊的段，直到找到這個鍵或查完最舊的段。如果任何段中都沒有這個鍵，它就不存在於資料庫中。
4. 後臺不時執行合併與壓實過程，將段檔案合併起來，並丟棄已經覆蓋或刪除的值。

段的合併類似於 歸併排序 演算法 ⁵，如 圖 4-3 所示。並行讀取各個輸入檔案，比較每個檔案當前的第一個鍵，把排序最靠前的鍵複製到輸出檔案，然後不斷重複。如果同一個鍵出現在多個輸入檔案中，只保留較新的值。這樣生成的新段仍按鍵排序，每個鍵只保留一個值；由於可以逐鍵遍歷 SSTable，整個過程只需要很少的記憶體。

為了避免資料庫崩潰時丟失記憶體表中的資料，儲存引擎還會在磁碟上儲存一個單獨的日誌，每次寫入都會立即追加到這個日誌。日誌不按鍵排序，但這並不重要，因為它的唯一用途是在崩潰後恢復記憶體表。每當記憶體表寫成 SSTable 後，日誌中相應的部分便可丟棄。

如果要刪除一個鍵及其關聯的值，必須向資料檔案追加一種稱為 墓碑（tombstone）的特殊刪除記錄。日誌段合併時，墓碑會指示合併過程丟棄這個鍵此前的所有值。墓碑一旦合併進最舊的段，自身也就可以刪除。

這裡描述的演算法，本質上就是 RocksDB ⁷、Cassandra、ScyllaDB 和 HBase ⁸ 所採用的演算法。這些系統都受 Google Bigtable 論文 ⁹ 的啟發；SSTable 和 memtable 兩個術語正是由該論文提出的。

這一演算法最初發表於 1996 年，名為 日誌結構合併樹（Log-Structured Merge-Tree，簡稱 LSM 樹）¹⁰，它建立在更早的日誌結構檔案系統研究之上 ¹¹。因此，凡是以合併、壓實有序檔案為基本原理的儲存引擎，通常都稱為 LSM 儲存引擎。

在 LSM 儲存引擎中，段檔案會一次寫完（或者由記憶體表寫出，或者由若干現有段合併而成），此後便不可變。段的合併與壓實可以由後臺執行緒完成；在此期間，舊段檔案仍可繼續處理讀取請求。合併完成後，讀取請求切換到新的合併段，舊段檔案即可刪除。

段檔案不一定要儲存在本地磁碟上；它們也非常適合寫入物件儲存。例如，SlateDB 和 Delta Lake 就採用這種方法 ¹²。

段檔案不可變，也讓崩潰恢復變得更簡單：如果寫出記憶體表或合併段時發生崩潰，資料庫只需刪除未完成的 SSTable，再重新開始即可。用於持久化記憶體表寫入的日誌，可能因寫到一半時崩潰或磁碟已滿而留下不完整記錄；通常可以藉助日誌中的校驗和檢測這些記錄，並丟棄損壞或不完整的條目。我們將在 第 8 章 進一步討論永續性與崩潰恢復。

布隆過濾器

在 LSM 儲存中，讀取很久以前才更新過的鍵，或讀取根本不存在的鍵，可能十分緩慢，因為儲存引擎必須檢查多個段檔案。為了加快這類讀取，LSM 儲存引擎通常會為每個段配備一個 布隆過濾器（Bloom filter）¹³，用來快速、近似地判斷某個鍵是否出現在某個 SSTable 中。

圖 4-4 展示了一個包含兩個鍵、長度為 16 位的布隆過濾器（實際的鍵和位都會多得多）。對 SSTable 中的每個鍵計算雜湊函式，會得到一組數字，再將這些數字解釋為位陣列中的下標 ¹⁴。把這些位置上的位設為 1，其餘位保持為 0。例如，鍵 handbag 的雜湊結果是 (2, 9, 4)，於是將第 2、9、4 位設為 1。得到的點陣圖會與稀疏鍵索引一起存入 SSTable。它會佔用一點額外空間，不過布隆過濾器通常遠小於 SSTable 的其餘部分。

要判斷某個鍵是否出現在 SSTable 中，只需對它計算同樣的雜湊，再檢查對應下標處的位。例如，圖 4-4 查詢的是鍵 handheld，其雜湊結果為 (6, 11, 2)。其中第 2 位為 1，另外兩位為 0。所有 CPU 都支援的位運算可以極快地完成這些檢查。

只要其中至少一位為 0，就能確定 SSTable 中絕對沒有這個鍵。如果查詢對應的位全為 1，這個鍵很可能在 SSTable 中，但也可能只是其他鍵碰巧把這些位全都設成了 1。這種看似存在、實際卻不存在的情況稱為 假陽性（false positive）。

假陽性的機率取決於鍵的數量、每個鍵設定多少位，以及布隆過濾器的總位數。可以藉助線上計算器為應用選擇合適的引數 ¹⁵。粗略地說，SSTable 中每個鍵分配 10 位布隆過濾器空間，假陽性機率約為 1%；此後每個鍵再多分配 5 位，機率就會降低一個數量級。

對 LSM 儲存引擎來說，假陽性不會造成正確性問題：

• 如果布隆過濾器判斷鍵 不存在，就可以放心跳過這個 SSTable，因為其中一定沒有該鍵。
• 如果布隆過濾器判斷鍵 存在，還要查詢稀疏索引、解碼鍵值對塊，確認鍵是否真的在其中。如果遇到假陽性，不過是多做了一點無用功，並無其他危害；繼續搜尋下一個更舊的段即可。

壓實策略

LSM 儲存的一項重要設計細節，是何時執行壓實，以及每次壓實應包含哪些 SSTable。許多基於 LSM 的儲存系統都允許配置壓實策略，常見選擇包括 ^{16 17}：

按大小分層壓實（size-tiered compaction）

將較新、較小的 SSTable 逐步合併到較舊、較大的 SSTable 中。儲存舊資料的 SSTable 可能變得非常大，合併時需要大量臨時磁碟空間。這種策略的優點是能應對很高的寫入吞吐量。

分級壓實（leveled compaction）

將鍵範圍拆分到較小的 SSTable 中，並把較舊的資料移入不同的“層級”。這樣可以更增量地進行壓實，所需磁碟空間也少於按大小分層策略。分級壓實的讀取效率更高，因為儲存引擎只需檢查較少的 SSTable，就能判斷其中是否含有所需的鍵。

根據經驗，如果工作負載以寫入為主、讀取很少，按大小分層壓實通常表現更好；如果讀取佔主導，分級壓實通常更好。若少量鍵經常寫入，而大量鍵很少寫入，分級壓實也可能更有優勢 ¹⁸。

儘管其中有許多微妙之處，LSM 樹的基本思想——儲存一系列在後臺合併的 SSTable——簡單而有效。我們將在 “比較 B 樹與 LSM 樹” 中更詳細地討論其效能特徵。

B 樹

日誌結構方法很流行，但它不是鍵值儲存的唯一形式。按鍵讀寫資料庫記錄時，使用最廣泛的結構是 B 樹。

B 樹自 1970 年問世 ²¹，不到 10 年就被稱為“無處不在”²²，很好地經受住了時間的考驗。時至今日，它仍然是幾乎所有關聯式資料庫中的標準索引實現，許多非關聯式資料庫也使用 B 樹。

與 SSTable 一樣，B 樹按鍵儲存有序的鍵值對，因而能夠高效地查詢鍵值和執行範圍查詢。但相似之處也到此為止：B 樹有著截然不同的設計理念。

前面看到的日誌結構索引把資料庫分成大小可變的 段（segment），通常每段為幾兆位元組或更大；段只寫入一次，此後便不可變。相比之下，B 樹把資料庫分成大小固定的 塊 或 頁，並允許就地覆蓋頁。傳統的頁大小是 4 KiB，不過 PostgreSQL 目前預設使用 8 KiB，MySQL 預設使用 16 KiB。

每一頁都有頁號作為標識，因此一頁可以引用另一頁——類似於指標，只不過位於磁碟而非記憶體。如果所有頁都儲存在同一個檔案中，頁號乘以頁大小，就是該頁在檔案中的位元組偏移量。利用這些頁引用可以構造一棵頁組成的樹，如 圖 4-5 所示。

其中一頁被指定為 B 樹的 根（root）；在索引中查詢鍵時，總是從這裡開始。根頁包含若干個鍵和對子頁的引用。每個子頁負責一段連續的鍵範圍，引用之間的鍵標示出相鄰範圍的邊界。（這種結構有時稱為 B+ 樹，不過這裡不必把它與其他 B 樹變體區分開來。）

在 圖 4-5 的例子中，我們要尋找鍵 251，因此沿著邊界 200 與 300 之間的頁引用向下走。接下來的一頁結構相似，只是把 200–300 進一步劃分成更小的子範圍。最終會到達包含各個鍵的 葉頁（leaf page）；葉頁或者直接儲存每個鍵的值，或者儲存指向值所在頁的引用。

B 樹一頁中對子頁的引用數稱為 分支因子（branching factor）。例如，圖 4-5 中的分支因子為 6。實踐中的分支因子取決於頁引用和範圍邊界所需的空間，不過通常可達幾百。

如果要更新 B 樹中已有鍵的值，就先找到包含該鍵的葉頁，再用含有新值的版本覆蓋磁碟上的這一頁。如果要新增新鍵，則找到範圍涵蓋該鍵的頁，並把鍵加入其中。如果頁內沒有足夠的空閒空間容納新鍵，就把它拆成兩個半滿的頁，並更新父頁，以反映鍵範圍的新劃分。

在 圖 4-6 中，我們想插入鍵 334，但負責 333–345 範圍的頁已經裝滿。於是把它拆成兩頁：一頁負責 333–337（幷包含新鍵），另一頁負責 337–344。父頁也必須更新，增加對兩個子頁的引用，並以 337 作為二者的邊界。如果父頁容不下新的引用，它也要拆分；這種拆分可能一路向上傳播到樹根。根頁拆分時，則在其上方建立一個新根。刪除鍵還可能需要合併節點，處理起來更加複雜 ⁵。

這個演算法可以確保樹始終 平衡（balanced）：包含 n 個鍵的 B 樹深度總是 O(log n)。大多數資料庫只需要三四層深的 B 樹，因此不必沿著很多頁引用就能找到目標頁。（一棵四層深、頁大小為 4 KiB、分支因子為 500 的樹，最多可以儲存 250 TB 資料。）

使 B 樹可靠

B 樹最基本的底層寫操作，是用新資料覆寫磁碟上的頁，並假定覆寫不會改變頁的位置：也就是說，頁被覆寫後，所有指向它的引用仍然有效。這與 LSM 樹一類日誌結構索引形成鮮明對比；後者只向檔案追加寫入（並最終刪除過時檔案），從不就地修改檔案。

一次覆寫多個頁——例如拆分頁時——是很危險的操作。如果資料庫只寫完其中一部分就崩潰，最終會留下損壞的樹（例如出現不屬於任何父頁的 孤兒頁，orphan page）。如果硬體不能原子地寫入整頁，還可能留下只寫了一部分的頁，這稱為 頁撕裂（torn page）²³。

為了讓資料庫能夠從崩潰中恢復，B 樹實現通常會在磁碟上維護一個額外的資料結構：預寫日誌（write-ahead log，WAL）。這是一個僅追加檔案；對 B 樹的每項修改，都必須先寫入 WAL，才能應用到樹本身的頁上。資料庫在崩潰後重新啟動時，會用這個日誌把 B 樹恢復到一致狀態 ^{2 24}。檔案系統中的對應機制稱為 日誌機制（journaling）。

為了提高效能，B 樹實現通常不會立刻把每個修改過的頁寫入磁碟，而是先把 B 樹頁在記憶體中緩衝一段時間。此時，預寫日誌還負責確保崩潰時不丟資料：只要資料已寫入 WAL，並透過 fsync() 系統呼叫刷到磁碟，它就是持久的，因為資料庫能夠在崩潰後將它恢復出來 ²⁵。

B 樹變體

由於 B 樹已經存在很久，多年來發展出了許多變體。這裡只舉幾例：

• 一些資料庫（如 LMDB）不覆寫頁，也不靠 WAL 進行崩潰恢復，而是採用寫時複製方案 ²⁶。修改過的頁寫入新的位置，併為樹中的父頁建立新版本，使其指向新位置。這種方法對併發控制也很有用，我們將在 “快照隔離與可重複讀” 中看到。
• 可以不儲存完整的鍵，而只儲存其縮寫，以節省頁內空間。尤其在樹的內部頁中，鍵只需包含足夠的資訊，能夠充當鍵範圍之間的邊界即可。一頁容納的鍵越多，樹的分支因子就越大，層數也越少。
• 為了加快按排序順序掃描鍵範圍，有些 B 樹實現會盡量安排樹的佈局，使葉頁在磁碟上也按順序出現，從而減少磁碟尋道。不過隨著樹不斷增長，這種順序很難維持。
• 還可以向樹中加入額外的指標。例如，讓每個葉頁引用左右相鄰的兄弟頁，便能按順序掃描鍵，而不必反覆跳回父頁。

比較 B 樹與 LSM 樹

根據經驗，LSM 樹更適合寫入密集型應用，而 B 樹的讀取通常更快 ^{27 28}。不過，基準測試結果往往對工作負載的細節非常敏感。只有使用自己的實際工作負載測試系統，比較才有意義。此外，LSM 樹與 B 樹並非嚴格的二選一：儲存引擎有時會融合兩種方法的特點，例如維護多棵 B 樹，再用 LSM 風格將它們合併。本節將簡要討論衡量儲存引擎效能時值得考慮的幾個方面。

讀取效能

在 B 樹中查詢鍵，需要在樹的每一層讀取一頁。由於層數通常很少，B 樹讀取一般很快，效能也比較容易預測。LSM 儲存引擎往往需要檢查處於不同壓實階段的多個 SSTable，不過布隆過濾器能減少實際需要執行的磁碟 I/O 次數。兩種方法都可能有良好表現；究竟哪種更快，取決於儲存引擎的具體實現和工作負載。

B 樹本身有序，因此範圍查詢簡單而快速。LSM 儲存也能利用 SSTable 的排序，但必須並行掃描所有段，再把結果合併起來。布隆過濾器對範圍查詢無能為力，因為不可能計算範圍內每個潛在鍵的雜湊；所以在 LSM 儲存中，範圍查詢的成本高於點查詢 ²⁹。

在日誌結構儲存引擎中，高寫入吞吐量可能在記憶體表填滿時引發延遲尖峰。如果資料來不及寫入磁碟——或許因為壓實速度趕不上新增寫入——就會出現這種情況。包括 RocksDB 在內的許多儲存引擎會在此時施加 背壓（backpressure）：暫停所有讀寫，直到記憶體表寫入磁碟 ^{30 31}。

至於讀取吞吐量，現代 SSD（尤其是 NVMe）可以並行處理許多相互獨立的讀取請求。LSM 樹和 B 樹都能提供很高的讀取吞吐量，但儲存引擎必須經過精心設計，才能利用這種並行能力 ³²。

順序與隨機寫入

使用 B 樹時，如果應用寫入的鍵散佈在整個鍵空間，產生的磁碟操作也會四處分散，因為儲存引擎要覆寫的頁可能位於磁碟任何位置。日誌結構儲存引擎則一次寫出整個段檔案——無論是把記憶體表寫出，還是壓實現有段——其大小遠遠超過 B 樹中的一頁。

這種數量多、規模小而位置分散的寫入模式（如 B 樹）稱為 隨機寫入（random write）；數量少、規模較大的寫入模式（如 LSM 樹）則稱為 順序寫入（sequential write）。磁碟的順序寫入吞吐量通常高於隨機寫入，因此在相同硬體上，日誌結構儲存引擎一般能承受比 B 樹更高的寫入吞吐量。這種差異在機械硬碟（HDD）上尤其顯著；如今多數資料庫使用固態硬碟（SSD），差距有所縮小，但依然不可忽略（參見 “SSD 上的順序與隨機寫入”）。

寫放大

無論採用哪種儲存引擎，應用發出的一次寫請求都會轉化為底層磁碟上的多次 I/O。對 LSM 樹而言，一個值首先寫入日誌以確保永續性；記憶體表寫入磁碟時又寫一次；此後每次所在的鍵值對參與壓實，還要再次寫入。（如果值遠大於鍵，可以把鍵和值分開存放，只壓實包含鍵和值引用的 SSTable，以降低這項開銷 ³⁷。）

B 樹索引也必須把每份資料至少寫兩次：一次寫入預寫日誌，一次寫入樹頁本身。為了確保 B 樹能在崩潰或斷電後正確恢復，有時即使頁內只有幾個位元組發生變化，也必須寫出整頁 ^{38 39}。

把某個工作負載實際寫入磁碟的總位元組數，除以不帶索引、只寫僅追加日誌時所需的位元組數，得到的比值就是 寫放大（write amplification）。（寫放大有時也按 I/O 操作次數而非位元組數定義。）在寫入密集型應用中，瓶頸可能是資料庫向磁碟寫入的速度。此時寫放大越高，在有限磁碟頻寬內每秒能處理的寫入就越少。

LSM 樹和 B 樹都有寫放大問題。孰優孰劣取決於許多因素，例如鍵和值的長度，以及覆蓋現有鍵與插入新鍵各有多頻繁。對典型工作負載而言，LSM 樹往往具有更低的寫放大，因為它不必寫出整頁，還可以壓縮 SSTable 中的資料塊 ⁴⁰。這也是 LSM 儲存引擎適合寫入密集型工作負載的原因之一。

寫放大除了影響吞吐量，也關係到 SSD 的磨損：儲存引擎的寫放大越低，SSD 損耗得就越慢。

測量儲存引擎的寫入吞吐量時，實驗必須執行足夠長的時間，才能顯現寫放大的影響。剛開始向空 LSM 樹寫入時，壓實尚未發生，全部磁碟頻寬都可供新寫入使用。隨著資料庫增長，新寫入便不得不與壓實共享磁碟頻寬。

磁碟空間使用

B 樹可能隨著時間推移逐漸 碎片化。例如，刪除大量鍵之後，資料庫檔案裡可能留下許多 B 樹不再使用的頁。以後向 B 樹新增資料時可以複用這些空閒頁，但它們位於檔案中間，很難歸還給作業系統，所以仍會佔用檔案系統空間。因此，資料庫需要後臺程序搬移並重新整理這些頁，例如 PostgreSQL 的清理（vacuum）程序 ²⁵。

碎片化對 LSM 樹來說問題較小，因為壓實過程本來就會定期重寫資料檔案，而且 SSTable 中不存在留有空閒空間的頁。此外，SSTable 中的鍵值對塊更便於壓縮，所以生成的磁碟檔案通常小於 B 樹。已經覆蓋的鍵和值會繼續佔用空間，直到在壓實中移除；不過採用分級壓實時，這項開銷相當低 ^{40 41}。按大小分層壓實（參見 “壓實策略”）會佔用更多磁碟空間，尤其是在壓實過程中臨時佔用的空間。

如果需要刪除某些資料並確信它們確實已經消失——例如為了遵守資料保護法規——磁碟上並存的多份副本也會帶來麻煩。在大多數 LSM 儲存引擎中，已刪除的記錄仍可能留在較高層級，直到代表刪除操作的墓碑傳遍所有壓實層級；這一過程可能持續很久。有些專門的儲存引擎設計可以更快地傳播刪除操作 ⁴²。

另一方面，SSTable 段檔案的不可變性很適合為資料庫建立時間點快照（例如用於備份，或複製一份資料庫進行測試）：只需寫出記憶體表，再記下當時存在哪些段檔案。只要不刪除屬於快照的檔案，就完全不必實際複製它們。B 樹會覆寫頁，因此很難如此高效地建立快照。

多列索引與二級索引

到目前為止，我們只討論了鍵值索引，它們類似於關係模型中的 主鍵 索引。主鍵唯一標識關係表中的一行、文件資料庫中的一個文件，或圖資料庫中的一個頂點。資料庫裡的其他記錄可以透過主鍵（或 ID）引用這一行、文件或頂點，而索引負責解析這種引用。

二級索引 也很常見。在關聯式資料庫中，可以用 CREATE INDEX 命令在同一張表上建立多個二級索引，從而按主鍵以外的列進行搜尋。例如，圖 3-1（見 第 3 章）中的各張表很可能都要在 user_id 列上建立二級索引，以便找出屬於同一使用者的所有行。

二級索引很容易用鍵值索引構建。主要區別在於，二級索引中的被索引值不一定唯一，也就是說，同一個索引條目下可能對應許多行（或文件、頂點）。有兩種解決辦法：把索引中的值做成匹配行識別符號的列表（類似全文索引的倒排列表）；或者在每個索引項後附加行識別符號，使它成為唯一項。B 樹一類就地更新的儲存引擎和日誌結構儲存都可以實現二級索引。

在索引中儲存值

索引中的鍵是查詢要搜尋的內容，而值可以採用以下幾種形式：

• 如果實際資料（行、文件或頂點）直接儲存在索引結構中，這就是 聚簇索引。例如，MySQL 的 InnoDB 儲存引擎總是把表的主鍵作為聚簇索引；SQL Server 則允許每張表指定一個聚簇索引 ⁴³。
• 另一種選擇是讓值引用實際資料：它可以是相應行的主鍵（InnoDB 的二級索引便是如此），也可以直接引用磁碟上的位置。後一種情況下，存放行的地方稱為 堆檔案（heap file）；堆檔案中的資料沒有特定順序，可以是僅追加的，也可以記錄已刪除的行，以便日後用新資料覆寫。例如，Postgres 就使用堆檔案 ⁴⁴。
• 兩者之間的折中稱為 覆蓋索引（covering index）或 包含列的索引（index with included columns）：完整的行仍儲存在堆檔案或主鍵聚簇索引中，但索引也會儲存表的 部分 列 ⁴⁵。這樣，一些查詢只用索引就能得到答案，不必再解析主鍵或訪問堆檔案；此時稱該索引 覆蓋 了查詢。覆蓋索引可以加快某些查詢，但重複資料會佔用更多磁碟空間，也會拖慢寫入。

到目前為止討論的索引，都只是把單個鍵對映到值。如果需要同時查詢表中的多個列（或文件中的多個欄位），請參見 “多維索引與全文索引”。

更新值但不改變鍵時，只要新值不大於舊值，堆檔案就能就地覆寫記錄。如果新值更大，情況會複雜一些：記錄可能必須移到堆內空間足夠的新位置。此時，要麼更新所有索引，使其指向記錄在堆中的新位置；要麼在舊位置留下一個轉發指標 ²。

全記憶體儲存

本章到目前為止討論的資料結構，都是對磁碟侷限的應對。與主記憶體相比，磁碟處理起來很麻煩。無論是磁性硬碟還是 SSD，要想獲得良好的讀寫效能，都必須仔細安排資料在磁碟上的佈局。不過我們能容忍這種麻煩，是因為磁碟有兩項顯著優勢：它是持久的（斷電後內容不會丟失），而且每 GB 的成本低於 RAM。

隨著 RAM 越來越便宜，磁碟的每 GB 成本優勢正在減弱。許多資料集本來就沒有那麼大，因此完全可以把它們全部放進記憶體，必要時還可以分佈到多臺機器上。於是，記憶體資料庫 發展了起來。

有些記憶體鍵值儲存（如 Memcached）僅用於快取，機器重啟時丟失資料也無妨。但另一些記憶體資料庫以永續性為目標，可以藉助特殊硬體（如電池供電的 RAM）、把變更日誌寫入磁碟、定期把快照寫入磁碟，或把記憶體狀態複製到其他機器來實現。

記憶體資料庫重啟時，需要從磁碟或透過網路從副本重新載入狀態（使用特殊硬體時除外）。它雖然寫磁碟，卻仍然屬於記憶體資料庫，因為磁碟只是用作確保永續性的僅追加日誌，所有讀取都由記憶體處理。寫入磁碟還有運維上的好處：外部工具可以輕鬆備份、檢查和分析磁碟上的檔案。

VoltDB、SingleStore 和 Oracle TimesTen 等產品是採用關係模型的記憶體資料庫。供應商宣稱，省去管理磁碟資料結構的全部開銷後，它們可以大幅提高效能 ^{46 47}。RAMCloud 則是一個具備永續性的開源記憶體鍵值儲存，對記憶體和磁碟中的資料都採用日誌結構方法 ⁴⁸。

Redis 和 Couchbase 透過非同步寫入磁碟提供弱永續性。

反直覺的是，記憶體資料庫的效能優勢並不來自省去了磁碟讀取。如果記憶體足夠，即便基於磁碟的儲存引擎也可能從不真正讀取磁碟，因為作業系統本來就會把最近使用的磁碟塊快取在記憶體中。記憶體資料庫之所以更快，是因為它省去了把記憶體資料結構編碼成可寫入磁碟的形式這一開銷 ⁴⁹。

除了效能之外，記憶體資料庫還有一個有趣之處：它可以提供很難用磁碟索引實現的資料模型。例如，Redis 為優先佇列、集合等各種資料結構提供了類似資料庫的介面。由於所有資料都放在記憶體中，實現起來相對簡單。

分析型資料儲存

資料倉儲最常採用關係資料模型，因為 SQL 通常很適合分析查詢。許多圖形化資料分析工具可以生成 SQL 查詢、視覺化查詢結果，並讓分析師透過 下鑽、切片與切塊 等操作探索資料。

表面上，資料倉儲與關係型 OLTP 資料庫十分相似，因為二者都有 SQL 查詢介面。然而，它們的內部實現可能大相徑庭，因為兩者針對的查詢模式完全不同。如今，許多資料庫供應商只專注於事務處理或分析工作負載中的一種，而非兩者兼顧。

Microsoft SQL Server、SAP HANA 和 SingleStore 等資料庫在同一產品中同時支援事務處理和資料倉儲。不過，這些混合事務/分析處理（HTAP）資料庫（已在 “資料倉儲” 中介紹）正日益演變成兩套彼此獨立的儲存與查詢引擎，只是恰好透過同一個 SQL 介面訪問 ^{50 51 52 53}。

雲資料倉儲

Teradata、Vertica 和 SAP HANA 等資料倉儲供應商，既以商業許可證銷售本地部署的資料倉儲，也提供雲端解決方案。隨著越來越多的客戶遷往雲端，Google Cloud BigQuery、Amazon Redshift 和 Snowflake 等新一代雲資料倉儲也得到廣泛採用。與傳統資料倉儲不同，雲資料倉儲會利用物件儲存、無伺服器計算平臺等可伸縮的雲基礎設施。

雲資料倉儲通常能更好地整合其他雲服務，也更具彈性。例如，許多雲資料倉儲支援自動攝取日誌，並且可以輕鬆接入 Google Cloud Dataflow、Amazon Web Services Kinesis 等資料處理框架。它們把查詢計算與儲存層解耦，因此也更具彈性 ⁵⁴。資料持久儲存在物件儲存而非本地磁碟上，於是儲存容量和查詢計算資源可以分別調整，正如 “雲原生系統架構” 所介紹的那樣。

Apache Hive、Trino 和 Apache Spark 等開源資料倉儲也隨著雲端計算共同演進。分析資料儲存遷入物件儲存上的資料湖之後，開源資料倉儲開始拆分、解耦 ⁵⁵。過去整合在 Apache Hive 這類單一系統中的功能，如今往往由以下獨立元件實現：

查詢引擎

Trino、Apache DataFusion 和 Presto 等查詢引擎負責解析 SQL 查詢，將其最佳化成執行計劃，再針對資料執行。查詢通常需要由分散式任務並行處理。有些查詢引擎內建了任務執行能力，另一些則藉助 Apache Spark 或 Apache Flink 等第三方執行框架。

儲存格式

儲存格式規定如何把表中的行編碼成檔案裡的位元組；檔案通常儲存在物件儲存或分散式檔案系統中 ¹²。查詢引擎可以訪問這些資料，使用同一資料湖的其他應用也可以。Parquet、ORC、Lance 和 Nimble 都屬於這類格式，下一節還會進一步介紹。

表格式

以 Apache Parquet 等儲存格式寫出的檔案通常不可變。為了支援插入和刪除行，還要使用 Apache Iceberg 或 Databricks Delta 等表格式。表格式用一種檔案格式來定義哪些檔案構成一張表，以及這張表採用什麼模式。它還可以提供時間旅行（查詢表在過去某個時刻的狀態）、垃圾回收乃至事務等高階功能。

資料目錄

正如表格式定義哪些檔案組成一張表，資料目錄定義哪些表組成一個資料庫。目錄用於建立、重新命名和刪除表。與儲存格式和表格式不同，Snowflake Polaris、Databricks Unity Catalog 等資料目錄通常作為獨立服務執行，並透過 REST 介面接受查詢。Apache Iceberg 也提供目錄，既可以嵌入客戶端執行，也可以作為獨立程序執行。查詢引擎讀寫表時會使用目錄資訊。傳統上，目錄與查詢引擎整合在一起；將二者解耦之後，資料發現和資料治理系統（見 “資料系統、法律與社會”）也可以訪問目錄中的後設資料。

列式儲存

正如 “星型與雪花型：分析模式” 所述，資料倉儲通常採用關係模式：一張巨大的事實表透過外來鍵引用各張維度表。如果事實表有數萬億行、數 PB 資料，如何高效儲存和查詢就成了嚴峻挑戰。維度表通常小得多（只有數百萬行），所以本節將重點討論事實表的儲存。

儘管事實表通常有 100 多列，但典型的資料倉儲查詢一次只訪問其中 4、5 列（分析查詢很少需要 "SELECT *"）⁵²。以 示例 4-1 為例：它會訪問大量行（2024 年中每一筆水果或糖果銷售記錄），卻只需要 fact_sales 表中的三列：date_key、product_sk 和 quantity。其他所有列都被查詢忽略了。

SELECT
    dim_date.weekday, dim_product.category,
    SUM(fact_sales.quantity) AS quantity_sold
FROM fact_sales
    JOIN dim_date ON fact_sales.date_key = dim_date.date_key
    JOIN dim_product ON fact_sales.product_sk = dim_product.product_sk
WHERE
    dim_date.year = 2024 AND
    dim_product.category IN ('Fresh fruit', 'Candy')
GROUP BY
    dim_date.weekday, dim_product.category;

怎樣才能高效執行這個查詢？

大多數 OLTP 資料庫都以 面向行（row-oriented）的方式佈置儲存：表中同一行的所有值相鄰存放。文件資料庫也很相似，通常把整個文件存成一段連續的位元組序列。圖 4-1 的 CSV 示例就是如此。

為了處理 示例 4-1 這樣的查詢，可以在 fact_sales.date_key 和（或）fact_sales.product_sk 上建立索引，告訴儲存引擎去哪裡尋找某一天或某種產品的所有銷售記錄。但面向行的儲存引擎仍要把這些完整的行（每行有 100 多個屬性）從磁碟載入記憶體，逐一解析，再過濾掉不滿足條件的行。這個過程可能十分耗時。

面向列（column-oriented，或 列式，columnar）儲存背後的想法很簡單：不要把同一行中的所有值放在一起，而要把同一 列 中的所有值放在一起 ⁵⁶。每列分別儲存後，查詢只需讀取和解析自己用到的列，能省下大量工作。圖 4-7 用 圖 3-5 中事實表的擴充套件版本展示了這一原理。

面向列的儲存佈局要求每一列都按相同的行順序儲存資料。因此，要重新拼出完整的一行，可以分別取出每列中的第 23 項，把它們組合成表的第 23 行。

實際上，列式儲存引擎並不會把完整的一列（可能有數萬億行）一次存放在一起。它會把表切成若干個包含數千乃至數百萬行的資料塊，再在每個塊內分別儲存各列的值 ⁶⁰。許多查詢只關注特定日期範圍，因此常讓每個塊包含某個時間戳範圍內的行。查詢只需在與目標日期範圍重疊的塊中，載入自己需要的列。

如今，幾乎所有分析資料庫都採用列式儲存 ⁶⁰：從 Snowflake ⁶¹ 這樣的大型雲資料倉儲，到 DuckDB ⁶² 這樣的單節點嵌入式資料庫，再到 Pinot ⁶³、Druid ⁶⁴ 等產品分析系統。Parquet、ORC ^{65 66}、Lance ⁶⁷ 和 Nimble ⁶⁸ 等儲存格式，以及 Apache Arrow ^{65 69}、pandas/NumPy ⁷⁰ 等記憶體分析格式，也都採用列式佈局。InfluxDB IOx ⁷¹、TimescaleDB ⁷² 等時間序列資料庫同樣以列式儲存為基礎。

列壓縮

除了只從磁碟載入查詢需要的列，還可以壓縮資料，進一步降低對磁碟吞吐量和網路頻寬的需求。幸運的是，列式儲存通常很適合壓縮。

看看 圖 4-7 中各列的值序列：它們往往相當重複，這是很適合壓縮的訊號。根據列中資料的不同，可以選用不同的壓縮技術。其中對資料倉儲特別有效的一種是 點陣圖編碼，如 圖 4-8 所示。

通常，一列中不同值的數量遠小於總行數（例如，零售商可能有數十億筆銷售交易，卻只有 100,000 種產品）。可以把一個具有 n 個不同值的列轉換成 n 張獨立點陣圖：每個不同值對應一張點陣圖，每一行對應其中一位。如果該行取這個值，對應位就是 1，否則為 0。

一種選擇是按每行一位直接儲存這些點陣圖。不過，點陣圖中通常有大量的 0，也就是十分 稀疏。這時還可以使用遊程編碼：統計連續出現的 0 或 1 的數量，並存下這個數字，如 圖 4-8 底部所示。Roaring 點陣圖會在兩種點陣圖表示之間切換，總是選用更緊湊的一種 ⁷³。這樣可以極其高效地編碼一整列。

像這樣的點陣圖索引非常適合資料倉儲中常見的查詢型別。例如：

WHERE product_sk IN (31, 68, 69):

載入 product_sk = 31、product_sk = 68 和 product_sk = 69 對應的三張點陣圖，再計算三者的按位 或，這個操作可以非常高效地完成。

WHERE product_sk = 30 AND store_sk = 3:

載入 product_sk = 30 和 store_sk = 3 對應的點陣圖，再計算按位 與。之所以可行，是因為各列中的行順序相同：一列點陣圖中的第 k 位，與另一列點陣圖中的第 k 位對應同一行。

點陣圖也可以回答圖查詢，例如找出社交網路中所有“被使用者 X 關注、同時又關注使用者 Y”的使用者 ⁷⁴。列式資料庫還有許多其他壓縮方案，參見參考文獻 ⁷⁵。

列儲存中的排序順序

在列式儲存中，行的儲存順序並不一定重要。最簡單的方式是按插入順序存放，因為插入新行時只需向每一列追加資料。不過，也可以像此前處理 SSTable 那樣，為資料指定某種順序，並把這種順序用作索引機制。

注意，分別對每一列獨立排序毫無意義，因為那樣就再也不知道不同列中的哪些項屬於同一行。我們之所以能夠重建一行，正是因為一列中的第 k 項與另一列中的第 k 項屬於同一行。

因此，即使資料按列儲存，排序也必須以整行為單位。資料庫管理員可以根據自己對常見查詢的瞭解，選擇表按哪些列排序。例如，如果查詢經常針對“上個月”這樣的日期範圍，就可以把 date_key 作為第一個排序鍵。這樣查詢只需掃描上個月的行，比掃描所有行快得多。

對於第一排序列中取值相同的行，可以用第二列進一步決定順序。例如，如果 圖 4-7 以 date_key 為第一排序鍵，那麼把 product_sk 作為第二排序鍵或許很有用：同一天、同一種產品的所有銷售記錄就會在儲存中相鄰。這有利於在特定日期範圍內按產品分組或篩選銷售記錄的查詢。

排序的另一個好處是有助於列壓縮。如果主排序列沒有太多不同的值，排序後會形成很長的連續序列，同一個值反覆出現。使用簡單的遊程編碼——就像 圖 4-8 中的點陣圖一樣——即可把這一列壓縮到幾千位元組，即使表中有數十億行也不例外。

這種壓縮效果在第一排序鍵上最強。第二、第三排序鍵會更加雜亂，不會出現那麼長的重複值序列。排序優先順序更低的列基本呈隨機順序，壓縮效果可能不佳。不過，只要前幾列經過排序，整體上依然受益。

寫入列式儲存

我們在 “事務處理與分析的特徵” 中看到，資料倉儲的讀取通常要聚合大量行；列式儲存、壓縮和排序都能加快這類讀查詢。資料倉儲的寫入則往往是批次匯入資料，通常透過 ETL 流程完成。

對列式儲存而言，在有序表的中間插入單獨一行非常低效，因為從插入位置開始，所有壓縮列都必須重寫。但一次批次寫入很多行，可以分攤重寫這些列的成本，因而效率很高。

批次寫入通常採用日誌結構方法。所有寫入先進入一個面向行、有序的記憶體儲存。積累足夠多的寫入後，再與磁碟上的列編碼檔案合併，併成批寫入新檔案。舊檔案保持不可變，新檔案一次寫成，所以物件儲存很適合儲存這些檔案。

查詢必須同時檢查磁碟上的列資料和記憶體中的近期寫入，再把兩部分結果合併起來。查詢執行引擎會向使用者隱藏這項區別。在分析師看來，插入、更新或刪除的資料會立刻反映在後續查詢中。Snowflake、Vertica、Apache Pinot、Apache Druid 等許多系統都是這樣做的 ^{61 63 64 76}。

查詢執行：編譯與向量化

複雜的分析型 SQL 查詢會被分解成一個 查詢計劃（query plan），其中包含多個稱為 運算元（operator）的執行階段；這些運算元可能分佈到多臺機器上並行執行。查詢規劃器可以決定選用哪些運算元、以什麼順序執行，以及每個運算元在哪裡執行，從而完成大量最佳化。

在每個運算元內部，查詢引擎都要對列中的值執行各種操作，例如找出值屬於某個集合的所有行（或許是連線的一部分），或者判斷值是否大於 15。查詢引擎還要同時檢視同一行的多個列，例如找出產品是香蕉、門店又恰好是目標門店的所有銷售記錄。

資料倉儲查詢需要掃描數百萬行，因此不僅要關注從磁碟讀取的資料量，還要關注執行複雜運算元所需的 CPU 時間。最簡單的運算元就像程式語言直譯器：遍歷每一行時，檢視錶示查詢的資料結構，弄清要對哪些列做什麼比較或計算。遺憾的是，這種方式對許多分析場景來說太慢。實踐中出現了兩種高效執行查詢的方法 ⁷⁷：

查詢編譯（query compilation）

查詢引擎根據 SQL 查詢生成執行程式碼。程式碼逐行迭代，讀取相關列中的值，完成所需的比較或計算；如果條件滿足，就把必要的值複製到輸出緩衝區。隨後，查詢引擎把生成的程式碼編譯成機器碼（往往藉助 LLVM 等現有編譯器），再對已經載入記憶體的列編碼資料執行。這種程式碼生成方式類似 Java 虛擬機器（JVM）等執行時採用的即時（JIT）編譯。

向量化處理（vectorized processing）

查詢仍然採用解釋執行，而非編譯執行；但它不再逐行迭代，而是成批處理一列中的許多值，從而提高速度。資料庫內建一組固定的預定義運算元，向運算元傳入引數，就會得到一批結果 ^{50 75}。

例如，把 product_sk 列和“香蕉”的 ID 傳給相等比較運算元，會得到一張點陣圖：輸入列的每個值對應一位，是香蕉則為 1。再把 store_sk 列和目標門店的 ID 傳給同一個運算元，得到另一張點陣圖。最後把兩張點陣圖傳給“按位與”運算元，如 圖 4-9 所示。結果點陣圖中，特定門店售出的每一筆香蕉都對應一個 1。

這兩種方法的實現大不相同，但都已投入實際使用 ⁷⁷。它們都能利用現代 CPU 的特點，獲得優異效能：

• 優先順序訪問記憶體而非隨機訪問，減少快取未命中 ⁷⁸；
• 把大部分工作放在緊湊的內層迴圈中（指令少且沒有函式呼叫），使 CPU 指令流水線保持忙碌，並避免分支預測錯誤；
• 利用多執行緒和單指令多資料（SIMD）指令等並行機制 ^{79 80}；
• 直接處理壓縮資料，不先解碼成另一種記憶體表示，從而省去記憶體分配和複製的成本。

物化檢視與多維資料集

我們曾在 “時間線的物化與更新” 中遇到 物化檢視（materialized view）。在關係資料模型中，它是一種類似表的物件，內容是某個查詢的結果。物化檢視是實際寫入磁碟的查詢結果副本，而虛擬檢視只是編寫查詢的快捷方式。從虛擬檢視讀取時，SQL 引擎會即時把它展開成底層查詢，再處理展開後的查詢。

底層資料變化時，物化檢視也必須隨之更新。有些資料庫可以自動完成這項工作，Materialize 等系統則專門負責維護物化檢視 ⁸¹。更新檢視會增加寫入工作量，但如果工作負載反覆執行相同查詢，物化檢視可以改善讀取效能。

物化聚合（materialized aggregate）是一類對資料倉儲很有用的物化檢視。如前所述，資料倉儲查詢經常使用 SQL 中的 COUNT、SUM、AVG、MIN 或 MAX 等聚合函式。如果許多查詢都使用相同的聚合，每次重新處理原始資料就太浪費了，何不把最常用的計數或總和快取起來？多維資料集（data cube，或 OLAP 多維資料集，OLAP cube）會建立一個按不同維度分組的聚合網格，正是為了實現這種快取 ⁸²。圖 4-10 展示了一個例子。

暫且假設每條事實記錄只外來鍵引用兩張維度表——圖 4-10 中是 date_key 和 product_sk。這樣可以畫出一張二維表，一條軸表示日期，另一條軸表示產品。每個單元格儲存具有相應“日期—產品”組合的所有事實記錄中，某項屬性（如 net_price）的聚合值（如 SUM）。再沿每一行或每一列應用同樣的聚合，就能得到減少一個維度的彙總結果：不考慮日期的產品銷售額，或者不考慮產品的逐日銷售額。

一般而言，事實往往不止兩個維度。圖 3-5 中就有日期、產品、門店、促銷和客戶五個維度。五維超立方體很難想象，但原理仍然一樣：每個單元格儲存特定“日期—產品—門店—促銷—客戶”組合的銷售額，隨後可以沿每個維度反覆彙總這些值。

物化多維資料集的優點，是某些查詢會變得非常快，因為結果實際上已經預先計算好了。例如，要知道昨天每家門店的總銷售額，只需檢視相應維度上的彙總值，不必掃描數百萬行。

缺點是多維資料集不如直接查詢原始資料靈活。例如，價格不是其中一個維度，就無法計算有多大比例的銷售額來自售價超過 100 美元的商品。因此，大多數資料倉儲會儘可能保留原始資料，只把多維資料集等聚合用作某些查詢的效能最佳化手段。

多維索引與全文索引

本章前半部分介紹的 B 樹和 LSM 樹，可以對單個屬性執行範圍查詢。例如，如果鍵是使用者名稱，就能用它們建立索引，高效找出所有以 L 開頭的名字。但有時，只按一個屬性搜尋並不夠用。

最常見的多列索引稱為 聯合索引（concatenated index）。它把一列接在另一列之後，將多個欄位組合成一個鍵；欄位的連線順序由索引定義指定。這就像老式紙質電話簿提供的索引：從（姓、名）對映到電話號碼。由於索引按這個順序排列，可以找出某個姓氏對應的所有人，也可以找出特定 姓—名 組合對應的所有人。但如果只想查詢某個名字對應的所有人，這個索引就毫無用處。

多維索引（multidimensional index）則允許同時查詢多個列，這對地理空間資料尤其重要。例如，餐廳搜尋網站的資料庫可能儲存了每家餐廳的經緯度。使用者檢視地圖時，網站需要找出當前矩形地圖區域內的所有餐廳。這就需要下面這樣的二維範圍查詢：

SELECT * FROM restaurants WHERE latitude > 51.4946 AND latitude < 51.5079
    AND longitude > -0.1162 AND longitude < -0.1004;

在緯度和經度列上建立聯合索引，無法高效回答這個查詢：它只能返回某一緯度範圍內的所有餐廳（經度任意），或者某一經度範圍內的所有餐廳（緯度可以是南北兩極之間的任意位置），卻無法同時約束兩者。

一種辦法是使用空間填充曲線把二維位置轉換成單個數字，再建立普通的 B 樹索引 ⁸³。更常見的做法是使用 R 樹、Bkd 樹 ⁸⁴ 等專門的空間索引；它們對空間進行劃分，讓鄰近的資料點儘量落在同一棵子樹中。例如，PostGIS 使用 PostgreSQL 的通用搜尋樹索引設施，以 R 樹實現地理空間索引 ⁸⁵。另一種選擇是使用規則排布的三角形、正方形或六邊形網格 ⁸⁶。

多維索引並不只用於地理位置。例如，電子商務網站可以在（紅、綠、藍）三個維度上建立索引，以搜尋特定顏色範圍內的產品；天氣觀測資料庫也可以在（日期、溫度）上建立二維索引，高效找出 2013 年中溫度介於 25～30℃ 的所有觀測記錄。使用一維索引，要麼必須掃描 2013 年的所有記錄（不考慮溫度）再按溫度篩選，要麼反過來處理。二維索引則可以同時按時間戳和溫度縮小結果範圍 ⁸⁷。

全文檢索

全文檢索（full-text search）允許按關鍵詞搜尋一組文字文件（網頁、產品描述等），關鍵詞可以出現在文字中的任意位置 ⁸⁸。資訊檢索是一門龐大而專門的學科，往往還要針對具體語言進行處理。例如，一些亞洲語言書寫時不會在詞與詞之間新增空格或標點，因此把文字切分成詞需要藉助模型，判斷哪些字元序列構成一個詞。全文檢索還經常需要匹配相似但不完全相同的詞（例如拼寫錯誤或同一個詞的不同語法形式），以及同義詞。這些問題都超出了本書的範圍。

不過從核心原理看，全文檢索也可以視為一種多維查詢：文字中可能出現的每個詞（即一個 詞項，term）都是一個維度。包含詞項 x 的文件在維度 x 上取值為 1，不包含 x 則取值為 0。搜尋提到“紅蘋果”的文件，就是同時尋找 紅 維度和 蘋果 維度都為 1 的文件。這樣一來，維度數可能非常龐大。

許多搜尋引擎使用 倒排索引（inverted index）回答這類查詢。它是一種鍵值結構：鍵是詞項，值是所有包含該詞項的文件 ID 列表，即 倒排列表（postings list）。如果文件 ID 是連續數字，倒排列表也可以表示成 圖 4-8 那樣的稀疏點陣圖：如果 ID 為 n 的文件包含詞項 x，那麼詞項 x 的點陣圖中第 n 位就是 1 ⁸⁹。

現在，查詢同時包含詞項 x 和 y 的所有文件，就類似於用向量化資料倉儲查詢尋找滿足兩個條件的行（圖 4-9）：載入 x 和 y 對應的兩張點陣圖，再計算按位與。即使點陣圖經過遊程編碼，這個操作也可以高效完成。

Elasticsearch 和 Solr 使用的全文索引引擎 Lucene 就採用這種方法 ⁹⁰。它把從詞項到倒排列表的對映儲存在類似 SSTable 的有序檔案中，再使用本章前面介紹的日誌結構方法，在後臺合併這些檔案 ⁹¹。PostgreSQL 的 GIN 索引也透過倒排列表支援全文檢索，以及 JSON 文件內部的索引 ^{92 93}。

除了把文字切分成詞，還可以找出所有長度為 n 的子串，稱為 n-gram。例如，字串 "hello" 的 3-gram（n = 3）是 "hel"、"ell" 和 "llo"。如果為所有 3-gram 建立倒排索引，就能搜尋任意長度至少為三個字元的子串。這樣的索引甚至支援在搜尋查詢中使用正規表示式，缺點是體積相當大 ⁹⁴。

為了應對文件或查詢中的拼寫錯誤，Lucene 可以搜尋與目標詞相差一定編輯距離的詞（編輯距離為 1，表示增加、刪除或替換了一個字母）⁹⁵。它把詞項集合儲存成一個以鍵中字元為邊的有限狀態自動機，結構類似 字典樹（trie）⁹⁶；再將其轉換成 萊文斯坦自動機（Levenshtein automaton），從而高效搜尋給定編輯距離以內的詞 ⁹⁷。

向量嵌入

語義搜尋不只處理同義詞和拼寫錯誤，還試圖理解文件表達的概念和使用者的意圖。例如，幫助中心有一頁標題是“取消訂閱”，那麼使用者搜尋“如何關閉賬戶”或“終止合同”時也應當找到它：這些說法用詞完全不同，意思卻十分接近。

為了理解文件的語義，也就是它表達的含義，語義搜尋索引會使用嵌入模型，把文件轉換成由浮點陣列成的向量，稱為 向量嵌入（vector embedding）。這個向量表示多維空間中的一個點，每個浮點數表示文件在某一維座標軸上的位置。如果輸入文件的語義相似，嵌入模型就會生成在多維空間中彼此接近的向量。

例如，一篇介紹農業的維基百科頁面，其三維向量嵌入可能是 [0.1, 0.22, 0.11]。介紹蔬菜的頁面應該離它很近，向量或許是 [0.13, 0.19, 0.24]。介紹星型模式的頁面則可能得到 [0.82, 0.39, -0.74]，距離相對很遠。只看數字也能發現，前兩個向量比第三個更接近。

實際的嵌入模型使用大得多的向量，往往包含 1,000 多個數字，但原理相同。我們不會試圖理解每個數字各自代表什麼；它們只是嵌入模型用來指向抽象多維空間中某個位置的方式。搜尋引擎透過餘弦相似度、歐幾里得距離等距離函式衡量向量間的距離。餘弦相似度計算兩個向量夾角的餘弦，判斷它們有多接近；歐幾里得距離則計算空間中兩點間的直線距離。

Word2Vec ⁹⁸、BERT ⁹⁹ 和 GPT ¹⁰⁰ 等許多早期嵌入模型都處理文字資料，通常以神經網路實現。後來，研究者又為影片、音訊和影象建立了嵌入模型。近來，模型架構進一步走向 多模態（multimodal）：同一個模型可以為文字、影象等多種模態生成向量嵌入。

使用者輸入查詢時，語義搜尋引擎會把查詢及其相關上下文（例如使用者位置）交給嵌入模型，生成查詢的向量嵌入。隨後，搜尋引擎還必須透過向量索引，找出向量嵌入與查詢相似的文件。

向量索引儲存一組文件的向量嵌入。查詢時傳入查詢本身的向量嵌入，索引會返回向量最接近查詢向量的文件。前面介紹的 R 樹不適合維度很高的向量，因此需要專門的向量索引，例如：

平面索引（Flat indexes）

向量原樣儲存在索引中。查詢必須讀取每個向量，並測量它與查詢向量的距離。平面索引結果精確，但逐一計算查詢與每個向量的距離很慢。

倒排檔案（IVF）索引

把向量空間聚類成若干向量分割槽，以減少必須比較的向量數；這些分割槽稱為 質心（centroid）。IVF 索引比平面索引更快，卻只能給出近似結果：查詢向量和某個文件向量可能十分接近，卻恰好落入不同分割槽。查詢 IVF 索引時，首先要指定 探測數（probes），也就是需要檢查多少個分割槽。探測數越大，查詢越準確，但也越慢，因為必須比較更多向量。

分層可導航小世界（HNSW）

HNSW 索引維護向量空間的多個層級，如 圖 4-11 所示。每層都表示成一張圖：節點代表向量，邊表示向量彼此接近。查詢先在節點很少的最頂層找到最近向量，再進入下一層的同一節點；下一層連線更密集，查詢沿邊尋找更接近查詢向量的向量。這個過程不斷重複，直至最底層。與 IVF 一樣，HNSW 也是近似索引。

許多流行的向量資料庫都實現了 IVF 和 HNSW 索引。Facebook 的 Faiss 庫為兩者提供了許多變體 ¹⁰¹，PostgreSQL 的 pgvector 也同時支援這兩種索引 ¹⁰²。IVF 和 HNSW 演算法的完整細節超出了本書範圍，不過介紹它們的論文是很好的參考資料 ^{103 104}。

總結

在本章中，我們試圖深入瞭解資料庫是如何處理儲存與檢索的。把資料存入資料庫時會發生什麼？日後再次查詢這些資料時，資料庫又會做什麼？

“分析型與事務型系統” 介紹了事務處理（OLTP）與分析（OLAP）的區別。本章進一步看到，針對 OLTP 最佳化的儲存引擎，與針對分析最佳化的儲存引擎大不相同：

• OLTP 系統針對大量請求最佳化；每個請求只讀寫少量記錄，並且需要迅速響應。記錄通常透過主鍵或二級索引訪問，這些索引一般是從鍵到記錄的有序對映，也支援範圍查詢。
• 資料倉儲等分析型系統，針對需要掃描大量記錄的複雜讀查詢最佳化。它們通常採用經過壓縮的列式儲存佈局，儘可能減少查詢要從磁碟讀取的資料量；並透過查詢的即時編譯或向量化，儘可能減少處理資料所耗費的 CPU 時間。

在 OLTP 方面，我們看到了兩個主要思想流派的儲存引擎：

• 日誌結構學派只允許向檔案追加資料和刪除過時檔案，從不更新已經寫出的檔案。SSTable、LSM 樹、RocksDB、Cassandra、HBase、ScyllaDB、Lucene 等都屬於這一類。一般而言，日誌結構儲存引擎能提供很高的寫入吞吐量。
• 就地更新學派把磁碟視為一組大小固定、可以覆寫的頁。B 樹是這種理念最典型的代表，所有主流關係型 OLTP 資料庫和許多非關聯式資料庫都使用它。根據經驗，B 樹通常更適合讀取，其讀取吞吐量高於日誌結構儲存，響應時間也更短。

隨後，我們考察了能夠同時搜尋多個條件的索引：R 樹等多維索引可以同時按經度和緯度搜尋地圖上的點；全文檢索索引則可以搜尋同一段文字中出現的多個關鍵詞。最後，向量資料庫用於對文字文件及其他媒體進行語義搜尋；它把資料表示成高維向量，再透過比較向量相似度找出相似文件。

作為應用開發者，如果掌握了這些有關儲存引擎內部機制的知識，就能更好地判斷哪種工具最適合自己的應用。需要調整資料庫的調優引數時，這種理解也讓你能夠設想引數調高或調低會產生怎樣的影響。

儘管本章無法讓你成為某一種儲存引擎的調優專家，但希望它已經提供了足夠的概念和詞彙，讓你能夠讀懂自己所選資料庫的文件。

參考文獻

5 編碼與演化

唯變所適。

以弗所的赫拉克利特，引自柏拉圖《克拉提魯斯》（公元前 360 年）

應用程式不可避免地會隨時間而變化。隨著新產品推出、對使用者需求的理解日益深入，或者商業環境發生變化，應用程式總要增添或修改功能。在 第 2 章 中，我們介紹了 可演化性（evolvability）的概念：應該盡力構建能夠靈活適應變化的系統（參見“可演化性：讓變化更容易”）。

在大多數情況下，修改應用程式的功能也意味著需要更改其儲存的資料：可能需要記錄新的欄位或記錄型別，也可能需要以新的方式呈現現有資料。

我們在 第 3 章 中討論的資料模型，採用不同的方法來應對這種變化。關聯式資料庫通常假定資料庫中的所有資料都遵循同一個模式：儘管可以透過模式遷移（即 ALTER 語句）來更改模式，但任何時刻都只有一個模式有效。相比之下，讀時模式（即“無模式”）資料庫不會強制使用某個模式，因此資料庫中可以混合存放在不同時間寫入的新舊資料格式（參見“文件模型中的模式靈活性”）。

當資料格式或模式發生變化時，通常也需要相應地修改應用程式程式碼（例如，為記錄新增新欄位，然後讓應用程式開始讀寫該欄位）。但在大型應用程式中，程式碼變更往往無法瞬間完成：

• 對於服務端應用程式，可能需要執行 滾動升級（rolling upgrade，也稱為 逐步釋出，staged rollout）：每次只把新版本部署到少數幾個節點，確認執行正常後，再逐步部署到所有節點。這樣無需中斷服務即可上線新版本，有利於更頻繁地釋出，也讓系統更容易演化。
• 對於客戶端應用程式，是否升級只能任由使用者決定，而使用者可能很長時間都不安裝更新。

這意味著，新舊版本的程式碼以及新舊資料格式，可能同時存在於系統中。系統要繼續順利執行，就需要保持雙向相容：

向後相容（backward compatibility）

較新的程式碼可以讀取由較舊程式碼寫入的資料。

向前相容（forward compatibility）

較舊的程式碼可以讀取由較新程式碼寫入的資料。

向後相容通常不難實現：新程式碼的作者知道舊程式碼寫入的資料格式，因此可以顯式地處理它（必要時，只要保留讀取舊資料的舊程式碼即可）。向前相容則可能棘手得多，因為舊程式碼必須忽略新版本程式碼新增的部分。

向前相容還有一個難點，如 圖 5-1 所示。假設你在記錄模式中新增了一個欄位，新程式碼建立了一條包含這個欄位的記錄，並把它存入資料庫。隨後，尚不瞭解這個新欄位的舊版程式碼讀出記錄，做了更新，又將其寫回。在這種情況下，通常希望舊程式碼把新欄位原樣保留下來，即使它無法解釋該欄位。但如果記錄被解碼成一個不會顯式保留未知欄位的模型物件，資料就可能丟失，如 圖 5-1 所示。

本章將介紹幾種資料編碼格式，包括 JSON、XML、Protocol Buffers 和 Avro。我們尤其關注這些格式如何應對模式變化，以及如何支援新舊資料與新舊程式碼共存。隨後，我們會討論這些格式如何用於儲存和通訊，包括資料庫、Web 服務、REST API、遠端過程呼叫（RPC）、工作流引擎，以及 actor 和訊息佇列等事件驅動系統。

編碼資料的格式

程式通常（至少）使用兩種形式的資料：

1. 在記憶體中，資料儲存在物件、結構體、列表、陣列、雜湊表、樹等資料結構中。這些結構通常使用指標，針對 CPU 的高效訪問與操作進行了最佳化。
2. 如果要將資料寫入檔案或透過網路傳送，就必須將其編碼成某種自包含的位元組序列（例如 JSON 文件）。由於指標對其他程序沒有意義，這種位元組序列表示通常與記憶體中的資料結構大不相同。

因此，需要在兩種表示之間進行轉換。從記憶體表示轉換為位元組序列，稱為 編碼（encoding，也稱為 序列化，serialization，或 編組，marshalling）；反過來則稱為 解碼（decoding，也稱為 解析，parsing，反序列化，deserialization，或 解組，unmarshalling）。

也有一些情況不需要編碼和解碼。例如，“查詢執行：編譯與向量化” 中介紹過，資料庫可以直接操作從磁碟載入的壓縮資料。還有一些 零複製（zero-copy）資料格式，例如 Cap’n Proto 和 FlatBuffers；它們既可用於執行時，也可直接用於磁碟或網路上的資料，無需顯式的轉換步驟。

不過，大多數系統仍需在記憶體物件與扁平的位元組序列之間轉換。這是個極其常見的問題，因而有數不清的庫和編碼格式可供選擇。下面先來簡要概覽一下。

特定語言的格式

許多程式語言都內建了將記憶體物件編碼成位元組序列的功能。例如，Java 有 java.io.Serializable，Python 有 pickle，Ruby 有 Marshal，等等。此外還有許多第三方庫，例如 Java 的 Kryo。

這些編碼庫非常方便，只需很少的額外程式碼就能儲存和恢復記憶體物件。但是，它們也有一些深層次的問題：

• 這類編碼通常與某種程式語言緊密繫結，其他語言很難讀取。如果用這類編碼儲存或傳輸資料，就可能在很長一段時間內把自己鎖定在當前語言上，也很難與其他組織的系統整合——它們使用的語言可能與你不同。
• 為了恢復出相同型別的物件，解碼過程必須能夠例項化任意類，這經常成為安全漏洞的來源 ¹。如果攻擊者能讓應用程式解碼任意位元組序列，就可能借此例項化任意類，進而實施遠端執行任意程式碼之類的惡意操作 ^{2 3}。
• 這些庫通常事後才考慮資料的版本管理。它們只求快速、方便地編碼資料，往往忽略向前相容和向後相容這些棘手的問題 ⁴。
• 效率——包括編碼或解碼所耗的 CPU 時間，以及編碼結果的大小——往往也是事後才考慮的。例如，Java 的內建序列化就因效能糟糕、編碼臃腫而臭名昭著 ⁵。

因此，除非資料只作非常短暫的使用，否則採用語言內建的編碼通常不是個好主意。

JSON、XML 及其二進位制變體

說到可由多種程式語言讀寫的標準編碼，JSON 和 XML 是最顯眼的候選者。它們廣為人知、廣受支援，也幾乎同樣“廣受憎惡”。XML 經常因為過於冗長和不必要的複雜而受到批評 ⁶。JSON 的流行，主要得益於 Web 瀏覽器的內建支援，以及它相對於 XML 的簡單性。CSV 是另一種流行的語言無關格式，但它只能表示不含巢狀的表格資料。

JSON、XML 和 CSV 都是文字格式，因而具有一定的人類可讀性（儘管它們的語法一直是熱門爭議話題）。除了表面的語法問題，它們還有一些不易察覺的麻煩：

• 數字 的編碼有很多模糊之處。在 XML 和 CSV 中，無法區分數值和碰巧只由數字組成的字串，除非藉助外部模式。JSON 雖然區分字串和數值，卻不區分整數與浮點數，也沒有規定精度。

  處理大數時，這會造成問題。例如，大於 2⁵³ 的整數無法用 IEEE 754 雙精度浮點數精確表示；如果某種語言像 JavaScript 一樣使用浮點數來解析數值，這些大整數就會失真 ⁷。X（原 Twitter）使用 64 位數字標識每條帖子，便是一個實際例子。為了繞過 JavaScript 應用程式無法正確解析這類數字的問題，其 API 返回的 JSON 會把帖子 ID 包含兩次：一次作為 JSON 數值，另一次作為十進位制字串 ⁸。

• JSON 和 XML 對 Unicode 字串（即人類可讀的文字）支援得很好，卻不支援二進位制字串（即不帶字元編碼的位元組序列）。二進位制字串非常有用，人們通常把二進位制資料用 Base64 編碼成文字來繞過這一限制，再由模式說明該值應按 Base64 解讀。這個辦法雖然管用，卻有些取巧，而且會讓資料體積增加 33%。

• XML 模式和 JSON 模式功能強大，因而學習和實現起來都相當複雜。數字、二進位制字串等資料的正確解釋依賴模式中的資訊，所以不使用 XML/JSON 模式的應用程式可能不得不硬編碼相應的編碼與解碼邏輯。

• CSV 沒有任何模式，每行每列的含義完全由應用程式自行定義。如果應用程式變更增加了一行或一列，就必須手工處理這種變化。CSV 本身也相當含糊：如果值中包含逗號或換行符，該怎麼辦？儘管轉義規則已有正式規範 ⁹，卻不是所有解析器都正確實現了它。

儘管有這些缺陷，JSON、XML 和 CSV 對許多用途來說已經足夠好。它們很可能會繼續流行，尤其是作為資料交換格式——也就是把資料從一個組織傳送給另一個組織。在這種情況下，只要大家能就格式達成一致，格式是否美觀或高效往往並不重要。畢竟，讓不同組織對 任何事情 達成一致，就已經壓倒了大多數其他考量。

JSON 模式

當資料需要在系統間交換或寫入儲存時，JSON 模式已經成為廣泛採用的資料建模方式。它出現在許多地方：作為 OpenAPI Web 服務規範的一部分用於 Web 服務（參見“Web 服務”）；用於 Confluent Schema Registry、Red Hat Apicurio Registry 等模式登錄檔；也用於資料庫，例如 PostgreSQL 的 pg_jsonschema 驗證擴充套件，以及 MongoDB 的 $jsonSchema 驗證語法。

JSON 模式規範提供了許多功能。它包含字串、數值、整數、物件、陣列、布林值和空值等標準基本型別，還另有一套驗證規範，開發者可以用它給欄位附加約束。例如，可以規定 port 欄位的最小值為 1、最大值為 65535。

JSON 模式可以採用開放或封閉的內容模型。開放內容模型允許出現模式未定義的任意欄位，而且這些欄位可以是任意資料型別；封閉內容模型則只允許出現顯式定義的欄位。在 JSON 模式中，把 additionalProperties 設為 true 就會啟用開放內容模型，而這恰好是預設值。因此，JSON 模式通常是在定義 不允許什麼（也就是已定義欄位上的無效值），而不是窮舉模式中 允許什麼。

開放內容模型功能強大，但也可能相當複雜。假設你想定義一個從整數（例如 ID）到字串的對映。JSON 沒有對映或字典型別，只有“物件”型別；物件的鍵必須是字串，值則可以是任意型別。此時可以藉助 JSON 模式，用 patternProperties 和 additionalProperties 約束物件，規定鍵只能由數字組成、值只能是字串，如 示例 5-1 所示。

{
    "$schema": "http://json-schema.org/draft-07/schema#",
    "type": "object",
    "patternProperties": {
        "^[0-9]+$": {
        "type": "string"
    }
    },
    "additionalProperties": false
}

除了開放和封閉內容模型以及驗證器，JSON 模式還支援條件式 if/else 模式邏輯、命名型別、遠端模式引用等諸多功能。這些能力造就了一門十分強大的模式語言，卻也讓模式定義變得龐雜難用。解析遠端模式、推斷條件規則，或者以向前或向後相容的方式演化模式，都可能很有挑戰 ¹⁰。XML 模式也有類似的問題 ¹¹。

二進位制編碼

JSON 比 XML 簡潔，但兩者與二進位制格式相比仍然很佔空間。於是，人們開發出了大量 JSON 的二進位制編碼（例如 MessagePack、CBOR、BSON、BJSON、UBJSON、BISON、Hessian 和 Smile）以及 XML 的二進位制編碼（例如 WBXML 和 Fast Infoset）。這些格式更緊湊，有時解析也更快，因此在各自的細分領域得到應用；但沒有一種像文字版 JSON 和 XML 那樣普及 ¹²。

其中一些格式擴充套件了資料型別集合，例如區分整數和浮點數，或者支援二進位制字串；除此之外，它們仍然沿用 JSON/XML 的資料模型。尤其是，它們沒有規定模式，所以必須把所有物件欄位名都寫進編碼後的資料。也就是說，對 示例 5-2 中的 JSON 文件進行二進位制編碼時，某處仍須包含 userName、favoriteNumber 和 interests 這些字串。

{
    "userName": "Martin",
    "favoriteNumber": 1337,
    "interests": ["daydreaming", "hacking"]
}

下面來看 MessagePack，它是 JSON 的一種二進位制編碼。圖 5-2 展示了用 MessagePack 編碼 示例 5-2 中的 JSON 文件後得到的位元組序列。開頭幾個位元組的含義如下：

1. 第一個位元組 0x83 表示接下來是一個物件（高四位 = 0x80），其中有三個欄位（低四位 = 0x03）。（如果物件超過 15 個欄位，欄位數無法裝進四位，就會改用另一種型別識別符號，並用兩個或四個位元組編碼欄位數。）
2. 第二個位元組 0xa8 表示接下來是一個字串（高四位 = 0xa0），長度為八個位元組（低四位 = 0x08）。
3. 接下來的八個位元組，是以 ASCII 編碼的欄位名 userName。由於前面已經給出長度，不需要再用標記或轉義來指示字串在哪裡結束。
4. 再往後的七個位元組，以字首 0xa6 加六個字母的方式編碼字串值 Martin，後續內容依此類推。

二進位制編碼共 66 位元組，只比去掉空白後的文字 JSON（81 位元組）略小一點。各種 JSON 二進位制編碼在這方面都差不多。如此有限的空間節省（外加也許更快的解析速度），是否值得犧牲人類可讀性，並不好說。

接下來我們會看到，同一條記錄其實可以只用 32 位元組編碼，效果好得多。

Protocol Buffers

Protocol Buffers（protobuf）是 Google 開發的二進位制編碼庫。它與最初由 Facebook 開發的 Apache Thrift 很相似 ¹³；本節關於 Protocol Buffers 的大部分內容也適用於 Thrift。

Protocol Buffers 要求任何待編碼的資料都有模式。要用 Protocol Buffers 編碼 示例 5-2 中的資料，可以用 Protocol Buffers 的介面定義語言（IDL）這樣描述模式：

syntax = "proto3";

message Person {
    string user_name = 1;
    int64 favorite_number = 2;
    repeated string interests = 3;
}

Protocol Buffers 自帶程式碼生成工具。它接收上述模式定義，生成用各種程式語言實現該模式的類，應用程式可以呼叫生成的程式碼來編碼或解碼符合模式的記錄。與 JSON 模式相比，Protocol Buffers 的模式語言非常簡單：它只定義記錄的欄位及其型別，不支援對欄位取值施加其他約束。

使用 Protocol Buffers 編碼器對 示例 5-2 進行編碼，需要 33 位元組，如 圖 5-3 所示 ¹⁴。

與 圖 5-2 類似，每個欄位都有型別註解，用來說明它是字串、整數還是其他型別；必要時還會給出長度，例如字串長度。資料中的字串（“Martin”“daydreaming”“hacking”）也和之前一樣編碼為 ASCII——準確地說，是 UTF-8。

與 圖 5-2 相比，最大的區別在於這裡沒有欄位名（userName、favoriteNumber、interests）。編碼資料包含的是數字形式的 欄位標籤（field tag）（1、2 和 3），也就是模式定義中的那些數字。欄位標籤好比欄位的別名：無需寫出欄位名，就能以緊湊的方式指出所說的是哪個欄位。

Protocol Buffers 把欄位型別和標籤號塞進同一個位元組，進一步節省了空間。它還使用變長整數：數字 1337 編碼成兩個位元組，每個位元組的最高位表示後面是否還有更多位元組。這樣，-64 到 63 之間的數字用一個位元組編碼，-8192 到 8191 之間的數字用兩個位元組編碼，依此類推；數字越大，佔用的位元組就越多。

Protocol Buffers 沒有顯式的列表或陣列資料型別。interests 欄位上的 repeated 修飾符表示該欄位包含一組值，而不是單個值。在二進位制編碼中，列表元素只是同一欄位標籤在同一條記錄中重複出現。

欄位標籤與模式演化

前面說過，模式不可避免地會隨時間改變，這稱為 模式演化（schema evolution）。Protocol Buffers 如何在保持向後和向前相容的同時處理模式變更？

從示例可以看出，一條編碼後的記錄，就是各個已編碼欄位的拼接。每個欄位由標籤號（示例模式中的 1、2、3）標識，並帶有資料型別註解（例如字串或整數）。如果某個欄位沒有值，就直接從編碼記錄中省略。由此可見，欄位標籤對編碼資料的含義至關重要。模式中的欄位名可以修改，因為編碼資料從不引用欄位名；但欄位標籤不能修改，否則現有的所有編碼資料都會失效。

可以向模式中新增新欄位，只要給它分配一個新的標籤號。舊程式碼並不知道新增的標籤號；當它讀取新程式碼寫入的資料、遇到無法識別的新欄位時，只需忽略該欄位即可。藉助資料型別註解，解析器能夠判斷要跳過多少位元組；同時還應保留未知欄位，以免出現 圖 5-1 所示的問題。這樣就保持了向前相容：舊程式碼仍能讀取新程式碼寫入的記錄。

向後相容又如何呢？只要每個欄位的標籤號唯一，新程式碼就總能讀取舊資料，因為標籤號的含義沒有改變。如果新模式增加了一個欄位，而讀取的舊資料尚不包含它，就會填入預設值：例如，字串欄位填入空字串，數值欄位填入零。

刪除欄位與新增欄位類似，只是向後相容和向前相容的考量正好相反。已經用過的標籤號絕不能再次使用，因為某處可能仍有帶著舊標籤號的資料，而新程式碼必須忽略這個欄位。可以在模式定義中把用過的標籤號標記為保留，確保以後不會忘記。

欄位的資料型別能否改變？某些型別可以，詳情需查閱文件，但值有可能被截斷。例如，假設把一個 32 位整數改成 64 位整數。新程式碼可以輕鬆讀取舊程式碼寫入的資料，因為解析器能用零補齊缺少的位。但如果舊程式碼讀取新程式碼寫入的資料，它仍會用 32 位變數儲存這個值；一旦解碼後的 64 位值裝不進 32 位，就會被截斷。

Avro

Apache Avro 是另一種二進位制編碼格式，與 Protocol Buffers 有著頗為有趣的差異。它於 2009 年作為 Hadoop 的子專案啟動，起因是 Protocol Buffers 不適合 Hadoop 的使用場景 ¹⁵。

Avro 也使用模式來規定待編碼資料的結構。它有兩種模式語言：一種是供人編輯的 Avro IDL，另一種基於 JSON，更便於機器讀取。與 Protocol Buffers 一樣，Avro 的模式語言只規定欄位及其型別，不支援 JSON 模式那樣複雜的驗證規則。

用 Avro IDL 編寫的示例模式可能如下所示：

record Person {
    string                  userName;
    union { null, long }    favoriteNumber = null;
    array<string>           interests;
}

等價的 JSON 表示如下：

{
    "type": "record",
    "name": "Person",
    "fields": [
        {"name": "userName",        "type": "string"},
        {"name": "favoriteNumber",  "type": ["null", "long"], "default": null},
        {"name": "interests",       "type": {"type": "array", "items": "string"}}
    ]
}

首先請注意，模式中沒有標籤號。如果用這個模式編碼示例記錄（示例 5-2），Avro 的二進位制編碼只有 32 位元組，是目前所見編碼中最緊湊的。圖 5-4 展示了這個位元組序列的組成。

仔細檢視這個位元組序列，會發現其中沒有任何內容標識欄位或資料型別；編碼僅僅是各個值的拼接。字串就是長度字首加上 UTF-8 位元組，但編碼資料本身並不說明它是字串——它同樣可能是整數或其他任何東西。整數則使用變長編碼。

要解析二進位制資料，必須按照欄位在模式中出現的順序逐一讀取，並由模式告知每個欄位的資料型別。這意味著，讀取資料的程式碼只有使用與寫入程式碼 完全相同的模式，才能正確解碼二進位制資料。讀寫雙方的模式只要有任何不一致，解碼結果就會出錯。

那麼，Avro 如何支援模式演化？

寫入者模式與讀取者模式

當應用程式要編碼資料——例如寫入檔案或資料庫，或者透過網路傳送——它會使用自己所知版本的模式；這個模式可能已經編譯進應用程式。這稱為 寫入者模式（writer’s schema）。

當應用程式要解碼資料——例如從檔案或資料庫讀取，或者從網路接收——它會使用兩個模式：一個是與編碼時完全相同的寫入者模式，另一個是可能有所不同的 讀取者模式（reader’s schema），如 圖 5-5 所示。讀取者模式定義了應用程式程式碼期望每條記錄包含哪些欄位，以及這些欄位的型別。

如果讀寫雙方的模式相同，解碼很簡單。如果不同，Avro 會並排比較寫入者模式與讀取者模式，把資料從前者轉換成後者，從而協調其中的差異。Avro 規範 ^{16 17} 精確定義了這一解析過程，圖 5-6 給出了示意。

例如，寫入者模式和讀取者模式中的欄位順序不同並不成問題，因為模式解析會按欄位名配對。讀取程式碼如果遇到只存在於寫入者模式、卻不在讀取者模式中的欄位，就將其忽略；如果讀取程式碼需要某個欄位，而寫入者模式中沒有同名欄位，就填入讀取者模式宣告的預設值。

模式演化規則

對 Avro 而言，向前相容意味著可以用新版模式寫入、用舊版模式讀取；反過來，向後相容意味著可以用舊版模式寫入、用新版模式讀取。

為了保持相容，只能新增或刪除帶預設值的欄位（示例 Avro 模式中的 favoriteNumber 欄位，預設值就是 null）。例如，假設新增了一個帶預設值的欄位，於是該欄位存在於新模式、卻不存在於舊模式。當採用新模式的讀取者讀取舊模式寫入的記錄時，就會為缺少的欄位填入預設值。

如果新增的欄位沒有預設值，新讀取者就無法讀取舊寫入者產生的資料，因而破壞向後相容。如果刪除的欄位沒有預設值，舊讀取者就無法讀取新寫入者產生的資料，因而破壞向前相容。

在某些程式語言中，任何變數都可以預設取 null，Avro 卻並非如此：如果希望欄位允許為 null，就必須使用 聯合型別（union type）。例如，union { null, long, string } field; 表示 field 可以是數字、字串或 null。而且，只有當 null 是聯合型別的第一個分支時，才能把它用作預設值。這種寫法比預設所有內容都可為 null 略顯冗長，卻明確說明了什麼可以、什麼不可以為 null，從而有助於避免錯誤 ¹⁸。

只要 Avro 能完成相應的型別轉換，就可以更改欄位的資料型別。欄位名也能更改，不過稍微麻煩一些：讀取者模式可以為欄位名宣告別名，從而讓舊寫入者模式中的欄位名與別名匹配。因此，更改欄位名向後相容，卻不向前相容。同樣，給聯合型別增加一個分支向後相容，卻不向前相容。

但什麼是寫入者模式？

到目前為止，我們一直略過一個重要問題：讀取者如何知道某段資料是用哪個寫入者模式編碼的？不能把整個模式塞進每條記錄，因為模式很可能比編碼後的資料大得多，那樣二進位制編碼省下的空間就全白費了。

答案取決於 Avro 的使用場景。舉幾個例子：

包含大量記錄的大檔案

Avro 的一種常見用途，是儲存包含數百萬條記錄的大檔案，所有記錄都使用同一個模式編碼（我們會在 第 11 章 討論這種情況）。此時，檔案的寫入者只需在檔案開頭寫入一次寫入者模式。Avro 為此規定了一種檔案格式，稱為物件容器檔案。

逐條寫入記錄的資料庫

在資料庫中，不同記錄可能在不同時間用不同的寫入者模式寫入，不能假定所有記錄都採用同一個模式。最簡單的解決方案，是在每條編碼記錄的開頭放一個版本號，並在資料庫中維護模式版本列表。讀取者取出記錄後先提取版本號，再從資料庫取得該版本對應的寫入者模式，用它解碼記錄的其餘部分。

例如，Apache Kafka 的 Confluent Schema Registry ¹⁹ 和 LinkedIn 的 Espresso ²⁰ 就採用這種做法。

透過網路連線傳送記錄

當兩個程序透過雙向網路連線通訊時，可以在建立連線時協商模式版本，並在連線的整個生命週期中使用這個模式。Avro RPC 協議（參見“流經服務的資料流：REST 與 RPC”）就是這樣工作的。

無論採用哪種方式，維護模式版本資料庫都很有用：它既是文件，也讓你有機會檢查模式相容性 ²¹。版本號可以是簡單遞增的整數，也可以是模式的雜湊值。

動態生成的模式

與 Protocol Buffers 相比，Avro 的一個優點是模式中沒有任何標籤號。但這為什麼重要？在模式中維護幾個數字，能有什麼問題？

區別在於，Avro 對 動態生成 的模式更友好。假設你想把關聯式資料庫的內容轉儲到檔案，並希望使用二進位制格式，避開前面提到的 JSON、CSV、XML 等文字格式的問題。使用 Avro 時，可以很容易地從關係模式生成 Avro 模式（採用前面展示過的 JSON 表示），再用它編碼資料庫內容，把所有資料轉儲到 Avro 物件容器檔案中 ²²。可以為每張資料庫表生成一個記錄模式，讓表中的每一列對應記錄中的一個欄位，資料庫列名則對映為 Avro 欄位名。

如果資料庫模式發生變化，例如表中增加一列、刪除一列，只要根據更新後的資料庫模式生成新的 Avro 模式，再用新模式匯出資料即可。資料匯出過程無需關注具體發生了什麼模式變更，每次執行時照常完成模式轉換就行。讀取新資料檔案的人會看到記錄欄位發生了變化，但由於欄位按名稱標識，更新後的寫入者模式仍能與舊讀取者模式匹配。

相比之下，如果用 Protocol Buffers 完成這項工作，欄位標籤很可能必須手工分配：資料庫模式每次變化，管理員都得手工更新資料庫列名到欄位標籤的對映。（這也許能夠自動化，但模式生成器必須格外謹慎，不能再次分配以前用過的標籤號。）動態生成模式從來就不是 Protocol Buffers 的設計目標，卻是 Avro 的設計目標之一。

模式的優點

正如我們所見，Protocol Buffers 和 Avro 都用模式描述二進位制編碼格式。它們的模式語言比 XML 模式或 JSON 模式簡單得多；後兩者支援更細緻的驗證規則，例如“這個欄位的字串值必須匹配某個正規表示式”，或者“這個欄位的整數值必須介於 0 和 100 之間”。Protocol Buffers 和 Avro 實現起來更簡單，使用起來也更簡單，因此已經支援相當廣泛的程式語言。

這些編碼背後的思想絕不新鮮。例如，它們與 ASN.1 有許多共同之處。ASN.1 是一門模式定義語言，早在 1984 年便首次標準化 ^{23 24}；它曾用於定義各種網路協議，其二進位制編碼 DER 至今仍用於編碼 SSL 證書（X.509）²⁵。與 Protocol Buffers 類似，ASN.1 也用標籤號支援模式演化 ²⁶。不過，ASN.1 非常複雜，文件也很糟糕，因此可能並不適合新的應用程式。

許多資料系統也為自身資料實現了某種專有二進位制編碼。例如，大多數關聯式資料庫都有自己的網路協議，用於接收查詢並返回響應。這些協議通常只適用於特定資料庫，由資料庫廠商提供驅動程式（例如採用 ODBC 或 JDBC API），把資料庫網路協議中的響應解碼成記憶體資料結構。

由此可見，儘管 JSON、XML 和 CSV 等文字格式非常普遍，基於模式的二進位制編碼同樣是可行的選擇，而且具備一些很好的性質：

• 它們可以比各種“二進位制 JSON”變體緊湊得多，因為編碼資料中不必包含欄位名。
• 模式本身就是一種很有價值的文件。解碼時必須使用模式，所以可以確信它與資料保持同步；而手工維護的文件很容易與實際情況脫節。
• 維護模式資料庫，可以在部署任何變更之前檢查它是否保持向前和向後相容。
• 對於靜態型別程式語言的使用者，從模式生成程式碼很有用，因為這樣可以在編譯時進行型別檢查。

總而言之，模式演化提供了與無模式/讀時模式 JSON 資料庫相同的靈活性（參見“文件模型中的模式靈活性”），同時還能為資料提供更強的保證和更好的工具。

資料流的模式

本章開頭曾經說過，每當你想把資料傳送給不共享記憶體的另一個程序——例如透過網路傳送資料，或者將資料寫入檔案——都需要先把它編碼成位元組序列。隨後，我們討論了完成這項工作所用的各種編碼。

我們還討論了向前相容與向後相容。兩者對可演化性都很重要：它們允許獨立升級系統的不同部分，不必一次改動所有內容，從而讓變更更容易。相容性描述的是編碼資料的程序與解碼資料的程序之間的關係。

這個概念相當抽象，因為資料可以透過許多方式從一個程序流向另一個程序。究竟由誰編碼，又由誰解碼？本章餘下部分將探討幾種最常見的程序間資料流：

• 透過資料庫（參見“流經資料庫的資料流”）
• 透過服務呼叫（參見“流經服務的資料流：REST 與 RPC”）
• 透過工作流引擎（參見“持久化執行與工作流”）
• 透過非同步訊息（參見“事件驅動的架構”）

流經資料庫的資料流

在資料庫中，寫入資料庫的程序負責編碼資料，讀取資料庫的程序負責解碼。也許始終只有一個程序訪問資料庫，此時讀取者只不過是同一程序的後續版本——可以把向資料庫存入資料看作 給未來的自己傳送訊息。

顯然，這裡必須保持向後相容，否則未來的你就無法解碼過去寫下的資料。

一般來說，多個不同程序同時訪問資料庫很常見。這些程序可能屬於不同的應用程式或服務，也可能只是同一服務的多個例項，為可伸縮性或容錯而並行執行。無論哪種情況，只要應用程式還在變化，訪問資料庫的程序就很可能有些執行新版程式碼，有些仍在執行舊版程式碼。例如，滾動升級期間，一部分例項已經更新，其他例項還沒有。

這意味著，資料庫中的某個值可能由 較新 版本的程式碼寫入，隨後卻被仍在執行的 較舊 版本讀取。因此，資料庫通常也需要向前相容。

不同時間寫入的不同值

資料庫通常允許隨時更新任何值。因此，同一個資料庫裡可能既有五毫秒前寫入的值，也有五年前寫入的值。

部署新版應用程式時——至少對服務端應用程式而言——可能只需幾分鐘就能用新版本完全替換舊版本。但資料庫內容不是這樣：除非顯式重寫，五年前的資料仍會以最初的編碼留在那裡。這種現象有時概括為：資料比程式碼更長壽。

當然，可以把資料重寫（即 遷移）到新模式，但對大型資料集來說代價高昂，所以大多數資料庫都會盡量避免。大多數關聯式資料庫允許某些簡單的模式變更，例如增加一個預設值為 null 的新列，而不必重寫已有資料。讀取舊行時，如果磁碟上的編碼資料缺少某一列，資料庫便為它填入 null。

因此，模式演化讓整個資料庫看上去彷彿都用同一個模式編碼，儘管底層儲存中可能混有按各個歷史版本模式編碼的記錄。

更複雜的模式變更——例如把單值屬性改成多值屬性，或者把一部分資料移到另一張表中——仍然需要重寫資料，而且通常要在應用程式層完成 ²⁷。如何在這類遷移中保持向前和向後相容，至今仍是一個研究問題 ²⁸。

歸檔儲存

也許你會不時為資料庫製作快照，用於備份或者載入到資料倉儲中（參見“資料倉儲”）。這時，即使源資料庫的原始編碼混合了不同時期的多個模式版本，資料轉儲通常也會統一使用最新模式編碼。反正資料總要複製一遍，不妨讓副本採用一致的編碼。

資料轉儲一次寫成，此後不再修改，因此 Avro 物件容器檔案之類的格式很適合。這裡也是把資料編碼成適合分析的列式格式（例如 Parquet）的好機會（參見“列壓縮”）。

在 第 11 章 中，我們會進一步討論歸檔儲存中資料的用途。

流經服務的資料流：REST 與 RPC

當多個程序需要透過網路通訊時，可以採用幾種不同的組織方式。最常見的方式包含兩個角色：客戶端（client）和 伺服器（server）。伺服器透過網路公開 API，客戶端連線伺服器並向 API 發出請求。伺服器公開的這個 API 稱為 服務（service）。

Web 正是這樣工作的：客戶端（Web 瀏覽器）向 Web 伺服器發出請求，用 GET 請求下載 HTML、CSS、JavaScript、圖片等內容，用 POST 請求向伺服器提交資料。這個 API 由一套標準化的協議和資料格式組成，包括 HTTP、URL、SSL/TLS、HTML 等。因為 Web 瀏覽器、Web 伺服器和網站作者基本都遵循這些標準，所以理論上可以用任何 Web 瀏覽器訪問任何網站。

Web 瀏覽器並不是唯一的客戶端。例如，執行在移動裝置或桌面計算機上的原生應用程式經常與伺服器通訊，瀏覽器中的客戶端 JavaScript 應用程式也可以發出 HTTP 請求。這種情況下，伺服器返回的通常不是供人閱讀的 HTML，而是便於客戶端程式碼進一步處理的編碼資料，最常見的是 JSON。HTTP 雖然可以作為傳輸協議，但構建在它之上的 API 仍然由應用程式自行定義，客戶端與伺服器必須就 API 的細節達成一致。

在某些方面，服務很像資料庫：它們通常允許客戶端提交和查詢資料。不過，資料庫允許使用 第 3 章 討論過的查詢語言發起任意查詢，服務公開的卻是應用程式專用 API，只接受服務業務邏輯（應用程式程式碼）預先規定的輸入，也只產生預先規定的輸出 ²⁹。這種限制帶來了一定程度的封裝：服務可以細粒度地約束客戶端能做什麼、不能做什麼。

面向服務架構或微服務架構的一項關鍵設計目標，是讓服務可以獨立部署和演化，從而使應用程式更容易修改和維護。一條常見原則是：每項服務由一個團隊負責，這個團隊應當能夠頻繁釋出服務的新版本，而不必與其他團隊協調。因此，伺服器和客戶端的新舊版本同時執行是意料之中的，雙方使用的資料編碼必須跨服務 API 版本保持相容。

Web 服務

如果以 HTTP 作為與服務通訊的底層協議，就稱為 Web 服務（Web service）。Web 服務常用於構建面向服務或微服務架構（前文“微服務與無伺服器”已經討論過）。不過，“Web 服務”這個名字並不十分貼切，因為它不只用於 Web，還出現在其他幾種場景中。例如：

1. 執行在使用者裝置上的客戶端應用程式（例如移動裝置上的原生應用，或者瀏覽器中的 JavaScript Web 應用）透過 HTTP 請求服務。這些請求通常經由公共網際網路傳輸。
2. 作為面向服務或微服務架構的一部分，一項服務請求同一組織擁有的另一項服務；兩者通常位於同一個資料中心。
3. 一項服務請求另一組織擁有的服務，通常經由網際網路完成。這種方式用於不同組織的後端系統交換資料，包括線上服務提供的公共 API，例如信用卡支付系統，以及用來共享訪問使用者資料的 OAuth。

最流行的服務設計理念是 REST，它建立在 HTTP 的原則之上 ^{30 31}。REST 強調簡單的資料格式，以 URL 標識資源，並利用 HTTP 的功能進行快取控制、身份認證和內容型別協商。遵循 REST 原則設計的 API 稱為 RESTful API。

呼叫 Web 服務 API 的程式碼必須知道應該請求哪個 HTTP 端點、應傳送什麼格式的資料，以及預期得到什麼響應。即使服務遵循 RESTful 設計原則，客戶端也得透過某種途徑獲知這些細節。服務開發者通常使用介面定義語言（IDL）來定義並記錄 API 端點和資料模型，隨後再逐步演化它們。其他開發者可以根據服務定義判斷如何發起請求。最流行的兩種服務 IDL 是 OpenAPI（也稱為 Swagger ³²）和 gRPC。OpenAPI 用於收發 JSON 資料的 Web 服務，而 gRPC 服務收發 Protocol Buffers 資料。

開發者通常用 JSON 或 YAML 編寫 OpenAPI 服務定義，參見 示例 5-3。服務定義可以描述端點、文件、版本、資料模型等許多內容。gRPC 的定義看起來與此相似，但採用 Protocol Buffers 的服務定義語法。

openapi: 3.0.0
info:
  title: Ping, Pong
  version: 1.0.0
servers:
  - url: http://localhost:8080
paths:
  /ping:
    get:
      summary: Given a ping, returns a pong message
      responses:
        '200':
          description: A pong
          content:
            application/json:
              schema:
                type: object
                properties:
                  message:
                    type: string
                    example: Pong!