NoSQL 數(shù)據(jù)庫：何時使用 NoSQL 與 SQL？

NoSQL 數(shù)據(jù)庫因其功能性、易于開發(fā)性和可擴展性而廣受認可，它們越來越多地用于大數(shù)據(jù)和實時 Web 應用程序，在本文中，我們通過示例討論 NoSQL、何時使用 NoSQL 與 SQL 及其用例。

創(chuàng)新互聯(lián)專注為客戶提供全方位的互聯(lián)網(wǎng)綜合服務，包含不限于成都網(wǎng)站設計、成都網(wǎng)站制作、三沙網(wǎng)絡推廣、成都微信小程序、三沙網(wǎng)絡營銷、三沙企業(yè)策劃、三沙品牌公關、搜索引擎seo、人物專訪、企業(yè)宣傳片、企業(yè)代運營等，從售前售中售后，我們都將竭誠為您服務，您的肯定，是我們最大的嘉獎；創(chuàng)新互聯(lián)為所有大學生創(chuàng)業(yè)者提供三沙建站搭建服務，24小時服務熱線：13518219792，官方網(wǎng)址：m.rwnh.cn

NoSQL是一種下一代數(shù)據(jù)庫管理系統(tǒng) (DBMS)。NoSQL 數(shù)據(jù)庫具有靈活的模式，可用于構(gòu)建具有大量數(shù)據(jù)和高負載的現(xiàn)代應用程序。

“NoSQL”一詞最初是由 Carlo Strozzi 在 1998 年創(chuàng)造的，盡管自 1960 年代后期以來就已經(jīng)存在類似的數(shù)據(jù)庫。然而，NoSQL 的發(fā)展始于 2009 年初，并且發(fā)展迅速。

在處理大量數(shù)據(jù)時，任何關系數(shù)據(jù)庫管理系統(tǒng) (RDBMS) 的響應時間都會變慢。為了解決這個問題，我們可以通過升級現(xiàn)有硬件來“擴大”信息系統(tǒng)，這非常昂貴。但是，NoSQL 可以更好地橫向擴展并且更具成本效益。

NoSQL 對于非結(jié)構(gòu)化或非常大的數(shù)據(jù)對象（例如聊天日志數(shù)據(jù)、視頻或圖像）非常有用，這就是為什么 NoSQL 在微軟、谷歌、亞馬遜、Meta (Facebook) 等互聯(lián)網(wǎng)巨頭中特別受歡迎的原因。

一些流行的 NoSQL 數(shù)據(jù)庫包括：

隨著企業(yè)更快地積累更大的數(shù)據(jù)集，結(jié)構(gòu)化數(shù)據(jù)和關系模式并不總是適合。有必要使用非結(jié)構(gòu)化數(shù)據(jù)和大型對象來更好地捕獲這些信息。

傳統(tǒng)的 RDBMS 使用 SQL（結(jié)構(gòu)化查詢語言）語法來存儲和檢索結(jié)構(gòu)化數(shù)據(jù)，相反，NoSQL 數(shù)據(jù)庫包含廣泛的功能，可以存儲和檢索結(jié)構(gòu)化、半結(jié)構(gòu)化、非結(jié)構(gòu)化和多態(tài)數(shù)據(jù)。

有時，NoSQL 也被稱為“ 不僅僅是 SQL ”，強調(diào)它可能支持類似 SQL 的語言或與 SQL 數(shù)據(jù)庫并列。SQL 和 NoSQL DBMS 之間的一個區(qū)別是 JOIN 功能。SQL 數(shù)據(jù)庫使用 JOIN 子句來組合來自兩個或多個表的行，因為 NoSQL 數(shù)據(jù)庫本質(zhì)上不是表格的，所以這個功能并不總是可行或相關的。

但是，一些 NoSQL DBMS 可以執(zhí)行類似于 JOIN的操作——就像 MongoDB 一樣。這并不意味著不再需要 SQL DBMS，相反，NoSQL 和 SQL 數(shù)據(jù)庫傾向于以不同的方式解決類似的問題。

一般來說，在以下情況下，NoSQL 比 SQL 更可?。?/p>

許多行業(yè)都在采用 NoSQL，取代關系數(shù)據(jù)庫，從而為某些業(yè)務應用程序提供更高的靈活性和可擴展性，下面給出了 NoSQL 數(shù)據(jù)庫的一些企業(yè)用例。

內(nèi)容管理是一組用于收集、管理、傳遞、檢索和發(fā)布任何格式的信息的過程，包括文本、圖像、音頻和視頻。NoSQL 數(shù)據(jù)庫可以通過其靈活和開放的數(shù)據(jù)模型為存儲多媒體內(nèi)容提供更好的選擇。

