《NoSQL數據庫類型》要點：
本文介紹了NoSQL數據庫類型，希望對您有用。如果有疑問，可以聯系我們。

本文摘自 Introducing Data Science,我們將向您介紹四大NoSQL數據庫類型.

有四大NoSQL類型：鍵值存儲(key-value store),文件存儲(document store),列導向的數據庫(Column-Oriented Database)和圖形數據庫(graph database).每種類型都辦理了傳統關系數據庫無法辦理的問題.實際的實現往往是這些組合的組合.例如,結合NoSQL類型,Orientdb是一個多模式的數據庫.Orientdb是圖形數據庫,每個節點都是一個文檔.

在進入不同的NoSQL數據庫之前,讓我們看看與關系數據庫之間的比較.傳統關系數據庫正在努力的走向規范化：確保每一個數據都只存儲一次.正規化標志著他們的結構設置.舉個例子來說,如果你想把一個人和他的喜好存儲為數據,那么你就可以建兩個表：一個表存儲為人,一個表存儲他們的喜好.如圖1所示,一個附加的表是必要的,因為他們存在著很多關系：一個人可以有多個喜好,然而一個喜好也可以有很多人喜歡.

圖1

一個全面的關系數據庫可以由許多實體和聯系表.現在讓我們看看NoSQL不同的類型的數據庫之間的比擬.

Column databases store列存儲數據庫

行數據庫實際上就是傳統的關系數據庫,每一行有一行id,并在一個表中存儲的行中的每個字段.假設,關于喜好,沒有額外的表來存儲并且你只有一個表來描述人,如圖2所示.注意,在這種情況下,你有輕微的反規范化,因為喜好是可以重復的.如果喜好這個信息是一個額外的信息,但在你使用時并不是必不可少的,添加它作為一個列表內的喜好列是可以接受的方法.但是如果這些信息對一個單獨的表來說是不夠的,它應該被存儲在所有的?

圖2

每次你在行存據庫中尋找某個數據,進行每行掃描,不管你必要哪列.假設你只必要生日在9月的列表.數據庫將在表中從上到下和從左到右掃描所有數據,如圖3所示,最終返回生日列表.

圖3

索引數據在某些列可以顯著提高查詢速度,但索引每一列帶來額外的開銷和數據庫仍然是掃描所有列.

Column databases store分別存儲每一列,允許更快的掃描時,只涉及一小部分列.見圖4.

圖4

這個布局看起來很像一個以行為導向的數據庫,每一列都有一個索引.一個數據庫索引是一種數據結構,允許在存儲空間上快速查找數據和額外的寫(索引更新).索引映射到數據的行數,而一個列數據庫將數據映射到行數,這樣計算變得更快,所以很容易看到有多少人喜歡射箭.例如,單獨存儲的列也可以優化壓縮,因為只有一個數據類型的表.

那么,何時該使用Row-Oriented Database和Column-Oriented Database呢?在Column-Oriented Database中,很容易添加另一個列,因為不受它的影響.但添加整個完整記錄必要調整所有的表.這使得Row-Oriented Database更好于Column-Oriented Database在聯機事務處理(OLTP)方面,因為他可以不斷地添加或更改記錄.

Column-Oriented Database在執行分析和申報時的表現: 求和值和計算條目.Row-Oriented Database通常是實際交易的操作數據庫(如銷售).夜間批處理作業將用于數據庫更新,支持客戶快速查找和聚合使用MapReduce算法申報.例如column-family stores are Apache HBase、Facebook的Cassandra、Hypertable和the grandfather of wide-column stores、谷歌的 BigTable.

KEY-VALUE STORES 鍵值存儲

鍵值存儲是最復雜的NoSQL數據庫.顧名思義,鍵值對的集合,如圖5所示,這種簡單性使得他們成為最可伸縮的NoSQL數據庫類型,能夠存儲大量的數據.

圖5

鍵值存儲的值可以是任何東西：一個字符串,一個數字,而且也是一個新的鍵值對封裝在一個對象.如圖6顯示了一個稍微復雜鍵值結構.關鍵值存儲的例子有Redis、Voldemort、Riak和Amazon’s Dynamo.

{"internal data":[{"entities":[         {"customer":[ {"id:1,"name":"Freddy"}, {"id:2,"name":"Fritz"} }], {"legal entities":[ {"id":1,"company":"Maiton"} ]}]},{"Products":[     {"furniture":[         {"id" :1,"name":"Octopus Table","stock":1}      ]}]}]} 

圖6

DOCUMENT STORES 文檔存儲

文檔存儲是鍵值存儲的復雜性的一個步驟：一個文檔存儲庫確實假定一個特定的文檔結構,可以用一個模式來指定.文檔存儲出現最自然的NoSQL數據庫類型中,因為它們用于存儲日常文檔,并且他們允許復雜的查詢和計算,這往往已經成為聚合形式的數據.在關系數據庫中存儲的方式是從一個正常化的角度來看,所有的一切都應該存儲一次,并通過外鍵連接.文件存儲的關心小的正常化,只要數據是在一個結構是有意義的.關系數據模型并不總是適合某些業務案例.

報紙或雜志,例如,包含文章.要把這些存儲在關系數據庫中,首先要把它們切碎：這篇文章正文在一個表中,作者和作者所有的信息,以及在一個網站上頒發的文章的評論.如圖7所示,報紙上一篇文章也可以存儲為一個單一的實體,這降低了對于習慣看到文章內容所消耗的時間.文檔存儲以MongoDB和CouchDB為例子.

圖7

GRAPH DATABASES 圖數據庫

最后一個大的NoSQL數據庫類型是最復雜的一個,為了高效地存儲實體之間的關系.數據是高度互聯的,如社會網絡,科學論文引用,或資本資產集群,圖形數據庫的答案.圖或網絡數據主要有2個組成部分：

節點：實體自己.在社交網絡中,這可能是人.

邊：實體間的關系.這種關系用一條線來表示,并且有它本身的特性.邊可以有一個方向,例如,如果箭頭表示誰是誰的老板.

圖可以變的非常復雜來給定足夠的關系和實體類型.圖8已經表明了復雜性,只有有限數量的實體.圖數據庫像Neo4j還聲稱保持ACID,而文檔存儲和鍵值存儲保持BASE.

圖8

這個可能性是無限的,因為世界正變得越來越互聯,Graph databases可能會贏過其他類型的數據庫,包含如今仍然占主導地位的關系數據庫.排名最受歡迎的數據庫和他們是如何進展可以點擊：最新數據庫排名

翻譯：CSDN編纂孫思,關注數據庫,歡迎加入CSDN 數據庫討論QQ群：123038767.尋求報道或投稿,請聯系sunsi@csdn.net.

2016年3月18日-19日,由CSDN重磅打造的數據庫核心技術與實戰應用峰會、互聯網應用架構實戰峰會將在上海舉行.這兩場峰會將邀請業內頂尖的架構師和技術專家,共同探討高可用/高并發系統架構設計、新技術應用、移動應用架構、微服務、智能硬件架構、云數據庫實戰、新一代數據庫平臺、產品選型、性能調優、大數據應用實戰等領域的熱點話題與技術.(報名參會)

維易PHP培訓學院每天發布《NoSQL數據庫類型》等實戰技能，PHP、MYSQL、LINUX、APP、JS,CSS全面培養人才。

轉載請注明本頁網址：
http://www.fzlkiss.com/jiaocheng/9332.html