關系數據庫和nosql的示例分析

小編給大家分享一下關系數據庫和nosql的示例分析，相信大部分人都還不怎么了解，因此分享這篇文章給大家參考一下，希望大家閱讀完這篇文章后大有收獲，下面讓我們一起去了解一下吧！

NoSQL概念

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

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

傳統關系數據庫的瓶頸

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

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

到了最近10年，網站開始快速發展。火爆的論壇、博客、sns、微博逐漸引領web領域的潮流。在初期，論壇的流量其實也不大，如果你接觸網絡比較早，你可能還記得那個時候還有文本型存儲的論壇程序，可以想象一般的論壇的流量有多大。

Memcached+MySQL

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

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

Mysql主從讀寫分離

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

分表分庫

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

MySQL的擴展性瓶頸

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

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

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

NOSQL的優勢

易擴展

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

大數據量，高性能

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

靈活的數據模型

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

高可用

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

總結

NoSQL數據庫的出現，彌補了關系數據（比如MySQL）在某些方面的不足，在某些方面能極大的節省開發成本和維護成本。

MySQL和NoSQL都有各自的特點和使用的應用場景，兩者的緊密結合將會給web2.0的數據庫發展帶來新的思路。讓關系數據庫關注在關系上，NoSQL關注在存儲上。

NoSQL的分類

NoSQL僅僅是一個概念，NoSQL數據庫根據數據的存儲模型和特點分為很多種類。

以上NoSQL數據庫類型的劃分并不是絕對，只是從存儲模型上來進行的大體劃分。它們之間沒有絕對的分界，也有交差的情況，比如Tokyo Cabinet / Tyrant的Table類型存儲，就可以理解為是文檔型存儲，Berkeley DB XML數據庫是基于Berkeley DB之上開發的。

NoSQL還是關系數據庫

雖然09年出現了比較激進的文章《關系數據庫已死》，但是我們心里都清楚，關系數據庫其實還活得好好的，你還不能不用關系數據庫。但是也說明了一個事實，關系數據庫在處理WEB2.0數據的時候，的確已經出現了瓶頸。

那么我們到底是用NoSQL還是關系數據庫呢？我想我們沒有必要來進行一個絕對的回答。我們需要根據我們的應用場景來決定我們到底用什么。

如果關系數據庫在你的應用場景中，完全能夠很好的工作，而你又是非常善于使用和維護關系數據庫的，那么我覺得你完全沒有必要遷移到NoSQL上面，除非你是個喜歡折騰的人。如果你是在金融，電信等以數據為王的關鍵領域，目前使用的是Oracle數據庫來提供高可靠性的，除非遇到特別大的瓶頸，不然也別貿然嘗試NoSQL。

然而，在WEB2.0的網站中，關系數據庫大部分都出現了瓶頸。在磁盤IO、數據庫可擴展上都花費了開發人員相當多的精力來優化，比如做分表分庫（database sharding）、主從復制、異構復制等等，然而，這些工作需要的技術能力越來越高，也越來越具有挑戰性。如果你正在經歷這些場合，那么我覺得你應該嘗試一下NoSQL了。

選擇合適的NoSQL

如此多類型的NoSQL，而每種類型的NoSQL又有很多，到底選擇什么類型的NoSQL來作為我們的存儲呢？這并不是一個很好回答的問題，影響我們選擇的因素有很多，而選擇也可能有多種，隨著業務場景，需求的變更可能選擇又會變化。我們常常需要根據如下情況考慮：

1. 數據結構特點。包括結構化、半結構化、字段是否可能變更、是否有大文本字段、數據字段是否可能變化。

2. 寫入特點。包括insert比例、update比例、是否經常更新數據的某一個小字段、原子更新需求。

3. 查詢特點。包括查詢的條件、查詢熱點的范圍。比如用戶信息的查詢，可能就是隨機的，而新聞的查詢就是按照時間，越新的越頻繁。

NoSQL和關系數據庫結合

其實NoSQL數據庫僅僅是關系數據庫在某些方面（性能，擴展）的一個彌補，單從功能上講，NoSQL的幾乎所有的功能，在關系數據庫上都能夠滿足，所以選擇NoSQL的原因并不在功能上。

所以，我們一般會把NoSQL和關系數據庫進行結合使用，各取所長，需要使用關系特性的時候我們使用關系數據庫，需要使用NoSQL特性的時候我們使用NoSQL數據庫，各得其所。

舉個簡單的例子吧，比如用戶評論的存儲，評論大概有主鍵id、評論的對象aid、評論內容content、用戶uid等字段。我們能確定的是評論內容content肯定不會在數據庫中用where content=’’查詢，評論內容也是一個大文本字段。那么我們可以把 主鍵id、評論對象aid、用戶id存儲在數據庫，評論內容存儲在NoSQL，這樣數據庫就節省了存儲content占用的磁盤空間，從而節省大量IO，對content也更容易做Cache。

