一、NoSQL的誕生原因

隨著互聯(lián)網(wǎng)快速發(fā)展，各種類(lèi)型的應(yīng)用層出不窮，所以導(dǎo)致在這個(gè)云計(jì)算的時(shí)代，對(duì)技術(shù)提出了更多的需求，主要體現(xiàn)在下面這四個(gè)方面：

1. 低延遲的讀寫(xiě)速度：應(yīng)用快速地反應(yīng)能極大地提升用戶(hù)的滿(mǎn)意度;

原因：當(dāng)數(shù)據(jù)量達(dá)到一定規(guī)模時(shí)，由于關(guān)系型數(shù)據(jù)庫(kù)的系統(tǒng)邏輯非常復(fù)雜，使得其非常容易發(fā)生死鎖等的并發(fā)問(wèn)題，所以導(dǎo)致其讀寫(xiě)速度下滑非常嚴(yán)重;

2. 支撐海量的數(shù)據(jù)和流量：對(duì)于搜索這樣大型應(yīng)用而言，需要利用PB級(jí)別的數(shù)據(jù)和能應(yīng)對(duì)百萬(wàn)級(jí)的流量;

原因：有限的支撐容量：現(xiàn)有關(guān)系型解決方案還無(wú)法支撐Google這樣海量的數(shù)據(jù)存儲(chǔ)

3. 大規(guī)模集群的管理：系統(tǒng)管理員希望分布式應(yīng)用能更簡(jiǎn)單的部署和管理;

原因：由于存在類(lèi)似Join這樣多表查詢(xún)機(jī)制，使得數(shù)據(jù)庫(kù)在擴(kuò)展方面很艱難;

4. 龐大運(yùn)營(yíng)成本的考量：IT經(jīng)理們希望在硬件成本、軟件成本和人力成本能夠有大幅度地降低;

原因：企業(yè)級(jí)數(shù)據(jù)庫(kù)的License價(jià)格很驚人，并且隨著系統(tǒng)的規(guī)模，而不斷上升;

業(yè)界為了解決上面提到的幾個(gè)需求，推出了多款新類(lèi)型的數(shù)據(jù)庫(kù)，并且由于它們?cè)谠O(shè)計(jì)上和傳統(tǒng)的NoSQL數(shù)據(jù)庫(kù)相比有很大的不同，所以被統(tǒng)稱(chēng)為 “NoSQL”系列數(shù)據(jù)庫(kù)?？偟膩?lái)說(shuō)，在設(shè)計(jì)上，它們非常關(guān)注對(duì)數(shù)據(jù)高并發(fā)地讀寫(xiě)和對(duì)海量數(shù)據(jù)的存儲(chǔ)等，與關(guān)系型數(shù)據(jù)庫(kù)相比，它們?cè)诩軜?gòu)和數(shù)據(jù)模型方量面 做了“減法”，而在擴(kuò)展和并發(fā)等方面做了“加法”?，F(xiàn)在主流的NoSQL數(shù)據(jù)庫(kù)有BigTable、HBase、Cassandra、SimpleDB、CouchDB、MongoDB和Redis等。

二、為何要使用NoSQL數(shù)據(jù)庫(kù)?

1. NoSQL具有靈活的數(shù)據(jù)模型，可以處理非結(jié)構(gòu)化/半結(jié)構(gòu)化的大數(shù)據(jù)

