為什么選擇使用NoSQL數(shù)據(jù)庫開發(fā)如此困難

傳統(tǒng)觀念中 NoSQL數(shù)據(jù)庫非常適合某些數(shù)據(jù)類型，如：非關(guān)系數(shù)據(jù)源。同時(shí)，NoSQL被吹捧為最適合Web應(yīng)用程序的優(yōu)秀平臺(tái)。然而他適合大多數(shù)數(shù)據(jù)，特別是web應(yīng)用程序的數(shù)據(jù)是相關(guān)型。那么，這是否可以給你一個(gè)堅(jiān)持使用RDMS的理由呢？也不一定，即使很困難，我們還是要做出選擇。

創(chuàng)新互聯(lián)公司一直在為企業(yè)提供服務(wù)，多年的磨煉，使我們?cè)趧?chuàng)意設(shè)計(jì)，網(wǎng)絡(luò)營銷推廣到技術(shù)研發(fā)擁有了開發(fā)經(jīng)驗(yàn)。我們擅長傾聽企業(yè)需求，挖掘用戶對(duì)產(chǎn)品需求服務(wù)價(jià)值，為企業(yè)制作有用的創(chuàng)意設(shè)計(jì)體驗(yàn)。核心團(tuán)隊(duì)擁有超過十余年以上行業(yè)經(jīng)驗(yàn)，涵蓋創(chuàng)意，策化，開發(fā)等專業(yè)領(lǐng)域，公司涉及領(lǐng)域有基礎(chǔ)互聯(lián)網(wǎng)服務(wù)綿陽服務(wù)器托管、app軟件定制開發(fā)、手機(jī)移動(dòng)建站、網(wǎng)頁設(shè)計(jì)、網(wǎng)絡(luò)整合營銷。

評(píng)估NoSQL是一個(gè)很茅盾的理論，一些人認(rèn)為，應(yīng)該將所有文檔數(shù)據(jù)存儲(chǔ)在一個(gè)文檔中，做鏈接代碼就是褻瀆神明。另外一部分人認(rèn)為，存儲(chǔ)應(yīng)用文檔，

加入代碼，才是合理選擇。與此同時(shí)，不同的數(shù)據(jù)庫，需要在文檔中限制嵌套數(shù)據(jù)數(shù)量。有的人會(huì)鼓勵(lì)文檔引用。這是NoSQL數(shù)據(jù)模型的基本部分，也沒有一個(gè)

明確的共識(shí)。

曾經(jīng)有一篇很熱的帖子"Why you should never use

XYZ"，我想，讀到這里，一定會(huì)有人搜索這篇文章。當(dāng)然，這種文章各式各樣，太過于籠統(tǒng)的標(biāo)題也沒什么幫助。毫無疑問，會(huì)有人會(huì)搜索這個(gè)文章，然后再找

到這個(gè)文章，進(jìn)一步深入，找到該文章的方法遠(yuǎn)比成功（理解問題）的故事多。很難知道誰提供了一個(gè)有效的技術(shù)問題，誰又誤讀了這個(gè)問題（或者缺少證據(jù)證明其

觀點(diǎn)）。

有大量選擇，RDBMS的世界，選擇就很容易。你有4或5個(gè)目標(biāo)，大家工作方式差不多，來選擇環(huán)境、預(yù)算支持的平臺(tái)。對(duì)于成熟的產(chǎn)品，風(fēng)險(xiǎn)比較小。 NoSQL的世界，有很多數(shù)據(jù)庫引擎功能選擇。每一個(gè)有自己的獨(dú)特優(yōu)勢(shì)，也有致命弱點(diǎn)。所以選擇很難， NoSQL項(xiàng)目生命周期短，嘗試新項(xiàng)目或者流行項(xiàng)目也會(huì)有風(fēng)險(xiǎn)。上次，我的的項(xiàng)目是在 CouchDB上，而現(xiàn)在似乎停擺了。

做出這個(gè)痛苦決定的原因是，這可能是一個(gè)案例：你需要做一大堆工作，才能知道，你做出的選擇對(duì)與錯(cuò)。你可以實(shí)體化你的數(shù)據(jù)模型，了解他與系統(tǒng)的工作

情況，但是，這只有你正真撞到南墻，才可以找到裂縫（答案）。以我為例，我建的應(yīng)用程序是關(guān)系數(shù)據(jù)庫，移動(dòng)文件存儲(chǔ)的主要因素是，需要一個(gè)無模式設(shè)計(jì)來達(dá)

到我的目標(biāo)。使用NoSQL 數(shù)據(jù)庫存儲(chǔ)關(guān)系型數(shù)據(jù)庫并不是我們所常說的，雖然，這種事常常發(fā)生。

現(xiàn)在我在用 Couchbase 和

