關聯式資料庫還是NoSQL資料庫

2021-07-04 04:54:33 字數 3120 閱讀 7516

在過去,我們只需要學習和使用一種資料庫技術,就能做幾乎所有的資料庫應用開發。因為成熟穩定的關聯式資料庫產品並不是很多,而供你選擇的免費版本就更加少了,所以網際網路領域基本上都選擇了免費的mysql資料庫。在高速發展的web2.0時代,我們發現關聯式資料庫在效能、擴充套件性、資料的快速備份和恢復、滿足需求的易用性上並不總是能很好的滿足我們的需要,我們越來越趨向於根據業務場景選擇合適的資料庫,以及進行多種資料庫的融合運用。幾年前的一篇文章《one size fits all - an idea whose time has come and gone》就已經闡述了這個觀點。

當我們在討論是否要使用nosql的時候,你還需要理解nosql也是分很多種類的,在nosql百花齊放的今天,nosql的正確選擇比選擇關聯式資料庫還具有挑戰性。雖然nosql的使用很簡單,但是選擇卻是個麻煩事,這也正是很多人在觀望的乙個原因。

nosql僅僅是乙個概念,nosql資料庫根據資料的儲存模型和特點分為很多種類。

型別部分代表

特點列儲存

hbase

cassandra

hypertable

顧名思義,是按列儲存資料的。最大的特點是方便儲存結構化和半結構化資料,方便做資料壓縮,對針對某一列或者某幾列的查詢有非常大的io優勢。

文件儲存

mongodb

couchdb

文件儲存一般用類似json的格式儲存,儲存的內容是文件型的。這樣也就有有機會對某些字段建立索引,實現關聯式資料庫的某些功能。

key-value儲存

tokyo cabinet / tyrant

berkeley db

memcachedb

redis

可以通過key快速查詢到其value。一般來說,儲存不管value的格式,照單全收。(redis包含了其他功能)

圖儲存neo4j

flockdb

圖形關係的最佳儲存。使用傳統關聯式資料庫來解決的話效能低下,而且設計使用不方便。

物件儲存

db4o

versant

通過類似物件導向語言的語法運算元據庫,通過物件的方式訪問資料。

xml資料庫

berkeley db xml

ba***

高效的儲存xml資料,並支援xml的內部查詢語法,比如xquery,xpath。

以上nosql資料庫型別的劃分並不是絕對,只是從儲存模型上來進行的大體劃分。它們之間沒有絕對的分界,也有交差的情況,比如tokyo cabinet / tyrant的table型別儲存,就可以理解為是文件型儲存,berkeley db xml資料庫是基於berkeley db之上開發的。

雖然09年出現了比較激進的文章《關聯式資料庫已死》,但是我們心裡都清楚,關聯式資料庫其實還活得好好的,你還不能不用關聯式資料庫。但是也說明了乙個事實,關聯式資料庫在處理web2.0資料的時候,的確已經出現了瓶頸。

那麼我們到底是用nosql還是關聯式資料庫呢?我想我們沒有必要來進行乙個絕對的回答。我們需要根據我們的應用場景來決定我們到底用什麼。

如果關聯式資料庫在你的應用場景中,完全能夠很好的工作,而你又是非常善於使用和維護關聯式資料庫的,那麼我覺得你完全沒有必要遷移到nosql上面,除非你是個喜歡折騰的人。如果你是在金融,電信等以資料為王的關鍵領域,目前使用的是oracle資料庫來提供高可靠性的,除非遇到特別大的瓶頸,不然也別貿然嘗試nosql。

然而,在web2.0的**中,關聯式資料庫大部分都出現了瓶頸。在磁碟io、資料庫可擴充套件上都花費了開發人員相當多的精力來優化,比如做分表分庫(database sharding)、主從複製、異構複製等等,然而,這些工作需要的技術能力越來越高,也越來越具有挑戰性。如果你正在經歷這些場合,那麼我覺得你應該嘗試一下nosql了。

如此多型別的nosql,而每種型別的nosql又有很多,到底選擇什麼型別的nosql來作為我們的儲存呢?這並不是乙個很好回答的問題,影響我們選擇的因素有很多,而選擇也可能有多種,隨著業務場景,需求的變更可能選擇又會變化。我們常常需要根據如下情況考慮:

