譯：為什么使用 NoSQL 數據庫

原文鏈接：Why NoSQL Database?

向數據時代的轉變正在推動 NoSQL

隨着各行各業朝着數據時代轉變，商業世界正在經歷巨大的變革。這是由互聯網以及其他二十一世紀新技術——雲計算、移動應用、社交媒體和大數據驅動的經濟模式。每一項數據時代業務的核心都是它的 Web、移動和物聯網應用。如今，這是企業用於與用戶進行互動的首要方式，同時也是企業如何擴大經營的方式。這些應用的使用體驗很大程度上決定了用戶的滿意度和忠誠度。

這些應用與傳統企業應用——如 ERP、HR 和財務會計軟件等，有什么不同呢？如今的 Web、移動、物聯網應用大都具備如下的特性：

• 支持大量並發用戶（數萬，甚至數百萬量級）
• 為全球范圍內的用戶提供高質量的交互體驗
• 高可靠性
• 支持處理半結構化數據和非結構化數據
• 快速適應不斷變化的需求

構建和運營這些 Web、移動、物聯網應用，實際上已經創建了一套新的技術要求。新的企業技術架構需要比以往更加敏捷，並要求有一種實時的數據管理方法，以適應這個在規模、速度和數據多樣性上都屬於前所未有的水平。關系型數據庫無法滿足這些新的要求，因此企業正在轉向采用 NoSQL 數據庫技術。

NoSQL 是十年前由一些領先的互聯網公司（包括谷歌，亞馬遜，Facebook 和領英）開創的，用於克服現代Web應用程序在使用 Oracle 和 MySQL 等關系型數據庫時受到的局限。當這些早期的先驅證明了 NoSQL 的優勢和高效時，企業開始逐漸采用 NoSQL：

• 基層實驗：第一階段（2010 年左右開始），企業開發人員開始在邊緣項目和非關鍵任務應用上嘗試使用NoSQL。他們的核心要求是，對於一些概念驗證和小型應用的敏捷開發可以得到靈活的支持。

• 關鍵任務部署：在第二階段（2013 年左右開始），企業開始在關鍵任務應用上采用 NoSQL。此階段的核心要求是，開發和遷移目標服務時的性能、可擴展性和可用性。

• 廣泛地重建：在第三階段（2015 年底開始），開發人員和企業雙方都需要一個通用的數據庫，以便被企業廣泛地采用，來重新搭建數據時代中所有關鍵任務應用和服務。在這個階段，對 NoSQL 數據庫的要求包括靈活性、性能、可擴展性、可用性，以及綜合的查詢語言和強大的索引功能。

NoSQL 關注五大趨勢衍生出的新技術挑戰

在更細粒度的水平，企業正在采用 NoSQL，以應對五大趨勢帶來的新一輪技術挑戰和要求：

1. 更多的用戶使用線上方式

越來越多的客戶開始在線上完成更多的事情，無論是在家里、工作中，還是在旅途中。他們在線上完成訂單支付、預定酒店、日常用品采購，而不是在當地的銀行、旅行社或雜貨店。

向線上轉移帶來的技術挑戰包括：

• 擴大規模，以支持數以千/萬計的用戶
• 以一致的高性能表現滿足用戶體驗要求
• 維持 7X24 小時的可用性

2. 互聯網正在連接一切

不只人們的生活工作方式逐漸遷移到線上。今天，越來越多的“物體”開始連接到互聯網——“物聯網”，而且它們都會使用和產生數據。它們可以是消費品，如電器、手表、汽車等等。它們可以是工業產品，如飛機引擎、風力發電機、石油鑽機和管道等。它們可能很大，也可能很小，可能在本地，也可能在遠端。

物聯網帶來的技術挑戰包括：

• 支持眾多不同的（常常是新生的）物體，意味着需要不同的數據結構
• 支持可能會導致數據結構改變的軟硬件更新
• 支持連續的實時數據流

3. 大數據變得越來越龐大

現在，用戶通過線上方式處理越來越多的事務，機器產生的數據也日益增長。因此，許多企業正在利用大數據來提高運營、應用程序、服務等方面的效率和有效性。

大數據帶來的技術挑戰包括：

• 存儲用戶生成的半結構化和非結構化數據
• 將來自不同來源不同類型的數據存儲在一起
• 存儲由數千/萬個用戶和物體產生的數據

4. 應用程序正在向雲端遷移

