共計 8262 個字符,預計需要花費 21 分鐘才能閱讀完成。
丸趣 TV 小編給大家分享一下關系數據庫和 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 數據庫根據數據的存儲模型和特點分為很多種類。
類型
部分代表
特點
列存儲
Hbase
Cassandra
Hypertable
顧名思義,是按列存儲數據的。最大的特點是方便存儲結構化和半結構化數據,方便做數據壓縮,對針對某一列或者某幾列的查詢有非常大的 IO 優勢。
文檔存儲
MongoDB
CouchDB
文檔存儲一般用類似 json 的格式存儲,存儲的內容是文檔型的。這樣也就有有機會對某些字段建立索引,實現關系數據庫的某些功能。
key-value 存儲
Tokyo Cabinet / Tyrant
Berkeley DB
MemcacheDB
Redis
可以通過 key 快速查詢到其 value。一般來說,存儲不管 value 的格式,照單全收。(Redis 包含了其他功能)
圖存儲
Neo4J
FlockDB
圖形關系的最佳存儲。使用傳統關系數據庫來解決的話性能低下,而且設計使用不方便。
對象存儲
db4o
Versant
通過類似面向對象語言的語法操作數據庫,通過對象的方式存取數據。
xml 數據庫
Berkeley DB XML
BaseX
高效的存儲 XML 數據,并支持 XML 的內部查詢語法,比如 XQuery,Xpath。
以上 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 來作為我們的存儲呢?這并不是一個很好回答的問題,影響我們選擇的因素有很多,而選擇也可能有多種,隨著業務場景,需求的變更可能選擇又會變化。我們常常需要根據如下情況考慮:
數據結構特點。包括結構化、半結構化、字段是否可能變更、是否有大文本字段、數據字段是否可能變化。
寫入特點。包括 insert 比例、update 比例、是否經常更新數據的某一個小字段、原子更新需求。
查詢特點。包括查詢的條件、查詢熱點的范圍。比如用戶信息的查詢,可能就是隨機的,而新聞的查詢就是按照時間,越新的越頻繁。
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 的示例分析”這篇文章的所有內容,感謝各位的閱讀!相信大家都有了一定的了解,希望分享的內容對大家有所幫助,如果還想學習更多知識,歡迎關注丸趣 TV 行業資訊頻道!