例如，福布斯在短短幾個月內(nèi)就構(gòu)建了一個基于 MongoDB 的定制內(nèi)容管理系統(tǒng)，以更低的成本為他們提供了更大的敏捷性。

大數(shù)據(jù)是指太大而無法通過傳統(tǒng)處理系統(tǒng)處理的數(shù)據(jù)集，實時存儲和檢索大數(shù)據(jù)的系統(tǒng)在分析 歷史 數(shù)據(jù)的同時使用流處理來攝取新數(shù)據(jù)，這是一系列非常適合 NoSQL 數(shù)據(jù)庫的功能。

Zoom使用 DynamoDB（按需模式）使其數(shù)據(jù)能夠在沒有性能問題的情況下進行擴展，即使該服務在 COVID-19 大流行的早期使用量激增。

物聯(lián)網(wǎng)設備具有連接到互聯(lián)網(wǎng)或通信網(wǎng)絡的嵌入式軟件和傳感器，能夠在無需人工干預的情況下收集和共享數(shù)據(jù)。隨著數(shù)十億臺設備生成數(shù)不清的數(shù)據(jù)，IoT NoSQL 數(shù)據(jù)庫為 IoT 服務提供商提供了可擴展性和更靈活的架構(gòu)。

Freshub就是這樣的一項服務，它從 MySQL 切換到 MongoDB，以更好地處理其大型、動態(tài)、非統(tǒng)一的數(shù)據(jù)集。

擁有數(shù)十億智能手機用戶，可擴展性正成為在移動設備上提供服務的企業(yè)面臨的最大挑戰(zhàn)。具有更靈活數(shù)據(jù)模型的 NoSQL DBMS 通常是完美的解決方案。

例如，The Weather Channel使用 MongoDB 數(shù)據(jù)庫每分鐘處理數(shù)百萬個請求，同時還處理用戶數(shù)據(jù)并提供天氣更新。

什么是NoSQL，它有什么優(yōu)缺點？

NoSQL，指的是非關系型的數(shù)據(jù)庫。NoSQL有時也稱作Not Only SQL的縮寫，是對不同于傳統(tǒng)的關系型數(shù)據(jù)庫的數(shù)據(jù)庫管理系統(tǒng)的統(tǒng)稱。

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

NoSQL的優(yōu)點/缺點

優(yōu)點:

- 高可擴展性

- 分布式計算

- 低成本

- 架構(gòu)的靈活性，半結(jié)構(gòu)化數(shù)據(jù)

- 沒有復雜的關系

缺點:

- 沒有標準化

- 有限的查詢功能（到目前為止）

- 最終一致是不直觀的程序 （BY三人行慕課）

什么是nosql非結(jié)構(gòu)化數(shù)據(jù)庫

基本含義NoSQL(NoSQL = Not Only SQL )，意即“不僅僅是SQL”，是一項全新的數(shù)據(jù)庫革命性運動，早期就有人提出，發(fā)展至2009年趨勢越發(fā)高漲。NoSQL的擁護者們提倡運用非關系型的數(shù)據(jù)存儲，相對于鋪天蓋地的關系型數(shù)據(jù)庫運用，這一概念無疑是一種全新的思維的注入。NoSQLNoSQL數(shù)據(jù)庫的四大分類鍵值(Key-Value)存儲數(shù)據(jù)庫這一類數(shù)據(jù)庫主要會使用到一個哈希表，這個表中有一個特定的鍵和一個指針指向特定的數(shù)據(jù)。Key/value模型對于IT系統(tǒng)來說的優(yōu)勢在于簡單、易部署。但是如果DBA只對部分值進行查詢或更新的時候，Key/value就顯得效率低下了。[3] 舉例如：Tokyo Cabinet/Tyrant, Redis, Voldemort, Oracle BDB.列存儲數(shù)據(jù)庫。這部分數(shù)據(jù)庫通常是用來應對分布式存儲的海量數(shù)據(jù)。鍵仍然存在，但是它們的特點是指向了多個列。這些列是由列家族來安排的。如：Cassandra, HBase, Riak.文檔型數(shù)據(jù)庫文檔型數(shù)據(jù)庫的靈感是來自于Lotus Notes辦公軟件的，而且它同第一種鍵值存儲相類似。該類型的數(shù)據(jù)模型是版本化的文檔，半結(jié)構(gòu)化的文檔以特定的格式存儲，比如JSON。文檔型數(shù)據(jù)庫可 以看作是鍵值數(shù)據(jù)庫的升級版，允許之間嵌套鍵值。而且文檔型數(shù)據(jù)庫比鍵值數(shù)據(jù)庫的查詢效率更高。如：CouchDB, MongoDb. 國內(nèi)也有文檔型數(shù)據(jù)庫SequoiaDB，已經(jīng)開源。圖形(Graph)數(shù)據(jù)庫圖形結(jié)構(gòu)的數(shù)據(jù)庫同其他行列以及剛性結(jié)構(gòu)的SQL數(shù)據(jù)庫不同，它是使用靈活的圖形模型，并且能夠擴展到多個服務器上。NoSQL數(shù)據(jù)庫沒有標準的查詢語言(SQL)，因此進行數(shù)據(jù)庫查詢需要制定數(shù)據(jù)模型。許多NoSQL數(shù)據(jù)庫都有REST式的數(shù)據(jù)接口或者查詢API。[2] 如：Neo4J, InfoGrid, Infinite Graph.因此，我們總結(jié)NoSQL數(shù)據(jù)庫在以下的這幾種情況下比較適用：1、數(shù)據(jù)模型比較簡單；2、需要靈活性更強的IT系統(tǒng)；3、對數(shù)據(jù)庫性能要求較高；4、不需要高度的數(shù)據(jù)一致性；5、對于給定key，比較容易映射復雜值的環(huán)境。

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

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

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

