雖然關系型數(shù)據(jù)庫系統(tǒng)RDBMS在安裝和使用上仍然占有主要地位，但毋庸置疑，非關系型數(shù)據(jù)庫NoSQL技術已經(jīng)成為今天發(fā)展最快的數(shù)據(jù)庫技術。
NoSQL是對數(shù)據(jù)庫系統(tǒng)的總稱，在某種程度上，它的性能和用途可能完全不同。NoSQL一詞最早產(chǎn)生于上世紀九十年代，意思是No SQL(沒有SQL語言)，后來隨著時間和技術的發(fā)展，SQL界面仍然作為處理數(shù)據(jù)的方式存在，所以NoSQL又有了新的詮釋，即Not Only SQL(不只是SQL語言)。今天，NoSQL數(shù)據(jù)庫憑借著其非關系型、分布式、開源和橫向擴展等優(yōu)勢，被認為是下一代數(shù)據(jù)庫產(chǎn)品。
四種主要的NoSQL數(shù)據(jù)庫和它們主要的應用場景
鍵值數(shù)據(jù)庫：當數(shù)據(jù)以鍵的形式訪問時，比如通過國際標準書號ISBN找一本書，鍵值數(shù)據(jù)庫是最理想的。在這里，ISBN是鍵，書籍的其他信息就是值。必須知道鍵才能查詢，不過值是一堆無意義的數(shù)據(jù)，讀取之后必須經(jīng)過翻譯。
文檔存儲數(shù)據(jù)庫：該數(shù)據(jù)庫以文檔的形式管理和存儲數(shù)據(jù)。有點類似于鍵值數(shù)據(jù)庫，但文檔數(shù)據(jù)庫中的數(shù)據(jù)有結構。與鍵值數(shù)據(jù)庫中值是一堆無意義的數(shù)據(jù)不同，文檔數(shù)據(jù)庫中數(shù)據(jù)以文檔的結構被描述，典型的是JavaScript Object Notation (JSON)或XML.文檔存儲數(shù)據(jù)庫中的數(shù)據(jù)可以通過定義的任何模式進行查詢，但鍵值數(shù)據(jù)庫只能通過它的鍵進行查詢。
列式數(shù)據(jù)庫：也被稱為列式存儲或?qū)捔写鎯?，一改之前行式存儲的方式，對?shù)據(jù)進行列式存儲。在傳統(tǒng)關系型數(shù)據(jù)庫中，數(shù)據(jù)經(jīng)常以行來訪問。以列式管理記錄的NoSQL數(shù)據(jù)庫可以管理大規(guī)模的動態(tài)列。因為沒有固定的模式，所以列名和鍵可以變換。列式數(shù)據(jù)庫適用于不經(jīng)常寫的情況，要滿足ACID(原子性、一致性、隔離性和持久性)的要求并不難，而且模式是變化的。
圖型數(shù)據(jù)庫：圖型數(shù)據(jù)庫關注值與值之間的關系，用圖型的數(shù)學概念存儲數(shù)據(jù)。圖型數(shù)據(jù)庫用帶有點、邊緣和屬性的圖的結構表示和存儲數(shù)據(jù)。在圖型數(shù)據(jù)庫中，每一個元素都包含一個直接的指向它毗鄰元素的點，所以也就不需要索引查找。
NoSQL數(shù)據(jù)庫在網(wǎng)頁擴展、大數(shù)據(jù)和分析部署等方面越來越流行。每一個種類的NoSQL數(shù)據(jù)庫都有適用的不同類型的應用程序和用例，這就涉及到一個NoSQL社區(qū)常用的一個話題，即多樣持久性，或者說根據(jù)數(shù)據(jù)庫處理應用程序需求的不同，使用不同的數(shù)據(jù)庫系統(tǒng)，用于不同的應用程序和用例。
因此，使用NoSQL最重要的是使用正確的數(shù)據(jù)庫，滿足具體的需求，哪怕是要引入一種新的數(shù)據(jù)庫系統(tǒng)。
NoSQL的優(yōu)勢和劣勢
那么，為什么考慮用NoSQL數(shù)據(jù)庫替代傳統(tǒng)數(shù)據(jù)庫呢?也許，前者大的有點在于它的去中心化、可擴展、容錯能力等屬性。很多公司應用NoSQL數(shù)據(jù)庫技術是考慮了它的可擴展能力。
用NoSQL數(shù)據(jù)庫，你可以為每一個特殊的用例定制化你的數(shù)據(jù)管理解決方案。關系型數(shù)據(jù)庫可以通過不同的用例廣泛地應用于實踐。通過考慮多樣持久性，組織可以選擇最能適應特殊應用場景的數(shù)據(jù)庫技術。
另外，大多數(shù)NoSQL產(chǎn)品都是輕量級的，因此花費比較少。自從NoSQL產(chǎn)品被設計用來滿足特殊的用例和解決特殊的問題，它的功能也就比大多數(shù)關系型數(shù)據(jù)庫少，因為后者要應用于更廣泛的領域。因此，NoSQL數(shù)據(jù)庫需要的代碼更少，這也是和復雜的關系型數(shù)據(jù)庫相比具備的一項優(yōu)勢。
當然，NoSQL也有它的缺點。ACID協(xié)議是關系型數(shù)據(jù)庫的標準，但很多NoSQL數(shù)據(jù)庫做不到。如果ACID支持很關鍵，你必須要確定你選的NoSQL數(shù)據(jù)庫是否提供ACID。
NoSQL數(shù)據(jù)庫的另一個缺點是不支持SQL語言。經(jīng)過40多年的發(fā)展，SQL已經(jīng)成為訪問數(shù)據(jù)的通用語言。一套數(shù)據(jù)庫系統(tǒng)不支持SQL語言就意味著要求開發(fā)者學習不同的訪問數(shù)據(jù)的語言。不過，像有的NoSQL支持ACID一樣，有的NoSQL數(shù)據(jù)庫也支持SQL語言，但不像傳統(tǒng)關系型數(shù)據(jù)庫那樣全面。總之，想要不做重大更改就在NoSQL數(shù)據(jù)庫中運行SQL查詢是不可能的。
今天的NoSQL市場依然很混亂。嚴格來講，有上百種不同的NoSQL數(shù)據(jù)庫可供選擇。而且沒有像關系型數(shù)據(jù)庫一樣正規(guī)的數(shù)據(jù)模型，因此NoSQL數(shù)據(jù)庫之間也是各不相同的，即便是同一種類也有所不同。這種混亂給NoSQL的廣泛應用帶來了阻礙，如果沒有深度的投資和研發(fā)，它很難成功。
NoSQL 數(shù)據(jù)庫用例
讓我們分別看一下不同NoSQL數(shù)據(jù)庫的用例：
鍵值。鍵值數(shù)據(jù)庫可以滿足游戲、零售和移動等應用程序的高可用性、低延遲需求。它的模式比較靈活，在會議管理、服務廣告內(nèi)容和管理用戶或產(chǎn)品文件方面有卓越的表現(xiàn)?？傊敂?shù)據(jù)不是按一定模式，而是包含很多種代碼的時候，可以使用鍵值數(shù)據(jù)庫。
但如果要管理不同數(shù)據(jù)集之間復雜的關系，或使用非限定的鍵進行查詢，鍵值數(shù)據(jù)庫的表現(xiàn)就欠佳了。
文檔數(shù)據(jù)庫。這種數(shù)據(jù)庫特別適合用于為每一個文檔存儲不同種類的數(shù)據(jù)，可以實現(xiàn)跨數(shù)據(jù)的彈性的搜索。如果你的模式不是網(wǎng)格式的，你又需要指定鍵之外的東西進行查詢，那么文檔存儲絕對是一個不錯的選擇。文檔數(shù)據(jù)庫適合應用于事件日志，線上購物，內(nèi)容管理和深度分析流程。對于要求快速原型的項目來說，文檔數(shù)據(jù)庫的模式靈活性也是一大亮點。
不過，文檔數(shù)據(jù)庫不適合復雜的事務處理。對于要求數(shù)據(jù)壓縮的應用程序來說，文檔數(shù)據(jù)庫并不是一個很好的選擇，因為彈性模式意味著跨文檔的數(shù)據(jù)不一致，也不可能被有效壓縮。
列式存儲。這種數(shù)據(jù)庫以列的方式存儲數(shù)據(jù)。與一個鍵(或識別符)相關的有很多列。和其他NoSQL數(shù)據(jù)庫一樣，它的模式很靈活，一個列式家族可以由不同的列組成。另外，列式存儲中的數(shù)據(jù)可以通過列訪問，而不是鍵。
列式存儲并不是一個新概念，它的變體過去作為一種概念應用于關系型數(shù)據(jù)庫中(比如SAP Sybase IQ和IBM DB2 BLU)。雖然關系型列式存儲也聚焦與列，但它不允許跨行的列有所不同，這是它與NoSQL列式存儲不同之處。
對于不經(jīng)常寫，但要頻繁地一次讀取很多行的幾列的情況下，列式存儲是很有效率的。對于時間日志、內(nèi)容管理、分析的計算和分類，列式存儲都很有效。如果你有要過期的數(shù)據(jù)，列式存儲非常有用，因為你可以建立一列，讓它自動過期。
如果是跨度很廣的查詢，不要用列式存儲，因為你可能不得不重新設計列。另外，列式存儲不是很適合ACID事務。
圖型數(shù)據(jù)庫。這種數(shù)據(jù)庫可能是和傳統(tǒng)數(shù)據(jù)庫以及其他NoSQL數(shù)據(jù)庫區(qū)別大的。圖型數(shù)據(jù)庫適用于數(shù)據(jù)元素之間相互關聯(lián)，而且彼此之間關系的數(shù)量不確定的情況。
圖型數(shù)據(jù)庫最常用于社交媒體網(wǎng)絡，比如LinkedIn和Facebook。當然也有一些其他的應用程序，比如分配路線和調(diào)度、定位系統(tǒng)、公共交通連接、地圖、課程計劃和網(wǎng)絡拓撲結構等。圖型數(shù)據(jù)庫的另一個實踐在于推薦引擎，常用語在線零售商。
圖型數(shù)據(jù)庫不適合用于數(shù)據(jù)經(jīng)常改變，常發(fā)生大規(guī)模數(shù)據(jù)之間實時更新的情況。另外，如果你計劃跨網(wǎng)絡分區(qū)數(shù)據(jù)庫的話，圖型數(shù)據(jù)庫很可能會性能下降。
六大考慮因素
NoSQL數(shù)據(jù)庫之間的很多不同給技術選擇帶來了難度。不同的數(shù)據(jù)庫類型和產(chǎn)品有不同的架構。即使同樣是NoSQL數(shù)據(jù)庫，不同類型之間也有所不同，沒有統(tǒng)一標準，即便是訪問數(shù)據(jù)的標準也不相同。這意味著在不同的數(shù)據(jù)庫中訪問數(shù)據(jù)，有不同的工具和應用程序需要采用和學習。以下是需要考慮的一些方面。
快速變化。NoSQL領域是持續(xù)變動的，特性不斷提升、功能不斷增加、甚至會產(chǎn)生新產(chǎn)品。在選擇NoSQL數(shù)據(jù)庫時，很難跟上最新最好的功能和產(chǎn)品。
對ACID的支持能力越來越強。NoSQL的一個早期賣點是它支持不要求全部ACID支持的事務。取代ACID，NoSQL提升了最終一致的基本可用軟件狀態(tài)服務(BASE)。雖然如此，很多應用程序依然依賴ACID，NoSQL對ACID事務的支持是用戶的需求，也是它自己在不斷完善的。
缺少對多平臺的支持。大多數(shù)NoSQL數(shù)據(jù)庫起源于開源運動，因此基本上都運行在Linux上，(或者Unix的變體)。如果你需要在Windows或者主機上部署數(shù)據(jù)庫，你需要考慮商業(yè)產(chǎn)品，因為商業(yè)產(chǎn)品對多平臺部署的支持性更好。
增加對SQL的支持。沒有SQL，查詢通常非常基礎，可能要求使用高級語言的復雜的代碼。當然，產(chǎn)品與產(chǎn)品之間也有所不同，不過最好選擇支持SQL的NoSQL數(shù)據(jù)庫，因為很多開發(fā)者熟悉的還是SQL語言。
開發(fā)多種類型數(shù)據(jù)庫的能力。一些NoSQL數(shù)據(jù)庫允許你用鍵值對、文檔和圖型的彈性的組合建模和部署數(shù)據(jù)。另外，關系型數(shù)據(jù)庫開始采用NoSQL能力。使用能夠開發(fā)多種類型數(shù)據(jù)庫存儲的數(shù)據(jù)庫系統(tǒng)能幫助你的組織獲得普適的持久性。
注意技術的版本。很多開源項目運行了很多年，但也沒有第一版。這些軟件可能很好用，但慎重的公司一般不會選擇沒有發(fā)行第一版的技術。
理解NoSQL數(shù)據(jù)庫
雖然NoSQL數(shù)據(jù)庫現(xiàn)在發(fā)展的很火，但該領域仍然面臨激烈競爭，日新月異。真正理解NoSQL數(shù)據(jù)局，需要深入了解不同數(shù)據(jù)庫引擎及其用例。選擇了錯誤的技術很可能導致整個項目的失敗。
今天，有很多NoSQL數(shù)據(jù)庫系統(tǒng)得到了成功的應用，一旦應用到正確的地方，它將發(fā)揮出無窮的力量。
重慶分公司
重慶分公司
