了得網計算機/網絡_NoSQL精粹（英文版）

編輯推薦

內容簡介

本書先從NoSQL的核心概念開始介紹：無模式的數據模型、新的分布式模型、CAP理論等，然後介紹了在實現NoSQL會遇到的體繫結構和設計方面的問題，並以很有代表性的幾種數據庫：Riak、MongoDB、Cassandra和Neo4j為例，展示了NoSQL數據庫的使用。

目錄
前言
**部分概念
第1章為什麼使用NoSQL3
1.1關繫型數據庫的價值3
1.1.1獲取持久化數據3
1.1.2並發4
1.1.3集成4
1.1.4近乎標準的模型4
1.2阻抗失諧5
1.3“應用程序數據庫”與“集成數據庫”6
1.4蜂擁而來的集群8
1.5NoSQL登場9
1.6要點12目錄

前言

**部分概念

第1章為什麼使用NoSQL3

1.1關繫型數據庫的價值3

1.1.1獲取持久化數據3

1.1.2並發4

1.1.3集成4

1.1.4近乎標準的模型4

1.2阻抗失諧5

1.3“應用程序數據庫”與“集成數據庫”6

1.4蜂擁而來的集群8

1.5NoSQL登場9

1.6要點12

第2章聚合數據模型13

2.1聚合14

2.1.1關繫模型與聚合模型示例14

2.1.2面向聚合的影響19

2.2鍵值數據模型與文檔數據模型20

2.3列族存儲21

2.4面向聚合數據庫總結23

2.5延伸閱讀24

2.6要點24

第3章數據模型詳解25

3.1關繫25

3.2圖數據庫26

3.3無模式數據庫28

3.4物化視圖30

3.5構建數據存取模型31

3.6要點36

第4章分布式模型37

4.1單一服務器37

4.2分片38

4.3主從復制40

4.4對等復制42

4.5結合“分片”與“復制”技術43

4.6要點44

第5章一致性47

5.1更新一致性47

5.2讀取一致性49

5.3放寬“一致性”約束52

5.4放寬“持久性”約束56

5.5仲裁57

5.6延伸閱讀59

5.7要點59

第6章版本戳61

6.1“商業事務”與“繫統事務”61

6.2在多節點環境中生成版本戳63

6.3要點65

第7章映射-化簡67

7.1基本“映射-化簡”68

7.2分區與歸並69

7.3組合“映射-化簡”計算72

7.3.1舉例說明兩階段“映射-化簡”73

7.3.2增量式“映射-化簡”76

7.4延伸閱讀77

7.5要點77

第二部分實現

第8章鍵值數據庫81

8.1何謂“鍵值數據庫”81

8.2鍵值數據庫特性83

8.2.1一致性83

8.2.2事務84

8.2.3查詢功能84

8.2.4數據結構86

8.2.5可擴展性86

8.3適用案例87

8.3.1存放會話信息87

8.3.2用戶配置信息87

8.3.3購物車數據87

8.4不適用場合87

8.4.1數據間關繫87

8.4.2含有多項操作的事務88

8.4.3查詢數據88

8.4.4操作關鍵字集合88

第9章文檔數據庫89

9.1何謂文檔數據庫90

9.2特性91

9.2.1一致性91

9.2.2事務92

9.2.3可用性93

9.2.4查詢功能94

9.2.5可擴展性95

9.3適用案例97

9.3.1事件記錄97

9.3.2內容管理繫統及博客平臺98

9.3.3網站分析與實時分析98

9.3.4電子商務應用程序98

9.4不適用場合98

9.4.1包含多項操作的復雜事務98

9.4.2查詢持續變化的聚合結構98

第10章列族數據庫99

10.1何謂列族數據庫99

10.2特性100

10.2.1一致性103

10.2.2事務104

10.2.3可用性104

10.2.4查詢功能105

10.2.5可擴展性107

10.3適用案例107

10.3.1事件記錄107

10.3.2內容管理繫統與博客平臺108

10.3.3計數器108

10.3.4限期使用108

10.4不適用場合109

第11章圖數據庫111