現(xiàn)在，我們可以通過(guò)Facebook、D&B等第三方輕松獲得與訪問(wèn)數(shù)據(jù)，如個(gè)人用戶(hù)信息、地理位置數(shù)據(jù)、社交圖譜、用戶(hù)產(chǎn)生的內(nèi)容、機(jī)器日志數(shù) 據(jù)以及傳感器生成的數(shù)據(jù)等。對(duì)這些數(shù)據(jù)的使用正在快速改變著通信、購(gòu)物、廣告、娛樂(lè)以及關(guān)系管理的特質(zhì)。沒(méi)有使用這些數(shù)據(jù)的應(yīng)用很快就會(huì)被用戶(hù)所遺忘。開(kāi) 發(fā)者希望使用非常靈活的數(shù)據(jù)庫(kù)，能夠輕松容納新的數(shù)據(jù)類(lèi)型，并且不會(huì)被第三方數(shù)據(jù)提供商內(nèi)容結(jié)構(gòu)的變化所累。很多新數(shù)據(jù)都是非結(jié)構(gòu)化或是半結(jié)構(gòu)化的，因此 開(kāi)發(fā)者還需要能夠高效存儲(chǔ)這種數(shù)據(jù)的數(shù)據(jù)庫(kù)。但遺憾的是，關(guān)系型數(shù)據(jù)庫(kù)所使用的定義嚴(yán)格、基于模式的方式是無(wú)法快速容納新的數(shù)據(jù)類(lèi)型的，對(duì)于非結(jié)構(gòu)化或是 半結(jié)構(gòu)化的數(shù)據(jù)更是無(wú)能為力。NoSQL提供的數(shù)據(jù)模型則能很好地滿(mǎn)足這種需求。很多應(yīng)用都會(huì)從這種非結(jié)構(gòu)化數(shù)據(jù)模型中獲益，比如說(shuō)CRM、ERP、 BPM等等，他們可以通過(guò)這種靈活性存儲(chǔ)數(shù)據(jù)而無(wú)需修改表或是創(chuàng)建更多的列。這些數(shù)據(jù)庫(kù)也非常適合于創(chuàng)建原型或是快速應(yīng)用，因?yàn)檫@種靈活性使得新特性的開(kāi)發(fā)變得非常容易。

 2. NoSQL很容易實(shí)現(xiàn)可伸縮性(向上擴(kuò)展與水平擴(kuò)展)

如果有很多用戶(hù)在頻繁且并發(fā)地使用你的應(yīng)用，那么你就需要考慮可伸縮的數(shù)據(jù)庫(kù)技術(shù)而非傳統(tǒng)的RDBMS了。對(duì)于關(guān)系型技術(shù)來(lái)說(shuō)，很多應(yīng)用開(kāi)發(fā)者會(huì)發(fā)現(xiàn)動(dòng)態(tài) 的可伸縮性是難以實(shí)現(xiàn)的，這時(shí)就應(yīng)該考慮切換到NoSQL數(shù)據(jù)庫(kù)上。對(duì)于云應(yīng)用來(lái)說(shuō)，關(guān)系型數(shù)據(jù)庫(kù)一開(kāi)始是普遍的選擇。然而，在使用過(guò)程中卻遇到了越來(lái)越 多的問(wèn)題，原因就在于他們是中心化的，向上擴(kuò)展而非水平擴(kuò)展的。這使得他們不適合于那些需要簡(jiǎn)單且動(dòng)態(tài)可伸縮性的應(yīng)用。NoSQL數(shù)據(jù)庫(kù)從一開(kāi)始就是分布 式、水平擴(kuò)展的，因此非常適合于互聯(lián)網(wǎng)應(yīng)用分布式的特性。

在三層互聯(lián)網(wǎng)架構(gòu)的Web/應(yīng)用層上，多年來(lái)向上擴(kuò)展已經(jīng)成為默認(rèn)的擴(kuò)展方式了。隨著應(yīng)用使用人數(shù)的激增，我們需要添加更多的服務(wù)器，性能則是通過(guò)負(fù)載均 衡來(lái)實(shí)現(xiàn)的，這時(shí)的代價(jià)與用戶(hù)數(shù)量成線性比例關(guān)系。在NoSQL數(shù)據(jù)庫(kù)之前，數(shù)據(jù)庫(kù)層的默認(rèn)擴(kuò)展方式就是向上擴(kuò)展。為了支持更多的并發(fā)用戶(hù)以及存儲(chǔ)更多的 數(shù)據(jù)，你需要越來(lái)越好的服務(wù)器，更好的CPU、更多的內(nèi)存、更大的磁盤(pán)來(lái)維護(hù)所有表。然而，好的服務(wù)器意味著更加復(fù)雜、私有、并且也更加昂貴。這與Web/應(yīng)用層所使用的便宜的硬件形成了鮮明的對(duì)比。