按需擴展和規模經營對靈活性也有要求，因為企業出於成本、靈活性、性能優化的考慮，逐漸轉向分布式軟件和商用硬件。這導致了對雲基礎設施的采用，無論是公有的、私有的、混合的、虛擬的、容器的還是裸機。

向雲端遷移帶來的技術挑戰包括：

• 按需擴展，以支持更多客戶和存儲更多數據
• 在全球范圍內運營應用程序，向全球用戶提供服務
• 最大限度地減少基礎設施成本，實現更快的市場推廣

5. 世界已進入移動化浪潮

越來越多的客戶正在通過移動平台進行互動——無論是智能手機、平板電腦、手表還是其他設備。企業不僅將應用程序和服務拓展到移動平台，而且他們正在評估一種“移動為主”，現在應該稱之為“離線為主”的解決方案。

向移動平台遷移帶來的技術挑戰包括：

• 創建不需要網絡連接的“離線為主”的應用程序
• 同步移動數據與雲中的遠程數據庫
• 支持具有單個后端的多個移動平台

為什么關系型數據庫有短板

幾十年來，企業一直依賴於 Oracle、SQL Server、DB2、MySQL 等關系型數據庫。那么為什么關系型技術不能滿足當今 Web、移動和物聯網應用的要求呢？

關系型數據庫誕生於大型機和商業應用的時代，早在互聯網、雲計算、大數據、移動化和數據時代之前。事實上，第一款商業實現由 Oracle 在 1979 年發布。這些數據庫被設計為在單個服務器上運行，服務器越大越好。增加這些數據庫容量的唯一方法是對服務器進行升級，也就是要對處理器、內存和硬盤進行升級。

NoSQL 數據庫的出現，可以看做是當今互聯網呈指數級增長和 Web 應用快速興起的必然結果。谷歌在 2006 年發布了關於 Bigtable 的研究，亞馬遜在 2007 年發布了關於 Dynamo 的研究。這些數據庫被設計出來，以滿足新一代的企業要求——敏捷開發需求以及高擴展性。

敏捷開發

為了在高速發展的數據時代保持競爭力，企業需要堅持創新，而現在他們必須比以前做的更快。因為這些創新多數集中在 Web、移動和物聯網應用的開發過程，開發人員必須比以往任何時候都要更加快速地交付應用程序和功能服務。速度和敏捷性至關重要，因為這些應用程序的演進速度遠遠超過傳統應用程序，如 ERP。關系型數據庫是敏捷性的主要障礙，它們對敏捷開發的支持並不友好，原因在於其固定不變的數據模型。

提高開發速度的靈活性

敏捷開發的一個核心原則是適應不斷變化的應用需求：當需求變化，數據模型也要隨之改變。而對於關系型數據庫來說，這是一個問題。因為關系型數據庫的數據模型由靜態架構所定義，是固定不變的。所以，為了改變數據模型，開發人員不得不改變架構。這樣就減慢甚至停滯了開發進程，不僅因為這是需要人工操作的、耗時的過程，更因為這會影響其他應用程序和功能服務。

圖1：RDBMS——固定的架構中無法按需添加新的屬性

相比之下，NoSQL 文檔型數據庫完全支持敏捷開發，因為它是無架構的並且不對數據模型進行靜態定義。恰恰相反，它的數據模型遵循於應用程序和功能服務，這樣就相當於遵循了開發人員的想法。應用 NoSQL 時，數據模型由應用模型定義，應用程序和功能服務的模型數據被當作對象。

應用文檔型數據庫時，應用程序和功能服務只需要簡單的讀寫文檔即可——通過將一個對象序列化為一個 JSON 文檔的方式寫入數據，或者通過相反的過程讀取數據。因為 JSON 文檔是自描述的，不需要外部架構。所以，通過這種修改對象來添加或移除屬性的方式，開發人員可以在不改變數據庫的情況下更改數據模型。顯然，這對於提高開發人員的生產力和敏捷性，起到了巨大的幫助作用。

圖2：JSON——數據模型隨着添加新屬性而變化

降低開發難度的簡易性

文檔數據庫的另一個利於企業快速創新的優勢是，具備應用程序直接讀取文檔的能力，而在應用程序模型和數據之間不需要對象關系映射層。

應用程序和功能服務構建數據模型時，是將數據作為對象，多值數據作為集合，相關數據作為嵌套對象或嵌套集合。然而，在關系型數據庫中，數據通過包含行和列的表進行組織。相關數據在不同的表中，多值數據在同一個表中。關系型數據庫的問題在於，數據讀寫過程中，需要分解或分割對象，然后再重新組合它們。對此，變通方案是對象關系映射框架，這樣做的理想情況無非是不夠高效，而最壞的情況是會導致出現錯誤。

