建站
咨詢
售后
建站咨詢
新聞中心
高性能 NoSQL
關(guān)系數(shù)據(jù)庫(kù)經(jīng)過幾十年的發(fā)展，已經(jīng)非常成熟，但同時(shí)也存在不足：
創(chuàng)新互聯(lián)建站專注于蒲城企業(yè)網(wǎng)站建設(shè),響應(yīng)式網(wǎng)站開發(fā),商城網(wǎng)站制作。蒲城網(wǎng)站建設(shè)公司,為蒲城等地區(qū)提供建站服務(wù)。全流程定制制作，專業(yè)設(shè)計(jì)，全程項(xiàng)目跟蹤，創(chuàng)新互聯(lián)建站專業(yè)和態(tài)度為您提供的服務(wù)
表結(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類：
Redis 是典型，其 value 是具體的數(shù)據(jù)結(jié)構(gòu)，包括 string, hash, list, set, sorted set, bitmap, hyperloglog，常被稱為數(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ù)是按行來存儲(chǔ)的，列式數(shù)據(jù)庫(kù)是按照列來存儲(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ī)寫效率遠(yuǎn)低于行式存儲(chǔ)，因?yàn)樾惺酱鎯?chǔ)時(shí)同一行多個(gè)列都存儲(chǔ)在連續(xù)空間中，而列式存儲(chǔ)將不同列存儲(chǔ)在不連續(xù)的空間。
一般將列式存儲(chǔ)應(yīng)用在離線大數(shù)據(jù)分析統(tǒng)計(jì)場(chǎng)景，因?yàn)檫@時(shí)主要針對(duì)部分列進(jìn)行操作，而且數(shù)據(jù)寫入后無(wú)須更新。
關(guān)系數(shù)據(jù)庫(kù)通過索引進(jìn)行快速查詢，但在全文搜索的情景下，索引就不夠了，因?yàn)椋?/p>
假設(shè)有一個(gè)交友網(wǎng)站，信息表如下：
需要匹配性別、地點(diǎn)、語(yǔ)言列。
需要匹配性別、地點(diǎn)、愛好列。
實(shí)際搜索中，各種排列組合非常多，關(guān)系數(shù)據(jù)庫(kù)很難支持。
全文搜索引擎是使用 倒排索引 技術(shù)，建立單詞到文檔的索引，例如上面的表信息建立倒排索引：
所以特別適合根據(jù)關(guān)鍵詞來查詢文檔內(nèi)容。
上面介紹了幾種典型的NoSQL方案，及各自的適用場(chǎng)景和特點(diǎn)，您可以根據(jù)實(shí)際需求進(jìn)行選擇。
NoSQL詳解：如何找到對(duì)的技術(shù)
NoSQL，泛指非關(guān)系型的數(shù)據(jù)庫(kù)。NoSQL數(shù)據(jù)庫(kù)的產(chǎn)生就是為了解決大規(guī)模數(shù)據(jù)集合多重?cái)?shù)據(jù)種類帶來的挑戰(zhàn)，尤其是大數(shù)據(jù)應(yīng)用難題。
雖然關(guān)系型數(shù)據(jù)庫(kù)系統(tǒng)RDBMS在安裝和使用上仍然占有主要地位，但毋庸置疑，非關(guān)系型數(shù)據(jù)庫(kù)NoSQL技術(shù)已經(jīng)成為今天發(fā)展最快的數(shù)據(jù)庫(kù)技術(shù)。
NoSQL詳解：如何找到對(duì)的技術(shù)
NoSQL是對(duì)數(shù)據(jù)庫(kù)系統(tǒng)的總稱，在某種程度上，它的性能和用途可能完全不同。NoSQL一詞最早產(chǎn)生于上世紀(jì)九十年代，意思是NoSQL(沒有SQL語(yǔ)言)，后來隨著時(shí)間和技術(shù)的發(fā)展，SQL界面仍然作為處理數(shù)據(jù)的方式存在，所以NoSQL又有了新的詮釋，即NotOnlySQL(不只是SQL語(yǔ)言)。今天，NoSQL數(shù)據(jù)庫(kù)憑借著其非關(guān)系型、分布式、開源和橫向擴(kuò)展等優(yōu)勢(shì)，被認(rèn)為是下一代數(shù)據(jù)庫(kù)產(chǎn)品。
四種主要的NoSQL數(shù)據(jù)庫(kù)和它們主要的應(yīng)用場(chǎng)景
鍵值數(shù)據(jù)庫(kù)：當(dāng)數(shù)據(jù)以鍵的形式訪問時(shí)，比如通過國(guó)際標(biāo)準(zhǔn)書號(hào)ISBN找一本書，鍵值數(shù)據(jù)庫(kù)是最理想的。在這里，ISBN是鍵，書籍的其他信息就是值。必須知道鍵才能查詢，不過值是一堆無(wú)意義的數(shù)據(jù)，讀取之后必須經(jīng)過翻譯。
文檔存儲(chǔ)數(shù)據(jù)庫(kù)：該數(shù)據(jù)庫(kù)以文檔的形式管理和存儲(chǔ)數(shù)據(jù)。有點(diǎn)類似于鍵值數(shù)據(jù)庫(kù)，但文檔數(shù)據(jù)庫(kù)中的數(shù)據(jù)有結(jié)構(gòu)。與鍵值數(shù)據(jù)庫(kù)中值是一堆無(wú)意義的數(shù)據(jù)不同，文檔數(shù)據(jù)庫(kù)中數(shù)據(jù)以文檔的結(jié)構(gòu)被描述，典型的是JavaScriptObjectNotation(JSON)或XML.文檔存儲(chǔ)數(shù)據(jù)庫(kù)中的數(shù)據(jù)可以通過定義的任何模式進(jìn)行查詢，但鍵值數(shù)據(jù)庫(kù)只能通過它的鍵進(jìn)行查詢。
常見NoSQL數(shù)據(jù)庫(kù)的應(yīng)用場(chǎng)景是怎么樣的
文檔數(shù)據(jù)庫(kù) 源起：受Lotus Notes啟發(fā)。 數(shù)據(jù)模型：包含了key-value的文檔集合 例子：CouchDB, MongoDB 優(yōu)點(diǎn)：數(shù)據(jù)模型自然，編程友好，快速開發(fā)，web友好，CRUD。 圖數(shù)據(jù)庫(kù) 源起： 歐拉和圖理論。 數(shù)據(jù)模型：節(jié)點(diǎn)和關(guān)系，也可處理鍵值對(duì)。 例子：AllegroGraph, InfoGrid, Neo4j 優(yōu)點(diǎn)：解決復(fù)雜的圖問題。 關(guān)系數(shù)據(jù)庫(kù) 源起： E. F. Codd 在A Relational Model of Data for Large Shared Data Banks提出的 數(shù)據(jù)模型：各種關(guān)系 例子：VoltDB, Clustrix, MySQL 優(yōu)點(diǎn)：高性能、可擴(kuò)展的OLTP，支持SQL，物化視圖，支持事務(wù)，編程友好。 對(duì)象數(shù)據(jù)庫(kù) 源起：圖數(shù)據(jù)庫(kù)研究 數(shù)據(jù)模型：對(duì)象 例子：Objectivity, Gemstone 優(yōu)點(diǎn)：復(fù)雜對(duì)象模型，快速鍵值訪問，鍵功能訪問，以及圖數(shù)據(jù)庫(kù)的優(yōu)點(diǎn)。 Key-Value數(shù)據(jù)庫(kù) 源起：Amazon的論文 Dynamo 和 Distributed HashTables。 數(shù)據(jù)模型：鍵值對(duì) 例子：Membase, Riak 優(yōu)點(diǎn)：處理大量數(shù)據(jù)，快速處理大量讀寫請(qǐng)求。編程友好。 BigTable類型數(shù)據(jù)庫(kù) 源起：Google的論文 BigTable。 數(shù)據(jù)模型：列簇，每一行在理論上都是不同的 例子：HBase, Hypertable, Cassandra 優(yōu)點(diǎn)：處理大量數(shù)據(jù)，應(yīng)對(duì)極高寫負(fù)載，高可用，支持跨數(shù)據(jù)中心， MapReduce。 數(shù)據(jù)結(jié)構(gòu)服務(wù) 源起： ? 數(shù)據(jù)模型：字典操作，lists, sets和字符串值 例子：Redis 優(yōu)點(diǎn)：不同于以前的任何數(shù)據(jù)庫(kù) 網(wǎng)格數(shù)據(jù)庫(kù) 源起：數(shù)據(jù)網(wǎng)格和元組空間研究。 數(shù)據(jù)模型：基于空間的架構(gòu) 例子：GigaSpaces, Coherence 優(yōu)點(diǎn)：適于事務(wù)處理的高性能和高擴(kuò)展性
NoSQL應(yīng)用
而傳統(tǒng)的關(guān)系數(shù)據(jù)庫(kù)在應(yīng)付web2.0網(wǎng)站，特別是超大規(guī)模和高并發(fā)的SNS類型的web2.0純動(dòng)態(tài)網(wǎng)站已經(jīng)顯得力不從心，暴露了很多難以克服的問題，例如：
1、High performance - 對(duì)數(shù)據(jù)庫(kù)高并發(fā)讀寫的需求
web2.0網(wǎng)站要根據(jù)用戶個(gè)性化信息來實(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)次讀寫請(qǐng)求。關(guān)系數(shù)據(jù)庫(kù)應(yīng)付上萬(wàn)次SQL查詢還勉強(qiáng)頂?shù)米?，但是?yīng)付上萬(wàn)次SQL寫數(shù)據(jù)請(qǐng)求，硬盤IO就已經(jīng)無(wú)法承受了。其實(shí)對(duì)于普通的BBS網(wǎng)站，往往也存在對(duì)高并發(fā)寫請(qǐng)求的需求。
2、Huge Storage - 對(duì)海量數(shù)據(jù)的高效率存儲(chǔ)和訪問的需求
對(duì)于大型的SNS網(wǎng)站，每天用戶產(chǎn)生海量的用戶動(dòng)態(tài)，以國(guó)外的Friendfeed為例，一個(gè)月就達(dá)到了2.5億條用戶動(dòng)態(tài)，對(duì)于關(guān)系數(shù)據(jù)庫(kù)來說，在一張2.5億條記錄的表里面進(jìn)行SQL查詢，效率是極其低下乃至不可忍受的。再例如大型web網(wǎng)站的用戶登錄系統(tǒng)，例如騰訊，盛大，動(dòng)輒數(shù)以億計(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)的用戶量和訪問量與日俱增的時(shí)候，你的數(shù)據(jù)庫(kù)卻沒有辦法像web server和app server那樣簡(jiǎn)單的通過添加更多的硬件和服務(wù)節(jié)點(diǎn)來擴(kuò)展性能和負(fù)載能力。對(duì)于很多需要提供24小時(shí)不間斷服務(wù)的網(wǎng)站來說，對(duì)數(shù)據(jù)庫(kù)系統(tǒng)進(jìn)行升級(jí)和擴(kuò)展是非常痛苦的事情，往往需要停機(jī)維護(hù)和數(shù)據(jù)遷移，為什么數(shù)據(jù)庫(kù)不能通過不斷的添加服務(wù)器節(jié)點(diǎn)來實(shí)現(xiàn)擴(kuò)展呢？
在上面提到的“三高”需求面前，關(guān)系數(shù)據(jù)庫(kù)遇到了難以克服的障礙，而對(duì)于web2.0網(wǎng)站來說，關(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ì)寫一致性要求也不高。因此數(shù)據(jù)庫(kù)事務(wù)管理成了數(shù)據(jù)庫(kù)高負(fù)載下一個(gè)沉重的負(fù)擔(dān)。
2、數(shù)據(jù)庫(kù)的寫實(shí)時(shí)性和讀實(shí)時(shí)性需求
對(duì)關(guān)系數(shù)據(jù)庫(kù)來說，插入一條數(shù)據(jù)之后立刻查詢，是肯定可以讀出來這條數(shù)據(jù)的，但是對(duì)于很多web應(yīng)用來說，并不要求這么高的實(shí)時(shí)性。
3、對(duì)復(fù)雜的SQL查詢，特別是多表關(guān)聯(lián)查詢的需求
任何大數(shù)據(jù)量的web系統(tǒng)，都非常忌諱多個(gè)大表的關(guān)聯(lián)查詢，以及復(fù)雜的數(shù)據(jù)分析類型的復(fù)雜SQL報(bào)表查詢，特別是SNS類型的網(wǎng)站，從需求以及產(chǎn)品設(shè)計(jì)角度，就避免了這種情況的產(chǎn)生。往往更多的只是單表的主鍵查詢，以及單表的簡(jiǎn)單條件分頁(yè)查詢，SQL的功能被極大的弱化了。
因此，關(guān)系數(shù)據(jù)庫(kù)在這些越來越多的應(yīng)用場(chǎng)景下顯得不那么合適了，為了解決這類問題的非關(guān)系數(shù)據(jù)庫(kù)應(yīng)運(yùn)而生。
NoSQL 是非關(guān)系型數(shù)據(jù)存儲(chǔ)的廣義定義。它打破了長(zhǎng)久以來關(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ǔ)在橫向伸縮性上能夠滿足需求。而 NoSQL 存儲(chǔ)就是為了實(shí)現(xiàn)這個(gè)需求。Google 的BigTable與Amazon的Dynamo是非常成功的商業(yè) NoSQL 實(shí)現(xiàn)。一些開源的 NoSQL 體系，如Facebook 的Cassandra， Apache 的HBase，也得到了廣泛認(rèn)同。
當(dāng)前標(biāo)題：nosql有哪些應(yīng)用場(chǎng)景,nosql的應(yīng)用
URL地址：http://www.dlmjj.cn/article/dsgisgp.html
