|
|
上一篇簡單的說明了為什么要使用NoSQL。接下來我們看下如何把NoSQL引入到我們的項(xiàng)目中，我們到底要不要把NoSQL引入到項(xiàng)目中。
在過去，我們只需要學(xué)習(xí)和使用一種數(shù)據(jù)庫技術(shù)，就能做幾乎所有的數(shù)據(jù)庫應(yīng)用開發(fā)。因?yàn)槌墒旆€(wěn)定的關(guān)系數(shù)據(jù)庫產(chǎn)品并不是很多，而供你選擇的免費(fèi)版本就更加少了，所以互聯(lián)網(wǎng)領(lǐng)域基本上都選擇了免費(fèi)的MySQL數(shù)據(jù)庫。在高速發(fā)展的WEB2.0時(shí)代，我們發(fā)現(xiàn)關(guān)系數(shù)據(jù)庫在性能、擴(kuò)展性、數(shù)據(jù)的快速備份和恢復(fù)、滿足需求的易用性上并不總是能很好的滿足我們的需要，我們越來越趨向于根據(jù)業(yè)務(wù)場景選擇合適的數(shù)據(jù)庫，以及進(jìn)行多種數(shù)據(jù)庫的融合運(yùn)用。幾年前的一篇文章《One Size Fits All - An Idea Whose Time Has Come and Gone》就已經(jīng)闡述了這個(gè)觀點(diǎn)。
當(dāng)我們在討論是否要使用NoSQL的時(shí)候，你還需要理解NoSQL也是分很多種類的，在NoSQL百花齊放的今天，NoSQL的正確選擇比選擇關(guān)系數(shù)據(jù)庫還具有挑戰(zhàn)性。雖然NoSQL的使用很簡單，但是選擇卻是個(gè)麻煩事，這也正是很多人在觀望的一個(gè)原因。
NoSQL的分類
NoSQL僅僅是一個(gè)概念，NoSQL數(shù)據(jù)庫根據(jù)數(shù)據(jù)的存儲模型和特點(diǎn)分為很多種類。
類型 | 部分代表 | 特點(diǎn) |
列存儲 | Hbase Cassandra Hypertable | 顧名思義，是按列存儲數(shù)據(jù)的。最大的特點(diǎn)是方便存儲結(jié)構(gòu)化和半結(jié)構(gòu)化數(shù)據(jù)，方便做數(shù)據(jù)壓縮，對針對某一列或者某幾列的查詢有非常大的IO優(yōu)勢。 |
文檔存儲 | MongoDB CouchDB | 文檔存儲一般用類似json的格式存儲，存儲的內(nèi)容是文檔型的。這樣也就有有機(jī)會對某些字段建立索引，實(shí)現(xiàn)關(guān)系數(shù)據(jù)庫的某些功能。 |
key-value存儲 | Tokyo CabiNET / Tyrant Berkeley DB MemcacheDB Redis | 可以通過key快速查詢到其value。一般來說，存儲不管value的格式，照單全收。（Redis包含了其他功能） |
圖存儲 | Neo4J FlockDB | 圖形關(guān)系的最佳存儲。使用傳統(tǒng)關(guān)系數(shù)據(jù)庫來解決的話性能低下，而且設(shè)計(jì)使用不方便。 |
對象存儲 | db4o Versant | 通過類似面向?qū)ο笳Z言的語法操作數(shù)據(jù)庫，通過對象的方式存取數(shù)據(jù)。 |
xml數(shù)據(jù)庫 | Berkeley DB XML BaseX | 高效的存儲XML數(shù)據(jù)，并支持XML的內(nèi)部查詢語法，比如XQuery,Xpath。 |
以上NoSQL數(shù)據(jù)庫類型的劃分并不是絕對，只是從存儲模型上來進(jìn)行的大體劃分。它們之間沒有絕對的分界，也有交差的情況，比如Tokyo CabiNET / Tyrant的Table類型存儲，就可以理解為是文檔型存儲，Berkeley DB XML數(shù)據(jù)庫是基于Berkeley DB之上開發(fā)的。
NoSQL還是關(guān)系數(shù)據(jù)庫
雖然09年出現(xiàn)了比較激進(jìn)的文章《關(guān)系數(shù)據(jù)庫已死》，但是我們心里都清楚，關(guān)系數(shù)據(jù)庫其實(shí)還活得好好的，你還不能不用關(guān)系數(shù)據(jù)庫。但是也說明了一個(gè)事實(shí)，關(guān)系數(shù)據(jù)庫在處理WEB2.0數(shù)據(jù)的時(shí)候，的確已經(jīng)出現(xiàn)了瓶頸。
那么我們到底是用NoSQL還是關(guān)系數(shù)據(jù)庫呢？我想我們沒有必要來進(jìn)行一個(gè)絕對的回答。我們需要根據(jù)我們的應(yīng)用場景來決定我們到底用什么。
如果關(guān)系數(shù)據(jù)庫在你的應(yīng)用場景中，完全能夠很好的工作，而你又是非常善于使用和維護(hù)關(guān)系數(shù)據(jù)庫的，那么我覺得你完全沒有必要遷移到NoSQL上面，除非你是個(gè)喜歡折騰的人。如果你是在金融，電信等以數(shù)據(jù)為王的關(guān)鍵領(lǐng)域，目前使用的是Oracle數(shù)據(jù)庫來提供高可靠性的，除非遇到特別大的瓶頸，不然也別貿(mào)然嘗試NoSQL。
然而，在WEB2.0的網(wǎng)站中，關(guān)系數(shù)據(jù)庫大部分都出現(xiàn)了瓶頸。在磁盤IO、數(shù)據(jù)庫可擴(kuò)展上都花費(fèi)了開發(fā)人員相當(dāng)多的精力來優(yōu)化，比如做分表分庫（database sharding）、主從復(fù)制、異構(gòu)復(fù)制等等，然而，這些工作需要的技術(shù)能力越來越高，也越來越具有挑戰(zhàn)性。如果你正在經(jīng)歷這些場合，那么我覺得你應(yīng)該嘗試一下NoSQL了。
選擇合適的NoSQL
如此多類型的NoSQL，而每種類型的NoSQL又有很多，到底選擇什么類型的NoSQL來作為我們的存儲呢？這并不是一個(gè)很好回答的問題，影響我們選擇的因素有很多，而選擇也可能有多種，隨著業(yè)務(wù)場景，需求的變更可能選擇又會變化。我們常常需要根據(jù)如下情況考慮：
- 數(shù)據(jù)結(jié)構(gòu)特點(diǎn)。包括結(jié)構(gòu)化、半結(jié)構(gòu)化、字段是否可能變更、是否有大文本字段、數(shù)據(jù)字段是否可能變化。
- 寫入特點(diǎn)。包括insert比例、update比例、是否經(jīng)常更新數(shù)據(jù)的某一個(gè)小字段、原子更新需求。
- 查詢特點(diǎn)。包括查詢的條件、查詢熱點(diǎn)的范圍。比如用戶信息的查詢，可能就是隨機(jī)的，而新聞的查詢就是按照時(shí)間，越新的越頻繁。
NoSQL和關(guān)系數(shù)據(jù)庫結(jié)合
其實(shí)NoSQL數(shù)據(jù)庫僅僅是關(guān)系數(shù)據(jù)庫在某些方面（性能，擴(kuò)展）的一個(gè)彌補(bǔ)，單從功能上講，NoSQL的幾乎所有的功能，在關(guān)系數(shù)據(jù)庫上都能夠滿足，所以選擇NoSQL的原因并不在功能上。
所以，我們一般會把NoSQL和關(guān)系數(shù)據(jù)庫進(jìn)行結(jié)合使用，各取所長，需要使用關(guān)系特性的時(shí)候我們使用關(guān)系數(shù)據(jù)庫，需要使用NoSQL特性的時(shí)候我們使用NoSQL數(shù)據(jù)庫，各得其所。
舉個(gè)簡單的例子吧，比如用戶評論的存儲，評論大概有主鍵id、評論的對象aid、評論內(nèi)容content、用戶uid等字段。我們能確定的是評論內(nèi)容content肯定不會在數(shù)據(jù)庫中用where content=’’查詢，評論內(nèi)容也是一個(gè)大文本字段。那么我們可以把 主鍵id、評論對象aid、用戶id存儲在數(shù)據(jù)庫，評論內(nèi)容存儲在NoSQL，這樣數(shù)據(jù)庫就節(jié)省了存儲content占用的磁盤空間，從而節(jié)省大量IO，對content也更容易做Cache。
//從MySQL中查詢出評論主鍵id列表
commentIds=DB.query("SELECT id FROM comments where aid='評論對象id' LIMIT 0,20");
//根據(jù)主鍵id列表，從NoSQL取回評論實(shí)體數(shù)據(jù)
CommentsList=NoSQL.get(commentIds);
it知識庫：關(guān)系數(shù)據(jù)庫還是NoSQL數(shù)據(jù)庫，轉(zhuǎn)載需保留來源！
鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請第一時(shí)間聯(lián)系我們修改或刪除，多謝。