MongoDB，Mongo對(duì)我沒多大吸引力，不過鑒于他非常流行，對(duì)于引起來說，很有好處。當(dāng)然，很多都可以以同樣的方式流行。PHP很流行，因?yàn)樗?/p>

易用性，而不是因?yàn)樗芎?。我現(xiàn)在在使用MongoDB和PHP，也在學(xué)習(xí)Couchbase，如果你有任何NoSQL平臺(tái)的使用感想，歡迎交流。

為什么要使用NoSQL

NoSQL被我們用得最多的當(dāng)數(shù)key-value存儲(chǔ)，當(dāng)然還有其他的文檔型的、列存儲(chǔ)、圖型數(shù)據(jù)庫、xml數(shù)據(jù)庫等。在NoSQL概念提出之前，這些數(shù)據(jù)庫就被用于各種系統(tǒng)當(dāng)中，但是卻很少用于web互聯(lián)網(wǎng)應(yīng)用。比如cdb、qdbm、bdb數(shù)據(jù)庫。

隨著web2.0的快速發(fā)展，非關(guān)系型、分布式數(shù)據(jù)存儲(chǔ)得到了快速的發(fā)展，它們不保證關(guān)系數(shù)據(jù)的ACID特性。NoSQL概念在2009年被提了出來。NoSQL最常見的解釋是“non-relational”，“Not Only SQL”也被很多人接受。（“NoSQL”一詞最早于1998年被用于一個(gè)輕量級(jí)的關(guān)系數(shù)據(jù)庫的名字。）

易擴(kuò)展?? NoSQL數(shù)據(jù)庫種類繁多，但是一個(gè)共同的特點(diǎn)都是去掉關(guān)系數(shù)據(jù)庫的關(guān)系型特性。數(shù)據(jù)之間無關(guān)系，這樣就非常容易擴(kuò)展。也無形之間，在架構(gòu)的層面上帶來了可擴(kuò)展的能力。

大數(shù)據(jù)量，高性能 NoSQL數(shù)據(jù)庫都具有非常高的讀寫性能，尤其在大數(shù)據(jù)量下，同樣表現(xiàn)優(yōu)秀。這得益于它的無關(guān)系性，數(shù)據(jù)庫的結(jié)構(gòu)簡單。一般MySQL使用Query

Cache，每次表的更新Cache就失效，是一種大粒度的Cache，在針對(duì)web2.0的交互頻繁的應(yīng)用，Cache性能不高。而NoSQL的Cache是記錄級(jí)的，是一種細(xì)粒度的Cache，所以NoSQL在這個(gè)層面上來說就要性能高很多了。

我們?yōu)槭裁匆褂肗OSQL非關(guān)系數(shù)據(jù)庫?

而傳統(tǒng)的關(guān)系數(shù)據(jù)庫在應(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ù)庫高并發(fā)讀寫的需求

web2.0網(wǎng)站要根據(jù)用戶個(gè)性化信息來實(shí)時(shí)生成動(dòng)態(tài)頁面和提供動(dòng)態(tài)信息，所以基本上無法使用動(dòng)態(tài)頁面靜態(tài)化技術(shù)，因此數(shù)據(jù)庫并發(fā)負(fù)載非常高，往往要達(dá)到每秒上萬次讀寫請(qǐng)求。關(guān)系數(shù)據(jù)庫應(yīng)付上萬次SQL查詢還勉強(qiáng)頂?shù)米?，但是?yīng)付上萬次SQL寫數(shù)據(jù)請(qǐng)求，硬盤IO就已經(jīng)無法承受了。其實(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)，以國外的Friendfeed為例，一個(gè)月就達(dá)到了2.5億條用戶動(dòng)態(tài)，對(duì)于關(guān)系數(shù)據(jù)庫來說，在一張2.5億條記錄的表里面進(jìn)行SQL查詢，效率是極其低下乃至不可忍受的。再例如大型web網(wǎng)站的用戶登錄系統(tǒng)，例如騰訊，盛大，動(dòng)輒數(shù)以億計(jì)的帳號(hào)，關(guān)系數(shù)據(jù)庫也很難應(yīng)付。

3、High Scalability High Availability- 對(duì)數(shù)據(jù)庫的高可擴(kuò)展性和高可用性的需求

