RDBMS vs. NoSQL Clojure概述
RDBMS vs. NoSQL 合作還是競爭
數據庫要解決的主要問題
不管是RDBMS還是NoSQL,在大的方面他們都屬于數據庫這個范疇,這個范疇之內所要面臨的一些共同問題有哪些呢。下面的圖是一個大致的歸納。
從圖中可以看出,一個數據庫系統主要解決以下幾個問題:
結構化和非結構化
RDBMS的一大特點就是數據是嚴格結構化的,存入的數據必須屬于預先定義好的某一數據結構,否則就不能存入,而NoSQL則放松了這一要求。
在不同的應用場景中,兩者優缺點立顯,比如銀行系統,要存儲的數據格式一般是事先可以預估,其改變的可能比較少,再比如稅務之類的。
而在電商和互聯網應用中,往往意味著經常進行數據格式的更改,如果采用RDBMS,schema改變帶來的開發工作則會非常巨大。
數據的一致性
在數據的一致性方面,RDBMS通過外鍵約束或者trigger等方式在server側來保證數據的約束。
從達到數據一致性的時間來看RDBMS是立即一致(immediately consistency)而NoSQL則是最終一致(eventual consistency),舉個應用場景,對銀行賬戶的任何修改都必須是即時一致的,約不參容忍不一致的出現。
Scalability
如果說到數據庫的動態擴容,則NoSQL明顯技勝一籌。
當然MySQL的NDB cluster在動態擴容方面,其能力也還是不錯的。
數據分析或數據挖掘工作
從數據分析的層面來看,RDBMS和NoSQL之間的成熟度差距是巨大的。
RDBMS為數據分析提供了一個清晰的標準,那就是SQL。利用SQL有非常明確的標準來進行規范,利用這些規范可以對數據進行各種各樣的查詢,而且內置了許多函數,如average,sum,count之類,讓在進行報表分析時,輕松異常。
NoSQL 中的No有人解釋為not only的意思,但何嘗又不是No SQL二字的縮寫了即there is no sql interface in the database system. 當然像MongoDB是支持Sql like的查詢語句的,但NoSQL確實沒有一套標準規范對數據的查詢和分析。
機會在哪里
正因為NoSQL中沒有一個統一進行數據分析的標準,所以現在出現了很多實時數據處理分析的框架,最火的莫過于Spark,且Spark有最強大的hadoop發行廠商Cloudera的強勁支持,大有一統NoSQL數據分析框架之勢,未來的發展勢頭將會異常迅猛。學會使用Spark有可能會是數據分析行業的一個基本的從業要求。
總結
個人以為NoSQL不是以傳統RDBMS的終結者身份出現,而是對RDBMS的一種補充來填補RDBMS所不能勝任領域的技術實現。
NoSQL在發展的初期,其實是通過放棄RDBMS的多種約束來達到其兩個主要目的,一是數據的海量存儲二是數據的動態可擴。至于數據分析則實現手法各異,對實時性的要求不是太高,故MapReduce之類的離線分析能滿足其需求。
在相當長的時間內會MySQL還是有飯吃的,當然需要同時花相當的精力來緊跟NoSQL的技術發展。
Clojure概述
楔子
由于閱讀storm源碼的原因,頭一次接觸到Clojure。沒有花特別的時間來研究clojure語法,只是在一些特殊的用法時,才查了一下clojure官網的文檔,基本上能夠很快的理解其意思。
在理解了storm中的基本處理流程之后,花了一段時間好好的看了幾本clojure編程的書籍,書籍名稱及評價分別如下。
語言概述
clojure是龐大的lisp編程語言家族中的一個新成員,所以其有lisp語言的鮮明特征,一切皆函數。
clojure語言的核心主要涉及如下幾個部分。
?
練習
clojure的語法非常簡潔優雅,花不了半天的時間就能大體知道個大概,但要想徹底的掌握還是需要大量的練習才行。
哪些題目值得花時間,哪些不值一提,這個已經有人想到了,并搞了個很好的網站。http://www.4clojure.com?到該網站注冊一個用戶名,總共150道題,難度由淺入深,是不可多得的學習資源。
clojure中的語法糖不是特別多,但想一個不落的記處還是有點累,為此完全可以將clojure cheatsheet放置在辦公桌最顯眼的地方,不多就兩張A4張。http://clojure.org/cheatsheet
總結
以上是生活随笔為你收集整理的RDBMS vs. NoSQL Clojure概述的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 计算机与数字媒体专业概论
- 下一篇: 开源分布式搜索平台ELK+Redis+S