第一章：Cassandra超越關係數據庫--Cassandra：The Definitive Guide 2nd Edition

歡迎來到Cassandra：The Definitive Guide。 本書的目的是幫助開發人員和數據庫管理員瞭解這一重要的數據庫技術。 在本書的過程中，我們將探討Cassandra如何與傳統的關係數據庫管理系統進行比較，並幫助您將其用於您自己的環境中。

關係數據庫有什麼問題？

我們要求你考慮一個數據模型，由一個擁有數千名員工的公司的小團隊發明。 它可以通過TCP / IP接口訪問，並且可以從各種語言中獲得，包括Java和Web服務。 除了最先進的計算機科學家之外，這個模型起初很難理解，直到更廣泛的採用有助於使概念更清晰。 使用圍繞此模型構建的數據庫需要學習新術語並以不同方式考慮數據存儲。 但隨着產品的興起，越來越多的企業和政府機構投入使用，這在很大程度上是因爲它能夠快速處理數千次操作。 它產生的收入是巨大的。

然後出現了一個新模型。

新模型受到威脅，主要有兩個原因。 首先，新模型與舊模型非常不同，舊模型引人注目。 這是一種威脅，因爲很難理解不同和新的東西。 隨後的辯論可以幫助人們在他們的觀點中頑固地進一步鞏固人們的觀點 - 這些觀點可能主要是從他們學習手藝的環境和他們工作的環境中繼承下來的。 其次，也許更重要的是，作爲一個障礙，新模式具有威脅性，因爲企業已經對舊模式進行了大量投資，並且用它賺了不少錢。 改變路線似乎很荒謬，甚至是不可能的。

當然，我們正在討論信息管理系統（IMS）分層數據庫，該數據庫於1966年在IBM發明。

IMS是爲土星五號月球火箭而設計的。 它的建築師是Vern Watts，他的職業生涯就是爲此而努力。 我們中的許多人都熟悉IBM的數據庫DB2。 IBM廣受歡迎的DB2數據庫得名於DB1的繼承者 - DB1是圍繞分層數據模型IMS構建的產品。 IMS於1968年發佈，隨後在客戶信息控制系統（CICS）和其他應用程序中取得了成功。 它至今仍在使用。

但是在IMS發明之後的幾年裏，新模型，破壞性模型，威脅模型，是關係數據庫。

在1970年的論文“大型共享數據庫的數據關係模型”中，Edgar F. Codd博士也在IBM聖何塞研究實驗室工作時提出了關於數據關係模型的理論。 本文仍然可以在http://www.seas.upenn.edu/~zives/03f/cis550/codd.pdf 上找到，它成爲關係數據庫管理系統的基礎工作。

Codd的工作與IMS的層次結構相對立。 理解和使用關係數據庫需要學習新術語，包括“關係”，“元組”和“正常形式”，所有這些術語對於IMS的用戶來說確實聽起來非常奇怪。 它比其前身具有一些關鍵優勢，例如表達多個實體之間複雜關係的能力，遠遠超出分層數據庫所代表的能力。

雖然這些想法及其應用已經發展了四十年，但關係數據庫顯然仍然是歷史上最成功的軟件應用程序之一。 它在獨資企業中以Microsoft Access的形式使用，在大型跨國公司中使用，其中包含數百個精細調整的實例集羣，代表數TB的數據倉庫。 關係數據庫存儲發票，客戶記錄，產品目錄，會計分類帳，用戶身份驗證方案 - 可能會出現這個世界。 毫無疑問，關係數據庫是現代技術和商業領域的關鍵方面，並且將在未來許多年內以各種形式與我們合作，IMS將以各種形式出現。 關係模型提供了IMS的替代方案，每種方法都有其用途。

因此，對“關係數據庫有什麼問題？”這個問題的簡短回答是“沒什麼”。

然而，有一個相當長的答案，它說，每隔一段時間，一個想法誕生，表面上會改變事物，併產生各種革命。 然而，從另一方面來看，從結構上看，這種革命只是歷史的一切照舊。 IMS，RDBMS，NoSQL。 馬，車，飛機。 它們各自以現有技術爲基礎，它們各自試圖解決某些問題，因此它們每個人都善於處理某些事情而不善於其他事情。 它們各自共存，即使是現在。