11.1何謂圖數據庫111

11.2特性113

11.2.1一致性114

11.2.2事務114

11.2.3可用性115

11.2.4查詢功能115

11.2.5可擴展性119

11.3適用案例120

11.3.1互聯數據120

11.3.2安排運輸路線、分派貨物和基於位置的服務120

11.3.3推薦引擎121

11.4不適用場合121

第12章模式遷移123

12.1模式變更123

12.2變更關繫型數據庫的模式123

12.2.1遷移全新項目124

12.2.2遷移既有項目126

12.3變更NoSQL數據庫的模式128

12.3.1增量遷移130

12.3.2遷移圖數據庫的模式131

12.3.3改變聚合結構132

12.4延伸閱讀132

12.5要點132

第13章混合持久化133

13.1各異的數據存儲需求133

13.2混用各類數據庫134

13.3將直接數據庫操作封裝為服務136

13.4擴展數據庫以增強其功能136

13.5選用合適的數據庫技術138

13.6企業使用混合持久化技術時的考量138

13.7部署復雜度139

13.8要點140

第14章超越NoSQL141

14.1文件繫統141

14.2事件溯源142

14.3內存映像144

14.4版本控制145

14.5XML數據庫145

14.6對像數據庫146

14.7要點146

第15章選擇合適的數據庫147

15.1程序員的工作效率149

15.2數據訪問性能150

15.3繼續沿用默認的關繫型數據庫150

15.4抽離數據庫策略以降低風險151

15.5要點152

15.6結語153

參考資料157

Contents

Part I: Understand . 1

Chapter 1: Why NoSQL? 3

1.1 The Value of Relational Databases 3

1.1.1 Getting at Persistent Data 3

1.1.2 Concurrency 4

1.1.3 Integration . 4

1.1.4 A (Mostly) Standard Model 4

1.2 Impedance Mismatch 5

1.3 Application and Integration Databases 6

1.4 Attack of the Clusters 8

1.5 The Emergence of NoSQL . 9

1.6 Key Points 12

Chapter 2: Aggregate Data Models 13

2.1 Aggregates . 14

2.1.1 Example of Relations and Aggregates 14

2.1.2 Consequences of Aggregate Orientation 19

2.2 Key-Value and Document Data Models . 20

2.3 Column-Family Stores . 21

2.4 Summarizing Aggregate-Oriented Databases . 23

2.5 Further Reading . 24

2.6 Key Points 24

Chapter 3: More Details on Data Models . 25

3.1 Relationships . 25

3.2 Graph Databases . 26

3.3 Schemaless Databases 28

3.4 Materialized Views 30

3.5 Modeling for Data Access 31

3.6 Key Points 36

Chapter 4: Distribution Models . 37

4.1 Single Server 37

4.2 Sharding 38

4.3 Master-Slave Replication . 40

4.4 Peer-to-Peer Replication . 42

4.5 Combining Sharding and Replication 43

4.6 Key Points 44

Chapter 5: Consistency 47

5.1 Update Consistency . 47

5.2 Read Consistency . 49

5.3 Relaxing Consistency . 52

5.3.1 The CAP Theorem 53

5.4 Relaxing Durability . 56

5.5 Quorums . 57

5.6 Further Reading . 59

5.7 Key Points 59

Chapter 6: Version Stamps . 61

6.1 Business and System Transactions 61

6.2 Version Stamps on Multiple Nodes 63

6.3 Key Points 65

Chapter 7: Map-Reduce . 67

7.1 Basic Map-Reduce . 68

7.2 Partitioning and Combining . 69

7.3 Composing Map-Reduce Calculations . 72

7.3.1 A Two Stage Map-Reduce Example 73

7.3.2 Incremental Map-Reduce . 76

7.4 Further Reading . 77

7.5 Key Points 77

Part II: Implement 79

Chapter 8: Key-Value Databases 81

8.1 What Is a Key-Value Store . 81

8.2 Key-Value Store Features . 83

8.2.1 Consistency . 83

8.2.2 Transactions 84

8.2.3 Query Features . 84

