真实的国产乱ⅩXXX66竹夫人,五月香六月婷婷激情综合,亚洲日本VA一区二区三区,亚洲精品一区二区三区麻豆

成都創(chuàng)新互聯(lián)網(wǎng)站制作重慶分公司

簡述NoSQL興起的原因,NoSQL數(shù)據(jù)庫具有以下幾個特點

什么是NoSQL數(shù)據(jù)庫?

2. 什么是NoSQL?

創(chuàng)新互聯(lián)是專業(yè)的興隆臺網(wǎng)站建設(shè)公司,興隆臺接單;提供成都做網(wǎng)站、網(wǎng)站制作,網(wǎng)頁設(shè)計,網(wǎng)站設(shè)計,建網(wǎng)站,PHP網(wǎng)站建設(shè)等專業(yè)做網(wǎng)站服務(wù);采用PHP框架,可快速的進(jìn)行興隆臺網(wǎng)站開發(fā)網(wǎng)頁制作和功能擴展;專業(yè)做搜索引擎喜愛的網(wǎng)站,專業(yè)的做網(wǎng)站團(tuán)隊,希望更多企業(yè)前來合作!

2.1 NoSQL 概述

NoSQL(NoSQL = Not Only SQL ),意即“不僅僅是SQL”,

泛指非關(guān)系型的數(shù)據(jù)庫。隨著互聯(lián)網(wǎng)web2.0網(wǎng)站的興起,傳統(tǒng)的關(guān)系數(shù)據(jù)庫在應(yīng)付web2.0網(wǎng)站,特別是超大規(guī)模和高并發(fā)的SNS類型的web2.0純動態(tài)網(wǎng)站已經(jīng)顯得力不從心,暴露了很多難以克服的問題,而非關(guān)系型的數(shù)據(jù)庫則由于其本身的特點得到了非常迅速的發(fā)展。NoSQL數(shù)據(jù)庫的產(chǎn)生就是為了解決大規(guī)模數(shù)據(jù)集合多重數(shù)據(jù)種類帶來的挑戰(zhàn),尤其是大數(shù)據(jù)應(yīng)用難題,包括超大規(guī)模數(shù)據(jù)的存儲。

(例如谷歌或Facebook每天為他們的用戶收集萬億比特的數(shù)據(jù))。這些類型的數(shù)據(jù)存儲不需要固定的模式,無需多余操作就可以橫向擴展。

2.2 NoSQL代表

MongDB、 Redis、Memcache

3. 關(guān)系型數(shù)據(jù)庫與NoSQL的區(qū)別?

3.1 RDBMS

高度組織化結(jié)構(gòu)化數(shù)據(jù)

結(jié)構(gòu)化查詢語言(SQL)

數(shù)據(jù)和關(guān)系都存儲在單獨的表中。

數(shù)據(jù)操縱語言,數(shù)據(jù)定義語言

嚴(yán)格的一致性

基礎(chǔ)事務(wù)

ACID

關(guān)系型數(shù)據(jù)庫遵循ACID規(guī)則

事務(wù)在英文中是transaction,和現(xiàn)實世界中的交易很類似,它有如下四個特性:

A (Atomicity) 原子性

原子性很容易理解,也就是說事務(wù)里的所有操作要么全部做完,要么都不做,事務(wù)成功的條件是事務(wù)里的所有操作都成功,只要有一個操作失敗,整個事務(wù)就失敗,需要回滾。比如銀行轉(zhuǎn)賬,從A賬戶轉(zhuǎn)100元至B賬戶,分為兩個步驟:1)從A賬戶取100元;2)存入100元至B賬戶。這兩步要么一起完成,要么一起不完成,如果只完成第一步,第二步失敗,錢會莫名其妙少了100元。

C (Consistency) 一致性

一致性也比較容易理解,也就是說數(shù)據(jù)庫要一直處于一致的狀態(tài),事務(wù)的運行不會改變數(shù)據(jù)庫原本的一致性約束。

I (Isolation) 獨立性

所謂的獨立性是指并發(fā)的事務(wù)之間不會互相影響,如果一個事務(wù)要訪問的數(shù)據(jù)正在被另外一個事務(wù)修改,只要另外一個事務(wù)未提交,它所訪問的數(shù)據(jù)就不受未提交事務(wù)的影響。比如現(xiàn)有有個交易是從A賬戶轉(zhuǎn)100元至B賬戶,在這個交易還未完成的情況下,如果此時B查詢自己的賬戶,是看不到新增加的100元的

