NoSQL資料庫的出現及選擇哪種NoSQL資料庫

    在沒有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. 推薦引擎。如果我們将資料以圖的形式表現，那麼将會非常有益于推薦的制定

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