8.2.4 Structure of Data 86

8.2.5 Scaling 86

8.3 Suitable Use Cases . 87

8.3.1 Storing Session Information . 87

8.3.2 User Pro.les, Preferences . 87

8.3.3 Shopping Cart Data 87

8.4 When Not to Use . 87

8.4.1 Relationships among Data . 87

8.4.2 Multioperation Transactions 88

8.4.3 Query by Data . 88

8.4.4 Operations by Sets 88

Chapter 9: Document Databases 89

9.1 What Is a Document Database? . 90

9.2 Features . 91

9.2.1 Consistency . 91

9.2.2 Transactions 92

9.2.3 Availability 93

9.2.4 Query Features . 94

9.2.5 Scaling 95

9.3 Suitable Use Cases . 97

9.3.1 Event Logging 97

9.3.2 Content Management Systems, Blogging Platforms . 98

9.3.3 Web Analytics or Real-Time Analytics . 98

9.3.4 E-Commerce Applications . 98

9.4 When Not to Use . 98

9.4.1 Complex Transactions Spanning Different Operations 98

9.4.2 Queries against Varying Aggregate Structure 98

Chapter 10: Column-Family Stores 99

10.1 What Is a Column-Family Data Store? . 99

10.2 Features . 100

10.2.1 Consistency 103

10.2.2 Transactions 104

10.2.3 Availability 104

10.2.4 Query Features . 105

10.2.5 Scaling 107

10.3 Suitable Use Cases 107

10.3.1 Event Logging 107

10.3.2 Content Management Systems, Blogging Platforms . 108

10.3.3 Counters 108

10.3.4 Expiring Usage . 108

10.4 When Not to Use . 109

Chapter 11: Graph Databases . 111

11.1 What Is a Graph Database? . 111

11.2 Features . 113

11.2.1 Consistency 114

11.2.2 Transactions 114

11.2.3 Availability 115

11.2.4 Query Features . 115

11.2.5 Scaling 119

11.3 Suitable Use Cases 120

11.3.1 Connected Data 120

11.3.2 Routing, Dispatch, and Location-Based Services . 120

11.3.3 Recommendation Engines 121

11.4 When Not to Use . 121

Chapter 12: Schema Migrations . 123

12.1 Schema Changes 123

12.2 Schema Changes in RDBMS 123

12.2.1 Migrations for Green Field Projects . 124

12.2.2 Migrations in Legacy Projects . 126

12.3 Schema Changes in a NoSQL Data Store . 128

12.3.1 Incremental Migration . 130

12.3.2 Migrations in Graph Databases 131

12.3.3 Changing Aggregate Structure 132

12.4 Further Reading . 132

12.5 Key Points 132

Chapter 13: Polyglot Persistence . 133

13.1 Disparate Data Storage Needs 133

13.2 Polyglot Data Store Usage 134

13.3 Service Usage over Direct Data Store Usage . 136

13.4 Expanding for Better Functionality 136

13.5 Choosing the Right Technology . 138

13.6 Enterprise Concerns with Polyglot Persistence . 138

13.7 Deployment Complexity 139

13.8 Key Points 140

Chapter 14: Beyond NoSQL 141

14.1 File Systems 141

14.2 Event Sourcing . 142

14.3 Memory Image . 144

14.4 Version Control . 145

14.5 XML Databases . 145

14.6 Object Databases . 146

14.7 Key Points 146

Chapter 15: Choosing Your Database 147

15.1 Programmer Productivity . 147

15.2 Data-Access Performance . 149

15.3 Sticking with the Default 150

15.4 Hedging Your Bets . 150

15.5 Key Points 151

15.6 Final Thoughts . 152

Bibliography . 153

前言