D (Durability) 持久性

持久性是指一旦事務(wù)提交后,它所做的修改將會永久的保存在數(shù)據(jù)庫上,即使出現(xiàn)宕機也不會丟失。

3.2 NoSQL

代表著不僅僅是SQL

沒有聲明性查詢語言

沒有預(yù)定義的模式

鍵 - 值對存儲,列存儲,文檔存儲,圖形數(shù)據(jù)庫

最終一致性,而非ACID屬性

非結(jié)構(gòu)化和不可預(yù)知的數(shù)據(jù)

CAP定理

高性能,高可用性和可伸縮性

分布式數(shù)據(jù)庫中的CAP原理(了解)

CAP定理:

Consistency(一致性), 數(shù)據(jù)一致更新,所有數(shù)據(jù)變動都是同步的

Availability(可用性), 好的響應(yīng)性能

Partition tolerance(分區(qū)容錯性) 可靠性

P: 系統(tǒng)中任意信息的丟失或失敗不會影響系統(tǒng)的繼續(xù)運作。

定理:任何分布式系統(tǒng)只可同時滿足二點,沒法三者兼顧。

CAP理論的核心是:一個分布式系統(tǒng)不可能同時很好的滿足一致性,可用性和分區(qū)容錯性這三個需求,

因此,根據(jù) CAP 原理將 NoSQL 數(shù)據(jù)庫分成了滿足 CA 原則、滿足 CP 原則和滿足 AP 原則三 大類:

CA - 單點集群,滿足一致性,可用性的系統(tǒng),通常在可擴展性上不太強大。

CP - 滿足一致性,分區(qū)容忍性的系統(tǒng),通常性能不是特別高。

AP - 滿足可用性,分區(qū)容忍性的系統(tǒng),通??赡軐σ恢滦砸蟮鸵恍?。

CAP理論就是說在分布式存儲系統(tǒng)中,最多只能實現(xiàn)上面的兩點。

而由于當(dāng)前的網(wǎng)絡(luò)硬件肯定會出現(xiàn)延遲丟包等問題,所以分區(qū)容忍性是我們必須需要實現(xiàn)的。

所以我們只能在一致性和可用性之間進(jìn)行權(quán)衡,沒有NoSQL系統(tǒng)能同時保證這三點。

說明:C:強一致性 A:高可用性 P:分布式容忍性

舉例:

CA:傳統(tǒng)Oracle數(shù)據(jù)庫

AP:大多數(shù)網(wǎng)站架構(gòu)的選擇

CP:Redis、Mongodb

注意:分布式架構(gòu)的時候必須做出取舍。

一致性和可用性之間取一個平衡。多余大多數(shù)web應(yīng)用,其實并不需要強一致性。

因此犧牲C換取P,這是目前分布式數(shù)據(jù)庫產(chǎn)品的方向。

4. 當(dāng)下NoSQL的經(jīng)典應(yīng)用

當(dāng)下的應(yīng)用是 SQL 與 NoSQL 一起使用的。

代表項目:阿里巴巴商品信息的存放。

去 IOE 化。

ps:I 是指 IBM 的小型機,很貴的,好像好幾萬一臺;O 是指 Oracle 數(shù)據(jù)庫,也很貴的,好幾萬呢;M 是指 EMC 的存儲設(shè)備,也很貴的。

難點:

數(shù)據(jù)類型多樣性。

數(shù)據(jù)源多樣性和變化重構(gòu)。

數(shù)據(jù)源改造而服務(wù)平臺不需要大面積重構(gòu)。

互聯(lián)網(wǎng)背景下,為什么用NoSql

本文將從單機MySQL的場景出發(fā),簡述一下隨著網(wǎng)站的訪問量越來越大,數(shù)據(jù)庫部署的演進(jìn)過程,到為什么要用MySQL的必要性。

大數(shù)據(jù)時代的數(shù)據(jù)有3V的特點:海量Volume、多樣Variety、實時Velocity。

互聯(lián)網(wǎng)網(wǎng)站需求的3高的特點:高并發(fā)、高可擴、高性能。

一、單機MySql

當(dāng)一個網(wǎng)站的訪問量不大時,用單個數(shù)據(jù)庫完全可以輕松應(yīng)付。

在那個時候,更多的都是靜態(tài)網(wǎng)頁,動態(tài)交互類型的網(wǎng)站不多。