資料結構特點。包括結構化、半結構化、字段是否可能變更、是否有大文字字段、資料字段是否可能變化。

寫入特點。包括insert比例、update比例、是否經常更新資料的某乙個小字段、原子更新需求。

查詢特點。包括查詢的條件、查詢熱點的範圍。比如使用者資訊的查詢,可能就是隨機的,而新聞的查詢就是按照時間,越新的越頻繁。

其實nosql資料庫僅僅是關聯式資料庫在某些方面(效能,擴充套件)的乙個彌補,單從功能上講,nosql的幾乎所有的功能,在關聯式資料庫上都能夠滿足,所以選擇nosql的原因並不在功能上。

所以,我們一般會把nosql和關聯式資料庫進行結合使用,各取所長,需要使用關係特性的時候我們使用關聯式資料庫,需要使用nosql特性的時候我們使用nosql資料庫,各得其所。

commentslist=nosql.get(commentids);

在某些應用場合,比如一些配置的關係鍵值對映儲存、使用者名稱和密碼的儲存、session會話儲存等等,用nosql完全可以替代mysql儲存。不但具有更高的效能,而且開發也更加方便。

mysql+memcached的架構中,我們處處都要精心設計我們的快取,包括過期時間的設計、快取的實時性設計、快取記憶體大小評估、快取命中率等等。

nosql資料庫一般都具有非常高的效能,在大多數場景下面,你不必再考慮在**層為nosql構建一層memcached快取。nosql資料本身在cache上已經做了相當多的優化工作。

memcached這類記憶體快取伺服器快取的資料大小受限於記憶體大小,如果用nosql來代替memcached來快取資料庫的話,就可以不再受限於記憶體大小。雖然可能有少量的磁碟io讀寫,可能比memcached慢一點,但是完全可以用來快取資料庫的查詢操作。

由於nosql是乙個比較新的東西,特別是我們選擇的nosql資料庫還不是非常成熟的產品,所以我們可能會遇到未知的風險。為了得到nosql的好處,又要考慮規避風險,魚與熊掌如何兼得?

現在業內很多公司的做法就是資料的備份。在往nosql裡面儲存資料的時候還會往mysql裡面儲存乙份。nosql資料庫本身也需要進行備份(冷備和熱備)。或者可以考慮使用兩種nosql資料庫,出現問題後可以進行切換(避免出現digg使用cassandra的悲劇)。

本文只是簡單的從mysql和nosql的角度分析如何選擇,以及進行融合使用。其實在選擇nosql的時候,你可能還會碰到關於cap原則,最終一致性,base思想的考慮。因為使用mysql架構的時候,你也會碰到上面的問題,所以這裡沒有闡述。

關聯式資料庫還是NoSQL資料庫

在過去,我們只需要學習和使用一種資料庫技術,就能做幾乎所有的資料庫應用開發。因為成熟穩定的關聯式資料庫產品並不是很多,而供你選擇的免費版本就更加少了,所以網際網路領域基本上都選擇了免費的mysql資料庫。在高速發展的web2.0時代,我們發現關聯式資料庫在效能 擴充套件性 資料的快速備份和恢復 滿足...

關聯式資料庫還是NoSQL資料庫

在過去,我們只需要學習和使用一種資料庫技術,就能做幾乎所有的資料庫應用開發。因為成熟穩定的關聯式資料庫產品並不是很多,而供你選擇的免費版本就更加少了,所以網際網路領域基本上都選擇了免費的mysql資料庫。在高速發展的web2.0時代,我們發現關聯式資料庫在效能 擴充套件性 資料的快速備份和恢復 滿足...

關聯式資料庫還是NoSQL資料庫

在過去,我們只需要學習和使用一種資料庫技術,就能做幾乎所有的資料庫應用開發。因為成熟穩定的關聯式資料庫產品並不是很多,而供你選擇的免費版本就更加少了,所以網際網路領域基本上都選擇了免費的mysql資料庫。在高速發展的web2.0時代,我們發現關聯式資料庫在效能 擴充套件性 資料的快速備份和恢復 滿足...