3. 動(dòng)態(tài)模式

關(guān)系型數(shù)據(jù)庫(kù)需要在添加數(shù)據(jù)前先定義好模式。比如說(shuō)，你需要存儲(chǔ)客戶(hù)的電話(huà)號(hào)碼、姓名、地址、城市與州等信息，SQL數(shù)據(jù)庫(kù)需要提前知曉你要存的是什么。 這對(duì)于敏捷開(kāi)發(fā)模式來(lái)說(shuō)是場(chǎng)災(zāi)難，因?yàn)槊看瓮瓿尚绿匦詴r(shí)，數(shù)據(jù)庫(kù)的模式通常都需要改變。因此，如果在開(kāi)發(fā)過(guò)程中想將客戶(hù)喜歡的條目加到數(shù)據(jù)庫(kù)中，那就得向 表中添加這一列才行，然后要做的就是將整個(gè)數(shù)據(jù)庫(kù)遷移到新的模式上。

4. 自動(dòng)分片

由于是結(jié)構(gòu)化的，關(guān)系型數(shù)據(jù)庫(kù)通常會(huì)垂直擴(kuò)展，單臺(tái)服務(wù)器要持有整個(gè)數(shù)據(jù)庫(kù)來(lái)確保可靠性與數(shù)據(jù)的持續(xù)可用性。這樣做的代價(jià)就是非常昂貴、擴(kuò)展受到限制，并 且數(shù)據(jù)庫(kù)基礎(chǔ)設(shè)施會(huì)成為失敗點(diǎn)。這個(gè)問(wèn)題的解決方案就是水平擴(kuò)展，添加服務(wù)器而不是為單臺(tái)服務(wù)器增加更多的能力。NoSQL數(shù)據(jù)庫(kù)通常都支持自動(dòng)分片，這 意味著他們本質(zhì)上就會(huì)自動(dòng)在多臺(tái)服務(wù)器上分發(fā)數(shù)據(jù)，應(yīng)用甚至都不知道這些事情。數(shù)據(jù)與查詢(xún)負(fù)載會(huì)自動(dòng)在多臺(tái)服務(wù)器上做到平衡，當(dāng)某臺(tái)服務(wù)器當(dāng)機(jī)時(shí)，它能快 速且透明地被替換掉。

5. 復(fù)制

大多數(shù)NoSQL數(shù)據(jù)庫(kù)也支持自動(dòng)復(fù)制，這意味著你可以獲得高可用性與災(zāi)備恢復(fù)功能。從開(kāi)發(fā)者的角度來(lái)看，存儲(chǔ)環(huán)境本質(zhì)上是虛擬化的。

三、NoSQL優(yōu)缺點(diǎn)

在優(yōu)勢(shì)方面，主要體現(xiàn)在下面這三點(diǎn)：

• 簡(jiǎn)單的擴(kuò)展：典型例子是Cassandra，由于其架構(gòu)是類(lèi)似于經(jīng)典的P2P，所以能通過(guò)輕松地添加新的節(jié)點(diǎn)來(lái)擴(kuò)展這個(gè)集群;
• 快速的讀寫(xiě)：主要例子有Redis，由于其邏輯簡(jiǎn)單，而且純內(nèi)存操作，使得其性能非常出色，單節(jié)點(diǎn)每秒可以處理超過(guò)10萬(wàn)次讀寫(xiě)操作;
• 低廉的成本：這是大多數(shù)分布式數(shù)據(jù)庫(kù)共有的特點(diǎn)，因?yàn)橹饕际情_(kāi)源軟件，沒(méi)有昂貴的License成本;

但瑕不掩瑜，NoSQL數(shù)據(jù)庫(kù)還存在著很多的不足，常見(jiàn)主要有下面這幾個(gè)：