讓我們來看看爲什麼，在這一點上，爲什麼我們可以考慮替代關係數據庫，就像四十年前Codd本人看到信息管理系統並認爲它可能不是組織信息的唯一合法方式 並解決數據問題，也許，對於某些問題，考慮替代方案可能會很有成效。

當關系應用程序成功並且使用率上升時，我們會遇到可伸縮性問題。 連接是任何相對規範化的關係數據庫中固有的，即使是適度的大小，連接也可能很慢。 數據庫獲得一致性的方式通常是通過使用事務，這需要鎖定數據庫的某些部分，以便其他客戶端無法使用。 在非常繁重的負載下，這可能變得難以維持，因爲鎖意味着競爭用戶開始排隊，等待他們輪流讀取或寫入數據。

我們通常通過以下一種或多種方式解決這些問題，有時按此順序：

• 通過添加更多內存，添加更快的處理器和升級磁盤來解決問題。這稱爲垂直縮放。這可以緩解你一段時間。

• 當問題再次出現時，答案似乎是相似的：現在一個框被最大化，您在數據庫集羣中以附加框的形式添加硬件。現在，您在常規使用和故障轉移方案中遇到了數據複製和一致性的問題。你以前沒有那個問題。

• 現在我們需要更新數據庫管理系統的配置。這可能意味着優化數據庫用於寫入底層文件系統的通道。我們關閉日誌記錄或日誌記錄，這通常不是理想的（或者，根據您的情況，合法）選項。

• 我們將注意力集中到數據庫系統中，然後轉向我們的應用程序。我們試圖改進我們的指數。我們優化查詢。但據推測，在這種規模下，我們並不完全不瞭解索引和查詢優化，並且已經有了很好的形狀。因此，這將成爲一個痛苦的過程，通過數據訪問代碼來尋找任何微調機會。這可能包括減少或重新組織聯接，拋出資源密集型功能，例如存儲過程中的XML處理等等。當然，大概我們正在進行XML處理是有原因的，所以如果我們必須在某個地方進行，我們將這個問題移到應用程序層，希望在那裏解決它並且交叉我們的手指我們不會破壞別的東西與此同時。

• 我們使用緩存層。 對於較大的系統，這可能包括分佈式緩存，例如memcached，Redis，Riak，EHCache或其他相關產品。 現在，我們在緩存中的更新和數據庫中的更新之間存在一致性問題，這在集羣中會加劇。

• 我們再次將注意力轉向數據庫並確定，現在應用程序已構建並且我們瞭解主要查詢路徑，我們可以複製一些數據，使其看起來更像是訪問它的查詢。 這個過程稱爲非規範化，與表徵關係模型的五種常規形式相對立，違反了Codd關於關係數據的12條規則。 我們提醒自己，我們生活在這個世界中，而不是在某些理論雲中，然後承諾盡我們所能使應用程序再次以可接受的水平響應，即使它不再是“純粹的”。

科德的十二條規則

Codd提供了12個規則（實際上有13個，編號爲0到12）的列表，正式確定了他對關係模型的定義，作爲對商業數據庫與其原始概念的分歧的迴應。 1985年10月，Codd在CompuWorld雜誌的一篇文章中介紹了他的規則，並在他的“數據庫管理關係模型”一書的第二版中將其正式化，現在已經絕版。

這聽起來很熟悉。在網絡規模上，工程師可以合理地思考這種情況是否與亨利·福特的斷言相似，即在某個時刻，它不僅僅是你想要的更快的馬。他們做了一些令人印象深刻，有趣的工作。

因此，我們必須從這裏開始認識到關係模型只是一個模型。也就是說，它旨在成爲一種觀察世界的有用方式，適用於某些問題。它並不意味着詳盡無遺，在所有其他表示數據的方式上結案，再也沒有進行過檢查，沒有留下替代品的餘地。如果我們從歷史的長遠看，Codd博士的模型在當時是一個相當具有破壞性的模型。它是新的，帶有奇怪的新詞彙和術語，如“元組” - 以新的和不同的方式使用的熟悉的單詞。關係模型受到懷疑，無疑遭受了強烈的批評者。它甚至以Codd博士自己的僱主IBM的形式遭遇了反對，IBM擁有圍繞IMS的非常有利可圖的產品，並且不需要年輕的暴發戶。