前言我們已經在企業級計算領域研究了20餘年，編程語言、架構、平臺、軟件開發流程等技術都在改變，然而這期間有一件事卻一直沒變，那就是：大家依然使用關繫型數據庫來存儲數據。雖說也出現了一些挑戰關繫型數據庫的產品，而且有的還在某些領域成功了，但是總體來說，留給架構師的數據存儲問題仍然是選擇使用哪款關繫型數據庫的問題。
穩定性在此領域頗受重視。企業的數據比程序存儲的時間要長很多（至少大家都是這麼說的。當然啦，我們也見過許多非常老的程序）。擁有一個既穩定，又容易理解，而且還能讓許多應用程序編程平臺訪問的數據庫，是非常有價值的。
不過，關繫型數據庫現在踫上新對手了，它的名字叫NoSQL。由於我們需要處理的數據量越來越大，必須以商用服務器集群來構建大型硬件平臺，因此NoSQL就應運而生了。這也使大家要再次考慮那個存在已久的難題，即代碼如何纔能同關繫型數據庫良好地結合起來。
“NoSQL”這個詞的定義是非常不明確的。它泛指那些*近誕生的非關繫型數據庫，諸如Cassandra、MongoDB、Neo4J和Riak等。它們主張使用無模式（schemaless）的數據，可以運行在集群環境中，並且能夠犧牲傳統數據庫所具備的一致性，以換取另外一些有用的特性。NoSQL的倡導者聲稱，使用它們可以構建出性能更高、擴展度更好且更易編程的繫統。前言我們已經在企業級計算領域研究了20餘年，編程語言、架構、平臺、軟件開發流程等技術都在改變，然而這期間有一件事卻一直沒變，那就是：大家依然使用關繫型數據庫來存儲數據。雖說也出現了一些挑戰關繫型數據庫的產品，而且有的還在某些領域成功了，但是總體來說，留給架構師的數據存儲問題仍然是選擇使用哪款關繫型數據庫的問題。

穩定性在此領域頗受重視。企業的數據比程序存儲的時間要長很多（至少大家都是這麼說的。當然啦，我們也見過許多非常老的程序）。擁有一個既穩定，又容易理解，而且還能讓許多應用程序編程平臺訪問的數據庫，是非常有價值的。

不過，關繫型數據庫現在踫上新對手了，它的名字叫NoSQL。由於我們需要處理的數據量越來越大，必須以商用服務器集群來構建大型硬件平臺，因此NoSQL就應運而生了。這也使大家要再次考慮那個存在已久的難題，即代碼如何纔能同關繫型數據庫良好地結合起來。

“NoSQL”這個詞的定義是非常不明確的。它泛指那些*近誕生的非關繫型數據庫，諸如Cassandra、MongoDB、Neo4J和Riak等。它們主張使用無模式（schemaless）的數據，可以運行在集群環境中，並且能夠犧牲傳統數據庫所具備的一致性，以換取另外一些有用的特性。NoSQL的倡導者聲稱，使用它們可以構建出性能更高、擴展度更好且更易編程的繫統。

這會不會敲響了關繫型數據庫即將滅亡的**聲警鐘呢？還是說NoSQL要搶走數據庫領域的頭把交椅？我們的回答是：“這兩種情況都不會出現。”關繫型數據庫是一個非常強大的工具，我們希望能長時間使用下去；然而大家也要看到一場深遠的變革，那就是：關繫型數據庫不再是**的選擇了。我們認為，數據庫領域正進入混合持久化（Polyglot Persistence）時代，由企業乃至個人研發的應用程序，可以使用多種技術來管理數據。因此架構師需要熟悉這些技術，並且能根據不同的需求做出適當的選擇。若非如此，筆者怎會花那麼多時間和精力來寫這本書呢？本書給諸位讀者提供足夠多的信息，協助大家在以後的研發過程中思考：項目是否真的值得使用NoSQL數據庫。每個項目都是不同的，我們不可能寫出一個簡單的決策樹，用它來選出合適的數據存儲方式。與之相反，本書力求講解大量的背景知識，以便大家了解NoSQL的工作原理，這樣的話，你不用在互聯網上四處尋找，就能夠做出適合自己項目的決定了。筆者刻意將本書寫得很短，以便讀者能夠快速閱覽它。雖說本書不會回答各種具體問題，但是，它可以幫你縮小考慮的範圍，讓你明白自己當前應該提出哪些問題。

