在沒有NOSQL資料時，關係型資料庫一直是資料持久化的唯一選擇，比較典型的關係型資料庫有SQL Server、Oracle，MySQL,DB2.做.NET開發的同學一般會選擇SQL Server，做JAVA的可能會偏向Oracle，MySQL,Python則是PostgreSQL或MySQL等等。過去很長一段時間內，關係資料庫的健壯性已經在多數應用程式中得到證實。我們可以使用這些傳統資料庫良好的控制併發操作、事務等等。然而如果傳統的關係型資料庫一直這麼可靠，那麼為什麼還會出現NOSQL呢？NoSQL之所以生存並得到發展，是因為它做到了傳統關係型資料庫做不到的事！

關係型資料庫中存在的問題

我們使用的高階程式語言如Java、.Net.python等語言他們都有一個共同的特性——面向物件。但是我們所使用資料庫MySQL、PostgreSQL、Oracle以及SQL Server他們同樣有一個共同的特性——關係型資料庫。這裡就牽扯到了“Impedance Mismatch”這個術語：儲存結構是面向物件的，但是資料庫卻是關係的，所以在每次儲存或者查詢資料時，我們都需要做轉換。

應用程式規模的變大

隨著網際網路的逐漸發展，越來越多的業務資料和訪問能力讓伺服器承受著巨大的負擔為了解決這個問題我們可以通過擴充套件：一種是縱向擴充套件，即購買更好的機器，更大的磁碟空間、更多的記憶體等等；另一種是橫向擴充套件，即購買更多的機器組成叢集，搭建分散式伺服器，在巨大的規模下，縱向擴充套件發揮的作用並不是很大。首先單機器效能提升需要鉅額的開銷並且有著效能的上限，在Google和Facebook這種規模下，永遠不可能使用一臺機器支撐所有的負載。鑑於這種情況，我們需要新的資料庫，因為關係資料庫並不能很好的執行在叢集上。

NoSQL 資料庫特點

不再使用SQL語言

一般為開源專案

為叢集執行而生

弱結構化——不會嚴格的限制資料結構型別

NoSQL資料庫的型別

NoSQL可以大體上分為4個種類：鍵-值對資料庫、列族/大表資料庫、文件資料庫以及圖形資料庫。下面就一覽這些型別的特性：

一、鍵-值對資料庫

鍵值資料庫就像在傳統語言中使用的雜湊表。你可以通過key來新增、查詢或者刪除資料，鑑於使用主鍵訪問，所以會獲得不錯的效能及擴充套件性雖然具備高度可擴充套件性，但卻無法幫助開發人員順暢處理複雜資料集。如果大家需要進行磁碟備份、分散式散列表並通過一致性對資料內容加以檢查，那麼上述方案既具備良好的規模化能力、又能提供出色的處理速度。然而如果我們需要通過某個鍵來獲取另一個鍵、進而訪問第三個鍵以查詢相關值，那麼問題就會變得不易處理了

代表產品：Couchbase、Riak、Redis、Memcached

案列：Youtube （Memcached）、Twitter （Redis）、StackOverFlow （Redis）、GitHub （Riak）

適用的場景

儲存使用者資訊，比如會話、配置檔案、引數、購物車等等。這些資訊一般都和ID（鍵）掛鉤，這種情景下鍵值資料庫是個很好的選擇。

不適用場景

1. 取代通過鍵查詢，而是通過值來查詢。Key-Value資料庫中根本沒有通過值查詢的途徑。

2. 需要儲存資料之間的關係。在Key-Value資料庫中不能通過兩個或以上的鍵來關聯資料。

3. 事務的支援。在Key-Value資料庫中故障產生時不可以進行回滾。

二、列族/大表資料庫

這是鍵-值資料庫的一種更為先進的表現形式。從本質上講，其中的鍵與值 存在一定程度的複合。我們可以將其視為一套貫穿多維陣列的雜湊對映。基本每一個列都容納著一行資料。舉個例子，如果我們有一個Person類，我們通常會一起查詢他們的姓名和年齡而不是薪資。這種情況下，姓名和年齡就會被放入一個列族中，而薪資則在另一個列族中。

代表產品：Cassandra、HBase

案列：Instagram （Cassandra）,NASA （Cassandra）,Yahoo!（HBase）

適用的場景

1. 日誌資訊。因為我們可以將資料儲存在不同的列中，每個應用程式可以將資訊寫入自己的列族中。

2. 社交平臺。我們儲存每個資訊到不同的列族中。

不適用場景

1. 需要ACID事務。

2.資料之間的關係與資料本身的重要性不相上下

三、文件資料庫

面向文件資料庫會將資料以文件的形式儲存。每個文件都是自包含的資料單元，是一系列資料項的集合。每個資料項都有一個名稱與對應的值，值既可以是簡單的資料型別，如字串、數字和日期等；也可以是複雜的型別，如有序列表和關聯物件。資料儲存的最小單位是文件，同一個表中儲存的文件屬性可以是不同的，資料可以使用XML、JSON或者JSONB等多種形式儲存。文件資料庫屬於自然而然的發展趨勢。從叢集化到資料訪問，文件資料庫與鍵-值資料庫幾乎完全一致;惟一的區別在於，文件資料庫能夠理解所儲存資料中的文件內容。”換句話來說，文件資料庫會可以將值作為JSON、而JSON文件中的元素則能夠通過檢索輕鬆進行查詢與搜尋。

代表產品：MongoDB、CouchDB、Couchbase

案列：SAP （MongoDB）

適用的場景

1. 文件資訊儲存。企業環境下，每個應用程式都有不同的日誌資訊。文件資料庫資料庫並沒有固定的模式，所以我們可以使用它儲存不同的資訊。

2. 分析。鑑於它的弱模式結構，不改變模式下就可以儲存不同的度量方法及新增新的度量。

不適用場景

在不同的文件上新增事務。文件資料庫資料庫並不支援文件間的事務

四、圖形資料庫

形資料庫並不太關注資料規模或者可用性，而主要針對我們的資料之間存在怎樣的相關性以及使用者需要如何執行計算任務。正如Neo Technologies公司(主要產品為Neo4j資料庫)產品工程高階主管Philip Rathle所說，圖形資料庫的威力主要體現在“資料集在本質上存在關聯且非表格形式的情況下。其首要資料訪問模式採用事務型機制，即OLTP/記錄系統而非批量處理機制……請大家記住，圖形資料庫允許以事務性方式執行關聯性操作，這一點在關係型資料庫管理系統領域只能通過批量處理來完成。”

代表產品：Neo4J

案列：Adobe（Neo4J）

適用的場景

1. 在一些關係性強的資料中

2. 推薦引擎。如果我們將資料以圖的形式表現，那麼將會非常有益於推薦的制定

不適用場景

不適合的資料模型。圖資料庫的適用範圍很小，因為很少有操作涉及到整個圖。