但是關係模型現在可以說是數據世界中最好的位置。 SQL得到了廣泛的支持和理解。 它在入門大學課程中講授。 有一些開源數據庫已經安裝好，可以使用每月4.95美元的網絡託管計劃。 基於雲的平臺即服務（PaaS）提供商（如Amazon Web Services，Google Cloud Platform，Rackspace和Microsoft Azure）提供關係數據庫訪問即服務，包括自動監控和維護功能。 我們最終使用的數據庫通常由我們組織內的架構標準決定。 即使沒有這樣的標準，也要謹慎地瞭解您的組織已經擁有的數據庫平臺。 我們在開發和基礎設施方面的同事擁有相當來之不易的知識

如果只是滲透（或慣性），我們多年來已經瞭解到關係數據庫是一種通用的解決方案。

所以也許更好的問題不是“關係數據庫有什麼問題？”而是“你有什麼問題？”

也就是說，您希望確保您的解決方案符合您的問題。 關係數據庫解決的問題很嚴重。 但是，網絡的爆炸式增長，尤其是社交網絡，意味着我們必須處理的大量數據相應爆炸式增長。 當Tim Berners-Lee在20世紀90年代初首次在網上工作時，它的目的是在物理實驗室的博士之間交換科學文獻。 當然，現在，網絡已經變得如此普遍，以至於每個人都使用它，從同樣的科學家到五歲大的小夥子交換關於小貓的表情符號。 這意味着它必須支持大量數據; 事實上，它確實是Web的巧妙架構的紀念碑。

但是，一些基礎設施開始在重量下屈服。

關係數據庫的快速回顧

雖然您可能熟悉它們，但讓我們簡單地將注意力轉向關係數據庫中的一些基本概念。 這將爲我們提供一個基礎，可以考慮圍繞分佈式數據系統固有的權衡取捨的最新進展，特別是非常大的分佈式數據系統，例如網絡規模所需的那些。

RDBMS：令人敬畏和不那麼多

關係數據庫在過去四十年中變得如此受歡迎的原因有很多。一個重要的結構化查詢語言（SQL），它功能豐富，使用簡單的聲明性語法。 SQL於1986年首次被正式採用爲ANSI標準;從那時起，它經歷了多次修訂，並且還通過Microsoft的T-SQL和Oracle的PL / SQL等供應商專有語法進行了擴展，以提供其他特定於實現的功能。

SQL功能強大有多種原因。它允許用戶使用形成數據操作語言（DML）的語句來表示與數據的複雜關係，以插入，選擇，更新，刪除，截斷和合並數據。您可以使用基於關係代數的函數執行各種各樣的操作，例如，查找集合中的最大值或最小值，或者過濾和排序結果。 SQL語句支持對聚合值進行分組並執行彙總函數。 SQL提供了一種使用數據定義語言（DDL）在運行時直接創建，更改和刪除模式結構的方法。 SQL還允許您使用相同的語法爲用戶和用戶組授予和撤消權限。

SQL易於使用。 可以快速學習基本語法，從概念上講，SQL和RDBMS提供了較低的入門門檻。 初級開發人員可以隨時變得熟練，而且在快速變化，緊迫的期限和預算爆炸的行業中經常出現這種情況，易用性非常重要。 並且它不僅僅是易於使用的語法; 有許多強大的工具，包括用於查看和使用數據庫的直觀圖形界面。

部分原因是它是標準，SQL允許您輕鬆地將RDBMS與各種系統集成。 您所需要的只是一個適用於您的應用程序語言的驅動程序，並且您可以通過非常便攜的方式參加比賽。 如果您決定更改應用程序實現語言（或您的RDBMS供應商），您通常可以輕鬆地執行此操作，假設您沒有使用大量專有擴展來支持自己。

事務，ACID-ity和兩階段提交

除了已經提到的功能之外，RDBMS和SQL還支持事務。 事務的一個關鍵特性是它們首先實際執行，允許程序員撤消（使用回滾）在執行期間可能出錯的任何更改; 如果一切順利，交易可以可靠地提交。 正如Jim Gray所說，交易是“國家轉型”，具有ACID屬性（參見“交易概念：美德與限制”）。

