《資料密集型應用系統設計》金句摘抄 - 1

第3章 資料儲存與檢索

金句

如果資料庫希望提供強大的事務語義，這方面B-tree（相比LSM tree）顯得更具吸引力。

記憶體資料庫的效能優勢並不是因為它們不需要從磁碟讀取（有足夠記憶體，磁碟資料庫也可以），而是因為它們避免使用寫磁碟的格式對記憶體資料結構編碼的開銷。

資料倉庫常用“星型模型”，事實表位於中間，被一系列維度表包圍。

面向列的儲存佈局也有利於高效利用CPU週期，查詢引擎可將一大塊壓縮列資料放入 CPU L1快取，以緊湊迴圈（沒有函式呼叫）進行迭代。

物化檢視對於大量讀密集的資料倉庫更有意義，對於寫密集它可能影響資料寫入效能。

OLTP

OLAP

主要讀特徵

基於鍵，每次查詢返回少量記錄

對大量記錄進行彙總

主要寫特徵

隨機訪問，低延遲寫入使用者的輸入

批次匯入（ETL）或事件流

典型使用場景

終端使用者，透過網路應用程式

內部分析師，為決策提供支援

資料表徵

最新的資料狀態（當前時間點）

隨著時間而變化的所有事件歷史

資料規模

GB到TB

TB到PB

小結

儲存引擎分為兩大類：OLTP和OLAP，它們典型的訪問模式存在很大差異：

OLTP通常面向使用者，這意味著它們可能收到大量的請求。為了處理負載，應用程式通常在每個查詢中只涉及少量的記錄。應用程式基於某種鍵來請求記錄，而儲存引擎使用索引來查詢所請求鍵的資料。磁碟

尋道時間

往往是瓶頸。

OLAP並不太廣為人知，主要由業務分析師使用。處理的查詢請求數目遠低於OLTP系統，但每個查詢往往非常苛刻，需要短時間內掃過數百萬條記錄。磁碟頻寬（不是尋道時間）通常是瓶頸，而面向列的儲存對於這種工作負載成為日益流行的解決方案。

在OLTP方面，有兩個主要流派的儲存引擎：

日誌結構流派，它只允許追加式更新檔案和刪除過時的檔案，但不會修改已寫入的檔案。如LevelDB。

原地更新流派，將磁碟視為可以覆蓋的一組固定大小的頁。B-tree是這一流派的典型資料結構，它已用於所有主要的關係資料庫，和大量的非關係資料庫。

日誌結構的儲存引擎上一個相對較新的方案。其關鍵思想上系統地將磁碟上隨機訪問寫入轉為順序寫入，由於磁碟驅動器和SSD的效能特徵，可以實現更高的寫入吞吐量。

此外，介紹了一些更復雜的索引結構，以及為全記憶體而最佳化的資料庫。

然後，從儲存引擎的內部間接探索了典型資料倉庫的總體架構。由此說明為什麼OLAP與OLTP如此不同：當查詢需要在大量行中順序掃描時，索引的關聯性就會顯著降低。相反，最重要的是非常緊湊地編碼資料，以儘量減少磁碟讀取的資料量。

第4章 資料編碼與演化

金句

在動態型別程式語言中，如JavaScript、Ruby或Python，因為沒有編譯時型別檢查，生成程式碼沒有太多意義。

2。 一種服務向同一組織擁有的另一項服務提出請求，這些服務通常位於同一資料中心內，作為面向服務/微型架構的一部分。支援這種用例的軟體有時被稱為中介軟體。

3。 向後相容

：較新程式碼可讀舊程式碼編寫的資料；

向前相容

：較舊程式碼可讀新程式碼編寫的資料。

4。 RPC的問題，網路請求與本地函式呼叫非常不同：

本地函式呼叫是可預測的，成功或失敗只取決於控制的引數；網路請求不可預測，請求或響應可能因網路問題丟失，或遠端計算機不可用，因此需有重試的準備。

本地函式呼叫要麼返回一個結果，要麼丟擲異常，要麼永不返回（陷入無限迴圈）；網路請求有另一可能：由於超時，返回時沒有結果，該種情況下，不知道發生了什麼。

重試 失敗的網路請求，可能會發生請求實際完成，只是響應丟失的情況。該種情況下，重試導致該操作執行多次。考慮用冪等性解決。

本地函式每次執行時間大致相同；網路請求因網路波動，執行時間波動較大。

本地函式可以藉助引用（指標）高效傳遞物件；網路請求時，需把物件編碼成可以透過網路傳送的位元組序列，對較大物件可能出現問題。

客戶和服務可以用不同程式語言實現，RPC框架需要講資料型別從一種語言轉換為另一種語言，但不是所有語言都具有相同的型別，可能因此導致問題（如JavaScript數字大於2的53次方）。

5。 與直接RPC相比，訊息代理的優點：

如果接收方不可用或過載，可以充當緩衝區，從而提高系統的可靠性；

可以自動將訊息重新發送到崩潰的程序，從而防止資訊丟失；

它避免了傳送方需要知道接收方的IP和埠號（這在虛擬機器經常容易起起停停的雲部署中特別有用）；

它支援一條訊息傳送給多個接收方；

它在邏輯上將傳送方和接收方分離（傳送方只是釋出訊息，並不關心誰使用它們）。

小結

研究了將記憶體資料結構轉換為網路或磁碟上的位元組流的方法。這些編碼細節不僅影響效率，還影響用用程式的體系結構和部署時的支援選項。

滾動升級：每次將新版本的服務部署到幾個節點，而不是同時部署到所有節點。滾動升級允許在不停機情況下發布新版本，降低部署風險（錯誤版本可在影響大量使用者之前檢測並回滾）。這些特性有利於應用程式的演化和更改。滾動升級時，必須假設不同節點在執行不同版本的程式碼，這就對向前、向後相容提出了需求。

多種資料編碼方式：

程式語言特定的方式：僅限於一種語言，往往無法提供向前、向後相容性；

文字格式（JSON、XML、CSV等）：使用普遍，相容性取決於使用方式；

二進位制模式（Thrift，Protocol Buffers，Avro）：支援使用清晰定義的向前、向後相容性語義進行緊湊、高效的編碼。對靜態型別語言中的文件和程式碼生成很有用，缺點是資料解碼後才是人類可讀的。

幾種資料流的模型：

資料庫：寫入資料庫的程序對資料進行編碼，讀取資料庫的程序進行解碼；

RPC和REST API：客戶端對請求進行編碼，伺服器對請求進行解碼並對響應進行編碼，客戶端最終對響應解碼。

非同步訊息傳遞（使用訊息代理）：節點間互相傳送資訊進行通訊，訊息由傳送者編碼並由接受者解碼。

待更新。。。