//從MySQL中查詢出評論主鍵id列表 
commentIds=DB.query("SELECT id FROM comments where aid='評論對象id' LIMIT 0,20"); 
//根據主鍵id列表，從NoSQL取回評論實體數據 
CommentsList=NoSQL.get(commentIds);

NoSQL代替MySQL

在某些應用場合，比如一些配置的關系鍵值映射存儲、用戶名和密碼的存儲、Session會話存儲等等，用NoSQL完全可以替代MySQL存儲。不但具有更高的性能，而且開發也更加方便。

NoSQL作為緩存服務器

MySQL+Memcached的架構中，我們處處都要精心設計我們的緩存，包括過期時間的設計、緩存的實時性設計、緩存內存大小評估、緩存命中率等等。

NoSQL數據庫一般都具有非常高的性能，在大多數場景下面，你不必再考慮在代碼層為NoSQL構建一層Memcached緩存。NoSQL數據本身在Cache上已經做了相當多的優化工作。

Memcached這類內存緩存服務器緩存的數據大小受限于內存大小，如果用NoSQL來代替Memcached來緩存數據庫的話，就可以不再受限于內存大小。雖然可能有少量的磁盤IO讀寫，可能比Memcached慢一點，但是完全可以用來緩存數據庫的查詢操作。

規避風險

由于NoSQL是一個比較新的東西，特別是我們選擇的NoSQL數據庫還不是非常成熟的產品，所以我們可能會遇到未知的風險。為了得到NoSQL的好處，又要考慮規避風險，魚與熊掌如何兼得？

現在業內很多公司的做法就是數據的備份。在往NoSQL里面存儲數據的時候還會往MySQL里面存儲一份。NoSQL數據庫本身也需要進行備份（冷備和熱備）。或者可以考慮使用兩種NoSQL數據庫，出現問題后可以進行切換（避免出現digg使用Cassandra的悲劇）。

總結

本文只是簡單的從MySQL和NoSQL的角度分析如何選擇，以及進行融合使用。其實在選擇NoSQL的時候，你可能還會碰到關于CAP原則，最終一致性，BASE思想的考慮。因為使用MySQL架構的時候，你也會碰到上面的問題，所以這里沒有闡述。

http://www.infoq.com/cn/news/2013/11/introducing-nosql

列簇存儲

面向列的DBMS是這樣一種數據庫管理系統，它將數據表存儲為數據列而非行的形式。從物理上來說，表是列的集合，每一列從本質上來說都是只有一個字段的表。這些數據庫通常用于分析系統、商業智能與分析型數據存儲。

優點：

• 可以比較數據，因為在表的一列中，數據通常都是同種類型的。

• 可以通過便宜、性能一般的硬件實現高速的查詢性能；由于壓縮的原因，相對于關系型數據庫來說，這種方式磁盤上的數據所占據的空間要少5到10倍。

缺點：

• 通常沒有事務。

• 對于熟悉傳統RDBMS的開發者來說存在不少限制。

典型代表：

• HBase

• Cassandra

• Accumulo

• Amazon SimpleDB

鍵值存儲

你可以通過這種數據庫將鍵值對存儲到持久化存儲中，隨后使用鍵來讀取值。那么對于這種初看起來用途非常有限的解決方案來說有哪些好處呢？在根據鍵來保存/讀取值時，系統是非常高效的，因為它沒有SQL處理器、索引系統以及分析系統等諸多限制。這種解決方案提供了最高效的性能，代價最低的實現以及可伸縮性。

優點：

• RDBMS太慢了，SQL游標的負擔過于沉重。

• 采用RDBMS的解決方案來存儲少量數據的代價有些大。

• 沒必要使用SQL查詢、索引、觸發器、存儲過程、臨時表、表單以及視圖等等。

• 由于其輕量級的設計，鍵值數據庫可以很容易實現可伸縮性以及高性能。

缺點：

• 關系型數據庫的限制可以從底層就確保數據的完整性，而鍵值存儲就沒有這些限制，數據的完整性是由應用來控制的。在這種情況下，數據的完整性可能會由于應用代碼的錯誤而做一些妥協。

• 在RDBMS中，如果模型設計良好，那么數據庫的邏輯結構就能完全反映出存儲數據的結構，并且與應用的結構有所不同（數據是獨立于應用的）。對于鍵值存儲來說，要想取得這種效果是非常困難的事情。

典型代表：

• Amazon DynamoDB

• Riak

• Redis

• LevelDB

• Scalaris

• MemcacheDB

• Kyoto Cabinet

文檔存儲

文檔存儲指的是用于存儲、搜索與管理面向文檔的信息（半結構化數據）的程序，其中心概念就是文檔。具體的面向文檔數據庫的實現是不同的，不過總的來說，他們都會以各種標準化格式對數據（文檔）進行封裝與加密，主要格式有XML、YAML、JSON、BSON、PDF等等。

