名著與大數(shù)據(jù)也能扯上關系？從紅樓夢看NoSQL數(shù)據(jù)庫

四大名著大數(shù)據(jù) 紅樓夢 NoSQL數(shù)據(jù)庫

吳大迪 | 2016-08-03 10:35

【數(shù)據(jù)猿導讀】在數(shù)據(jù)庫誕生以前，數(shù)據(jù)的管理都還處于較為低級的階段，直到數(shù)據(jù)庫系統(tǒng)的出現(xiàn)。數(shù)據(jù)庫的誕生數(shù)據(jù)庫其實也挺年輕的，也就60多歲吧。初生的事物總是有較快的發(fā)展，從最原始的數(shù)據(jù)庫誕生到早期數(shù)據(jù)庫系統(tǒng)的建立，不過短短十年而已。早期的數(shù)據(jù)庫系統(tǒng)以IBM公司開發(fā)的IMS層次性數(shù)據(jù)庫最為著名...

名著與大數(shù)據(jù)也能扯上關系？從紅樓夢看NoSQL數(shù)據(jù)庫

好吧，相信大家通過我上一篇關于Hadoop的文章，也都大概知道Hadoop是個什么鬼了(白話大數(shù)據(jù)|Hadoop究竟是什么鬼)。那么小編這次就給大家挖一挖著名的大數(shù)據(jù)核心技術之一：NoSQL數(shù)據(jù)庫吧!

就像衣服要放進衣柜一樣，數(shù)據(jù)就要放進數(shù)據(jù)庫，數(shù)據(jù)庫是管理數(shù)據(jù)的工具，人類對數(shù)據(jù)的管理真可謂是歷史悠久~ 從古人用竹子記錄到如今存入電腦，這些都是對數(shù)據(jù)的管理，在電視劇《瑯琊榜》中，就展現(xiàn)了古人精密的數(shù)據(jù)分類儲存系統(tǒng)。

但是小編認為，在數(shù)據(jù)庫誕生以前，數(shù)據(jù)的管理都還處于較為低級的階段，直到數(shù)據(jù)庫系統(tǒng)的出現(xiàn)。數(shù)據(jù)庫的誕生數(shù)據(jù)庫其實也挺年輕的，也就60多歲吧。初生的事物總是有較快的發(fā)展，從最原始的數(shù)據(jù)庫誕生到早期數(shù)據(jù)庫系統(tǒng)的建立，不過短短十年而已。早期的數(shù)據(jù)庫系統(tǒng)以IBM公司開發(fā)的IMS層次性數(shù)據(jù)庫最為著名

該數(shù)據(jù)系統(tǒng)結構簡單但不能準確反映數(shù)據(jù)之間的關系，實際操作起來又很復雜，因而這個數(shù)據(jù)庫系統(tǒng)最終消逝在歷史長流之中，小編就不對其多講了。

當今使用最多數(shù)據(jù)庫——關系型數(shù)據(jù)庫

關系型數(shù)據(jù)庫組起源于IBM的研究院E.F.Codd提出的關系模型的概念，這也成為了關系型數(shù)據(jù)庫的基礎。關系模型由關系和關系模式組成，關系模式是型，關系是它的值。其實所謂關系模型其實就是一張表!

舉個例子：

紅樓夢里的人物關系如果用數(shù)據(jù)庫來存儲的話，是這樣的：

簡單地說關系型數(shù)據(jù)庫就是能做好多好多張表(配偶表、父子(女)表、母子(女)表……)，把表放在一起構成一個數(shù)據(jù)庫。

再配合簡單易懂的操作語句(SQL)，用于對數(shù)據(jù)的查找、添加、刪除和改動，這些就構成了關系型數(shù)據(jù)庫~ 關系型數(shù)據(jù)庫總體說來，操作簡單，理論基礎非常扎實。

賈政生完探春以后又生了寶玉怎么辦?數(shù)據(jù)庫回答：添加一行唄上面那一堆表示新手建的。老手會這樣建立表格：

是不是更加清楚了?雖然關系型數(shù)據(jù)庫很好用，但它一切都是建立在關系之上的。如果關系變多了，比如除了上述父親、母親等等屬性外，還需要增加一條大女兒的屬性，那么程序猿哥哥就會覺得你好討厭呀，為什么不早點說啦。。。表都建好了，牽一發(fā)而動千鈞又或者除了存儲這些文字描述外，你還要存一張賈政的照片，以及修過圖的照片……程序猿哥哥說：咱做不了，洗洗睡吧

后起之秀——NoSQL數(shù)據(jù)庫

NoSQL是泛指非關系型數(shù)據(jù)庫，全名叫Not Only SQL(不僅僅是SQL)，所以說NoSQL是一場數(shù)據(jù)庫的革命性運動，旨在打破關系型數(shù)據(jù)庫統(tǒng)治的格局，解決關系型數(shù)據(jù)庫所解決不了的問題。

1.NoSQL是一類數(shù)據(jù)庫的統(tǒng)稱，不同的NoSQL是為了解決不同問題而開發(fā)的。著名的NoSQL數(shù)據(jù)庫有MongDB, HBase。其中Facebook是HBase的最大用戶。

2.NoSQL有一個共同的特點，就是能儲存海量的數(shù)據(jù)，當然還是用我們熟知的分布式的思想。(戳這里回憶什么是分布式)NoSQL沒有復雜的關系模式，表示可以拆分的，關系型數(shù)據(jù)庫是無法拆分的，因為拆分會破壞關系模式。

3.在數(shù)據(jù)如此之多的今天，我們都把數(shù)據(jù)存進表中，那么查詢效率太低了。像紅樓夢里面人物數(shù)量是比較少的，實際數(shù)據(jù)庫中上億條數(shù)據(jù)，查起來太慢啦。于是有些NoSQL(例如HBase等)為這種問題想出的方法就是KV儲存

4.對數(shù)據(jù)的儲存類型沒有要求，什么都能往里面塞，這也是NoSQL可以儲存圖像等復雜文件的原因。其中有專業(yè)圖儲存的Neo4J，文檔儲存比較占優(yōu)勢的MongoDB，其他的還有Cassandra等。

知道這段你們又不想看了，還是舉個栗子吧，依舊以上面紅樓夢為例