NoSQL數據庫為何引人關注我們來看一下大家選用NoSQL數據庫的兩個主要原因。

應用程序的開發效率。在很多應用程序的開發過程中，大量精力和時間都放在了內存（in-memory）數據結構和關繫型數據庫之間的映射上面。NoSQL數據庫可以提供一種更加符合應用程序需求的數據模型，從而簡化了數據交互，減少了所需編寫、調試並修改的代碼量。

大規模的數據。企業所重視的是，數據庫要能夠快速獲取並處理數據。他們發現，即便關繫型數據庫能達成這一目標，其成本也很高。主要原因在於，關繫型數據庫是為獨立運行的計算機而設計的，但是現在大家通常使用由更小、更廉價的計算機所組成的集群來計算數據，這樣更實惠些。許多NoSQL數據庫正是為集群環境而設計，因此它們更適合大數據量的應用場景。

本書內容本書分為兩個部分。**部分主要講述核心概念，讓讀者能夠判斷出NoSQL數據庫是否適合自己，並且了解各種NoSQL數據庫之間的差別。第二部分更加專注於實現NoSQL數據庫繫統。

第1章解釋了NoSQL發展如此迅速的原因：由於需要處理的數據量越來越多，所以大型繫統的擴展方式，由原來在單一計算機上的縱向擴展，轉變為在計算機集群上的橫向擴展。這也印證了許多NoSQL數據庫的數據模型所具備的一個重要特性，那就是：可以把內容密切相關的數據組織成一種豐富的結構，並將其顯式存儲起來，以便作為（unit）來訪問。本書中，我們將這種類型的結構稱為聚合（aggregate）。

第2章描述了在NoSQL領域的三種主要數據模型中，如何體現“聚合”這一概念。這三種數據庫模型是：“鍵值模型”（key-value，參見2.2節），“文檔模型”（document，參見2.2節）和“列族模型”（column family，參見2.3節）。聚合為許多種應用提供了一個自然的，既改善了集群的運行狀況，又使編寫程序來訪問數據庫變得更為容易。第3章轉到聚合的缺點上面：難以處理位於不同聚合的實體之間的關繫（參見3.1節）。這自然就引出了圖數據庫（參見3.2節），它是一個不屬於面向聚合（aggregated-oriented）陣營的NoSQL數據模型。我們也會講到NoSQL數據庫的共同特性：它們都是以“無模式”的形式來操作的（參見3.3節）。模式的這種特性確實提供了更大的靈活性，但是它並不像大家想像的那麼**。

在講完NoSQL數據模型方面的內容之後，我們接下來要講分布模型。第4章描述了數據庫如何在集群中分布數據。這個問題又細分為“分片”（sharding，參見4.2節）和“復制”（replication），復制方式可以是“主從復制”（master-slave replication，參見4.3節）或者“對等復制”（peer-to-peer replication，參見4.4節）。了解完分布模型的概念後，接下來要講“一致性”（consistency）問題。與關繫型數據庫相比，NoSQL數據庫在一致性方面提供了更多選擇，這麼做是因為NoSQL要更好地支持集群。於是，第5章談到了更新與讀取操作對一致性的影響（分別參見5.1節和5.2節），如何在一致性與持久性之間進行仲裁（參見5.5節），以及如何放寬對持久性的約束以提升其他特性（參見5.4節）。如果之前聽過NoSQL，那麼就應該聽過“CAP定理”（The CAP Theorem）。5.3節中介紹了CAP定理的相關知識，告訴大家如何根據該理論來權衡一致性與其他特性。

前面這些章節主要側重於如何分布數據並保持其一致性，接下來的兩章討論了要完成這項工作所需的一些重要工具。第6章講述了版本戳（version stamp），它用來記錄數據庫的內容變更，並且可以檢測數據是否一致。第7章概述了“映射-化簡”（Map-Reduce）操作，這種計算方式很適合在集群中組織並行計算，因而也適用於NoSQL繫統。

