NoSQL型別介紹及適用場景

NO IMAGE

應用程式規模的變大

網路應用程式的規模日漸變大,我們需要儲存更多的資料、服務更多的使用者以及需求更多的計算能力。為了應對這種情形,我們需要不停的擴充套件。擴充套件分為兩類:一種是縱向擴充套件,即購買更好的機器,更多的磁碟、更多的記憶體等等;另一種是橫向擴充套件,即購買更多的機器組成叢集。在巨大的規模下,縱向擴充套件發揮的作用並不是很大。首先單機器效能提升需要鉅額的開銷並且有著效能的上限,在Google和Facebook這種規模下,永遠不可能使用一臺機器支撐所有的負載。鑑於這種情況,我們需要新的資料庫,因為關聯式資料庫並不能很好的執行在叢集上。不錯你也可能會去搭建關聯式資料庫叢集,但是他們使用的是共享儲存,這並不是我們想要的型別。於是就有了以Google、Facebook、Amazon這些試圖處理更多傳輸所引領的NoSQL紀元。

NoSQL紀元

當下已經存在很多的NoSQL資料庫,比如MongoDB、Redis、Riak、HBase、Cassandra等等。每一個都擁有以下幾個特性中的一個:

  • 不再使用SQL語言,比如MongoDB、Cassandra就有自己的查詢語言
  • 通常是開源專案
  • 為叢集執行而生
  • 弱結構化——不會嚴格的限制資料結構型別

NoSQL資料庫的型別

NoSQL可以大體上分為4個種類:Key-value、Document-Oriented、Column-Family Databases以及 Graph-Oriented Databases。下面就一覽這些型別的特性:

一、 鍵值(Key-Value)資料庫

鍵值資料庫就像在傳統語言中使用的雜湊表。你可以通過key來新增、查詢或者刪除資料,鑑於使用主鍵訪問,所以會獲得不錯的效能及擴充套件性。

產品:Riak、Redis、Memcached、Amazon’s Dynamo、Project Voldemort

有誰在使用:GitHub (Riak)、BestBuy (Riak)、Twitter (Redis和Memcached)、StackOverFlow (Redis)、 Instagram (Redis)、Youtube (Memcached)、Wikipedia(Memcached)

適用的場景

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

不適用場景

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

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

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

二、 面向文件(Document-Oriented)資料庫

面向文件資料庫會將資料以文件的形式儲存。每個文件都是自包含的資料單元,是一系列資料項的集合。每個資料項都有一個名稱與對應的值,值既可以是簡單的資料型別,如字串、數字和日期等;也可以是複雜的型別,如有序列表和關聯物件。資料儲存的最小單位是文件,同一個表中儲存的文件屬性可以是不同的,資料可以使用XML、JSON或者JSONB等多種形式儲存。

產品:MongoDB、CouchDB、RavenDB

有誰在使用:SAP (MongoDB)、Codecademy (MongoDB)、Foursquare (MongoDB)、NBC News (RavenDB)

適用的場景

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

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

不適用場景

在不同的文件上新增事務。Document-Oriented資料庫並不支援文件間的事務,如果對這方面有需求則不應該選用這個解決方案。

三、 列儲存(Wide Column Store/Column-Family)資料庫

列儲存資料庫將資料儲存在列族(column family)中,一個列族儲存經常被一起查詢的相關資料。舉個例子,如果我們有一個Person類,我們通常會一起查詢他們的姓名和年齡而不是薪資。這種情況下,姓名和年齡就會被放入一個列族中,而薪資則在另一個列族中。

產品:Cassandra、HBase

有誰在使用:Ebay (Cassandra)、Instagram (Cassandra)、NASA (Cassandra)、Twitter (Cassandra and HBase)、Facebook (HBase)、Yahoo!(HBase)

適用的場景

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

2. 部落格平臺。我們儲存每個資訊到不同的列族中。舉個例子,標籤可以儲存在一個,類別可以在一個,而文章則在另一個。

不適用場景

1. 如果我們需要ACID事務。Vassandra就不支援事務。

2. 原型設計。如果我們分析Cassandra的資料結構,我們就會發現結構是基於我們期望的資料查詢方式而定。在模型設計之初,我們根本不可能去預測它的查詢方式,而一旦查詢方式改變,我們就必須重新設計列族。

四、 圖(Graph-Oriented)資料庫

圖資料庫允許我們將資料以圖的方式儲存。實體會被作為頂點,而實體之間的關係則會被作為邊。比如我們有三個實體,Steve Jobs、Apple和Next,則會有兩個“Founded by”的邊將Apple和Next連線到Steve Jobs。

產品:Neo4J、Infinite Graph、OrientDB

有誰在使用:Adobe (Neo4J)、Cisco (Neo4J)、T-Mobile (Neo4J)

適用的場景

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

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

不適用場景

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