關于NoSQL數(shù)據(jù)庫你應該知道的10件事
原創(chuàng)關系數(shù)據(jù)庫模型已經(jīng)流行了幾十年了，但是一種新類型的數(shù)據(jù)庫——被稱為NoSQL，正在引起企業(yè)的注意。下面是關于它的優(yōu)勢和劣勢的一個概述。二十多年以來，對數(shù)據(jù)庫管理來說，關系數(shù)據(jù)庫（RDBMS）模型一直是一個占統(tǒng)治地位的數(shù)據(jù)庫模型。但是，今天，非關系數(shù)據(jù)庫，“云”數(shù)據(jù)庫，或“NoSQL”數(shù)據(jù)庫作為關系數(shù)據(jù)庫以外的一些選擇，正在引起大家的廣泛關注。在這篇文章里，我們將主要關注那些非關系的NoSQL數(shù)據(jù)庫的十大利弊：包括五大優(yōu)勢和五大挑戰(zhàn)。
NoSQL的五大優(yōu)勢
1，靈活的可擴展性
多年以來，數(shù)據(jù)庫管理員們都是通過“縱向擴展”的方式（當數(shù)據(jù)庫的負載增加的時候，購買更大型的服務器來承載增加的負載）來進行擴展的，而不是通過“橫向擴展”的方式（當數(shù)據(jù)庫負載增加的時候，在多臺主機上分配增加的負載）來進行擴展。但是，隨著交易率和可用性需求的增加，數(shù)據(jù)庫也正在遷移到云端或虛擬化環(huán)境中，“橫向擴展”在commodity hardware方面的經(jīng)濟優(yōu)勢變得更加明顯了，對各大企業(yè)來說，這種“誘惑”是無法抗拒的。
在commodity clusters上，要對RDBMS做“橫向擴展”，并不是很容易，但是各種新類型的NoSQL數(shù)據(jù)庫主要是為了進行透明的擴展，來利用新節(jié)點而設計的，而且，它們通常都是為了低成本的commodity hardware而設計的。
2，大數(shù)據(jù)
在過去的十年里，正如交易率發(fā)生了翻天覆地的增長一樣，需要存儲的數(shù)據(jù)量也發(fā)生了急劇地膨脹。O’Reilly把這種現(xiàn)象稱為：“數(shù)據(jù)的工業(yè)革命”。為了滿足數(shù)據(jù)量增長的需要，RDBMS的容量也在日益增加，但是，對一些企業(yè)來說，隨著交易率的增加，單一數(shù)據(jù)庫需要管理的數(shù)據(jù)約束的數(shù)量也變得越來越讓人無法忍受了?，F(xiàn)在，大量的“大數(shù)據(jù)”可以通過NoSQL系統(tǒng)（例如：Hadoop）來處理，它們能夠處理的數(shù)據(jù)量遠遠超出了最大型的RDBMS所能處理的極限。
3，“永別了”！DBA們！（再見？）
在過去的幾年里，雖然一些RDBMS供應商們聲稱在可管理性方面做出了很多的改進，但是高端的RDBMS系統(tǒng)維護起來仍然十分昂貴，而且還需要訓練有素的DBA們的協(xié)助。DBA們需要親自參與高端的RDBMS系統(tǒng)的設計，安裝和調(diào)優(yōu)。
NoSQL數(shù)據(jù)庫從一開始就是為了降低管理方面的要求而設計的：從理論上來說，自動修復，數(shù)據(jù)分配和簡單的數(shù)據(jù)模型的確可以讓管理和調(diào)優(yōu)方面的要求降低很多。但是，DBA的死期將至的謠言未免有些過于夸張了?？偸切枰腥藢﹃P鍵性的數(shù)據(jù)庫的性能和可用性負責的。
4，經(jīng)濟
NoSQL數(shù)據(jù)庫通常使用廉價的commodity servers集群來管理膨脹的數(shù)據(jù)和事務數(shù)量，而RDBMS通常需要依靠昂貴的專有服務器和存儲系統(tǒng)來做到這一點。使用NoSQL，每GB的成本或每秒處理的事務的成本都比使用RDBMS的成本少很多倍，這可以讓你花費更低的成本存儲和處理更多的數(shù)據(jù)。
5，靈活的數(shù)據(jù)模型
對于大型的生產(chǎn)性的RDBMS來說，變更管理是一件很令人頭痛的事情。即使只對一個RDBMS的數(shù)據(jù)模型做了很小的改動，也必須要十分小心地管理，也許還需要停機或降低服務水平。NoSQL數(shù)據(jù)庫在數(shù)據(jù)模型約束方面是更加寬松的，甚至可以說并不存在數(shù)據(jù)模型約束。NoSQL的主鍵值數(shù)據(jù)庫和文檔數(shù)據(jù)庫可以讓應用程序在一個數(shù)據(jù)元素里存儲任何結(jié)構的數(shù)據(jù)。即使是規(guī)定更加嚴格的基于“大表”的NoSQL數(shù)據(jù)庫（例如：Cassandra, HBase）通常也允許創(chuàng)建新列，這并不會造成什么麻煩。
應用程序變更和數(shù)據(jù)庫模式的變更并不需要作為一個復雜的變更單元來管理。從理論上來說，這可以讓應用程序迭代的更快，但是，很明顯，如果應用程序無法維護數(shù)據(jù)的完整性，那么這會帶來一些不良的副作用。
NoSQL的五大挑戰(zhàn)
NoSQL的種種承諾引發(fā)了一場熱潮，但是在它們得到主流的企業(yè)的青睞以前，它們還有許多困難需要克服。下面是NoSQL需要面對的一些挑戰(zhàn)。
1，成熟度
RDBMS系統(tǒng)已經(jīng)發(fā)展很長時間了。NoSQL的擁護者們認為，RDBMS系統(tǒng)那超長的發(fā)展的年限恰恰表示它們已經(jīng)過時了，但是對于大多數(shù)的CIO們來說，RDBMS的成熟度更加令它們放心。大多數(shù)情況下，RDBMS系統(tǒng)更加穩(wěn)定，而且功能也更加豐富。相比之下，大多數(shù)的NoSQL數(shù)據(jù)庫都是pre-production版本，許多關鍵性的功能還有待實現(xiàn)。
對于大多數(shù)開發(fā)者來說，處于技術的最前沿的確是很令人興奮的，但是企業(yè)應該懷著極端謹慎的態(tài)度來處理此事。
2，支持
企業(yè)都希望能得到這樣的保證：如果一個關鍵性的系統(tǒng)出現(xiàn)問題了，他們可以獲得及時有效的支持。所有的RDBMS供應商都在竭盡全力地提供高水平的企業(yè)支持。
相反，大多數(shù)的NoSQL系統(tǒng)都是開源項目，雖然對于每個NoSQL數(shù)據(jù)庫來說，通常也會有一個或多個公司對它們提供支持，但是那些公司通常是小型的創(chuàng)業(yè)公司，在支持的范圍，支持的資源，或可信度方面，它們和Oracle, Microsoft或IBM是無法相提并論的。
3，分析和商業(yè)智能化
NoSQL數(shù)據(jù)庫現(xiàn)在已經(jīng)可以滿足現(xiàn)代的Web2.0應用程序的高度的可擴展性的要求了。這直接導致的結(jié)果是，它們的大多數(shù)功能都是面向這些應用程序而設計的。但是，在一個應用程序中，具有商業(yè)價值的數(shù)據(jù)早就已經(jīng)超出了一個標準的Web應用程序需要的“插入-讀取-更新-刪除”的范疇了。在公司的數(shù)據(jù)庫中進行商業(yè)信息的挖掘可以提高企業(yè)的效率和競爭力，而且對于所有的中到大型的公司來說，商業(yè)智能化（BI）一直是一個至關重要的IT問題。
NoSQL數(shù)據(jù)庫幾乎沒有提供什么專用的查詢和分析工具。即使是一個簡單的查詢，也要求操作者具有很高超的編程技術，而且，常用的BI工具是無法連接到NoSQL的。
像HIVE或PIG那樣的新出現(xiàn)的一些解決方案在這方面可以提供一些幫助，它們可以讓訪問Hadoop集群中的數(shù)據(jù)變得更加容易，最后也許還會支持其他的NoSQL數(shù)據(jù)庫。Quest軟件已經(jīng)開發(fā)了一個產(chǎn)品——Toad for Cloud Databases——它給各種NoSQL數(shù)據(jù)庫提供了專用的查詢功能。
4，管理
NoSQL的設計目標是提供一個“零管理”的解決方案，但是目前來說，還遠遠沒有達到這個目標。安裝NoSQL還是需要很多技巧的，同時，維護它也需要付出很多的努力。
5，專業(yè)知識
毫不夸張地說，全世界有數(shù)百萬的開發(fā)者，他們都對RDBMS的概念和編程方法很熟悉，在每個業(yè)務部門中都有這樣的開發(fā)者。相反，幾乎每一個NoSQL開發(fā)者都正處于學習狀態(tài)中。雖然這種情況會隨著時間的推移而改變，但是現(xiàn)在，找到一些有經(jīng)驗的RDBMS程序員或管理員要比找到一個NoSQL專家容易的多。
結(jié)論
NoSQL數(shù)據(jù)庫正在逐漸地成為數(shù)據(jù)庫領域中不可或缺的一部分，如果使用方法得當?shù)脑挘塬@得很多的好處。但是，企業(yè)應該謹慎行事，要充分地認識到這些數(shù)據(jù)庫的一些限制和問題。
【編輯推薦】
