NoSQL 精華重點
在我們的書 NoSQL 精華中,我們用一些重點總結了許多章節。作為快速參考,我們在此包含了這些重點。
第一章
為何使用 NoSQL?
- 關係資料庫已經成功使用了二十年,提供持久性、並發控制和整合機制。
- 應用程式開發人員一直對關係模型和記憶體中資料結構之間的阻抗不匹配感到沮喪。
- 有一種趨勢,從使用資料庫作為整合點轉向將資料庫封裝在應用程式中,並透過服務進行整合。
- 資料儲存變化的重要因素是需要透過執行叢集來支援大量的資料。關係資料庫並未設計為在叢集上有效率地執行。
- NoSQL 是個意外的新詞。沒有規範性的定義,你只能觀察到共同的特徵。
-
NoSQL 資料庫的共同特徵是
- 不使用關係模型
- 在叢集上執行良好
- 開源
- 建置於 21 世紀的網路資產
- 無架構
- NoSQL 崛起的最重要的結果是多語持久性。
第二章
聚合資料模型
- 聚合是一組我們以單元方式互動的資料。聚合形成資料庫中 ACID 作業的界線。
- 鍵值、文件和欄位家族資料庫都可以視為聚合導向資料庫的形式。
- 聚合讓資料庫更容易在叢集上管理資料儲存。
- 當大多數資料互動都是使用相同的聚合時,聚合導向資料庫的效果最好;當互動使用以許多不同形式組織的資料時,聚合無知資料庫的效果較好。
第三章
更多關於資料模型的詳細資訊
- 聚合導向資料庫使得聚合間關係比聚合內關係更難處理。
- 圖形資料庫將資料組織成節點和邊緣圖形;它們最適合具有複雜關係結構的資料。
- 無架構資料庫允許你自由地將欄位新增到記錄中,但資料使用者通常會預期有一個隱含的架構。
- 聚合導向資料庫通常會計算具象化檢視,以提供與其主要聚合不同組織的資料。這通常是透過 map-reduce 計算來完成的。
第 4 章
資料分佈模式
-
有兩種資料分佈方式
- 分片會將不同的資料分佈在多個伺服器上,因此每個伺服器都是資料子集的單一來源。
- 複製會將資料複製到多個伺服器上,因此每個資料位元都可以在多個地方找到。
系統可以使用其中一種或兩種技術。
-
複製有兩種形式
- 主從複製會將一個節點設為具有寫入權限的權威副本,而從屬節點會與主節點同步,並可能處理讀取作業。
- 點對點複製允許對任何節點進行寫入;節點會協調以同步其資料副本。
主從複製可降低更新衝突的機率,但點對點複製則可避免將所有寫入作業都載入單一故障點。
第 5 章
一致性
- 當兩個用戶端嘗試同時寫入相同的資料時,就會發生寫入-寫入衝突。當一個用戶端在另一個用戶端寫入過程中讀取不一致的資料時,就會發生讀取-寫入衝突。
- 悲觀方法會鎖定資料記錄以防止衝突。樂觀方法會偵測衝突並修復衝突。
- 由於某些節點已收到更新而其他節點尚未收到更新,因此分散式系統會看到讀取-寫入衝突。最終一致性表示,在所有寫入作業傳播到所有節點後,系統會在某個時間點變得一致。
- 用戶端通常需要讀取-寫入一致性,這表示用戶端可以寫入資料,然後立即讀取新值。如果讀取和寫入發生在不同的節點上,這可能會很困難。
- 要獲得良好的一致性,您需要讓許多節點參與資料作業,但這會增加延遲。因此,您通常必須在一致性和延遲之間進行權衡。
- CAP 定理指出,如果您遇到網路分割,您必須在資料可用性和一致性之間進行權衡。
- 耐用性也可以與延遲進行權衡,特別是如果您想在複製資料的情況下存活下來。
- 您不需要聯繫所有副本即可透過複製來維持強一致性;您只需要足夠大的法定人數即可。
第 6 章
版本戳記
- 版本戳記可幫助您偵測並行衝突。當您讀取資料,然後更新資料時,您可以檢查版本戳記以確保在您讀取和寫入之間沒有人更新資料。
- 版本戳記可以使用計數器、GUID、內容雜湊、時間戳記或這些選項的組合來實作。
- 在分散式系統中,版本戳記向量可讓您偵測不同的節點是否有衝突的更新。
第 7 章
Map-Reduce
- Map-Reduce 是一種模式,可讓計算在叢集上平行化。
- Map 工作會從聚合讀取資料,並將其簡化為相關的鍵值對。Map 一次只會讀取單一記錄,因此可以平行化並在儲存記錄的節點上執行。
- Reduce 工作會採用 Map 工作的單一鍵輸出許多值,並將其摘要成單一輸出。每個 Reducer 會針對單一鍵的結果執行作業,因此可以按鍵平行化。
- 輸入和輸出形式相同的 Reducer 可以合併成管線。這會改善平行化,並減少要傳輸的資料量。
- Map-Reduce 作業可以組合成管線,其中一個 Reduce 的輸出是另一個作業 Map 的輸入。
- 如果 Map-Reduce 計算的結果廣泛使用,則可以將其儲存為實體化檢視。
- 實體化檢視可以透過增量 Map-Reduce 作業更新,這些作業只會計算檢視的變更,而不是從頭開始重新計算所有內容。
第 12 章
Schema 遷移
- 具有強 Schema 的資料庫(例如關聯式資料庫)可以透過儲存每個 Schema 變更及其資料遷移,在版本控制的順序中進行遷移。
- 無 Schema 資料庫仍需要小心遷移,因為任何存取資料的程式碼中都有隱含的 Schema。
- 無 Schema 資料庫可以使用與具有強 Schema 的資料庫相同的遷移技術。
- 無 Schema 資料庫也可以用一種容忍資料隱含 Schema 變更的方式讀取資料,並使用增量遷移來更新資料。
第 13 章
多語持久性
- 多語持久性是指使用不同的資料儲存技術來處理不同的資料儲存需求。
- 多語持久性可以應用於整個企業或單一應用程式中。
- 將資料存取封裝成服務,可以減少資料儲存選擇對系統其他部分的影響。
- 新增更多資料儲存技術會增加程式設計和作業的複雜性,因此良好的資料儲存配合的優點需要與此複雜性權衡。
第 14 章
超越 NoSQL
- NoSQL 只是資料儲存技術的一種。隨著我們對多語持久性的熟悉度提升,我們應該考慮其他資料儲存技術,無論它們是否具有 NoSQL 標籤。
第 15 章
選擇您的資料庫
-
使用 NoSQL 技術的兩個主要原因是
- 透過使用更符合應用程式需求的資料庫來提升程式設計師的工作效率。
- 透過處理更大資料量、減少延遲和提升傳輸量等組合方式來提升資料存取效能。
- 在承諾使用 NoSQL 技術之前,務必測試您對程式設計師工作效率和/或效能的預期。
- 服務封裝支援隨著需求和技術演進而變更資料儲存技術。將應用程式的部分分隔成服務,也能讓您將 NoSQL 引入現有的應用程式。
- 大多數應用程式,尤其是非策略性的應用程式,都應該堅持使用關聯式技術,至少等到 NoSQL 生態系統變得更成熟。
第 8-11 章沒有重點,因為這些是資料庫使用的範例