• 不提供對(duì)SQL的支持：如果不支持SQL這樣的工業(yè)標(biāo)準(zhǔn)，將會(huì)對(duì)用戶(hù)產(chǎn)生一定的學(xué)習(xí)和應(yīng)用遷移成本;
• 支持的特性不夠豐富：現(xiàn)有產(chǎn)品所提供的功能都比較有限，大多數(shù)NoSQL數(shù)據(jù)庫(kù)都不支持事務(wù)，也不像MS SQL Server和Oracle那樣能提供各種附加功能，比如BI和報(bào)表等;
• 現(xiàn)有產(chǎn)品的不夠成熟：大多數(shù)產(chǎn)品都還處于初創(chuàng)期，和關(guān)系型數(shù)據(jù)庫(kù)幾十年的完善不可同日而語(yǔ);

上面NoSQL產(chǎn)品的優(yōu)缺點(diǎn)都是些比較共通的，在實(shí)際情況下，每個(gè)產(chǎn)品都會(huì)根據(jù)自己所遵從的數(shù)據(jù)模型和CAP理念而有所不同。

四、適合場(chǎng)景

NoSQL數(shù)據(jù)庫(kù)正在成為數(shù)據(jù)庫(kù)領(lǐng)域的重要力量。如果使用恰當(dāng)，那么它會(huì)帶來(lái)很多好處。然而，企業(yè)應(yīng)該非常小心并注意到這些數(shù)據(jù)庫(kù)的限制與問(wèn)題。

NoSQL這兩年越來(lái)越熱，尤其是大型互聯(lián)網(wǎng)公司非常熱衷這門(mén)技術(shù)。根據(jù)筆者的經(jīng)驗(yàn)，并不是任何場(chǎng)景，NoSQL都要優(yōu)于關(guān)系型數(shù)據(jù)庫(kù)。下面我們來(lái)具體聊聊，什么時(shí)候使用NoSQL比較給力：

1. 數(shù)據(jù)庫(kù)表schema經(jīng)常變化

比如在線商城，維護(hù)產(chǎn)品的屬性經(jīng)常要增加字段，這就意味著ORMapping層的代碼和配置要改，如果該表的數(shù)據(jù)量過(guò)百萬(wàn)，新增字段會(huì)帶來(lái)額外開(kāi)銷(xiāo)(重建索引等)。NoSQL應(yīng)用在這種場(chǎng)景，可以極大提升DB的可伸縮性，開(kāi)發(fā)人員可以將更多的精力放在業(yè)務(wù)層。

2. 數(shù)據(jù)庫(kù)表字段是復(fù)雜數(shù)據(jù)類(lèi)型

對(duì)于復(fù)雜數(shù)據(jù)類(lèi)型，比如SQL Sever提供了可擴(kuò)展性的支持，像xml類(lèi)型的字段。很多用過(guò)的同學(xué)應(yīng)該知道，該字段不管是查詢(xún)還是更改，效率非常一般。主要原因是是DB層對(duì)xml字 段很難建高效索引，應(yīng)用層又要做從字符流到dom的解析轉(zhuǎn)換。NoSQL以json方式存儲(chǔ)，提供了原生態(tài)的支持，在效率方便遠(yuǎn)遠(yuǎn)高于傳統(tǒng)關(guān)系型數(shù)據(jù)庫(kù)。

3. 高并發(fā)數(shù)據(jù)庫(kù)請(qǐng)求

此類(lèi)應(yīng)用常見(jiàn)于web2.0的網(wǎng)站，很多應(yīng)用對(duì)于數(shù)據(jù)一致性要求很低，而關(guān)系型數(shù)據(jù)庫(kù)的事務(wù)以及大表join反而成了”性能殺手”。在高并發(fā)情況 下，sql與no-sql的性能對(duì)比由于環(huán)境和角度不同一直是存在爭(zhēng)議的，并不是說(shuō)在任何場(chǎng)景，no-sql總是會(huì)比sql快。有篇article和大家 分享下，http://artur.ejsmont.org/blog/content/insert-performance-comparison-of-nosql-vs-sql-servers