上述架構(gòu)下,我們來看看數(shù)據(jù)存儲的瓶頸是什么?

1.數(shù)據(jù)量的總大小 一個機器放不下時

2.數(shù)據(jù)的索引(B+ Tree)一個機器的內(nèi)存放不下時

3.訪問量(讀寫混合)一個實例不能承受

如果滿足了上述1 or 3個,進(jìn)化......

二、Memcached(緩存)+Mysql+垂直拆分

后來,隨著訪問量的上升,幾乎大部分使用MySQL架構(gòu)的網(wǎng)站在數(shù)據(jù)庫上都開始出現(xiàn)了性能問題,web程序不再僅僅專注在功能上,同時也在追求性能。程序員們開始大量的使用緩存技術(shù)來緩解數(shù)據(jù)庫的壓力,優(yōu)化數(shù)據(jù)庫的結(jié)構(gòu)和索引。開始比較流行的是通過文件緩存來緩解數(shù)據(jù)庫壓力,但是當(dāng)訪問量繼續(xù)增大的時候,多臺web機器通過文件緩存不能共享,大量的小文件緩存也帶了了比較高的IO壓力。在這個時候,Memcached就自然的成為一個非常時尚的技術(shù)產(chǎn)品。

Memcached作為一個獨立的分布式的緩存服務(wù)器,為多個web服務(wù)器提供了一個共享的高性能緩存服務(wù),在Memcached服務(wù)器上,又發(fā)展了根據(jù)hash算法來進(jìn)行多臺Memcached緩存服務(wù)的擴展,然后又出現(xiàn)了一致性hash來解決增加或減少緩存服務(wù)器導(dǎo)致重新hash帶來的大量緩存失效的弊端

三、MySql主從復(fù)制讀寫分離

由于數(shù)據(jù)庫的寫入壓力增加,Memcached只能緩解數(shù)據(jù)庫的讀取壓力。讀寫集中在一個數(shù)據(jù)庫上讓數(shù)據(jù)庫不堪重負(fù),大部分網(wǎng)站開始使用主從復(fù)制技術(shù)來達(dá)到讀寫分離,以提高讀寫性能和讀庫的可擴展性。Mysql的master-slave模式成為這個時候的網(wǎng)站標(biāo)配了。

四、分庫分表+水平拆分+Mysql集群

在Memcached的高速緩存,MySQL的主從復(fù)制,讀寫分離的基礎(chǔ)之上,這時MySQL主庫的寫壓力開始出現(xiàn)瓶頸,而數(shù)據(jù)量的持續(xù)猛增,由于MyISAM使用表鎖,在高并發(fā)下會出現(xiàn)嚴(yán)重的鎖問題,大量的高并發(fā)MySQL應(yīng)用開始使用InnoDB引擎代替MyISAM。

同時,開始流行使用分表分庫來緩解寫壓力和數(shù)據(jù)增長的擴展問題。這個時候,分表分庫成了一個熱門技術(shù),是面試的熱門問題也是業(yè)界討論的熱門技術(shù)問題。也就在這個時候,MySQL推出了還不太穩(wěn)定的表分區(qū),這也給技術(shù)實力一般的公司帶來了希望。雖然MySQL推出了MySQL Cluster集群,但性能也不能很好滿足互聯(lián)網(wǎng)的要求,只是在高可靠性上提供了非常大的保證。

五、Mysql的擴展性瓶頸

MySQL數(shù)據(jù)庫也經(jīng)常存儲一些大文本字段,導(dǎo)致數(shù)據(jù)庫表非常的大,在做數(shù)據(jù)庫恢復(fù)的時候就導(dǎo)致非常的慢,不容易快速恢復(fù)數(shù)據(jù)庫。比如1000萬4KB大小的文本就接近40GB的大小,如果能把這些數(shù)據(jù)從MySQL省去,MySQL將變得非常的小。關(guān)系數(shù)據(jù)庫很強大,但是它并不能很好的應(yīng)付所有的應(yīng)用場景。MySQL的擴展性差(需要復(fù)雜的技術(shù)來實現(xiàn)),大數(shù)據(jù)下IO壓力大,表結(jié)構(gòu)更改困難,正是當(dāng)前使用MySQL的開發(fā)人員面臨的問題。

六、為什么用Nosql

