日韩无码专区无码一级三级片|91人人爱网站中日韩无码电影|厨房大战丰满熟妇|AV高清无码在线免费观看|另类AV日韩少妇熟女|中文日本大黄一级黄色片|色情在线视频免费|亚洲成人特黄a片|黄片wwwav色图欧美|欧亚乱色一区二区三区

RELATEED CONSULTING
相關(guān)咨詢
選擇下列產(chǎn)品馬上在線溝通
服務(wù)時(shí)間：8:30-17:00
你可能遇到了下面的問題
關(guān)閉右側(cè)工具欄

新聞中心

這里有您想知道的互聯(lián)網(wǎng)營(yíng)銷解決方案
SQLvsNoSQL：數(shù)據(jù)庫(kù)并發(fā)寫入性能比拼

最近聽說了很多關(guān)于NoSQL的新聞，比如之前Sourceforge改用MongoDB，Digg改用Cassandra等等。再加上之前做數(shù)據(jù)庫(kù)比較時(shí)有人推薦我mongodb，所以也搜索了一下NoSQL，覺得NoSQL可能真的是未來的趨勢(shì)。

成都創(chuàng)新互聯(lián)專注于網(wǎng)站建設(shè)|成都網(wǎng)站改版|優(yōu)化|托管以及網(wǎng)絡(luò)推廣，積累了大量的網(wǎng)站設(shè)計(jì)與制作經(jīng)驗(yàn)，為許多企業(yè)提供了網(wǎng)站定制設(shè)計(jì)服務(wù)，案例作品覆蓋成都濕噴機(jī)等行業(yè)。能根據(jù)企業(yè)所處的行業(yè)與銷售的產(chǎn)品，結(jié)合品牌形象的塑造，量身開發(fā)品質(zhì)網(wǎng)站。

NoSQL vs SQL

傳統(tǒng)SQL數(shù)據(jù)庫(kù)為了實(shí)現(xiàn)ACID(atomicity, consistency, isolation, durability)，往往需要頻繁應(yīng)用文件鎖，這使得其在現(xiàn)代的web2.0應(yīng)用中越來越捉襟見肘?，F(xiàn)在SNS網(wǎng)站每一個(gè)點(diǎn)擊都是一條/多條查詢，對(duì)數(shù)據(jù)庫(kù)寫的并發(fā)要求非常之高，而傳統(tǒng)數(shù)據(jù)庫(kù)無法很好地應(yīng)對(duì)這種需求。而仔細(xì)想來SNS中大部分需求并不要求ACID，比如Like/Unlike投票等等。

NoSQL吸取了教訓(xùn)，比如有些NoSQL采用了eventually consistency的概念，在沒有Update操作一段時(shí)間后，數(shù)據(jù)庫(kù)將最終是consistency的，顯然這樣的數(shù)據(jù)庫(kù)將能更好的支持高并發(fā)讀寫。

SQL數(shù)據(jù)庫(kù)是基于schema的，這對(duì)時(shí)時(shí)刻刻更新著的web2.0應(yīng)用開發(fā)者來說是個(gè)噩夢(mèng)：隨時(shí)隨地有新的應(yīng)用出現(xiàn)，舊的數(shù)據(jù)庫(kù)無法適應(yīng)新的應(yīng)用，只能不停地更新schema，或者做補(bǔ)丁表，如此一來要么schema越發(fā)混亂，要么就是數(shù)據(jù)庫(kù)頻繁升級(jí)而耗時(shí)耗力耗錢。

NoSQL一般就沒有schema這種概念，大部分NoSQL都直接保存json類的Row，比如一個(gè)記錄可以是{ id = 1, name = Bob, phone = 38492839 }，這樣擴(kuò)展升級(jí)非常方便，比如需要地址信息直接加入 address=blahblah 即可。

傳統(tǒng)SQL很難進(jìn)行分布式應(yīng)用，即使可以也往往代價(jià)高昂。而NoSQL則很好地解決了這個(gè)問題：他們一般都直接從分布式系統(tǒng)中吸取了Map/Reduce方法，從而很容易就可以處理規(guī)模急速增加的問題。

推薦robbin牛的NoSQL數(shù)據(jù)庫(kù)探討之一 -為什么要用非關(guān)系數(shù)據(jù)庫(kù)?一文，介紹了主流的一些NoSQL系統(tǒng)，還有這個(gè)站http://nosql-database.org/收集了基本上目前所有的NoSQL系統(tǒng)。

總結(jié)一下我對(duì)NoSQL的看法，NoSQL出現(xiàn)的目的就是為了解決高并發(fā)讀寫的問題，而高并發(fā)應(yīng)用往往需要分布式的數(shù)據(jù)庫(kù)來實(shí)現(xiàn)高性能和高可靠性，所以NoSQL的關(guān)鍵字就是concurrency和scalability。

我的瓶頸

我之前主要關(guān)注數(shù)據(jù)庫(kù)的select性能也就是read性能，在讀性能方面SQL數(shù)據(jù)庫(kù)并沒有明顯的劣勢(shì)，應(yīng)該說純粹高并發(fā)讀的性能的話往往要優(yōu)于NoSQL數(shù)據(jù)庫(kù)，然而一旦涉及寫，事情就不一樣了。