優點：

• 足夠靈活的查詢語言。

• 易于水平擴展。

缺點：

在很多時候原子性是得不到保障的。

典型代表：

• MongoDB

• Couchbase

• CouchDB

• RethinkDB

圖型數據庫

圖型數據庫指的是使用圖結構的數據庫，通過結點、邊與屬性來表示和存儲數據。根據定義，圖型數據庫是一種提供了無需索引而彼此鄰接的存儲系統。這意味著每個元素都包含了直接指向鄰接元素的指針，因此沒必要再通過索引進行查找了。

優點：

• 對于關聯數據集的查找速度更快。

• 可以很自然地擴展為更大的數據集，因為他們無需使用代價高昂的連接運算符。

缺點：

• RDBMS可以用在更為通用的場景下，圖型數據庫只適合類似于圖的數據。

典型代表：

• Neo4j

• FlockDB

• InfoGrid

• OrientDB

多模數據庫

這些數據庫包含了多種數據庫的特性。

有兩種不同的產品分組可以認為是多模的：

• 支持多種數據模型和用例的多模數據庫。 比如說，ArangoDB宣稱它擁有鍵值存儲的好處，同時還提供了面向文檔以及圖型數據庫的支持。

• 支持多種模式的通用目的的數據庫。 比如說，Oracle的MySQL 5.6支持SQL方式的訪問，也可以通過Memcached API實現鍵值訪問。

典型代表：

• ArangoDB

• Aerospike

• Datomic

http://coolshell.cn/articles/7270.html

要開始討論數據建模技術，我們不得不或多或少地先系統地看一下NoSQL數據模型的成長的趨勢，以此我們可以了解一些他們內在的聯系。下圖是NoSQL家族的進化圖，我們可以看到這樣的進化：Key-Value時代，BigTable時代，Document時代，全文搜索時代，和Graph數據庫時代：（陳皓注：注意圖中SQL說的那句話，NoSQL再這樣發展下去就是SQL了，哈哈。）

NoSQL Data Models

首先，我們需要注意的是SQL和關系型數據模型已存在了很長的時間，這種面向用戶的自然性意味著：

• 最終用戶一般更感興趣于數據的聚合顯示，而不是分離的數據，這主要通過SQL來完成。

• 我們無法通過人手工控制數據的并發性，完整性，一致性，或是數據類型校驗這些東西的。這就是為什么SQL需要在事務，二維表結構（schema）和外表聯合上做很多事。

另一方面，SQL可以讓軟件應用程序在很多情況下不需要關心數據庫的數據聚合，和數據完整性和有效性進行控制。而如果我們去除了數據一致性，完整性這些東西，會對性能和分布存儲有著重的幫助。正因為如此，我們才有數據模型的進化：

• Key-Value 鍵值對存儲是非常簡單而強大的。下面的很多技術基本上都是基于這個技術開始發展的。但是，Key-Value有一個非常致命的問題，那就是如果我們需要查找一段范圍內的key。（陳皓注：學過hash-table數據結構的人都應該知道，hash-table是非序列容器，其并不像數組，鏈接，隊列這些有序容器，我們可以控制數據存儲的順序）。于是，有序鍵值
  （Ordered Key-Value） 數據模型被設計出來解決這一限制，來從根本上提高數據集的問題。

• Ordered Key-Value 有序鍵值模型也非常強大，但是，其也沒有對Value提供某種數據模型。通常來說，Value的模型可以由應用負責解析和存取。這種很不方便，于是出現了 BigTable類型的數據庫，這個數據模型其實就是map里有map，map里再套map，一層一層套下去，也就是層層嵌套的key-value（value里又是一個key-value），這種數據庫的Value主要通過“列族”（column
  families），列，和時間戳來控制版本。（陳皓注：關于時間戳來對數據的版本控制主要是解決數據存儲并發問題，也就是所謂的樂觀鎖，

• Document databases 文檔數據庫 改進了 BigTable 模型，并提供了兩個有意義的改善。第一個是允許Value中有主觀的模式（scheme），而不是map套map。第二個是索引。 Full Text Search Engines 全文搜索引擎可以被看作是文檔數據庫的一個變種，他們可以提供靈活的可變的數據模式（scheme）以及自動索引。他們之間的不同點主要是，文檔數據庫用字段名做索引，而全文搜索引擎用字段值做索引。

• Graph data models 圖式數據庫 可以被認為是這個進化過程中從 Ordered Key-Value 數據庫發展過來的一個分支。圖式數據庫允許構建議圖結構的數據模型。它和文檔數據庫有關系的原因是，它的很多實現允許value可以是一個map或是一個document。

以上是“關系數據庫和nosql的示例分析”這篇文章的所有內容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內容對大家有所幫助，如果還想學習更多知識，歡迎關注億速云行業資訊頻道！