講完這些概念後，我們針對以下4種數據庫各舉一些例子，來演示如何實現上述概念。第8章使用Riak來演示“鍵值數據庫”，第9章使用MongoDB作為“文檔數據庫”的示例，第10章選用Cassandra來探討“列族數據庫”，第11章選擇了Neo4J作為“圖數據庫”的示例。此處必須強調：要想全面學習數據庫，隻依靠這些章節是不夠的。因為除此之外還有很多內容，沒辦法寫在這本書中，而且還有更多東西必須嘗試之後纔能學會。本書選擇這些示例，並不是建議大家在工作中使用它們，其目的是讓讀者知道數據的各種存儲方式，明白不同的數據庫技術如何使用前面提到的概念。讀者會看到這些數據庫繫統都需要何種程序代碼，並且簡單了解使用它們時所應遵循的開發思路。

有些人經常會覺得：因為NoSQL數據庫沒有模式，所以在應用程序的生命期中，可以毫無困難地改變其數據結構。本書不同意此觀點，因為無模式的數據庫其實隱含了一種模式，在實現數據結構變更時，也必須修改其規則。所以，第12章解釋了數據如何在強模式與無模式繫統之間遷移。

所有這一切都清楚地表明：NoSQL不是獨立存在的，也不會取代關繫型數據庫。第13章著眼於混合持久化領域的發展趨勢：多種數據存儲方式將共存，有時甚至會存在於同一個應用中。第14章將大家的視野擴展至本書之外，在混合持久化領域中，考慮一些前面沒有涉及的技術。

掌握了前面所講的全部內容之後，讀者就應該明白如何選擇合適的數據存儲技術了。所以*後一章（第15章）提供了一些選擇數據庫時可以參考的建議。筆者認為，有兩個關鍵因素：找到一種高效的編程模型，其數據存儲模型要非常符合待開發的應用程序，並且確保其獲取數據的效率與彈性均符合開發者的需求。從NoSQL誕生之初，我們就擔心沒有一套定義明確的流程可以遵循，現在，你仍然需要結合自己的需求，來驗證自己所選擇的數據庫技術是否合適。

本書隻是個簡要的概述，所以筆者一直在盡力壓縮篇幅。我們精選了自己認為*重要的信息，這部分內容讀者就不必再去找了。如果打算認真研究這些技術，那就需要進一步研讀本書以外的知識了，不過，我們還是希望本書能為你的探索之路開個好頭。

還需要強調的是：計算機領域中的這些技術是日新月異的，存儲技術的某些重要方面在不斷變化，每年都會出現新的特性與新的數據庫。筆者投入了巨大的精力來專門講述概念，因為就算底層技術變了，對這些概念的理解也依然有價值。我們非常確信，本書所講的大部分概念都會歷久綿長，但絕不能保證所有概念都會如此。

誰應該閱讀本書如果正在考慮選用某種形式的NoSQL數據庫，那就應該閱讀本書。選用NoSQL的原因可能是你打算做一個新的項目，也可能是既有項目遭遇瓶頸，所以要將其數據庫遷移到NoSQL數據庫上。

本書致力於給讀者提供足夠的信息，以判斷自己所選的NoSQL技術是否符合需求，如果符合的話，應該深入研究哪些工具。我們設想本書的主要讀者是架構師或技術主管，然而那些想大概了解這門新技術的軟件管理人員也可以閱讀本書。此外，對於想大概了解這項技術的開發人員來說，這也是本很好的入門讀物。

本書不講編程細節，也不去部署某個特定的數據庫，那些內容留待更為專業的教材來寫吧。我們還嚴格限制了本書的篇幅。筆者認為，這種書應該在坐飛機的時候讀：它不會回答你提出的所有問題，但卻會激發你提出一堆好問題來。

若是之前已經深入研究了NoSQL領域，那麼本書可能不會增加你的知識儲備。不過，它仍然有助於你將之前學到的東西解釋給別人聽。把圍繞著NoSQL的爭論理解清楚是很重要的，尤其當你要勸說別人在項目中也采用NoSQL技術時更是如此。