今天我們可以通過第三方平臺(如:Google,Facebook等)可以很容易的訪問和抓取數(shù)據(jù)。用戶的個人信息,社交網(wǎng)絡(luò),地理位置,用戶生成的數(shù)據(jù)和用戶操作日志已經(jīng)成倍的增加。我們?nèi)绻獙@些用戶數(shù)據(jù)進(jìn)行挖掘,那SQL數(shù)據(jù)庫已經(jīng)不適合這些應(yīng)用了, NoSQL數(shù)據(jù)庫的發(fā)展也卻能很好的處理這些大的數(shù)據(jù)。下面給大家看一下,web應(yīng)用數(shù)據(jù)量的增長圖:

七、Nosql是什么

NoSQL(NoSQL = Not Only SQL ),意即“不僅僅是SQL”,

泛指非關(guān)系型的數(shù)據(jù)庫。隨著互聯(lián)網(wǎng)web2.0網(wǎng)站的興起,傳統(tǒng)的關(guān)系數(shù)據(jù)庫在應(yīng)付web2.0網(wǎng)站,特別是超大規(guī)模和高并發(fā)的SNS類型的web2.0純動態(tài)網(wǎng)站已經(jīng)顯得力不從心,暴露了很多難以克服的問題,而非關(guān)系型的數(shù)據(jù)庫則由于其本身的特點得到了非常迅速的發(fā)展。NoSQL數(shù)據(jù)庫的產(chǎn)生就是為了解決大規(guī)模數(shù)據(jù)集合多重數(shù)據(jù)種類帶來的挑戰(zhàn),尤其是大數(shù)據(jù)應(yīng)用難題,包括超大規(guī)模數(shù)據(jù)的存儲。

(例如谷歌或Facebook每天為他們的用戶收集萬億比特的數(shù)據(jù))。這些類型的數(shù)據(jù)存儲不需要固定的模式,無需多余操作就可以橫向擴展。

八、Nosql的優(yōu)勢

1.易擴展

NoSQL數(shù)據(jù)庫種類繁多,但是一個共同的特點都是去掉關(guān)系數(shù)據(jù)庫的關(guān)系型特性。

數(shù)據(jù)之間無關(guān)系,這樣就非常容易擴展。也無形之間,在架構(gòu)的層面上帶來了可擴展的能力。

2.大數(shù)據(jù)量,高性能

NoSQL數(shù)據(jù)庫都具有非常高的讀寫性能,尤其在大數(shù)據(jù)量下,同樣表現(xiàn)優(yōu)秀。

這得益于它的無關(guān)系性,數(shù)據(jù)庫的結(jié)構(gòu)簡單。一般MySQL使用Query Cache,每次表的更新Cache就失效,是一種大粒度的Cache,在針對web2.0的交互頻繁的應(yīng)用,Cache性能不高。而NoSQL的Cache是記錄級的,是一種細(xì)粒度的Cache,所以NoSQL在這個層面上來說就要性能高很多了。

3.多樣靈活的數(shù)據(jù)模型

NoSQL無需事先為要存儲的數(shù)據(jù)建立字段,隨時可以存儲自定義的數(shù)據(jù)格式。而在關(guān)系數(shù)據(jù)庫里,增刪字段是一件非常麻煩的事情。如果是非常大數(shù)據(jù)量的表,增加字段簡直就是一個噩夢。

九、Nosql數(shù)據(jù)庫的四大分類

鍵值(Key-Value)存儲

列存儲

文檔存儲

圖形存儲

常見的有:Redis、Memcache、MongoDB,這里就不一 一 介紹了。

為什么海量數(shù)據(jù)場景中NoSQL越來越重要

本質(zhì)是因為:隨著互聯(lián)網(wǎng)的進(jìn)一步發(fā)展與各行業(yè)信息化建設(shè)進(jìn)程加快、參與者的增多,人們對軟件有了更多更新的要求,需要軟件不僅能實現(xiàn)功能,而且要求保證許多人可以共同參與使用,因而軟件所需承載的數(shù)據(jù)量和吞吐量必須達(dá)到相應(yīng)的需求。而目前的關(guān)系型數(shù)據(jù)庫在某些方面有一些缺點,導(dǎo)致不能滿足需要。

具體則需要對比關(guān)系型數(shù)據(jù)庫與Nosql之間的區(qū)別可以得出

關(guān)系型數(shù)據(jù)庫

關(guān)系型數(shù)據(jù)庫把所有的數(shù)據(jù)都通過行和列的二元表現(xiàn)形式表示出來。