ACID是Atomic，Consistent，Isolated，Durable的首字母縮寫，它是我們用來評估交易是否正確執行並且成功的指標：

• 原子性

  原子意味着“全有或全無”; 也就是說，當執行語句時，事務中的每個更新都必須成功才能被調用成功。 沒有部分失敗，其中一次更新成功，另一次相關更新失敗。 這裏的常見例子是ATM上的貨幣轉賬：轉賬需要從一個賬戶中減去錢並將其添加到另一個賬戶。 此操作無法細分; 他們必須都成功。

• 一致性

  一致意味着數據從一個正確的狀態移動到另一個正確的狀態，讀者不可能一起查看不合理的不同值。 例如，如果交易嘗試刪除客戶及其訂單歷史記錄，則不能保留引用已刪除客戶主鍵的訂單行; 這是一種不一致的狀態，如果有人試圖讀取這些訂單記錄，則會導致錯誤

• 隔離性

  隔離意味着併發執行的事務不會相互糾纏; 它們各自在自己的空間中執行。 也就是說，如果兩個不同的事務試圖同時修改相同的數據，那麼其中一個將不得不等待另一個完成。

• 持久性

  一旦事務成功，更改將不會丟失。 這並不意味着另一個事務不會在以後修改相同的數據; 它只是意味着編寫者可以確信更改可用於下一個要處理的事務。

關於支持交易的爭論很快就會成爲圍繞非關係數據存儲的對話中的一個痛點，所以讓我們花點時間重新審視這意味着什麼。從表面上看，ACID屬性似乎顯然是可取的，甚至不值得談話。據推測，沒有人運行數據庫會表明數據更新不必持續一段時間;這是進行更新的重點 - 他們可以讓其他人閱讀。但是，更細微的檢查可能會讓我們想要找到一種方法來稍微調整這些屬性並稍微控制它們。正如他們所說，互聯網上沒有免費午餐，一旦我們看到我們如何支付交易費用，我們可能會開始懷疑是否有其他選擇。

在重負荷下交易變得困難。當您首次嘗試水平擴展關係數據庫，使其分佈時，您現在必須考慮分佈式事務，其中事務不僅僅在單個表或單個數據庫中運行，而是分佈在多個系統中。爲了繼續遵守事務的ACID屬性，您現在需要一個事務管理器來跨多個節點進行編排。

爲了說明跨多個主機的成功完成，引入了兩階段提交（有時稱爲“2PC”）的想法。但是，因爲兩階段提交會鎖定所有相關資源，所以它僅對可以非常快速完成的操作有用。儘管通常情況下您的分佈式操作可以在亞秒內完成，但情況肯定並非總是如此。某些用例需要您可能無法控制的多個主機之間的協調。協調若干不同但相關活動的操作可能需要數小時才能更新。

兩階段提交塊;也就是說，客戶端（“競爭消費者”）必須等待先前的事務完成才能訪問被阻止的資源。該協議將等待節點響應，即使它已經死亡。在此事件中可以避免永遠等待，因爲可以設置超時，允許事務協調器節點決定節點不響應並且應該中止事務。但是，2PC仍然可以實現無限循環;這是因爲節點可以向事務協調器節點發送消息，同意協調器可以提交整個事務。然後，節點將等待協調器發送提交響應（或者，如果不同的節點無法提交，則返回回滾響應）;如果協調器在這種情況下失效，那麼該節點可能會永遠等待。

因此，爲了解決分佈式事務的兩階段提交中的這些缺點，數據庫世界轉向了補償的想法。 通常在Web服務中使用的補償意味着操作立即提交，然後在報告某些錯誤的情況下，調用新操作以恢復正常狀態。

有一些基本的，衆所周知的補償行爲模式，架構師經常不得不考慮作爲兩階段提交的替代方案。 這些包括在交易失敗時註銷，決定丟棄錯誤的交易並在以後進行覈對。 另一種方法是稍後在通知時重試失敗的操作。 在預訂系統或股票銷售代碼中，這些不太可能滿足您的要求。 對於其他類型的應用程序，例如計費或票務應用程序，這是可以接受的。