4. 海量數(shù)據(jù)的分布式存儲(chǔ)

海量數(shù)據(jù)的存儲(chǔ)如果選用大型商用數(shù)據(jù)，如Oracle，那么整個(gè)解決方案的成本是非常高的，要花很多錢(qián)在軟硬件上。NoSQL分布式存儲(chǔ)，可以部署在廉價(jià)的硬件上，是一個(gè)性?xún)r(jià)比非常高的解決方案。Mongo的auto-sharding已經(jīng)運(yùn)用到了生產(chǎn)環(huán)境。http://www.mongodb.org/display/DOCS/Sharding

并不是說(shuō)NoSQL可以解決一切問(wèn)題，像ERP系統(tǒng)、BI系統(tǒng)，在大部分情況還是推薦使用傳統(tǒng)關(guān)系型數(shù)據(jù)庫(kù)。主要的原因是此類(lèi)系統(tǒng)的業(yè)務(wù)模型復(fù)雜，使用NoSQL將導(dǎo)致系統(tǒng)的維護(hù)成本增加。

五、選擇SQL還是NoSQL

上面說(shuō)明了為什么要使用NoSQL。接下來(lái)我們看下如何把NoSQL引入到我們的項(xiàng)目中，我們到底要不要把NoSQL引入到項(xiàng)目中。

在過(guò)去，我們只需要學(xué)習(xí)和使用一種數(shù)據(jù)庫(kù)技術(shù)，就能做幾乎所有的數(shù)據(jù)庫(kù)應(yīng)用開(kāi)發(fā)。因?yàn)槌墒旆€(wěn)定的關(guān)系數(shù)據(jù)庫(kù)產(chǎn)品并不是很多，而供你選擇的免費(fèi)版本就 更加少了，所以互聯(lián)網(wǎng)領(lǐng)域基本上都選擇了免費(fèi)的MySQL數(shù)據(jù)庫(kù)。在高速發(fā)展的WEB2.0時(shí)代，我們發(fā)現(xiàn)關(guān)系數(shù)據(jù)庫(kù)在性能、擴(kuò)展性、數(shù)據(jù)的快速備份和恢 復(fù)、滿(mǎn)足需求的易用性上并不總是能很好的滿(mǎn)足我們的需要，我們?cè)絹?lái)越趨向于根據(jù)業(yè)務(wù)場(chǎng)景選擇合適的數(shù)據(jù)庫(kù)，以及進(jìn)行多種數(shù)據(jù)庫(kù)的融合運(yùn)用。幾年前的一篇文 章《One Size Fits All - An Idea Whose Time Has Come and Gone》就已經(jīng)闡述了這個(gè)觀點(diǎn)。

當(dāng)我們?cè)谟懻撌欠褚褂肗oSQL的時(shí)候，你還需要理解NoSQL也是分很多種類(lèi)的，在NoSQL百花齊放的今天，NoSQL的正確選擇比選擇關(guān)系數(shù)據(jù)庫(kù)還具有挑戰(zhàn)性。雖然NoSQL的使用很簡(jiǎn)單，但是選擇卻是個(gè)麻煩事，這也正是很多人在觀望的一個(gè)原因。

六、NoSQL的分類(lèi)

NoSQL僅僅是一個(gè)概念，NoSQL數(shù)據(jù)庫(kù)根據(jù)數(shù)據(jù)的存儲(chǔ)模型和特點(diǎn)分為很多種類(lèi)。

以上NoSQL數(shù)據(jù)庫(kù)類(lèi)型的劃分并不是絕對(duì)，只是從存儲(chǔ)模型上來(lái)進(jìn)行的大體劃分。它們之間沒(méi)有絕對(duì)的分界，也有交差的情況，比如Tokyo Cabinet / Tyrant的Table類(lèi)型存儲(chǔ)，就可以理解為是文檔型存儲(chǔ)，Berkeley DB XML數(shù)據(jù)庫(kù)是基于Berkeley DB之上開(kāi)發(fā)的。