關(guān)系型數(shù)據(jù)庫的優(yōu)勢:

1.?保持?jǐn)?shù)據(jù)的一致性(事務(wù)處理)

2.由于以標(biāo)準(zhǔn)化為前提,數(shù)據(jù)更新的開銷很?。ㄏ嗤淖侄位旧隙贾挥幸惶帲?/p>

3.?可以進(jìn)行Join等復(fù)雜查詢

其中能夠保持?jǐn)?shù)據(jù)的一致性是關(guān)系型數(shù)據(jù)庫的最大優(yōu)勢。

關(guān)系型數(shù)據(jù)庫的不足:

不擅長的處理

1.?大量數(shù)據(jù)的寫入處理(這點尤為重要)

2.?為有數(shù)據(jù)更新的表做索引或表結(jié)構(gòu)(schema)變更

3.?字段不固定時應(yīng)用

4.?對簡單查詢需要快速返回結(jié)果的處理

--大量數(shù)據(jù)的寫入處理

讀寫集中在一個數(shù)據(jù)庫上讓數(shù)據(jù)庫不堪重負(fù),大部分網(wǎng)站已使用主從復(fù)制技術(shù)實現(xiàn)讀寫分離,以提高讀寫性能和讀庫的可擴展性。

所以在進(jìn)行大量數(shù)據(jù)操作時,會使用數(shù)據(jù)庫主從模式。數(shù)據(jù)的寫入由主數(shù)據(jù)庫負(fù)責(zé),數(shù)據(jù)的讀入由從數(shù)據(jù)庫負(fù)責(zé),可以比較簡單地通過增加從數(shù)據(jù)庫來實現(xiàn)規(guī)?;?,但是數(shù)據(jù)的寫入?yún)s完全沒有簡單的方法來解決規(guī)模化問題。

第一,要想將數(shù)據(jù)的寫入規(guī)?;?,可以考慮把主數(shù)據(jù)庫從一臺增加到兩臺,作為互相關(guān)聯(lián)復(fù)制的二元主數(shù)據(jù)庫使用,確實這樣可以把每臺主數(shù)據(jù)庫的負(fù)荷減少一半,但是更新處理會發(fā)生沖突,可能會造成數(shù)據(jù)的不一致,為了避免這樣的問題,需要把對每個表的請求分別分配給合適的主數(shù)據(jù)庫來處理。

第二,可以考慮把數(shù)據(jù)庫分割開來,分別放在不同的數(shù)據(jù)庫服務(wù)器上,比如將不同的表放在不同的數(shù)據(jù)庫服務(wù)器上,數(shù)據(jù)庫分割可以減少每臺數(shù)據(jù)庫服務(wù)器上的數(shù)據(jù)量,以便減少硬盤IO的輸入、輸出處理,實現(xiàn)內(nèi)存上的高速處理。但是由于分別存儲字不同服務(wù)器上的表之間無法進(jìn)行Join處理,數(shù)據(jù)庫分割的時候就需要預(yù)先考慮這些問題,數(shù)據(jù)庫分割之后,如果一定要進(jìn)行Join處理,就必須要在程序中進(jìn)行關(guān)聯(lián),這是非常困難的。

--為有數(shù)據(jù)更新的表做索引或表結(jié)構(gòu)變更

在使用關(guān)系型數(shù)據(jù)庫時,為了加快查詢速度需要創(chuàng)建索引,為了增加必要的字段就一定要改變表結(jié)構(gòu),為了進(jìn)行這些處理,需要對表進(jìn)行共享鎖定,這期間數(shù)據(jù)變更、更新、插入、刪除等都是無法進(jìn)行的。如果需要進(jìn)行一些耗時操作,例如為數(shù)據(jù)量比較大的表創(chuàng)建索引或是變更其表結(jié)構(gòu),就需要特別注意,長時間內(nèi)數(shù)據(jù)可能無法進(jìn)行更新。

--字段不固定時的應(yīng)用

如果字段不固定,利用關(guān)系型數(shù)據(jù)庫也是比較困難的,有人會說,需要的時候加個字段就可以了,這樣的方法也不是不可以,但在實際運用中每次都進(jìn)行反復(fù)的表結(jié)構(gòu)變更是非常痛苦的。你也可以預(yù)先設(shè)定大量的預(yù)備字段,但這樣的話,時間一長很容易弄不清除字段和數(shù)據(jù)的對應(yīng)狀態(tài),即哪個字段保存有哪些數(shù)據(jù)。