2PC爲應用程序開發人員引入的問題包括部分故障期間的可用性損失和更高的延遲。 這些都不可取。 因此，一旦你有足夠的成功就必須通過一臺機器擴展數據庫，你現在必須弄清楚如何在多臺機器上處理事務並仍然使ACID屬性適用。 無論您有10臺還是100臺或1,000臺數據庫計算機，事務中仍然需要原子性，就像您在單個節點上工作一樣。 但它現在吞下了一個更大，更大的藥丸。

架構

關係數據庫系統的一個經常被稱讚的特性是它們提供的豐富模式。 您可以在關係模型中表示域對象。 圍繞（昂貴的）工具（例如CA ERWin Data Modeler）湧現出整個行業來支持這一努力。 但是，爲了創建正確規範化的模式，您必須創建在域中不存在的業務對象的表。 例如，大學數據庫的模式可能需要“學生”表和“課程”表。 但由於這裏的“多對多”關係（一個學生可以同時學習多門課程，一門課程同時有很多學生），你必須創建一個連接表。 這污染了原始數據模型，我們更喜歡只有學生和課程。 它還迫使我們創建更復雜的SQL語句來將這些表連接在一起。 反過來，join語句可能很慢。

同樣，在適度規模的系統中，這不是一個大問題。但是，一旦在許多表中處理大量行來處理複雜查詢和多個連接，就會變得非常緩慢。

最後，並非所有模式都能很好地映射到關係模型。在過去十年中越來越受歡迎的一種系統是複雜的事件處理系統，它以非常快的速度表示狀態變化。將運行時事件與可能相關的其他事件進行上下文關聯通常很有用，以便推斷出一些支持業務決策的結論。雖然事件流可以用關係數據庫來表示，但這是一個令人不舒服的延伸。

如果您是一名應用程序開發人員，您無疑會熟悉近年來湧現出來的許多對象關係映射（ORM）框架，以幫助減輕將應用程序對象映射到關係模型的難度。同樣，對於小型系統，ORM可以是一種解脫。但它也引入了自己的新問題，例如擴展內存需求，並且它經常使用越來越難以處理的映射代碼來污染應用程序代碼。這是一個使用Hibernate來減輕必須編寫SQL代碼負擔的Java方法的示例：

是否確定我們已經做了什麼，只是在這裏解決問題？ 當然，對於某些系統，例如那些廣泛使用文檔交換的系統，如服務或基於XML的應用程序，關係數據庫並不總是有明確的映射。 這加劇了這個問題。

分片和無共享架構

嘗試擴展關係數據庫的另一種方法是爲您的體系結構引入分片。這已經在eBay這樣的大型網站上得到了很好的效果，eBay每天支持數十億條SQL查詢，在其他現代網絡應用程序中也是如此。這裏的想法是，您將數據拆分，以便不是將所有數據託管在單個服務器上，也不是複製羣集中所有服務器上的所有數據，而是水平分割部分數據並分別託管它們。

例如，考慮關係數據庫中的大型客戶表。最不具破壞性的事情（對於編程人員來說，無論如何）是通過添加CPU，增加內存和獲得更快的硬盤來垂直擴展，但如果你繼續成功並增加更多客戶，在某些時候（可能是幾十個）數百萬行），您可能不得不開始考慮如何添加更多機器。當你這樣做時，你只是複製數據，以便所有的機器都有它嗎？或者您是否將該單個客戶表分開，以便每個數據庫只有一些記錄，並保留其訂單？然後，當客戶端執行查詢時，他們只將負載放在具有他們正在查找的記錄的計算機上，而在其他計算機上沒有負載。

似乎很清楚，爲了分片，你需要找到一個好的密鑰來訂購你的記錄。 例如，您可以將您的客戶記錄劃分爲26臺機器，每個字母對應一個字母，每個機器只記錄姓氏以該特定字母開頭的客戶的記錄。 這可能不是一個好的策略，但是可能沒有很多以“Q”或“Z”開頭的姓氏，所以那些機器將閒置而“J”，“M”和“S” 機器穗。 您可以根據數字，例如電話號碼，“成員自”日期或客戶狀態的名稱進行分片。 這完全取決於您的特定數據可能如何分配。

確定分片結構有三種基本策略：

基於特徵的分片或功能分段