關系型數(shù)據(jù)庫

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

關系型數(shù)據(jù)庫的優(yōu)勢：

1.?保持數(shù)據(jù)的一致性（事務處理）

2.由于以標準化為前提，數(shù)據(jù)更新的開銷很小（相同的字段基本上都只有一處）

3.?可以進行Join等復雜查詢

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

關系型數(shù)據(jù)庫的不足：

不擅長的處理

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

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

3.?字段不固定時應用

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

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

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

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

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

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

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

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

--字段不固定時的應用

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

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

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

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

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

優(yōu)點：

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

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

典型的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)存中，這樣保存和讀取的速度非?？?，但是當memcached停止時，數(shù)據(jù)就不存在了。由于數(shù)據(jù)保存在內(nèi)存中，所以無法操作超出內(nèi)存容量的數(shù)據(jù)，舊數(shù)據(jù)會丟失?？偨Y(jié)來說：

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

。可以進行非?？焖俚谋４婧妥x取處理

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

（2）永久性

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

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

。可以進行非?？焖俚谋４婧妥x取處理（但無法與memcached相比）

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

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

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

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

?？梢赃M行非?？焖俚谋４婧妥x取處理

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

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

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

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

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

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

（2）可以使用復雜的查詢條件

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

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

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

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

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

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

為什么要使用NoSQL？NOSQL的優(yōu)勢

這次的NoSQL專欄系列將先整體介紹NoSQL，然后介紹如何把NoSQL運用到自己的項目中合適的場景中，還會適當?shù)胤治鲆恍┏晒Π咐?，希望有成功使用NoSQL經(jīng)驗的朋友給我提供一些線索和信息。

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

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

傳統(tǒng)關系數(shù)據(jù)庫的瓶頸

傳統(tǒng)的關系數(shù)據(jù)庫具有不錯的性能，高穩(wěn)定型，久經(jīng)歷史考驗，而且使用簡單，功能強大，同時也積累了大量的成功案例。在互聯(lián)網(wǎng)領域，MySQL成為了絕對靠前的王者，毫不夸張的說，MySQL為互聯(lián)網(wǎng)的發(fā)展做出了卓越的貢獻。

在90年代，一個網(wǎng)站的訪問量一般都不大，用單個數(shù)據(jù)庫完全可以輕松應付。在那個時候，更多的都是靜態(tài)網(wǎng)頁，動態(tài)交互類型的網(wǎng)站不多。

到了最近10年，網(wǎng)站開始快速發(fā)展?；鸨恼搲⒉┛?、sns、微博逐漸引領web領域的潮流。在初期，論壇的流量其實也不大，如果你接觸網(wǎng)絡比較早，你可能還記得那個時候還有文本型存儲的論壇程序，可以想象一般的論壇的流量有多大。

Memcached+MySQL

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

Memcached作為一個獨立的分布式的緩存服務器，為多個web服務器提供了一個共享的高性能緩存服務，在Memcached服務器上，又發(fā)展了根據(jù)hash算法來進行多臺Memcached緩存服務的擴展，然后又出現(xiàn)了一致性hash來解決增加或減少緩存服務器導致重新hash帶來的大量緩存失效的弊端。當時，如果你去面試，你說你有Memcached經(jīng)驗，肯定會加分的。

Mysql主從讀寫分離

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