--對簡單查詢需要快速返回結(jié)果的處理? (這里的“簡單”指的是沒有復(fù)雜的查詢條件)

這一點稱不上是缺點,但不管怎樣,關(guān)系型數(shù)據(jù)庫并不擅長對簡單的查詢快速返回結(jié)果,因為關(guān)系型數(shù)據(jù)庫是使用專門的sql語言進(jìn)行數(shù)據(jù)讀取的,它需要對sql與越南進(jìn)行解析,同時還有對表的鎖定和解鎖等這樣的額外開銷,這里并不是說關(guān)系型數(shù)據(jù)庫的速度太慢,而只是想告訴大家若希望對簡單查詢進(jìn)行高速處理,則沒有必要非使用關(guān)系型數(shù)據(jù)庫不可。

NoSQL數(shù)據(jù)庫

關(guān)系型數(shù)據(jù)庫應(yīng)用廣泛,能進(jìn)行事務(wù)處理和表連接等復(fù)雜查詢。相對地,NoSQL數(shù)據(jù)庫只應(yīng)用在特定領(lǐng)域,基本上不進(jìn)行復(fù)雜的處理,但它恰恰彌補了之前所列舉的關(guān)系型數(shù)據(jù)庫的不足之處。

優(yōu)點:

易于數(shù)據(jù)的分散

各個數(shù)據(jù)之間存在關(guān)聯(lián)是關(guān)系型數(shù)據(jù)庫得名的主要原因,為了進(jìn)行join處理,關(guān)系型數(shù)據(jù)庫不得不把數(shù)據(jù)存儲在同一個服務(wù)器內(nèi),這不利于數(shù)據(jù)的分散,這也是關(guān)系型數(shù)據(jù)庫并不擅長大數(shù)據(jù)量的寫入處理的原因。相反NoSQL數(shù)據(jù)庫原本就不支持Join處理,各個數(shù)據(jù)都是獨立設(shè)計的,很容易把數(shù)據(jù)分散在多個服務(wù)器上,故減少了每個服務(wù)器上的數(shù)據(jù)量,即使要處理大量數(shù)據(jù)的寫入,也變得更加容易,數(shù)據(jù)的讀入操作當(dāng)然也同樣容易。

典型的NoSQL數(shù)據(jù)庫

臨時性鍵值存儲(memcached、Redis)、永久性鍵值存儲(ROMA、Redis)、面向文檔的數(shù)據(jù)庫(MongoDB、CouchDB)、面向列的數(shù)據(jù)庫(Cassandra、HBase)

一、 鍵值存儲

它的數(shù)據(jù)是以鍵值的形式存儲的,雖然它的速度非???,但基本上只能通過鍵的完全一致查詢獲取數(shù)據(jù),根據(jù)數(shù)據(jù)的保存方式可以分為臨時性、永久性和兩者兼具 三種。

(1)臨時性

所謂臨時性就是數(shù)據(jù)有可能丟失,memcached把所有數(shù)據(jù)都保存在內(nèi)存中,這樣保存和讀取的速度非???,但是當(dāng)memcached停止時,數(shù)據(jù)就不存在了。由于數(shù)據(jù)保存在內(nèi)存中,所以無法操作超出內(nèi)存容量的數(shù)據(jù),舊數(shù)據(jù)會丟失??偨Y(jié)來說:

。在內(nèi)存中保存數(shù)據(jù)

??梢赃M(jìn)行非??焖俚谋4婧妥x取處理

。數(shù)據(jù)有可能丟失

(2)永久性

所謂永久性就是數(shù)據(jù)不會丟失,這里的鍵值存儲是把數(shù)據(jù)保存在硬盤上,與臨時性比起來,由于必然要發(fā)生對硬盤的IO操作,所以性能上還是有差距的,但數(shù)據(jù)不會丟失是它最大的優(yōu)勢??偨Y(jié)來說:

。在硬盤上保存數(shù)據(jù)

??梢赃M(jìn)行非??焖俚谋4婧妥x取處理(但無法與memcached相比)

。數(shù)據(jù)不會丟失

(3) 兩者兼?zhèn)?/p>