在基于web的架構(gòu)當(dāng)中，數(shù)據(jù)庫是最難進(jìn)行橫向擴(kuò)展的，當(dāng)一個(gè)應(yīng)用系統(tǒng)的用戶量和訪問量與日俱增的時(shí)候，你的數(shù)據(jù)庫卻沒有辦法像web server和app server那樣簡單的通過添加更多的硬件和服務(wù)節(jié)點(diǎn)來擴(kuò)展性能和負(fù)載能力。對(duì)于很多需要提供24小時(shí)不間斷服務(wù)的網(wǎng)站來說，對(duì)數(shù)據(jù)庫系統(tǒng)進(jìn)行升級(jí)和擴(kuò)展是非常痛苦的事情，往往需要停機(jī)維護(hù)和數(shù)據(jù)遷移，為什么數(shù)據(jù)庫不能通過不斷的添加服務(wù)器節(jié)點(diǎn)來實(shí)現(xiàn)擴(kuò)展呢？

在上面提到的“三高”需求面前，關(guān)系數(shù)據(jù)庫遇到了難以克服的障礙，而對(duì)于web2.0網(wǎng)站來說，關(guān)系數(shù)據(jù)庫的很多主要特性卻往往無用武之地，例如：

1、數(shù)據(jù)庫事務(wù)一致性需求

很多web實(shí)時(shí)系統(tǒng)并不要求嚴(yán)格的數(shù)據(jù)庫事務(wù)，對(duì)讀一致性的要求很低，有些場(chǎng)合對(duì)寫一致性要求也不高。因此數(shù)據(jù)庫事務(wù)管理成了數(shù)據(jù)庫高負(fù)載下一個(gè)沉重的負(fù)擔(dān)。

2、數(shù)據(jù)庫的寫實(shí)時(shí)性和讀實(shí)時(shí)性需求

對(duì)關(guān)系數(shù)據(jù)庫來說，插入一條數(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)生。往往更多的只是單表的主鍵查詢，以及單表的簡單條件分頁查詢，SQL的功能被極大的弱化了。

因此，關(guān)系數(shù)據(jù)庫在這些越來越多的應(yīng)用場(chǎng)景下顯得不那么合適了，為了解決這類問題的非關(guān)系數(shù)據(jù)庫應(yīng)運(yùn)而生。

NoSQL 是非關(guān)系型數(shù)據(jù)存儲(chǔ)的廣義定義。它打破了長久以來關(guān)系型數(shù)據(jù)庫與ACID理論大一統(tǒng)的局面。NoSQL 數(shù)據(jù)存儲(chǔ)不需要固定的表結(jié)構(gòu)，通常也不存在連接操作。在大數(shù)據(jù)存取上具備關(guān)系型數(shù)據(jù)庫無法比擬的性能優(yōu)勢(shì)。該術(shù)語在 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)同。

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

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

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

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

一、單機(jī)MySql

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

在那個(gè)時(shí)候，更多的都是靜態(tài)網(wǎng)頁，動(dòng)態(tài)交互類型的網(wǎng)站不多。

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

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

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

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

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

二、Memcached（緩存）+Mysql+垂直拆分

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

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

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

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

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

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

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

五、Mysql的擴(kuò)展性瓶頸

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

六、為什么用Nosql

今天我們可以通過第三方平臺(tái)（如：Google,Facebook等）可以很容易的訪問和抓取數(shù)據(jù)。用戶的個(gè)人信息，社交網(wǎng)絡(luò)，地理位置，用戶生成的數(shù)據(jù)和用戶操作日志已經(jīng)成倍的增加。我們?nèi)绻獙?duì)這些用戶數(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純動(dòng)態(tài)網(wǎng)站已經(jīng)顯得力不從心，暴露了很多難以克服的問題，而非關(guān)系型的數(shù)據(jù)庫則由于其本身的特點(diǎn)得到了非常迅速的發(fā)展。NoSQL數(shù)據(jù)庫的產(chǎn)生就是為了解決大規(guī)模數(shù)據(jù)集合多重?cái)?shù)據(jù)種類帶來的挑戰(zhàn)，尤其是大數(shù)據(jù)應(yīng)用難題，包括超大規(guī)模數(shù)據(jù)的存儲(chǔ)。

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

八、Nosql的優(yōu)勢(shì)

1.易擴(kuò)展

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

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

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

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

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

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

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

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

鍵值(Key-Value)存儲(chǔ)

列存儲(chǔ)

文檔存儲(chǔ)

圖形存儲(chǔ)

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

為什么要使用nosql

因?yàn)殛P(guān)系數(shù)據(jù)庫運(yùn)行的慢

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

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

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

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

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

為什么要使用NoSQL數(shù)據(jù)庫

因?yàn)殛P(guān)系數(shù)據(jù)庫運(yùn)行的慢

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

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

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

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

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

文章標(biāo)題：為什么用nosql,為什么用了煙酰胺越來越黑
文章位置：http://aaarwkj.com/article30/dssgppo.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供軟件開發(fā)、品牌網(wǎng)站建設(shè)、品牌網(wǎng)站制作、App開發(fā)、定制開發(fā)、網(wǎng)頁設(shè)計(jì)公司

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)