本書要講的數據庫類型本書遵循常見的分類方式，也就是按照數據模型來劃分各種NoSQL數據庫。下表列出了4種數據模型，以及歸屬於每種數據模型的數據庫。這份列表並不完整，其中隻列出了較為常見的數據庫。撰寫本書時，在http://nosql-database.org與http://nosql.mypopescu.com/kb/nosql都可查閱到更為完整的列表。每個分類中，以斜體標出的數據庫，都會在相關章節中作為範例來講解。

數據模型範例數據庫數據模型範例數據庫鍵值（參見第8章）BerkeleyDBLevelDBMemcachedProject VoldemortRedisRiak文檔（參見第9章）CouchDBMongoDBOrientDBRavenDBTerrastore列族（參見第10章）Amazon SimpleDBCassandraHBaseHypertable圖（參見第11章）FlockDBHyperGraphDBInfinite GraphNeo4JOrientDB這樣劃分的目的是從每一類數據庫中，選出一個*有代表性的工具來講。盡管每個分類下列出的那些數據庫各不相同，不可像這樣一概而論，但是，書中提到的那些具體示例，其實大多數情況下也適用於此分類中的其他數據庫。我們會從“鍵值數據庫”“文檔數據庫”“列族數據庫”和“圖數據庫”這4類中各選一個作為範例，此外，在必要時，還會提到可以滿足某個特定功能的其他產品。

按數據模型來分類是可行的，但卻失之武斷。不同數據模型之間的界限往往是模糊的，比如鍵值和文檔數據庫（參見2.2節）之間的區別就不是很明顯。許多數據庫並不能明確地歸入某一類。例如，OrientDB稱自己既是文檔數據庫又是圖數據庫。

致謝首先感謝ThoughtWorks的諸位同仁，在過去的幾年中，很多同事在交付的項目中應用了NoSQL。筆者寫作本書的動機主要來源於他們的經驗，而這些經驗亦是能印證NoSQL技術價值的實用信息。目前為止通過使用NoSQL數據存儲積累了一些有益的經驗，基於這些經驗，我們認為：NoSQL是一項重要的數據存儲技術，它正引發該領域內的一場重大變革。

我們也要感謝舉辦公開講座、發表文章和博客來分享NoSQL使用心得的各種社群。若是大家都不願意與同行分享研究成果的話，那麼許多軟件開發領域的發展就不為人知了。特別感謝谷歌及亞馬遜的BigTable和Dynamo技術規範論文，它們對NoSQL的發展影響深遠。也要感謝為開源NoSQL數據庫的開發提供贊助及技術貢獻的公司。這一次發生在數據存儲領域的變革，與以往相比有一個較為有趣的差別：NoSQL的發展深度植根於開源工作。

特別感謝ThoughtWorks公司給予筆者時間來寫作本書。我們兩個大約同一時間加入ThoughtWorks，並且在這裡工作了10餘年。ThoughtWorks對我們來說一直是個非常友好的大家庭，同時也是知識和實踐的來源。在這個良好的環境中，大家可以公開分享各自所學的知識，這與傳統的繫統交付公司（System Delivery Organization）非常不同。

Bethany Anders-Beck、Ilias Bartolini、Tim Berglund、Duncan Craig、Paul Duvall、Oren Eini、Perryn Fowler、Michael Hunger、Eric Kascic、 Kerievsky、Anand Krishnaswamy、Bobby Norton、Ade Oshineye、Thiyagu Palanisamy、Prasanna Pendse、Dan Pritchett、David Rice、Mike Roberts、Marko Rodriquez、Andrew Slocum、Toby Tripp、Steve Vinoski、Dean Wampler、Jim Webber和Wee Witthawaskul審閱了本書初稿，並提出了改進建議。

此外，Pramod要感謝紹姆堡圖書館（Schaumburg Library）提供的一流服務和安靜的寫作空間；感謝愛女Arhana和Arula，你們知道爸爸到圖書館是為了寫書，而沒有帶你們同去；感謝愛妻Rupali，你給了我巨大的支持和幫助，讓我能夠集中精力完成本書。

商品搜索

商品分类

【醫學】

【各大出版社】