十年網(wǎng)站開發(fā)經(jīng)驗(yàn) + 多家企業(yè)客戶 + 靠譜的建站團(tuán)隊
量身定制 + 運(yùn)營維護(hù)+專業(yè)推廣+無憂售后,網(wǎng)站問題一站解決
Web1.0的時代,數(shù)據(jù)訪問量很有限,用一夫當(dāng)關(guān)的高性能的單點(diǎn)服務(wù)器可以解決大部分問題。

創(chuàng)新互聯(lián)建站是一家專注于成都做網(wǎng)站、網(wǎng)站設(shè)計與策劃設(shè)計,鋼城網(wǎng)站建設(shè)哪家好?創(chuàng)新互聯(lián)建站做網(wǎng)站,專注于網(wǎng)站建設(shè)10多年,網(wǎng)設(shè)計領(lǐng)域的專業(yè)建站公司;建站業(yè)務(wù)涵蓋:鋼城等地區(qū)。鋼城做網(wǎng)站價格咨詢:18980820575
隨著Web2.0的時代的到來,用戶訪問量大幅度提升,同時產(chǎn)生了大量的用戶數(shù)據(jù)。加上后來的智能移動設(shè)備的普及,所有的互聯(lián)網(wǎng)平臺都面臨了巨大的性能挑戰(zhàn)。
NoSQL(NoSQL = Not Only SQL ),意即“不僅僅是SQL”,泛指非關(guān)系型的數(shù)據(jù)庫。
NoSQL 不依賴業(yè)務(wù)邏輯方式存儲,而以簡單的key-value模式存儲。因此大大的增加了數(shù)據(jù)庫的擴(kuò)展能力。
Memcache Memcache Redis Redis MongoDB MongoDB 列式數(shù)據(jù)庫 列式數(shù)據(jù)庫 Hbase Hbase
HBase是Hadoop項目中的數(shù)據(jù)庫。它用于需要對大量的數(shù)據(jù)進(jìn)行隨機(jī)、實(shí)時的讀寫操作的場景中。
HBase的目標(biāo)就是處理數(shù)據(jù)量非常龐大的表,可以用普通的計算機(jī)處理超過10億行數(shù)據(jù),還可處理有數(shù)百萬列元素的數(shù)據(jù)表。
Cassandra Cassandra
Apache Cassandra是一款免費(fèi)的開源NoSQL數(shù)據(jù)庫,其設(shè)計目的在于管理由大量商用服務(wù)器構(gòu)建起來的龐大集群上的海量數(shù)據(jù)集(數(shù)據(jù)量通常達(dá)到PB級別)。在眾多顯著特性當(dāng)中,Cassandra最為卓越的長處是對寫入及讀取操作進(jìn)行規(guī)模調(diào)整,而且其不強(qiáng)調(diào)主集群的設(shè)計思路能夠以相對直觀的方式簡化各集群的創(chuàng)建與擴(kuò)展流程。
主要應(yīng)用:社會關(guān)系,公共交通網(wǎng)絡(luò),地圖及網(wǎng)絡(luò)拓譜(n*(n-1)/2)
而傳統(tǒng)的關(guān)系數(shù)據(jù)庫在應(yīng)付web2.0網(wǎng)站,特別是超大規(guī)模和高并發(fā)的SNS類型的web2.0純動態(tài)網(wǎng)站已經(jīng)顯得力不從心,暴露了很多難以克服的問題,例如:
1、High performance - 對數(shù)據(jù)庫高并發(fā)讀寫的需求
web2.0網(wǎng)站要根據(jù)用戶個性化信息來實(shí)時生成動態(tài)頁面和提供動態(tài)信息,所以基本上無法使用動態(tài)頁面靜態(tài)化技術(shù),因此數(shù)據(jù)庫并發(fā)負(fù)載非常高,往往要達(dá)到每秒上萬次讀寫請求。關(guān)系數(shù)據(jù)庫應(yīng)付上萬次SQL查詢還勉強(qiáng)頂?shù)米?,但是?yīng)付上萬次SQL寫數(shù)據(jù)請求,硬盤IO就已經(jīng)無法承受了。其實(shí)對于普通的BBS網(wǎng)站,往往也存在對高并發(fā)寫請求的需求。
2、Huge Storage - 對海量數(shù)據(jù)的高效率存儲和訪問的需求
對于大型的SNS網(wǎng)站,每天用戶產(chǎn)生海量的用戶動態(tài),以國外的Friendfeed為例,一個月就達(dá)到了2.5億條用戶動態(tài),對于關(guān)系數(shù)據(jù)庫來說,在一張2.5億條記錄的表里面進(jìn)行SQL查詢,效率是極其低下乃至不可忍受的。再例如大型web網(wǎng)站的用戶登錄系統(tǒng),例如騰訊,盛大,動輒數(shù)以億計的帳號,關(guān)系數(shù)據(jù)庫也很難應(yīng)付。
3、High Scalability High Availability- 對數(shù)據(jù)庫的高可擴(kuò)展性和高可用性的需求
在基于web的架構(gòu)當(dāng)中,數(shù)據(jù)庫是最難進(jìn)行橫向擴(kuò)展的,當(dāng)一個應(yīng)用系統(tǒng)的用戶量和訪問量與日俱增的時候,你的數(shù)據(jù)庫卻沒有辦法像web server和app server那樣簡單的通過添加更多的硬件和服務(wù)節(jié)點(diǎn)來擴(kuò)展性能和負(fù)載能力。對于很多需要提供24小時不間斷服務(wù)的網(wǎng)站來說,對數(shù)據(jù)庫系統(tǒng)進(jìn)行升級和擴(kuò)展是非常痛苦的事情,往往需要停機(jī)維護(hù)和數(shù)據(jù)遷移,為什么數(shù)據(jù)庫不能通過不斷的添加服務(wù)器節(jié)點(diǎn)來實(shí)現(xiàn)擴(kuò)展呢?
在上面提到的“三高”需求面前,關(guān)系數(shù)據(jù)庫遇到了難以克服的障礙,而對于web2.0網(wǎng)站來說,關(guān)系數(shù)據(jù)庫的很多主要特性卻往往無用武之地,例如:
1、數(shù)據(jù)庫事務(wù)一致性需求
很多web實(shí)時系統(tǒng)并不要求嚴(yán)格的數(shù)據(jù)庫事務(wù),對讀一致性的要求很低,有些場合對寫一致性要求也不高。因此數(shù)據(jù)庫事務(wù)管理成了數(shù)據(jù)庫高負(fù)載下一個沉重的負(fù)擔(dān)。
2、數(shù)據(jù)庫的寫實(shí)時性和讀實(shí)時性需求
對關(guān)系數(shù)據(jù)庫來說,插入一條數(shù)據(jù)之后立刻查詢,是肯定可以讀出來這條數(shù)據(jù)的,但是對于很多web應(yīng)用來說,并不要求這么高的實(shí)時性。
3、對復(fù)雜的SQL查詢,特別是多表關(guān)聯(lián)查詢的需求
任何大數(shù)據(jù)量的web系統(tǒng),都非常忌諱多個大表的關(guān)聯(lián)查詢,以及復(fù)雜的數(shù)據(jù)分析類型的復(fù)雜SQL報表查詢,特別是SNS類型的網(wǎng)站,從需求以及產(chǎn)品設(shè)計角度,就避免了這種情況的產(chǎn)生。往往更多的只是單表的主鍵查詢,以及單表的簡單條件分頁查詢,SQL的功能被極大的弱化了。
因此,關(guān)系數(shù)據(jù)庫在這些越來越多的應(yīng)用場景下顯得不那么合適了,為了解決這類問題的非關(guān)系數(shù)據(jù)庫應(yīng)運(yùn)而生。
NoSQL 是非關(guān)系型數(shù)據(jù)存儲的廣義定義。它打破了長久以來關(guān)系型數(shù)據(jù)庫與ACID理論大一統(tǒng)的局面。NoSQL 數(shù)據(jù)存儲不需要固定的表結(jié)構(gòu),通常也不存在連接操作。在大數(shù)據(jù)存取上具備關(guān)系型數(shù)據(jù)庫無法比擬的性能優(yōu)勢。該術(shù)語在 2009 年初得到了廣泛認(rèn)同。
當(dāng)今的應(yīng)用體系結(jié)構(gòu)需要數(shù)據(jù)存儲在橫向伸縮性上能夠滿足需求。而 NoSQL 存儲就是為了實(shí)現(xiàn)這個需求。Google 的BigTable與Amazon的Dynamo是非常成功的商業(yè) NoSQL 實(shí)現(xiàn)。一些開源的 NoSQL 體系,如Facebook 的Cassandra, Apache 的HBase,也得到了廣泛認(rèn)同。
nosql數(shù)據(jù)庫的四種類型如下:
1.key-value鍵值存儲數(shù)據(jù)庫:
相關(guān)產(chǎn)品: Redis、Riak、SimpleDB、Chordless、Scalaris、Memcached.
主要應(yīng)用: 內(nèi)容緩存,處理大量數(shù)據(jù)的高負(fù)載訪問,也用于系統(tǒng)日志。
優(yōu)點(diǎn):查找速度快,大量操作時性能高。
2.列存儲數(shù)據(jù)庫:
相關(guān)產(chǎn)品: BigTable、HBase、Cassandra、HadoopDB、GreenPlum、PNUTS.
主要應(yīng)用: 分布式數(shù)據(jù)的儲存與管理。
優(yōu)點(diǎn):查找速度快,可擴(kuò)展性強(qiáng),容易進(jìn)行分布式擴(kuò)展。
缺點(diǎn):功能相對局限。
3.文檔型數(shù)據(jù)庫
相關(guān)產(chǎn)品:MongoDB、CouchDB、ThruDB、CloudKit、Perservere、Jackrabbit.
主要應(yīng)用: web應(yīng)用,管理面向文檔的數(shù)據(jù)或者類似的半結(jié)構(gòu)化數(shù)據(jù)。
優(yōu)點(diǎn):數(shù)據(jù)結(jié)構(gòu)靈活,表結(jié)構(gòu)可變,復(fù)雜性低。
缺點(diǎn):查詢效率低,且缺乏統(tǒng)一的查詢語言。
4.Graph圖形數(shù)據(jù)庫
相關(guān)產(chǎn)品: Neo4J、OrientDB、InfoGrid、GraphDB.
主要應(yīng)用: 復(fù)雜,互連接,低結(jié)構(gòu)化的圖結(jié)構(gòu)場合, 專注構(gòu)建關(guān)系圖譜。
優(yōu)點(diǎn): 利用圖結(jié)構(gòu)相關(guān)算法, 可用于構(gòu)建復(fù)雜的關(guān)系圖譜。
缺點(diǎn): 復(fù)雜度高。
文檔數(shù)據(jù)庫
源起:受Lotus Notes啟發(fā)。
數(shù)據(jù)模型:包含了key-value的文檔集合
例子:CouchDB, MongoDB
優(yōu)點(diǎn):數(shù)據(jù)模型自然,編程友好,快速開發(fā),web友好,CRUD。
圖數(shù)據(jù)庫
源起: 歐拉和圖理論。
數(shù)據(jù)模型:節(jié)點(diǎn)和關(guān)系,也可處理鍵值對。
例子:AllegroGraph, InfoGrid, Neo4j
優(yōu)點(diǎn):解決復(fù)雜的圖問題。
關(guān)系數(shù)據(jù)庫
源起: 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ù),編程友好。
對象數(shù)據(jù)庫
源起:圖數(shù)據(jù)庫研究
數(shù)據(jù)模型:對象
例子:Objectivity, Gemstone
優(yōu)點(diǎn):復(fù)雜對象模型,快速鍵值訪問,鍵功能訪問,以及圖數(shù)據(jù)庫的優(yōu)點(diǎn)。
Key-Value數(shù)據(jù)庫
源起:Amazon的論文 Dynamo 和 Distributed HashTables。
數(shù)據(jù)模型:鍵值對
例子:Membase, Riak
優(yōu)點(diǎn):處理大量數(shù)據(jù),快速處理大量讀寫請求。編程友好。
BigTable類型數(shù)據(jù)庫
源起:Google的論文 BigTable。
數(shù)據(jù)模型:列簇,每一行在理論上都是不同的
例子:HBase, Hypertable, Cassandra
優(yōu)點(diǎn):處理大量數(shù)據(jù),應(yīng)對極高寫負(fù)載,高可用,支持跨數(shù)據(jù)中心, MapReduce。
數(shù)據(jù)結(jié)構(gòu)服務(wù)
源起: ?
數(shù)據(jù)模型:字典操作,lists, sets和字符串值
例子:Redis
優(yōu)點(diǎn):不同于以前的任何數(shù)據(jù)庫
網(wǎng)格數(shù)據(jù)庫
源起:數(shù)據(jù)網(wǎng)格和元組空間研究。
數(shù)據(jù)模型:基于空間的架構(gòu)
例子:GigaSpaces, Coherence
優(yōu)點(diǎn):適于事務(wù)處理的高性能和高擴(kuò)展性