Redis屬于這種類型。Redis有些特殊,臨時性和永久性兼具。Redis首先把數(shù)據(jù)保存在內(nèi)存中,在滿足特定條件(默認(rèn)是?15分鐘一次以上,5分鐘內(nèi)10個以上,1分鐘內(nèi)10000個以上的鍵發(fā)生變更)的時候?qū)?shù)據(jù)寫入到硬盤中,這樣既確保了內(nèi)存中數(shù)據(jù)的處理速度,又可以通過寫入硬盤來保證數(shù)據(jù)的永久性,這種類型的數(shù)據(jù)庫特別適合處理數(shù)組類型的數(shù)據(jù)。總結(jié)來說:

。同時在內(nèi)存和硬盤上保存數(shù)據(jù)

??梢赃M(jìn)行非常快速的保存和讀取處理

。保存在硬盤上的數(shù)據(jù)不會消失(可以恢復(fù))

。適合于處理數(shù)組類型的數(shù)據(jù)

二、面向文檔的數(shù)據(jù)庫

MongoDB、CouchDB屬于這種類型,它們屬于NoSQL數(shù)據(jù)庫,但與鍵值存儲相異。

(1)不定義表結(jié)構(gòu)

即使不定義表結(jié)構(gòu),也可以像定義了表結(jié)構(gòu)一樣使用,還省去了變更表結(jié)構(gòu)的麻煩。

(2)可以使用復(fù)雜的查詢條件

跟鍵值存儲不同的是,面向文檔的數(shù)據(jù)庫可以通過復(fù)雜的查詢條件來獲取數(shù)據(jù),雖然不具備事務(wù)處理和Join這些關(guān)系型數(shù)據(jù)庫所具有的處理能力,但初次以外的其他處理基本上都能實現(xiàn)。

三、?面向列的數(shù)據(jù)庫

Cassandra、HBae、HyperTable屬于這種類型,由于近年來數(shù)據(jù)量出現(xiàn)爆發(fā)性增長,這種類型的NoSQL數(shù)據(jù)庫尤其引入注目。

普通的關(guān)系型數(shù)據(jù)庫都是以行為單位來存儲數(shù)據(jù)的,擅長以行為單位的讀入處理,比如特定條件數(shù)據(jù)的獲取。因此,關(guān)系型數(shù)據(jù)庫也被成為面向行的數(shù)據(jù)庫。相反,面向列的數(shù)據(jù)庫是以列為單位來存儲數(shù)據(jù)的,擅長以列為單位讀入數(shù)據(jù)。

面向列的數(shù)據(jù)庫具有搞擴展性,即使數(shù)據(jù)增加也不會降低相應(yīng)的處理速度(特別是寫入速度),所以它主要應(yīng)用于需要處理大量數(shù)據(jù)的情況。另外,把它作為批處理程序的存儲器來對大量數(shù)據(jù)進(jìn)行更新也是非常有用的。但由于面向列的數(shù)據(jù)庫跟現(xiàn)行數(shù)據(jù)庫存儲的思維方式有很大不同,故應(yīng)用起來十分困難。

總結(jié):關(guān)系型數(shù)據(jù)庫與NoSQL數(shù)據(jù)庫并非對立而是互補的關(guān)系,即通常情況下使用關(guān)系型數(shù)據(jù)庫,在適合使用NoSQL的時候使用NoSQL數(shù)據(jù)庫,讓NoSQL數(shù)據(jù)庫對關(guān)系型數(shù)據(jù)庫的不足進(jìn)行彌補。

為什么要使用nosql

因為關(guān)系數(shù)據(jù)庫運行的慢

處理大數(shù)據(jù)的大多數(shù)情況是nosql比較高效

但是nosql也沒法完全取代關(guān)系數(shù)據(jù)庫

nosql不能處理復(fù)雜的邏輯

但是很多情況下只是簡單的mapping,匯總,

在目前互聯(lián)網(wǎng)大數(shù)據(jù)的環(huán)境下nosql會越來越普及

nosql是什么

NoSQL,泛指非關(guān)系型的數(shù)據(jù)庫。隨著互聯(lián)網(wǎng)web2.0網(wǎng)站的興起,傳統(tǒng)的關(guān)系數(shù)據(jù)庫在應(yīng)付web2.0網(wǎng)站,特別是超大規(guī)模和高并發(fā)的SNS類型的web2.0純動態(tài)網(wǎng)站已經(jīng)顯得力不從心,暴露了很多難以克服的問題,而非關(guān)系型的數(shù)據(jù)庫則由于其本身的特點得到了非常迅速的發(fā)展。NoSQL數(shù)據(jù)庫的產(chǎn)生就是為了解決大規(guī)模數(shù)據(jù)集合多重數(shù)據(jù)種類帶來的挑戰(zhàn),尤其是大數(shù)據(jù)應(yīng)用難題。