我本來以為自己不會(huì)遇到大量寫的問題，后來發(fā)現(xiàn)即使在simplecd這種簡(jiǎn)單的應(yīng)用環(huán)境下也會(huì)產(chǎn)生大量的并發(fā)寫：這就是爬VC用戶評(píng)論的時(shí)候。事實(shí)上，sqlite3在處理這個(gè)問題上非常的力不從心，所以我產(chǎn)生了換個(gè)數(shù)據(jù)庫(kù)的想法。

既然我是要求能高并發(fā)讀寫，干脆就不用SQL了，但是同時(shí)我也想測(cè)試一下其他SQL的寫性能。

我的數(shù)據(jù)有180萬條，總共350M，測(cè)試用了10個(gè)線程，每個(gè)線程做若干次100個(gè)數(shù)據(jù)的bulk寫入，然后記錄總共耗時(shí)。結(jié)果如下:

  • innodb: 15.19
  • myiasm: 14.34
  • pgsql: 23.41
  • sqlite3: 鎖住了
  • sqlite3(單線程): 300+
  • mongodb: 3.82
  • couchdb: 90
  • couchdb(單線程):66

作為一個(gè)MySQL黑，看到這組測(cè)試數(shù)據(jù)我表示壓力很大。在SQL數(shù)據(jù)庫(kù)中，mysql意外地取得了***的成績(jī)，好于pgsql，遠(yuǎn)好于sqlite。更令人意外的是myisam居然優(yōu)于號(hào)稱insert比較快的innodb。不管如何，對(duì)我的應(yīng)用來說，用mysql保存評(píng)論數(shù)據(jù)是一個(gè)更為明智的選擇。我對(duì)mysql徹底改觀了，我宣布我是mysql半黑。以后select-intensive的應(yīng)用我還是會(huì)選擇sqlite，但是 insert/update-intensive的應(yīng)用我就會(huì)改用mysql了。

MongoDB和CouchDB同為NoSQL，表現(xiàn)卻截然相反，MongoDB性能很高，CouchDB的并發(fā)性能我只能ORZ，這種性能實(shí)在太抱歉了。

NoSQL的碎碎念

其實(shí)我本來還打算測(cè)試cassandra的，可是cassandra用的是java，這首先讓我眉頭一皺，內(nèi)存大戶我養(yǎng)不起啊，其次看了 cassandra的文檔，立刻崩潰，這簡(jiǎn)直就是沒有文檔么。(BTW，CouchDB也好不到哪里去，我都是用python-couchdb然后 help(couchdb.client)看用法的)

至于CouchDB，可能是因?yàn)椴捎胔ttp方式發(fā)送請(qǐng)求，所以并發(fā)性能糟糕的一塌糊涂，很懷疑它是否有存在的理由。

MongoDB是我用下來最討人喜歡的一個(gè)NoSQL。不但文檔豐富，使用簡(jiǎn)單，性能也非常好，它的Map/Reduce查詢(很多NoSQL都有)讓我驚嘆，數(shù)據(jù)庫(kù)可以非常簡(jiǎn)單地就擴(kuò)大規(guī)模，完全不用理會(huì)什么分區(qū)分表之類繁瑣的問題，可惜這方面我暫時(shí)沒有需求。但是MongoDB有兩大致命問題。

***是刪除鎖定問題，當(dāng)批量刪除記錄時(shí)，數(shù)據(jù)庫(kù)還是會(huì)鎖定不讓讀寫。這意味著進(jìn)行數(shù)據(jù)清理時(shí)會(huì)讓網(wǎng)站應(yīng)用失去響應(yīng)。見locking problems

第二是內(nèi)存占用問題，MongoDB用了操作系統(tǒng)的內(nèi)存文件映射，這導(dǎo)致操作系統(tǒng)會(huì)把所有空閑內(nèi)存都分配給MongoDB，當(dāng)MongoDB有這個(gè)需要時(shí)。更可怕的是，MongoDB從來不主動(dòng)釋放已經(jīng)霸占的內(nèi)存，它只會(huì)滾雪球一樣越滾越大，除非重啟數(shù)據(jù)庫(kù)。這樣的上下文環(huán)境下，MongoDB只適合一臺(tái)主機(jī)就一個(gè)數(shù)據(jù)庫(kù)，而沒有其他應(yīng)用的環(huán)境，否則一會(huì)兒功夫MongoDB就會(huì)吃光內(nèi)存，然后你都fork不出新進(jìn)程，徹底悲劇。見memory limit

總之NoSQL雖然讓我眼前一亮，可是目前嘗試的一些產(chǎn)品都讓人望而生畏，現(xiàn)在的NoSQL都把目光放在了巨型網(wǎng)站上，而沒有一個(gè)小型的，可以在VPS里面應(yīng)用的高性能NoSQL，令我有點(diǎn)失望。NoSQL尚未成熟，很期待它的將來發(fā)展，目前來說MySQL還是更好的選擇。

原文鏈接：http://blog.sina.com.cn/s/blog_872edce20100te9t.html

【編輯推薦】

  1. NoSQL數(shù)據(jù)庫(kù)對(duì)比：MongoDB vs.Cassandra
  2. CouchDB和SQLite聯(lián)合推出NoSQL查詢語言
  3. Java開源NoSQL數(shù)據(jù)庫(kù)大全
  4. SQL到NOSQL的思維轉(zhuǎn)變

分享題目：SQLvsNoSQL：數(shù)據(jù)庫(kù)并發(fā)寫入性能比拼
URL地址：http://www.5511xx.com/article/dpogcjd.html