七、選擇和使用建議

雖然09年出現(xiàn)了比較激進(jìn)的文章《關(guān)系數(shù)據(jù)庫(kù)已死》，但是我們心里都清楚，關(guān)系數(shù)據(jù)庫(kù)其實(shí)還活得好好的，你還不能不用關(guān)系數(shù)據(jù)庫(kù)。但是也說(shuō)明了一個(gè)事實(shí)，關(guān)系數(shù)據(jù)庫(kù)在處理WEB2.0數(shù)據(jù)的時(shí)候，的確已經(jīng)出現(xiàn)了瓶頸。

那么我們到底是用NoSQL還是關(guān)系數(shù)據(jù)庫(kù)呢?我想我們沒(méi)有必要來(lái)進(jìn)行一個(gè)絕對(duì)的回答。我們需要根據(jù)我們的應(yīng)用場(chǎng)景來(lái)決定我們到底用什么。

如果關(guān)系數(shù)據(jù)庫(kù)在你的應(yīng)用場(chǎng)景中，完全能夠很好的工作，而你又是非常善于使用和維護(hù)關(guān)系數(shù)據(jù)庫(kù)的，那么我覺(jué)得你完全沒(méi)有必要遷移到NoSQL上面， 除非你是個(gè)喜歡折騰的人。如果你是在金融，電信等以數(shù)據(jù)為王的關(guān)鍵領(lǐng)域，目前使用的是Oracle數(shù)據(jù)庫(kù)來(lái)提供高可靠性的，除非遇到特別大的瓶頸，不然也 別貿(mào)然嘗試NoSQL。

然而，在WEB2.0的網(wǎng)站中，關(guān)系數(shù)據(jù)庫(kù)大部分都出現(xiàn)了瓶頸。在磁盤(pán)IO、數(shù)據(jù)庫(kù)可擴(kuò)展上都花費(fèi)了開(kāi)發(fā)人員相當(dāng)多的精力來(lái)優(yōu)化，比如做分表分庫(kù) (database sharding)、主從復(fù)制、異構(gòu)復(fù)制等等，然而，這些工作需要的技術(shù)能力越來(lái)越高，也越來(lái)越具有挑戰(zhàn)性。如果你正在經(jīng)歷這些場(chǎng)合，那么我覺(jué)得你應(yīng)該嘗 試一下NoSQL了。

1. 選擇合適的NoSQL

如此多類(lèi)型的NoSQL，而每種類(lèi)型的NoSQL又有很多，到底選擇什么類(lèi)型的NoSQL來(lái)作為我們的存儲(chǔ)呢?這并不是一個(gè)很好回答的問(wèn)題，影響我們選擇 的因素有很多，而選擇也可能有多種，隨著業(yè)務(wù)場(chǎng)景，需求的變更可能選擇又會(huì)變化。我們常常需要根據(jù)如下情況考慮：

• 數(shù)據(jù)結(jié)構(gòu)特點(diǎn)。包括結(jié)構(gòu)化、半結(jié)構(gòu)化、字段是否可能變更、是否有大文本字段、數(shù)據(jù)字段是否可能變化。
• 寫(xiě)入特點(diǎn)。包括insert比例、update比例、是否經(jīng)常更新數(shù)據(jù)的某一個(gè)小字段、原子更新需求。
• 查詢(xún)特點(diǎn)。包括查詢(xún)的條件、查詢(xún)熱點(diǎn)的范圍。比如用戶(hù)信息的查詢(xún)，可能就是隨機(jī)的，而新聞的查詢(xún)就是按照時(shí)間，越新的越頻繁。

2. NoSQL和關(guān)系數(shù)據(jù)庫(kù)結(jié)合