分表分庫隨著web2.0的繼續(xù)高速發(fā)展，在Memcached的高速緩存，MySQL的主從復制，讀寫分離的基礎之上，這時MySQL主庫的寫壓力開始出現(xiàn)瓶頸，而數(shù)據(jù)量的持續(xù)猛增，由于MyISAM使用表鎖，在高并發(fā)下會出現(xiàn)嚴重的鎖問題，大量的高并發(fā)MySQL應用開始使用InnoDB引擎代替MyISAM。同時，開始流行使用分表分庫來緩解寫壓力和數(shù)據(jù)增長的擴展問題。這個時候，分表分庫成了一個熱門技術，是面試的熱門問題也是業(yè)界討論的熱門技術問題。也就在這個時候，MySQL推出了還不太穩(wěn)定的表分區(qū)，這也給技術實力一般的公司帶來了希望。雖然MySQL推出了MySQL Cluster集群，但是由于在互聯(lián)網(wǎng)幾乎沒有成功案例，性能也不能滿足互聯(lián)網(wǎng)的要求，只是在高可靠性上提供了非常大的保證。

MySQL的擴展性瓶頸

在互聯(lián)網(wǎng)，大部分的MySQL都應該是IO密集型的，事實上，如果你的MySQL是個CPU密集型的話，那么很可能你的MySQL設計得有性能問題，需要優(yōu)化了。大數(shù)據(jù)量高并發(fā)環(huán)境下的MySQL應用開發(fā)越來越復雜，也越來越具有技術挑戰(zhàn)性。分表分庫的規(guī)則把握都是需要經(jīng)驗的。雖然有像淘寶這樣技術實力強大的公司開發(fā)了透明的中間件層來屏蔽開發(fā)者的復雜性，但是避免不了整個架構(gòu)的復雜性。分庫分表的子庫到一定階段又面臨擴展問題。還有就是需求的變更，可能又需要一種新的分庫方式。

MySQL數(shù)據(jù)庫也經(jīng)常存儲一些大文本字段，導致數(shù)據(jù)庫表非常的大，在做數(shù)據(jù)庫恢復的時候就導致非常的慢，不容易快速恢復數(shù)據(jù)庫。比如1000萬4KB大小的文本就接近40GB的大小，如果能把這些數(shù)據(jù)從MySQL省去，MySQL將變得非常的小。

關系數(shù)據(jù)庫很強大，但是它并不能很好的應付所有的應用場景。MySQL的擴展性差（需要復雜的技術來實現(xiàn)），大數(shù)據(jù)下IO壓力大，表結(jié)構(gòu)更改困難，正是當前使用MySQL的開發(fā)人員面臨的問題。

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

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

NoSQL數(shù)據(jù)庫都具有非常高的讀寫性能，尤其在大數(shù)據(jù)量下，同樣表現(xiàn)優(yōu)秀。這得益于它的無關系性，數(shù)據(jù)庫的結(jié)構(gòu)簡單。一般MySQL使用Query Cache，每次表的更新Cache就失效，是一種大粒度的Cache，在針對web2.0的交互頻繁的應用，Cache性能不高。而NoSQL的Cache是記錄級的，是一種細粒度的Cache，所以NoSQL在這個層面上來說就要性能高很多了。

靈活的數(shù)據(jù)模型

NoSQL無需事先為要存儲的數(shù)據(jù)建立字段，隨時可以存儲自定義的數(shù)據(jù)格式。而在關系數(shù)據(jù)庫里，增刪字段是一件非常麻煩的事情。如果是非常大數(shù)據(jù)量的表，增加字段簡直就是一個噩夢。這點在大數(shù)據(jù)量的web2.0時代尤其明顯。

高可用NoSQL在不太影響性能的情況，就可以方便的實現(xiàn)高可用的架構(gòu)。比如Cassandra，HBase模型，通過復制模型也能實現(xiàn)高可用。

總結(jié)NoSQL數(shù)據(jù)庫的出現(xiàn)，彌補了關系數(shù)據(jù)（比如MySQL）在某些方面的不足，在某些方面能極大的節(jié)省開發(fā)成本和維護成本。

MySQL和NoSQL都有各自的特點和使用的應用場景，兩者的緊密結(jié)合將會給web2.0的數(shù)據(jù)庫發(fā)展帶來新的思路。

當前題目：nosql數(shù)據(jù)庫心得,nosql數(shù)據(jù)庫使用更加方便
當前URL：http://m.rwnh.cn/article0/phpoio.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供軟件開發(fā)、關鍵詞優(yōu)化、用戶體驗、網(wǎng)站設計公司、自適應網(wǎng)站、網(wǎng)站設計

廣告

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