關於大資料和資料庫的討論

標籤：

前幾天上了水木社區，發現還是有大牛的，看了關於大資料和資料庫的討論，發現還是蠻有意思的，限於篇幅和版面，我做了部分的整理。
先看看這位人士的分析，對於行業的現狀還是很有瞭解，不是大學教授就是行業先鋒。
#####################################
大資料是一種方案，而不是一種模型。方案有方案的壓力， 
只能使出各種絕招來“解決”問題。既然是方案，就包括了存貯，運算，輸入和輸出等等。 就運算模型上，因為要更好地採用廉價硬體，實踐出如hadoop/mapreduce這樣的計算模型， 還有就是storm，以及其他模型。在存貯方面，也有很大的變化。 
  
其實大資料最需要解決的存貯系統問題很大程度上是I/O與計算任務的關係。 RDBM雖然已經考慮了儲存系統的特點，設計時考慮了讀寫資料帶來的代價， 但這些分析和研究是基於70年代，80年代的硬體架構。現在的硬體架構下， 包括網路架構，和70年代80年代的差別已經很大。
比如80年代是不可以想象 個人電腦有2T的硬碟，即使是90年代末，這麼大的存貯系統是必須上磁碟矩陣， 現在一個單碟硬碟就能解決。然而硬碟磁頭這種機械組件並沒有象容量一樣升級， 不單還是以前那樣龜速（當然要快很多，但還是慢），而且還是象以前一樣脆弱。 這個直接
導致了人們紛紛質疑RDBMS中的範式的合理性：解決冗餘所即省的空間意義不大，但隨機讀寫讓磁頭速度問題突顯。 
  
回到大資料與資料庫的關係。資料庫其實有很多模型。關聯式模式只是其中一種。 然而關聯式模式的基礎，關係代數，在數學層面解決了大量資料存貯相關的問題 （比如笛卡爾積讓獨立存貯的不同資料來源能無限擴充進一張虛擬表，映射則又解決了表或虛擬表資料的選擇與定位，使得無論
存貯表有多大，還是多小，資料的存貯， 尋找都不是問題）。正因為關聯式模式的理論支撐，讓關聯式資料庫有了統一天下的現狀。 然而資料存貯方案還是有很多種的。key-value是其中一種，oodb也是一種， 即使是直接存貯json也可以是一種。這些存貯模式沒有象關聯式模式那樣的數學支援， 
使得他們從一開始就是二等公民，三等公民。但二等公民也是公民，無論他們有多萎縮。 
  
另一種就是NewSQL。這種資料庫採用的還是關聯式資料庫模型，但relax normalization。 也就是說資料存放區和查詢還是二維關聯式模式，笛卡爾積，projection這些還是資料庫 的根本，而SQL也很容易在這些資料庫上實現和使用，唯一不同的是他們建議人們不要 使用範式，而是利用“冗餘”資料
帶來的“好”處讓資料庫效率更高。比如列式資料庫就是 一種典型的newSQL資料庫。列式資料庫提出資料的存貯和讀取上，列關聯遠強與行關聯， 這表現為大多數時候使用者關注的是同一列，或同幾列，而不是同一行的所有列；從存貯上， 他們還發現同一列的資料相似性很高，如果把這些資料放在一起存貯，有可能引入非常好的 壓縮演算法（未列是壓縮）。比如有一個列是國藉，傳統RDBM會有一個表存貯國家，然後 獲得一個nation_id，在其他地方使用id而不是國家名稱。然而New SQL的思想是直接在所有用到國藉的地方直接寫上國家名稱，因為全世界就那麼幾個國家，如果有 
一百萬條記錄，其他真正有意義的就是一百多條記錄，壓縮一下根本就不是個事。這樣的好處就是每次查詢不需要用笛卡爾積護展另一張表，而只需要讀同一個地方，資料就出來了。 也就是磁頭重新置放的機會少很多。 
  
還有就是索引。在rdbm上，索引是用來加速查詢的。然而索引的使用，讓讀和寫的速度兩三個數量組的下降。為瞭解決這個問題，有的人就提出直接複製一次資料，而不是使用索引。 也就是說，如果有A, B, C三列，A和B都做索引，就存成, B, C一張表，A, , C 另一張表。需要A做索引時取, B, C，需要B做索引時另一張。這種方法看起來很笨，但很有效。當然，資料量也出現了幾倍的提升，這是一個不得不考慮的問題。 
  
第三就是資料的更新。以前總以為要更新資料庫找到原來的記錄，改一改資料就行。 但現在發現，改一個記錄和寫大量記錄的差別不大，如果改的量大時，後者優勢更大。 所以現在很多資料庫系統實質上是read-only database，也就是只能添記錄，不能改記錄。 記錄的改動是通過添加一條新記錄，並記錄添加時間，然後在讀出時和原有的記錄合并。 
  
有了read-only，資料的存貯就可以大大最佳化。比如一個block的記錄直接用lzo演算法 壓縮起來放到hdfs上 —— 相象一下如果要改動一個壓縮了的記錄是多讓人頭痛的事。 

話鋒一處，馬上產生了共鳴。看看這位人士的分析。
##########################################
1. 非常同意大資料是個平台的觀點，它不僅僅關係到資料的儲存和訪問，還涉及到資料的匯入，匯出，分析，應用等。 
2. 大資料的核心問題是分布式，包含分布式資料存放區，分散式運算（包含分布式SQL引擎，分布式資料採礦演算法， 。。。）。很多MPP資料庫可以認為也是大資料範疇的東西，比如Teradata, Oracle ExaData, Greenplum, IBM DPF...  
3. 相對於資料冗餘，我覺得範式主要解決的是資料一致性的問題。這個在事務性應用中比較關鍵。 
4. 關聯式資料庫中的很多特性都很好，比如範式、一致性約束、索引、基於統計資訊的SQL最佳化器等，不是大資料平台不想要，而是由於CAP准側的約束，這些特性在分布式系統上的實現都很困難，所以必須做些取捨或是針對性的開發不同的版本來滿足不同的應用。
很多的SQL on Hadoop/SQL on HDFS都在開發基於統計資訊的SQL最佳化器，也在添加 一些比較簡單的索引。  

不知道怎麼說著說著，一不小心就扯到rac和exadata了，看看他們怎麼說的。
##########################################
oracle/rac和oracle exadata不是一個東西。exadata儲存之上可以架普通的oracle  server,也可以架oracle rac。 
share nonthing架構不一定廉價，Teradata就賣的很貴。基於hadoop的方案之所以cost  effective，是因為1.hdfs提供的資料冗餘能夠保證一個節點的宕機不會造成資料丟失以及整個系統宕機,從而能夠使得這些方案能夠在廉價硬體上部署。 
2.hadoop/yarn/tez/spark等提供了免費且開源的分散式運算架構，從而使得在上面進行大資料方案開發成本降低。 大資料本質上是分散式運算，share nothing是分散式運算中可擴充性的必然選擇； 因為share的越多，可擴充性就越弱

最後還不忘拿pg和mongo來做一個比較，這是約架的節奏啊。
########################################
mongodb的記憶體管理太原始，如果活動資料大於記憶體，效能急劇下降。同時無schema導致資料體積大，吃更多記憶體。 
postgresql和mongodb都有空間索引支援，能力應該類似。postgresql的事務支援又秒殺mongodb. postgresql 9.4後效能有不錯提升。 
所以mongodb在這方面不如pg 

java企業級通用許可權安全架構源碼 SpringMVC mybatis or hibernate+ehcache shiro druid bootstrap HTML5

【java架構源碼下載】

關於大資料和資料庫的討論