而傳統(tǒng)的關(guān)系數(shù)據(jù)庫(kù)在應(yīng)付web2.0網(wǎng)站,特別是超大規(guī)模和高并發(fā)的SNS類(lèi)型的web2.0純動(dòng)態(tài)網(wǎng)站已經(jīng)顯得力不從心,暴露了很多難以克服的問(wèn)題,例如:

將樂(lè)網(wǎng)站建設(shè)公司創(chuàng)新互聯(lián)公司,將樂(lè)網(wǎng)站設(shè)計(jì)制作,有大型網(wǎng)站制作公司豐富經(jīng)驗(yàn)。已為將樂(lè)上1000+提供企業(yè)網(wǎng)站建設(shè)服務(wù)。企業(yè)網(wǎng)站搭建\成都外貿(mào)網(wǎng)站建設(shè)要多少錢(qián),請(qǐng)找那個(gè)售后服務(wù)好的將樂(lè)做網(wǎng)站的公司定做!
1、High performance - 對(duì)數(shù)據(jù)庫(kù)高并發(fā)讀寫(xiě)的需求
web2.0網(wǎng)站要根據(jù)用戶(hù)個(gè)性化信息來(lái)實(shí)時(shí)生成動(dòng)態(tài)頁(yè)面和提供動(dòng)態(tài)信息,所以基本上無(wú)法使用動(dòng)態(tài)頁(yè)面靜態(tài)化技術(shù),因此數(shù)據(jù)庫(kù)并發(fā)負(fù)載非常高,往往要達(dá)到每秒上萬(wàn)次讀寫(xiě)請(qǐng)求。關(guān)系數(shù)據(jù)庫(kù)應(yīng)付上萬(wàn)次SQL查詢(xún)還勉強(qiáng)頂?shù)米。菓?yīng)付上萬(wàn)次SQL寫(xiě)數(shù)據(jù)請(qǐng)求,硬盤(pán)IO就已經(jīng)無(wú)法承受了。其實(shí)對(duì)于普通的BBS網(wǎng)站,往往也存在對(duì)高并發(fā)寫(xiě)請(qǐng)求的需求。
2、Huge Storage - 對(duì)海量數(shù)據(jù)的高效率存儲(chǔ)和訪(fǎng)問(wèn)的需求
對(duì)于大型的SNS網(wǎng)站,每天用戶(hù)產(chǎn)生海量的用戶(hù)動(dòng)態(tài),以國(guó)外的Friendfeed為例,一個(gè)月就達(dá)到了2.5億條用戶(hù)動(dòng)態(tài),對(duì)于關(guān)系數(shù)據(jù)庫(kù)來(lái)說(shuō),在一張2.5億條記錄的表里面進(jìn)行SQL查詢(xún),效率是極其低下乃至不可忍受的。再例如大型web網(wǎng)站的用戶(hù)登錄系統(tǒng),例如騰訊,盛大,動(dòng)輒數(shù)以?xún)|計(jì)的帳號(hào),關(guān)系數(shù)據(jù)庫(kù)也很難應(yīng)付。
3、High Scalability High Availability- 對(duì)數(shù)據(jù)庫(kù)的高可擴(kuò)展性和高可用性的需求
在基于web的架構(gòu)當(dāng)中,數(shù)據(jù)庫(kù)是最難進(jìn)行橫向擴(kuò)展的,當(dāng)一個(gè)應(yīng)用系統(tǒng)的用戶(hù)量和訪(fǎng)問(wèn)量與日俱增的時(shí)候,你的數(shù)據(jù)庫(kù)卻沒(méi)有辦法像web server和app server那樣簡(jiǎn)單的通過(guò)添加更多的硬件和服務(wù)節(jié)點(diǎn)來(lái)擴(kuò)展性能和負(fù)載能力。對(duì)于很多需要提供24小時(shí)不間斷服務(wù)的網(wǎng)站來(lái)說(shuō),對(duì)數(shù)據(jù)庫(kù)系統(tǒng)進(jìn)行升級(jí)和擴(kuò)展是非常痛苦的事情,往往需要停機(jī)維護(hù)和數(shù)據(jù)遷移,為什么數(shù)據(jù)庫(kù)不能通過(guò)不斷的添加服務(wù)器節(jié)點(diǎn)來(lái)實(shí)現(xiàn)擴(kuò)展呢?
在上面提到的“三高”需求面前,關(guān)系數(shù)據(jù)庫(kù)遇到了難以克服的障礙,而對(duì)于web2.0網(wǎng)站來(lái)說(shuō),關(guān)系數(shù)據(jù)庫(kù)的很多主要特性卻往往無(wú)用武之地,例如:
1、數(shù)據(jù)庫(kù)事務(wù)一致性需求
很多web實(shí)時(shí)系統(tǒng)并不要求嚴(yán)格的數(shù)據(jù)庫(kù)事務(wù),對(duì)讀一致性的要求很低,有些場(chǎng)合對(duì)寫(xiě)一致性要求也不高。因此數(shù)據(jù)庫(kù)事務(wù)管理成了數(shù)據(jù)庫(kù)高負(fù)載下一個(gè)沉重的負(fù)擔(dān)。
2、數(shù)據(jù)庫(kù)的寫(xiě)實(shí)時(shí)性和讀實(shí)時(shí)性需求
對(duì)關(guān)系數(shù)據(jù)庫(kù)來(lái)說(shuō),插入一條數(shù)據(jù)之后立刻查詢(xún),是肯定可以讀出來(lái)這條數(shù)據(jù)的,但是對(duì)于很多web應(yīng)用來(lái)說(shuō),并不要求這么高的實(shí)時(shí)性。
3、對(duì)復(fù)雜的SQL查詢(xún),特別是多表關(guān)聯(lián)查詢(xún)的需求
任何大數(shù)據(jù)量的web系統(tǒng),都非常忌諱多個(gè)大表的關(guān)聯(lián)查詢(xún),以及復(fù)雜的數(shù)據(jù)分析類(lèi)型的復(fù)雜SQL報(bào)表查詢(xún),特別是SNS類(lèi)型的網(wǎng)站,從需求以及產(chǎn)品設(shè)計(jì)角度,就避免了這種情況的產(chǎn)生。往往更多的只是單表的主鍵查詢(xún),以及單表的簡(jiǎn)單條件分頁(yè)查詢(xún),SQL的功能被極大的弱化了。
因此,關(guān)系數(shù)據(jù)庫(kù)在這些越來(lái)越多的應(yīng)用場(chǎng)景下顯得不那么合適了,為了解決這類(lèi)問(wèn)題的非關(guān)系數(shù)據(jù)庫(kù)應(yīng)運(yùn)而生。
NoSQL 是非關(guān)系型數(shù)據(jù)存儲(chǔ)的廣義定義。它打破了長(zhǎng)久以來(lái)關(guān)系型數(shù)據(jù)庫(kù)與ACID理論大一統(tǒng)的局面。NoSQL 數(shù)據(jù)存儲(chǔ)不需要固定的表結(jié)構(gòu),通常也不存在連接操作。在大數(shù)據(jù)存取上具備關(guān)系型數(shù)據(jù)庫(kù)無(wú)法比擬的性能優(yōu)勢(shì)。該術(shù)語(yǔ)在 2009 年初得到了廣泛認(rèn)同。
當(dāng)今的應(yīng)用體系結(jié)構(gòu)需要數(shù)據(jù)存儲(chǔ)在橫向伸縮性上能夠滿(mǎn)足需求。而 NoSQL 存儲(chǔ)就是為了實(shí)現(xiàn)這個(gè)需求。Google 的BigTable與Amazon的Dynamo是非常成功的商業(yè) NoSQL 實(shí)現(xiàn)。一些開(kāi)源的 NoSQL 體系,如Facebook 的Cassandra, Apache 的HBase,也得到了廣泛認(rèn)同。
因?yàn)樗俣瓤臁D闵蟽|級(jí)數(shù)據(jù)的情況下NOSQL是比普通SQL效率更高,哪怕有索引。畢竟NOSQL的存儲(chǔ)空間使用是普通SQL三倍多。基本都用在索引方面了。
如果是全文搜索關(guān)鍵字,左右模糊等就更甩SQL幾條街了
nosql速度快,但是完成不了關(guān)系數(shù)據(jù)庫(kù)的復(fù)雜邏輯
sql功能強(qiáng)大,但是效率上有瓶頸
看項(xiàng)目大小取舍
因?yàn)樗饕唷M粭l個(gè)數(shù)據(jù),NOSQL占用空間是一般SQL數(shù)據(jù)庫(kù)的3-5倍。
你可以理解成NOSQL默認(rèn)開(kāi)啟全字段索引和全文索引什么的。
其實(shí)在十萬(wàn)級(jí)以下的數(shù)據(jù),只要SQL建好索引的情況并不比NOSQL慢。NOSQL主要是用于千萬(wàn)上億級(jí)的時(shí)候。
關(guān)系數(shù)據(jù)庫(kù)經(jīng)過(guò)幾十年的發(fā)展,已經(jīng)非常成熟,但同時(shí)也存在不足:
表結(jié)構(gòu)是強(qiáng)約束的,業(yè)務(wù)變更時(shí)擴(kuò)充很麻煩。
如果對(duì)大數(shù)據(jù)量的表進(jìn)行統(tǒng)計(jì)運(yùn)算,I/O會(huì)很高,因?yàn)榧词怪会槍?duì)某列進(jìn)行運(yùn)算,也需要將整行數(shù)據(jù)讀入內(nèi)存。
全文搜索只能使用 Like 進(jìn)行整表掃描,性能非常低。
針對(duì)這些不足,產(chǎn)生了不同的 NoSQL 解決方案,在某些場(chǎng)景下比關(guān)系數(shù)據(jù)庫(kù)更有優(yōu)勢(shì),但同時(shí)也犧牲了某些特性,所以不能片面的迷信某種方案,應(yīng)將其作為 SQL 的有利補(bǔ)充。
NoSQL != No SQL,而是:
NoSQL = Not Only SQL
典型的 NoSQL 方案分為4類(lèi):
Redis 是典型,其 value 是具體的數(shù)據(jù)結(jié)構(gòu),包括 string, hash, list, set, sorted set, bitmap, hyperloglog,常被稱(chēng)為數(shù)據(jù)結(jié)構(gòu)服務(wù)器。
以 list 為例:
LPOP key 是移除并返回隊(duì)列左邊的第一個(gè)元素。
如果用關(guān)系數(shù)據(jù)庫(kù)就比較麻煩了,需要操作:
Redis 的缺點(diǎn)主要體現(xiàn)在不支持完成的ACID事務(wù),只能保證隔離性和一致性,無(wú)法保證原子性和持久性。
最大的特點(diǎn)是 no-schema,無(wú)需在使用前定義字段,讀取一個(gè)不存在的字段也不會(huì)導(dǎo)致語(yǔ)法錯(cuò)誤。
特點(diǎn):
以電商為例,不同商品的屬性差異很大,如冰箱和電腦,這種差異性在關(guān)系數(shù)據(jù)庫(kù)中會(huì)有很大的麻煩,而使用文檔數(shù)據(jù)庫(kù)則非常方便。
文檔數(shù)據(jù)庫(kù)的主要缺點(diǎn):
關(guān)系數(shù)據(jù)庫(kù)是按行來(lái)存儲(chǔ)的,列式數(shù)據(jù)庫(kù)是按照列來(lái)存儲(chǔ)數(shù)據(jù)。
按行存儲(chǔ)的優(yōu)勢(shì):
在某些場(chǎng)景下,這些優(yōu)勢(shì)就成為劣勢(shì)了,例如,計(jì)算超重人員的數(shù)據(jù),只需要讀取體重這一列進(jìn)行統(tǒng)計(jì)即可,但行式存儲(chǔ)會(huì)將整行數(shù)據(jù)讀取到內(nèi)存中,很浪費(fèi)。
而列式存儲(chǔ)中,只需要讀取體重這列的數(shù)據(jù)即可,I/O 將大大減少。
除了節(jié)省I/O,列式存儲(chǔ)還有更高的壓縮比,可以節(jié)省存儲(chǔ)空間。普通行式數(shù)據(jù)庫(kù)的壓縮比在 3:1 到 5:1 左右,列式數(shù)據(jù)庫(kù)在 8:1 到 30:1,因?yàn)閱蝹€(gè)列的數(shù)據(jù)相似度更高。
列式存儲(chǔ)的隨機(jī)寫(xiě)效率遠(yuǎn)低于行式存儲(chǔ),因?yàn)樾惺酱鎯?chǔ)時(shí)同一行多個(gè)列都存儲(chǔ)在連續(xù)空間中,而列式存儲(chǔ)將不同列存儲(chǔ)在不連續(xù)的空間。
一般將列式存儲(chǔ)應(yīng)用在離線(xiàn)大數(shù)據(jù)分析統(tǒng)計(jì)場(chǎng)景,因?yàn)檫@時(shí)主要針對(duì)部分列進(jìn)行操作,而且數(shù)據(jù)寫(xiě)入后無(wú)須更新。
關(guān)系數(shù)據(jù)庫(kù)通過(guò)索引進(jìn)行快速查詢(xún),但在全文搜索的情景下,索引就不夠了,因?yàn)椋?/p>
假設(shè)有一個(gè)交友網(wǎng)站,信息表如下:
需要匹配性別、地點(diǎn)、語(yǔ)言列。
需要匹配性別、地點(diǎn)、愛(ài)好列。
實(shí)際搜索中,各種排列組合非常多,關(guān)系數(shù)據(jù)庫(kù)很難支持。
全文搜索引擎是使用 倒排索引 技術(shù),建立單詞到文檔的索引,例如上面的表信息建立倒排索引:
所以特別適合根據(jù)關(guān)鍵詞來(lái)查詢(xún)文檔內(nèi)容。
上面介紹了幾種典型的NoSQL方案,及各自的適用場(chǎng)景和特點(diǎn),您可以根據(jù)實(shí)際需求進(jìn)行選擇。
當(dāng)前名稱(chēng):nosql效率,nosql的優(yōu)勢(shì)
路徑分享:http://chinadenli.net/article41/dsedohd.html
成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供網(wǎng)頁(yè)設(shè)計(jì)公司、做網(wǎng)站、手機(jī)網(wǎng)站建設(shè)、軟件開(kāi)發(fā)、搜索引擎優(yōu)化、品牌網(wǎng)站設(shè)計(jì)
聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶(hù)投稿、用戶(hù)轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請(qǐng)盡快告知,我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng),如需處理請(qǐng)聯(lián)系客服。電話(huà):028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時(shí)需注明來(lái)源: 創(chuàng)新互聯(lián)