例如，假設有一個管理簡歷的應用程序。它需要與簡歷進行交互，簡歷作為用戶對象，包含一個記錄技能數據的數組和一個記錄工作經驗數據的集合。將一份簡歷寫入關系型數據庫，應用程序需要將用戶對象分割成數據片段才能完成。

存儲簡歷時，要求應用程序將六行數據插入到三個表中：

圖3：RDBMS——應用程序將對象分割成多行數據存儲在多個表中

讀取簡歷時，要求應用程序從三個表中讀取六行數據：

圖4：RDBMS——查詢結果包含冗余的數據，應用程序需要對其進行過濾。

作為對比，文檔型的 NoSQL 數據庫讀取和寫入 JSON 格式的數據，這已經成了 Web、移動、物聯網應用使用和產生數據過程中事實上的標准。它消除了對象關系映射的瓶頸，並且簡化了應用程序開發過程，因為讀取寫入對象的時候，不需要再對其進行分割，一個對象可以作為一個文檔來進行讀取或者寫入。

圖5：JSON——應用程序可以將含有嵌套數據的對象存儲為一個文檔

NoSQL對查詢和SQL的支持性

NoSQL 代表“Not Only SQL”，這一點非常重要。SQL 是一種成熟的查詢技術，大部分的開發人員都正在使用這種技術。實際上，任何一種編程語言和框架，以及幾乎所有的BI和報表工具都支持 SQL。因此，開發人員在使用 NoSQL 數據庫進行開發時，能夠最大限度的利用他們已掌握的SQL技能和工具，是非常重要的。

DDBS 引入了 N1QL，這是一種強大的查詢語言，它在 SQL 的基礎上擴展了 JSON 的特性，使開發人員能夠充分利用 SQL 的強大能力和 JSON 的靈活性。它不僅支持標准的 SELECT/FROM/WHERE 語句，還支持聚合（GROUY BY）、排序（SORT BY）、連接（LEFT OUTER/INNER），以及查詢嵌套的數組和集合。

SQL

SELECT		breweries.name AS brewery,
			count(*) AS cnt
FROM		beers
INNER JOIN	breweries
ON			beer.brewery_id = breweries.id
WHERE		beers.type = "beer" AND
			breweries.type = "brewery" AND
			beers.style = "American-Style Imperial Stout"
GROUP BY	breweries.name
HAVING		count(*) > 2
OEDER BY	cnt DESC;

N1QL

SELECT		breweries.name AS brewery,
			count(*) AS cnt
FROM		`beer-sample` beers
INNER JOIN	`beer-sample` breweries
ON			beer.brewery_id
WHERE		beers.type = "beer" AND
			breweries.type = "brewery" AND
			beers.style = "American-Style Imperial Stout"
GROUP BY	breweries.name
HAVING		count(*) > 2
OEDER BY	cnt DESC;

任意規模下皆可運行

Web、移動和物聯網應用所使用的數據庫，必須具備能夠在任意規模下運行的能力。雖然擴展關系型數據庫（如 Oracle，可使用 Oracle RAC 擴展）是可行的，但這樣的擴展，通常既復雜又花費高昂，並且不完全可靠。例如，使用 RAC 技術擴展 Oracle 需要很多的組件，並且出現單點故障時會危及可用性。相比之下，NoSQL 分布式數據庫——設計有橫向擴展架構且不會出現因單點故障造成的服務失效，具備顯著的優勢。

規模上具有彈性

應用程序和功能服務必須支持持續增長的用戶和數據。同時，企業要擴展規模以維持性能表現，這些必須快速有效的完成。

數據庫必須支持讀寫操作次數和存儲容量的提升。而對於關系型數據庫來說，這是問題所在，即規模擴展存在上限。例如，向單個物理服務器增加處理器、內存和儲存空間，是有限制的。因此，在規模上按需、高效的擴展，是一個很大挑戰。這會導致越來越大開銷，因為企業必須采購更大型服務器以適應更多用戶和數據。而且，執行硬件升級時，如果需要將數據庫下線，會導致應用程序和功能服務的不可用。

這樣造成的另外一個問題是，擴展的規模會低於或高於實際需求值。如果服務器擴展的過大，富余的能力就變成了不必要的浪費。如果擴展的不夠大，下降的性能表現將會導致用戶體驗變差。