這是eBay的傑出建築師Randy Shoup採取的方法，他在2006年幫助將網站的架構變得成熟，每天支持數十億次查詢。使用此策略，數據的分割不是通過在單個表中劃分記錄（如前面討論的客戶示例），而是通過將不相互重疊的特徵拆分爲單獨的數據庫。例如，在eBay上，用戶在一個分片中，而待售商品在另一個分片中。在Flixster，電影評級在一個分片中，評論在另一個分片中。此方法取決於您對域的理解，以便您可以乾淨地細分數據。

基於密鑰的分片

在這種方法中，您可以在數據中找到一個密鑰，該密鑰可以在分片中均勻分佈。因此，不像在早期和不正確的早期示例中那樣簡單地爲每個服務器存儲一個字母，而是在關鍵數據元素上使用單向散列，並根據散列在機器之間分配數據。在此策略中常見的是找到基於時間或數字鍵的哈希值。

查找表

在此方法中，羣集中的一個節點充當“黃頁”目錄，並查找哪個節點具有您嘗試訪問的數據。 這有兩個明顯的缺點。 首先，每次必須通過查找表作爲額外的躍點時，您將獲得性能提升。 第二，查找表不僅成爲瓶頸，而且成爲單點故障。

分片可以根據您的策略最小化爭用，並且不僅可以水平縮放，還可以更精確地縮放，因爲您可以爲需要它的特定分片添加功率。

Sharding可以被稱爲一種特定於數據庫的“無共享”架構。

無共享體系結構是沒有集中（共享）狀態的體系結構，但是分佈式系統中的每個節點都是獨立的，因此共享資源沒有客戶端爭用。 這個術語最初是由加州大學伯克利分校的邁克爾斯通布拉克爾在他1986年的論文“無共享案例”中創造的。谷歌最近普及了無共享架構，谷歌已經編寫了Bigtable數據庫和MapReduce等系統。 不共享狀態的實現，因此能夠接近無限擴展。 Cassandra數據庫是一種無共享架構，因爲它沒有中央控制器，也沒有主/從的概念; 它的所有節點都是一樣的。

MongoDB還提供自動分片功能來管理故障轉移和節點平衡。許多非關係數據庫自動提供這個並且開箱即用非常方便;手動創建和維護自定義數據分片是一個邪惡的主張。一般來說，理解數據架構方面的分片很好，但特別是在Cassandra方面更具體，因爲它可以採用類似於基於密鑰的分片的方法來跨節點分配數據，但這樣做是自動完成的。

網絡規模

總之，關係數據庫非常擅長解決某些數據存儲問題，但由於它們的重點，它們在縮放時也會產生自己的問題。然後，您經常需要找到一種方法來擺脫您的連接，這意味着對數據進行非規範化，這意味着在數據庫和應用程序中維護多個數據副本並嚴重破壞您的設計。此外，您幾乎肯定需要找到解決分佈式事務的方法，這很快就會成爲瓶頸。除了最昂貴的RDBMS之外，不會直接支持這些補償操作。即使您可以編寫如此龐大的支票，您仍然需要仔細選擇分區鍵，以至於您永遠無法完全忽略限制。

也許更重要的是，當我們看到RDBMS的一些侷限性以及架構師用來緩解其縮放問題的一些策略時，一幅畫面慢慢開始出現。這張照片讓一些NoSQL解決方案看起來可能不像我們最初想象的那麼激進和不那麼可怕，更像是一個自然表達和封裝已經用於管理超大型數據庫的一些工作。

由於RDBMS中的一些固有的設計決策，並不總是像其他一些考慮Web結構的更新的可能性那樣容易擴展。然而，我們不僅要考慮Web的結構，還要考慮其顯着的增長，因爲隨着越來越多的數據變得可用，我們需要架構，使我們的組織能夠近乎實時地利用這些數據來支持決策爲我們的客戶製作並提供新的，更強大的功能和功能。