其實(shí)NoSQL數(shù)據(jù)庫(kù)僅僅是關(guān)系數(shù)據(jù)庫(kù)在某些方面(性能，擴(kuò)展)的一個(gè)彌補(bǔ)，單從功能上講，NoSQL的幾乎所有的功能，在關(guān)系數(shù)據(jù)庫(kù)上都能夠滿(mǎn)足，所以選擇NoSQL的原因并不在功能上。

所以，我們一般會(huì)把NoSQL和關(guān)系數(shù)據(jù)庫(kù)進(jìn)行結(jié)合使用，各取所長(zhǎng)，需要使用關(guān)系特性的時(shí)候我們使用關(guān)系數(shù)據(jù)庫(kù)，需要使用NoSQL特性的時(shí)候我們使用NoSQL數(shù)據(jù)庫(kù)，各得其所。

舉個(gè)簡(jiǎn)單的例子吧，比如用戶(hù)評(píng)論的存儲(chǔ)，評(píng)論大概有主鍵id、評(píng)論的對(duì)象aid、評(píng)論內(nèi)容content、用戶(hù)uid等字段。我們能確定的是評(píng)論內(nèi) 容content肯定不會(huì)在數(shù)據(jù)庫(kù)中用where content=’’查詢(xún)，評(píng)論內(nèi)容也是一個(gè)大文本字段。那么我們可以把 主鍵id、評(píng)論對(duì)象aid、用戶(hù)id存儲(chǔ)在數(shù)據(jù)庫(kù)，評(píng)論內(nèi)容存儲(chǔ)在NoSQL，這樣數(shù)據(jù)庫(kù)就節(jié)省了存儲(chǔ)content占用的磁盤(pán)空間，從而節(jié)省大量IO， 對(duì)content也更容易做Cache。

//從MySQL中查詢(xún)出評(píng)論主鍵id列表 commentIds=DB.query(“SELECT id FROM comments where aid=’評(píng)論對(duì)象id’ LIMIT 0,20”); //根據(jù)主鍵id列表，從NoSQL取回評(píng)論實(shí)體數(shù)據(jù) CommentsList=NoSQL.get(commentIds);NoSQL代替MySQL  

在某些應(yīng)用場(chǎng)合，比如一些配置的關(guān)系鍵值映射存儲(chǔ)、用戶(hù)名和密碼的存儲(chǔ)、Session會(huì)話(huà)存儲(chǔ)等等，用NoSQL完全可以替代MySQL存儲(chǔ)。不但具有更高的性能，而且開(kāi)發(fā)也更加方便。

3. NoSQL作為緩存服務(wù)器

MySQL+Memcached的架構(gòu)中，我們處處都要精心設(shè)計(jì)我們的緩存，包括過(guò)期時(shí)間的設(shè)計(jì)、緩存的實(shí)時(shí)性設(shè)計(jì)、緩存內(nèi)存大小評(píng)估、緩存命中率等等。

NoSQL數(shù)據(jù)庫(kù)一般都具有非常高的性能，在大多數(shù)場(chǎng)景下面，你不必再考慮在代碼層為NoSQL構(gòu)建一層Memcached緩存。NoSQL數(shù)據(jù)本身在Cache上已經(jīng)做了相當(dāng)多的優(yōu)化工作。

Memcached這類(lèi)內(nèi)存緩存服務(wù)器緩存的數(shù)據(jù)大小受限于內(nèi)存大小，如果用NoSQL來(lái)代替Memcached來(lái)緩存數(shù)據(jù)庫(kù)的話(huà)，就可以不再受限于內(nèi)存大小。雖然可能有少量的磁盤(pán)IO讀寫(xiě)，可能比Memcached慢一點(diǎn)，但是完全可以用來(lái)緩存數(shù)據(jù)庫(kù)的查詢(xún)操作。

【本文為51CTO專(zhuān)欄作者“大數(shù)據(jù)和云計(jì)算”的原創(chuàng)稿件，轉(zhuǎn)載請(qǐng)通過(guò)微信公眾號(hào)獲取聯(lián)系和授權(quán)】

戳這里，看該作者更多好文