圖6：RDBMS——服務器低於或高於實際需求值，導致低下的性能表現或不必要的浪費。

分布式 NoSQL 數據庫利用商用硬件擴展規模，比如通過增加服務器來新增資源。這種可擴展能力能夠使企業高效地進行擴展，在滿足當前負載的情況下又不會過量部署硬件。

為了能夠方便的進行擴展，分布式 NoSQL 數據庫的安裝和配置都非常簡易。除了讀寫和存儲的方式被設計成分布式的之外，所有的操作都可在任意規模下執行，包括管理和監視各種大大小小的集群。

圖7：NoSQL——按需增加商用服務器，因此硬件資源與應用負載相匹配。

始終如一的可用性，支持全球化部署

隨着通過 Web、移動應用接入的線上用戶互動日益增加，可用性成為了主要值得關注的問題。這些關鍵任務型應用必須 7x24 小時保持在可用狀態，不允許有異常情況發生。對於部署在單個物理服務器或基於共享存儲的集群上的關系型數據庫來說，交付 7x24 小時可用性是一個挑戰。如果部署在單個服務器上並且服務器出現故障，或者部署在基於共享存儲的集群上並且共享存儲出現故障，關系型數據庫就無法使用。

圖8：RMDBS——服務器或存儲設備故障導致整個數據庫不可用

與關系型數據庫相比，分布式 NoSQL 數據庫不使用共享資源，將數據分組后分布地存儲在多個數據庫實例中。並且，數據可以從一個實例復制到其他實例中，從而提高可用性。Oracle 這樣的關系型數據庫要求使用另外的軟件來進行復制，例如 Oracle Active Data Guard。NoSQL 數據庫不需要，它的復制功能是內建的並且可以自動執行。此外，自動故障切換能夠保障在一個節點失效的情況下，數據庫可以通過向其他節點發送請求來實現不間斷地執行讀寫操作。

圖9：NoSQL——如果一個實例失效，應用程序可以向其他的節點發送請求。

由於用戶互動逐漸遷移到線上，在不同的國家和地區保障可用性的需求變得至關重要。為多個數據中心建立一個數據庫能夠提高可用性，並且有助於災難恢復。同時，還有益於提高性能表現，因為所有的讀寫操作都可以在最近的數據中心執行，所以減少了延時。

確保全球可用性對關系型數據庫來說顯得有些困難，因為需要額外使用其他軟件，這增加了復雜性。而且，多個數據中心間的復制功能只能在故障切換的時候使用，因為在同一時間只有一個數據中心處於活動狀態。以 Oracle 為例，它需要 Oracle GoldenGate 來進行容災備份。在數據中心之間執行復制操作時，基於關系型數據庫的應用程序會表現出性能下降或者數據中心彼此脫離同步狀態的問題。

分布式 NoSQL 數據庫具有數據中心之間的復制功能，這項功能是內建的，不需要使用額外的軟件。此外，有些NoSQL數據庫同時包含了單向和雙向的復制功能，能夠對數據中心實現充分的活動節點對活動節點的數據庫部署。這使得數據庫可以在不同國家和地區部署，並且提供本地數據給本地的應用程序和用戶。這不僅提高了性能，並且通過硬件路由可以實現即刻故障切換，應用程序不必再等待數據庫來發現故障以及后續的故障切換。

圖10：RDBMS——要求使用另外的軟件將數據復制到其他的數據中心

圖11：NoSQL——數據中心間的復制功能是內建的並且可以是雙向的

NoSQL更符合數據時代的要求

在雲計算、移動化、社交媒體以及大數據這些技術的推動下，企業正在向數據時代遷移。開發人員和運營團隊必須不斷加快建立和維護 Web、移動和物聯網應用的速度。而在支撐如今的 Web、移動和物聯網應用方面，NoSQL 無疑是最具有優勢的數據庫技術。

全球 2000 強企業中已有幾百家采用了 NoSQL 數據庫，除此之外，還有上萬家小型企業和創業公司也采用了 NoSQL。對於許多企業來說，剛開始只是將 NoSQL 用於緩存、概念驗證或者小型應用程序，然后擴展到關鍵任務應用程序，到現在將 NoSQL 作為所有應用開發的基礎。

在 NoSQL 的幫助下，企業在開發過程中能夠更好地兼顧敏捷性和靈活性，最終提供所需的性能和可用性，以滿足數據時代業務的要求。