隨着Web的快速發展，需要存儲，處理和查詢的數據種類繁多，而使用此類數據的企業則有很多種。 不僅要考慮熟悉的零售商或供應商的客戶數據，還要考慮數字視頻內容，以及數字電視所需的移動以及電子郵件，消息傳遞，移動電話，RFID，IP語音（VoIP）使用的爆炸式增長，以及 物聯網（IoT）。 由於我們偏離了物理消費者媒體存儲，提供內容的公司和圍繞它們構建的第三方增值業務需要非常可擴展的數據解決方案。 還要考慮作爲典型的業務應用程序開發人員或數據庫管理員，我們可能會習慣將關係數據庫視爲我們Universe的中心。 然後，您可能會驚訝地發現，在公司內部，大約80％的數據是非結構化的。

NoSQL的崛起

最近對非關係數據庫的興趣反映了軟件開發社區對Web規模數據解決方案的需求日益增長。 “NoSQL”一詞在2009年左右開始流行，作爲描述這些數據庫的簡寫方式。 這個術語在歷史上一直是爭論的主題，但已經出現了一個共識，即該術語指的是支持“不僅僅是SQL”語義的非關係數據庫。

各種專家試圖在幾大類別中組織這些數據庫; 我們將研究一些最常見的：

• 鍵值存儲

  在鍵值存儲中，數據項是具有一組屬性的鍵。 與密鑰相關的所有數據都與密鑰一起存儲; 數據經常重複。 流行的鍵值商店包括亞馬遜的Dynamo DB，Riak和Voldemort。 此外，許多流行的緩存技術充當鍵值存儲，包括Oracle Coherence，Redis和MemcacheD。

• 列存儲

  列存儲也經常被稱爲寬列存儲。 谷歌的Bigtable是實施的靈感來源，包括Cassandra，Hypertable和Apache Hadoop的HBase。

• 文檔存儲

  文檔數據庫中的基本存儲單元是完整文檔，通常以JSON，XML或YAML等格式存儲。 流行的文檔存儲包括MongoDB和CouchDB。

• 圖數據庫

  圖形數據庫將數據表示爲圖形 - 連接節點的節點和邊緣的網絡。 節點和邊都可以具有屬性。 因爲它們對關係給予了高度重視，所以圖形數據庫（如FlockDB，Neo4J和Polyglot）已經證明可以用於構建社交網絡和語義Web應用程序。

• 對象數據庫

  對象數據庫不是根據關係，列和行來存儲數據，而是根據對象本身，使得從面向對象的應用程序中使用數據庫變得簡單。 db4o和InterSystemsCaché等對象數據庫允許您避免使用存儲過程和對象關係映射（ORM）工具等技術。

• XML數據庫

  XML數據庫是一種特殊形式的文檔數據庫，專門用於處理XML。 所謂的“XML原生”數據庫包括Software AG和eXist的Tamino。

有關NoSQL數據庫的完整列表，請訪問網站http://nosql-database.org。

這些數據庫的目標和功能有很多種，但它們往往具有一系列共同特徵。其中最明顯的是NoSQL這個名稱 - 這些數據庫支持數據模型，數據定義語言（DDL）以及流行關係數據庫中可用的標準SQL之外的接口。此外，這些數據庫通常是沒有集中控制的分佈式系統。它們強調水平可伸縮性和高可用性，在某些情況下以強一致性和ACID語義爲代價。它們傾向於支持快速開發和部署。他們採用靈活的方法來定義模式，在某些情況下不需要預先定義任何模式。它們爲大數據和分析用例提供支持。

在過去幾年中，NoSQL領域出現了大量的開源和商業產品。它們的採用和質量差異很大，但領導者已經出現在剛剛討論的類別中，並且許多已經成爲具有大型安裝基礎和商業支持的成熟技術。我們很高興地報告Cassandra是這些技術之一，我們將在下一章深入探討。

總結

在過去的四十年中，關係模型爲軟件行業提供了良好的服務，但現代應用程序所需的可用性和可擴展性水平已將關係數據庫技術擴展到了突破點。

本書的目的不是通過巧妙的論證來說服您採用Apache Cassandra等非關係型數據庫。 我們只是想介紹一下Cassandra可以做什麼以及它如何做到這一點，這樣你就可以做出明智的決定，並且如果你發現它適用，就可以開始以實際的方式使用它。

那麼，也許最終的問題不是“關係數據庫有什麼問題？”而是“如果不是問題，我會對數據做什麼樣的事情呢？”在一個現在正在網絡規模工作並期待 未來，Apache Cassandra可能是答案的一部分。