雖然NoSQL流行語火起來才短短一年的時間,但是不可否認(rèn),現(xiàn)在已經(jīng)開始了第二代運動。盡管早期的堆棧代碼只能算是一種實驗,然而現(xiàn)在的系統(tǒng)已經(jīng)更加的成熟、穩(wěn)定。不過現(xiàn)在也面臨著一個嚴(yán)酷的事實:技術(shù)越來越成熟——以至于原來很好的NoSQL數(shù)據(jù)存儲不得不進(jìn)行重寫,也有少數(shù)人認(rèn)為這就是所謂的2.0版本。這里列出一些比較知名的工具,可以為大數(shù)據(jù)建立快速、可擴展的存儲庫。

NoSQL(NoSQL = Not Only SQL ),意即“不僅僅是SQL”,是一項全新的數(shù)據(jù)庫革命性運動,早期就有人提出,發(fā)展至2009年趨勢越發(fā)高漲。NoSQL的擁護(hù)者們提倡運用非關(guān)系型的數(shù)據(jù)存儲,相對于鋪天蓋地的關(guān)系型數(shù)據(jù)庫運用,這一概念無疑是一種全新的思維的注入。

對于NoSQL并沒有一個明確的范圍和定義,但是他們都普遍存在下面一些共同特征:

不需要預(yù)定義模式:不需要事先定義數(shù)據(jù)模式,預(yù)定義表結(jié)構(gòu)。數(shù)據(jù)中的每條記錄都可能有不同的屬性和格式。當(dāng)插入數(shù)據(jù)時,并不需要預(yù)先定義它們的模式。

無共享架構(gòu):相對于將所有數(shù)據(jù)存儲的存儲區(qū)域網(wǎng)絡(luò)中的全共享架構(gòu)。NoSQL往往將數(shù)據(jù)劃分后存儲在各個本地服務(wù)器上。因為從本地磁盤讀取數(shù)據(jù)的性能往往好于通過網(wǎng)絡(luò)傳輸讀取數(shù)據(jù)的性能,從而提高了系統(tǒng)的性能。

彈性可擴展:可以在系統(tǒng)運行的時候,動態(tài)增加或者刪除結(jié)點。不需要停機維護(hù),數(shù)據(jù)可以自動遷移。

分區(qū):相對于將數(shù)據(jù)存放于同一個節(jié)點,NoSQL數(shù)據(jù)庫需要將數(shù)據(jù)進(jìn)行分區(qū),將記錄分散在多個節(jié)點上面。并且通常分區(qū)的同時還要做復(fù)制。這樣既提高了并行性能,又能保證沒有單點失效的問題。

異步復(fù)制:和RAID存儲系統(tǒng)不同的是,NoSQL中的復(fù)制,往往是基于日志的異步復(fù)制。這樣,數(shù)據(jù)就可以盡快地寫入一個節(jié)點,而不會被網(wǎng)絡(luò)傳輸引起遲延。缺點是并不總是能保證一致性,這樣的方式在出現(xiàn)故障的時候,可能會丟失少量的數(shù)據(jù)。

BASE:相對于事務(wù)嚴(yán)格的ACID特性,NoSQL數(shù)據(jù)庫保證的是BASE特性。BASE是最終一致性和軟事務(wù)。

NoSQL數(shù)據(jù)庫并沒有一個統(tǒng)一的架構(gòu),兩種NoSQL數(shù)據(jù)庫之間的不同,甚至遠(yuǎn)遠(yuǎn)超過兩種關(guān)系型數(shù)據(jù)庫的不同??梢哉f,NoSQL各有所長,成功的NoSQL必然特別適用于某些場合或者某些應(yīng)用,在這些場合中會遠(yuǎn)遠(yuǎn)勝過關(guān)系型數(shù)據(jù)庫和其他的NoSQL。


分享文章:簡述NoSQL興起的原因,NoSQL數(shù)據(jù)庫具有以下幾個特點
瀏覽地址:http://weahome.cn/article/hoijsj.html

其他資訊

在線咨詢

微信咨詢

電話咨詢

028-86922220(工作日)

18980820575(7×24)

提交需求

返回頂部