什么是New SQL?分析NewSQL是如何融合NoSQL和RDBMS兩者的優(yōu)勢

NewSQL是對一類現代關系型數據庫的統稱，這類數據庫對于一般的OLTP讀寫請求提供可橫向擴展的性能，同時支持事務的ACID保證。這些系統既擁有NoSQL數據庫的擴展性，又保持傳統數據庫的事務特性。NewSQL重新將“應用程序邏輯與數據操作邏輯應該分離”的理念帶回到現代數據庫的世界，這也驗證了歷史的發(fā)展總是呈現出螺旋上升的形式。

創(chuàng)新互聯建站專業(yè)為企業(yè)提供天祝藏族自治網站建設、天祝藏族自治做網站、天祝藏族自治網站設計、天祝藏族自治網站制作等企業(yè)網站建設、網頁設計與制作、天祝藏族自治企業(yè)網站模板建站服務，十年天祝藏族自治做網站經驗，不只是建網站，更提供有價值的思路和整體網絡服務。

在21世紀00年代中，出現了許多數據倉庫系統 (如 Vertica，Greeplum 和AsterData)，這些以處理OLAP 請求為設計目標的系統并不在本文定義的NewSQL范圍內。OLAP 數據庫更關注針對海量數據的大型、復雜、只讀的查詢，查詢時間可能持續(xù)秒級、分鐘級甚至更長。

NoSQL的擁躉普遍認為阻礙傳統數據庫橫向擴容、提高可用性的原因在于ACID保證和關系模型，因此NoSQL運動的核心就是放棄事務強一致性以及關系模型，擁抱最終一致性和其它數據模型?(如 key/value，graphs 和Documents)。

兩個最著名的NoSQL數據庫就是Google的BigTable和Amazon的Dynamo，由于二者都未開源，其它組織就開始推出類似的開源替代項目，包括Facebook的 Cassandra (基于BigTable和Dynamo)、PowerSet的 Hbase(基于BigTable)。有一些創(chuàng)業(yè)公司也加入到這場NoSQL運動中，它們不一定是受BigTable和Dynamo的啟發(fā)，但都響應了NoSQL的哲學，其中最出名的就是MongoDB。

在21世紀00年代末，市面上已經有許多供用戶選擇的分布式數據庫產品。使用NoSQL的優(yōu)勢在于應用開發(fā)者可以更關注應用邏輯本身，而非數據庫的擴展性問題；但與此同時許多應用，如金融系統、訂單處理系統，由于無法放棄事務的一致性要求被拒之門外。

一些組織，如Google，已經發(fā)現他們的許多工程師將過多的精力放在處理數據一致性上，這既暴露了數據庫的抽象、又提高了代碼的復雜度，這時候要么選擇回到傳統DBMS時代，用更高的機器配置縱向擴容，要么選擇回到中間件時代，開發(fā)支持分布式事務的中間件。這兩種方案成本都很高，于是NewSQL運動開始醞釀。

NewSQL數據庫設計針對的讀寫事務有以下特點：

1、耗時短。

2、使用索引查詢，涉及少量數據。

3、重復度高，通常使用相同的查詢語句和不同的查詢參考。

也有一些學者認為NewSQL系統是特指實現上使用Lock-free并發(fā)控制技術和share-nothing架構的數據庫。所有我們認為是NewSQL的數據庫系統確實都有這樣的特點。

目前哪些NoSQL數據庫應用廣泛，各有什么特點

特點：

它們可以處理超大量的數據。

它們運行在便宜的PC服務器集群上。

PC集群擴充起來非常方便并且成本很低，避免了“sharding”操作的復雜性和成本。

它們擊碎了性能瓶頸。

NoSQL的支持者稱，通過NoSQL架構可以省去將Web或Java應用和數據轉換成SQL友好格式的時間，執(zhí)行速度變得更快。

“SQL并非適用于所有的程序代碼，” 對于那些繁重的重復操作的數據，SQL值得花錢。但是當數據庫結構非常簡單時，SQL可能沒有太大用處。

沒有過多的操作。

雖然NoSQL的支持者也承認關系數據庫提供了無可比擬的功能集合，而且在數據完整性上也發(fā)揮絕對穩(wěn)定，他們同時也表示，企業(yè)的具體需求可能沒有那么多。

Bootstrap支持

因為NoSQL項目都是開源的，因此它們缺乏供應商提供的正式支持。這一點它們與大多數開源項目一樣，不得不從社區(qū)中尋求支持。

優(yōu)點：

易擴展

NoSQL數據庫種類繁多，但是一個共同的特點都是去掉關系數據庫的關系型特性。數據之間無關系，這樣就非常容易擴展。也無形之間，在架構的層面上帶來了可擴展的能力。

大數據量，高性能

NoSQL數據庫都具有非常高的讀寫性能，尤其在大數據量下，同樣表現優(yōu)秀。這得益于它的無關系性，數據庫的結構簡單。一般MySQL使用 Query Cache，每次表的更新Cache就失效，是一種大粒度的Cache，在針對web2.0的交互頻繁的應用，Cache性能不高。而NoSQL的 Cache是記錄級的，是一種細粒度的Cache，所以NoSQL在這個層面上來說就要性能高很多了。

靈活的數據模型

NoSQL無需事先為要存儲的數據建立字段，隨時可以存儲自定義的數據格式。而在關系數據庫里，增刪字段是一件非常麻煩的事情。如果是非常大數據量的表，增加字段簡直就是一個噩夢。這點在大數據量的web2.0時代尤其明顯。

高可用

NoSQL在不太影響性能的情況，就可以方便的實現高可用的架構。比如Cassandra，HBase模型，通過復制模型也能實現高可用。

主要應用：

Apache HBase

這個大數據管理平臺建立在谷歌強大的BigTable管理引擎基礎上。作為具有開源、Java編碼、分布式多個優(yōu)勢的數據庫，Hbase最初被設計應用于Hadoop平臺，而這一強大的數據管理工具，也被Facebook采用，用于管理消息平臺的龐大數據。

Apache Storm

用于處理高速、大型數據流的分布式實時計算系統。Storm為Apache Hadoop添加了可靠的實時數據處理功能，同時還增加了低延遲的儀表板、安全警報，改進了原有的操作方式，幫助企業(yè)更有效率地捕獲商業(yè)機會、發(fā)展新業(yè)務。

Apache Spark

該技術采用內存計算，從多迭代批量處理出發(fā)，允許將數據載入內存做反復查詢，此外還融合數據倉庫、流處理和圖計算等多種計算范式，Spark用Scala語言實現，構建在HDFS上，能與Hadoop很好的結合，而且運行速度比MapReduce快100倍。

Apache Hadoop

該技術迅速成為了大數據管理標準之一。當它被用來管理大型數據集時，對于復雜的分布式應用，Hadoop體現出了非常好的性能，平臺的靈活性使它可以運行在商用硬件系統，它還可以輕松地集成結構化、半結構化和甚至非結構化數據集。

Apache Drill

你有多大的數據集？其實無論你有多大的數據集，Drill都能輕松應對。通過支持HBase、Cassandra和MongoDB，Drill建立了交互式分析平臺，允許大規(guī)模數據吞吐，而且能很快得出結果。

Apache Sqoop

也許你的數據現在還被鎖定于舊系統中，Sqoop可以幫你解決這個問題。這一平臺采用并發(fā)連接，可以將數據從關系數據庫系統方便地轉移到Hadoop中，可以自定義數據類型以及元數據傳播的映射。事實上，你還可以將數據（如新的數據）導入到HDFS、Hive和Hbase中。

Apache Giraph

這是功能強大的圖形處理平臺，具有很好可擴展性和可用性。該技術已經被Facebook采用，Giraph可以運行在Hadoop環(huán)境中，可以將它直接部署到現有的Hadoop系統中。通過這種方式，你可以得到強大的分布式作圖能力，同時還能利用上現有的大數據處理引擎。

Cloudera Impala

Impala模型也可以部署在你現有的Hadoop群集上，監(jiān)視所有的查詢。該技術和MapReduce一樣，具有強大的批處理能力，而且Impala對于實時的SQL查詢也有很好的效果，通過高效的SQL查詢，你可以很快的了解到大數據平臺上的數據。

Gephi

它可以用來對信息進行關聯和量化處理，通過為數據創(chuàng)建功能強大的可視化效果，你可以從數據中得到不一樣的洞察力。Gephi已經支持多個圖表類型，而且可以在具有上百萬個節(jié)點的大型網絡上運行。Gephi具有活躍的用戶社區(qū)，Gephi還提供了大量的插件，可以和現有系統完美的集成到一起，它還可以對復雜的IT連接、分布式系統中各個節(jié)點、數據流等信息進行可視化分析。

MongoDB

這個堅實的平臺一直被很多組織推崇，它在大數據管理上有極好的性能。MongoDB最初是由DoubleClick公司的員工創(chuàng)建，現在該技術已經被廣泛的應用于大數據管理。MongoDB是一個應用開源技術開發(fā)的NoSQL數據庫，可以用于在JSON這樣的平臺上存儲和處理數據。目前，紐約時報、Craigslist以及眾多企業(yè)都采用了MongoDB，幫助他們管理大型數據集。（Couchbase服務器也作為一個參考）。

十大頂尖公司：

Amazon Web Services

Forrester將AWS稱為“云霸主”，談到云計算領域的大數據，那就不得不提到亞馬遜。該公司的Hadoop產品被稱為EMR（Elastic Map Reduce），AWS解釋這款產品采用了Hadoop技術來提供大數據管理服務，但它不是純開源Hadoop，經過修改后現在被專門用在AWS云上。

Forrester稱EMR有很好的市場前景。很多公司基于EMR為客戶提供服務，有一些公司將EMR應用于數據查詢、建模、集成和管理。而且AWS還在創(chuàng)新，Forrester稱未來EMR可以基于工作量的需要自動縮放調整大小。亞馬遜計劃為其產品和服務提供更強大的EMR支持，包括它的RedShift數據倉庫、新公布的Kenesis實時處理引擎以及計劃中的NoSQL數據庫和商業(yè)智能工具。不過AWS還沒有自己的Hadoop發(fā)行版。

Cloudera

Cloudera有開源Hadoop的發(fā)行版，這個發(fā)行版采用了Apache Hadoop開源項目的很多技術，不過基于這些技術的發(fā)行版也有很大的進步。Cloudera為它的Hadoop發(fā)行版開發(fā)了很多功能，包括Cloudera管理器，用于管理和監(jiān)控，以及名為Impala的SQL引擎等。Cloudera的Hadoop發(fā)行版基于開源Hadoop，但也不是純開源的產品。當Cloudera的客戶需要Hadoop不具備的某些功能時，Cloudera的工程師們就會實現這些功能，或者找一個擁有這項技術的合作伙伴。Forrester表示：“Cloudera的創(chuàng)新方法忠于核心Hadoop，但因為其可實現快速創(chuàng)新并積極滿足客戶需求，這一點使它不同于其他那些供應商。”目前，Cloudera的平臺已經擁有200多個付費客戶，一些客戶在Cloudera的技術支持下已經可以跨1000多個節(jié)點實現對PB級數據的有效管理。

Hortonworks

和Cloudera一樣，Hortonworks是一個純粹的Hadoop技術公司。與Cloudera不同的是，Hortonworks堅信開源Hadoop比任何其他供應商的Hadoop發(fā)行版都要強大。Hortonworks的目標是建立Hadoop生態(tài)圈和Hadoop用戶社區(qū)，推進開源項目的發(fā)展。Hortonworks平臺和開源Hadoop聯系緊密，公司管理人員表示這會給用戶帶來好處，因為它可以防止被供應商套牢（如果Hortonworks的客戶想要離開這個平臺，他們可以輕松轉向其他開源平臺）。這并不是說Hortonworks完全依賴開源Hadoop技術，而是因為該公司將其所有開發(fā)的成果回報給了開源社區(qū)，比如Ambari，這個工具就是由Hortonworks開發(fā)而成，用來填充集群管理項目漏洞。Hortonworks的方案已經得到了Teradata、Microsoft、Red Hat和SAP這些供應商的支持。

IBM

當企業(yè)考慮一些大的IT項目時，很多人首先會想到IBM。IBM是Hadoop項目的主要參與者之一，Forrester稱IBM已有100多個Hadoop部署，它的很多客戶都有PB級的數據。IBM在網格計算、全球數據中心和企業(yè)大數據項目實施等眾多領域有著豐富的經驗。“IBM計劃繼續(xù)整合SPSS分析、高性能計算、BI工具、數據管理和建模、應對高性能計算的工作負載管理等眾多技術。”

Intel

和AWS類似，英特爾不斷改進和優(yōu)化Hadoop使其運行在自己的硬件上，具體來說，就是讓Hadoop運行在其至強芯片上，幫助用戶打破Hadoop系統的一些限制，使軟件和硬件結合的更好，英特爾的Hadoop發(fā)行版在上述方面做得比較好。Forrester指出英特爾在最近才推出這個產品，所以公司在未來還有很多改進的可能，英特爾和微軟都被認為是Hadoop市場上的潛力股。

MapR Technologies

MapR的Hadoop發(fā)行版目前為止也許是最好的了，不過很多人可能都沒有聽說過。Forrester對Hadoop用戶的調查顯示，MapR的評級最高，其發(fā)行版在架構和數據處理能力上都獲得了最高分。MapR已將一套特殊功能融入其Hadoop發(fā)行版中。例如網絡文件系統（NFS）、災難恢復以及高可用性功能。Forrester說MapR在Hadoop市場上沒有Cloudera和Hortonworks那樣的知名度，MapR要成為一個真正的大企業(yè)，還需要加強伙伴關系和市場營銷。

Microsoft

微軟在開源軟件問題上一直很低調，但在大數據形勢下，它不得不考慮讓Windows也兼容Hadoop，它還積極投入到開源項目中，以更廣泛地推動Hadoop生態(tài)圈的發(fā)展。我們可以在微軟的公共云Windows Azure HDInsight產品中看到其成果。微軟的Hadoop服務基于Hortonworks的發(fā)行版，而且是為Azure量身定制的。

微軟也有一些其他的項目，包括名為Polybase的項目，讓Hadoop查詢實現了SQLServer查詢的一些功能。Forrester說：“微軟在數據庫、數據倉庫、云、OLAP、BI、電子表格（包括PowerPivot）、協作和開發(fā)工具市場上有很大優(yōu)勢，而且微軟擁有龐大的用戶群，但要在Hadoop這個領域成為行業(yè)領導者還有很遠的路要走。”

Pivotal Software

EMC和Vmware部分大數據業(yè)務分拆組合產生了Pivotal。Pivotal一直努力構建一個性能優(yōu)越的Hadoop發(fā)行版，為此，Pivotal在開源Hadoop的基礎上又添加了一些新的工具，包括一個名為HAWQ的SQL引擎以及一個專門解決大數據問題的Hadoop應用。Forrester稱Pivotal Hadoop平臺的優(yōu)勢在于它整合了Pivotal、EMC、Vmware的眾多技術，Pivotal的真正優(yōu)勢實際上等于EMC和Vmware兩大公司為其撐腰。到目前為止，Pivotal的用戶還不到100個，而且大多是中小型客戶。

Teradata

對于Teradata來說，Hadoop既是一種威脅也是一種機遇。數據管理，特別是關于SQL和關系數據庫這一領域是Teradata的專長。所以像Hadoop這樣的NoSQL平臺崛起可能會威脅到Teradata。相反，Teradata接受了Hadoop，通過與Hortonworks合作，Teradata在Hadoop平臺集成了SQL技術，這使Teradata的客戶可以在Hadoop平臺上方便地使用存儲在Teradata數據倉庫中的數據。

AMPLab

通過將數據轉變?yōu)樾畔ⅲ覀儾趴梢岳斫馐澜纾@也正是AMPLab所做的。AMPLab致力于機器學習、數據挖掘、數據庫、信息檢索、自然語言處理和語音識別等多個領域，努力改進對信息包括不透明數據集內信息的甄別技術。除了Spark，開源分布式SQL查詢引擎Shark也源于AMPLab，Shark具有極高的查詢效率，具有良好的兼容性和可擴展性。近幾年的發(fā)展使計算機科學進入到全新的時代，而AMPLab為我們設想一個運用大數據、云計算、通信等各種資源和技術靈活解決難題的方案，以應對越來越復雜的各種難題。

nosql是什么

NoSQL，泛指非關系型的數據庫。隨著互聯網web2.0網站的興起，傳統的關系數據庫在應付web2.0網站，特別是超大規(guī)模和高并發(fā)的SNS類型的web2.0純動態(tài)網站已經顯得力不從心，暴露了很多難以克服的問題，而非關系型的數據庫則由于其本身的特點得到了非常迅速的發(fā)展。NoSQL數據庫的產生就是為了解決大規(guī)模數據集合多重數據種類帶來的挑戰(zhàn)，尤其是大數據應用難題。

雖然NoSQL流行語火起來才短短一年的時間，但是不可否認，現在已經開始了第二代運動。盡管早期的堆棧代碼只能算是一種實驗，然而現在的系統已經更加的成熟、穩(wěn)定。不過現在也面臨著一個嚴酷的事實：技術越來越成熟——以至于原來很好的NoSQL數據存儲不得不進行重寫，也有少數人認為這就是所謂的2.0版本。這里列出一些比較知名的工具，可以為大數據建立快速、可擴展的存儲庫。

NoSQL(NoSQL = Not Only SQL )，意即“不僅僅是SQL”，是一項全新的數據庫革命性運動，早期就有人提出，發(fā)展至2009年趨勢越發(fā)高漲。NoSQL的擁護者們提倡運用非關系型的數據存儲，相對于鋪天蓋地的關系型數據庫運用，這一概念無疑是一種全新的思維的注入。

對于NoSQL并沒有一個明確的范圍和定義，但是他們都普遍存在下面一些共同特征：

不需要預定義模式：不需要事先定義數據模式，預定義表結構。數據中的每條記錄都可能有不同的屬性和格式。當插入數據時，并不需要預先定義它們的模式。

無共享架構：相對于將所有數據存儲的存儲區(qū)域網絡中的全共享架構。NoSQL往往將數據劃分后存儲在各個本地服務器上。因為從本地磁盤讀取數據的性能往往好于通過網絡傳輸讀取數據的性能，從而提高了系統的性能。

彈性可擴展：可以在系統運行的時候，動態(tài)增加或者刪除結點。不需要停機維護，數據可以自動遷移。

分區(qū)：相對于將數據存放于同一個節(jié)點，NoSQL數據庫需要將數據進行分區(qū)，將記錄分散在多個節(jié)點上面。并且通常分區(qū)的同時還要做復制。這樣既提高了并行性能，又能保證沒有單點失效的問題。

異步復制：和RAID存儲系統不同的是，NoSQL中的復制，往往是基于日志的異步復制。這樣，數據就可以盡快地寫入一個節(jié)點，而不會被網絡傳輸引起遲延。缺點是并不總是能保證一致性，這樣的方式在出現故障的時候，可能會丟失少量的數據。

BASE：相對于事務嚴格的ACID特性，NoSQL數據庫保證的是BASE特性。BASE是最終一致性和軟事務。

NoSQL數據庫并沒有一個統一的架構，兩種NoSQL數據庫之間的不同，甚至遠遠超過兩種關系型數據庫的不同。可以說，NoSQL各有所長，成功的NoSQL必然特別適用于某些場合或者某些應用，在這些場合中會遠遠勝過關系型數據庫和其他的NoSQL。

newsql和nosql的區(qū)別和聯系

在大數據時代，“多種架構支持多類應用”成為數據庫行業(yè)應對大數據的基本思路，數據庫行業(yè)出現互為補充的三大陣營，適用于事務處理應用的OldSQL、適用于數據分析應用的NewSQL和適用于互聯網應用的NoSQL。但在一些復雜的應用場景中，單一數據庫架構都不能完全滿足應用場景對海量結構化和非結構化數據的存儲管理、復雜分析、關聯查詢、實時性處理和控制建設成本等多方面的需要，因此不同架構數據庫混合部署應用成為滿足復雜應用的必然選擇。不同架構數據庫混合使用的模式可以概括為：OldSQL+NewSQL、OldSQL+NoSQL、NewSQL+NoSQL三種主要模式。下面通過三個案例對不同架構數據庫的混合應用部署進行介紹。

OldSQL+NewSQL 在數據中心類應用中混合部署

采用OldSQL+NewSQL模式構建數據中心，在充分發(fā)揮OldSQL數據庫的事務處理能力的同時，借助NewSQL在實時性、復雜分析、即席查詢等方面的獨特優(yōu)勢，以及面對海量數據時較強的擴展能力，滿足數據中心對當前“熱”數據事務型處理和海量歷史“冷”數據分析兩方面的需求。OldSQL+NewSQL模式在數據中心類應用中的互補作用體現在，OldSQL彌補了NewSQL不適合事務處理的不足，NewSQL彌補了OldSQL在海量數據存儲能力和處理性能方面的缺陷。

商業(yè)銀行數據中心采用OldSQL+NewSQL混合部署方式搭建，OldSQL數據庫滿足各業(yè)務系統數據的歸檔備份和事務型應用，NewSQL MPP數據庫集群對即席查詢、多維分析等應用提供高性能支持，并且通過MPP集群架構實現應對海量數據存儲的擴展能力。

商業(yè)銀行數據中心存儲架構

與傳統的OldSQL模式相比，商業(yè)銀行數據中心采用OldSQL+NewSQL混合搭建模式，數據加載性能提升3倍以上，即席查詢和統計分析性能提升6倍以上。NewSQL MPP的高可擴展性能夠應對新的業(yè)務需求，可隨著數據量的增長采用集群方式構建存儲容量更大的數據中心。

OldSQL+NoSQL 在互聯網大數據應用中混合部署

在互聯網大數據應用中采用OldSQL+NoSQL混合模式，能夠很好的解決互聯網大數據應用對海量結構化和非結構化數據進行存儲和快速處理的需求。在諸如大型電子商務平臺、大型SNS平臺等互聯網大數據應用場景中，OldSQL在應用中負責高價值密度結構化數據的存儲和事務型處理，NoSQL在應用中負責存儲和處理海量非結構化的數據和低價值密度結構化數據。OldSQL+NoSQL模式在互聯網大數據應用中的互補作用體現在，OldSQL彌補了NoSQL在ACID特性和復雜關聯運算方面的不足，NoSQL彌補了OldSQL在海量數據存儲和非結構化數據處理方面的缺陷。

數據魔方是淘寶網的一款數據產品，主要提供行業(yè)數據分析、店鋪數據分析。淘寶數據產品在存儲層采用OldSQL+NoSQL混合模式，由基于MySQL的分布式關系型數據庫集群MyFOX和基于HBase的NoSQL存儲集群Prom組成。由于OldSQL強大的語義和關系表達能力，在應用中仍然占據著重要地位，目前存儲在MyFOX中的統計結果數據已經達到10TB，占據著數據魔方總數據量的95%以上。另一方面，NoSQL作為SQL的有益補充，解決了OldSQL數據庫無法解決的全屬性選擇器等問題。

淘寶海量數據產品技術架構

基于OldSQL+NoSQL混合架構的特點，數據魔方目前已經能夠提供壓縮前80TB的數據存儲空間，支持每天4000萬的查詢請求，平均響應時間在28毫秒，足以滿足未來一段時間內的業(yè)務增長需求。

NewSQL+NoSQL 在行業(yè)大數據應用中混合部署

行業(yè)大數據與互聯網大數據的區(qū)別在于行業(yè)大數據的價值密度更高，并且對結構化數據的實時處理、復雜的多表關聯分析、即席查詢、數據強一致性等都比互聯網大數據有更高的要求。行業(yè)大數據應用場景主要是分析類應用，如：電信、金融、政務、能源等行業(yè)的決策輔助、預測預警、統計分析、經營分析等。

在行業(yè)大數據應用中采用NewSQL+NoSQL混合模式，充分利用NewSQL在結構化數據分析處理方面的優(yōu)勢，以及NoSQL在非結構數據處理方面的優(yōu)勢，實現NewSQL與NoSQL的功能互補，解決行業(yè)大數據應用對高價值結構化數據的實時處理、復雜的多表關聯分析、即席查詢、數據強一致性等要求，以及對海量非結構化數據存儲和精確查詢的要求。在應用中，NewSQL承擔高價值密度結構化數據的存儲和分析處理工作，NoSQL承擔存儲和處理海量非結構化數據和不需要關聯分析、Ad-hoc查詢較少的低價值密度結構化數據的工作。

當前電信運營商在集中化BI系統建設過程中面臨著數據規(guī)模大、數據處理類型多等問題，并且需要應對大量的固定應用，以及占統計總數80%以上的突發(fā)性臨時統計(ad-hoc)需求。在集中化BI系統的建設中采用NewSQL+NoSQL混搭的模式，充分利用NewSQL在復雜分析、即席查詢等方面處理性能的優(yōu)勢，及NoSQL在非結構化數據處理和海量數據存儲方面的優(yōu)勢，實現高效低成本。

集中化BI系統數據存儲架構

集中化BI系統按照數據類型和處理方式的不同，將結構化數據和非結構化數據分別存儲在不同的系統中：非結構化數據在Hadoop平臺上存儲與處理;結構化、不需要關聯分析、Ad-hoc查詢較少的數據保存在NoSQL數據庫或Hadoop平臺;結構化、需要關聯分析或經常ad-hoc查詢的數據，保存在NewSQL MPP數據庫中，短期高價值數據放在高性能平臺，中長期放在低成本產品中。

結語

當前信息化應用的多樣性、復雜性，以及三種數據庫架構各自所具有的優(yōu)勢和局限性，造成任何一種架構的數據庫都不能完全滿足應用需求，因此不同架構數據庫混合使用，從而彌補其他架構的不足成為必然選擇。根據應用場景采用不同架構數據庫進行組合搭配，充分發(fā)揮每種架構數據庫的特點和優(yōu)勢，并且與其他架構數據庫形成互補，完全涵蓋應用需求，保證數據資源的最優(yōu)化利用，將成為未來一段時期內信息化應用主要采用的解決方式。

目前在國內市場上，OldSQL主要為Oracle、IBM等國外數據庫廠商所壟斷，達夢、金倉等國產廠商仍處于追趕狀態(tài);南大通用憑借國產新型數據庫GBase 8a異軍突起，與EMC的Greenplum和HP的Vertica躋身NewSQL市場三強;NoSQL方面用戶則大多采用Hadoop開源方案。

網易傳媒技術團隊：消息中間件實現延遲隊列的應用與實踐

早期需要延遲處理的業(yè)務場景，更多的是通過定時任務掃表，然后執(zhí)行滿足條件的記錄，具有頻率高、命中低、資源消耗大的缺點。隨著消息中間件的普及，延遲消息可以很好的處理這種場景，本文主要介紹延遲消息的使用場景以及基于常見的消息中間件如何實現延遲隊列，最后給出了一個在網易公開課使用延遲隊列的實踐。

1、有效期：限時活動、拼團。。。

2、超時處理：取消超時未支付訂單、超時自動確認收貨。。。

4、重試：網絡異常重試、打車派單、依賴條件未滿足重試。。。

5、定時任務：智能設備定時啟動。。。

1、RabbitMQ

1）簡介：基于AMQP協議，使用Erlang編寫，實現了一個Broker框架

a、Broker：接收和分發(fā)消息的代理服務器

b、Virtual Host：虛擬主機之間相互隔離，可理解為一個虛擬主機對應一個消息服務

c、Exchange：交換機，消息發(fā)送到指定虛擬機的交換機上

d、Binding：交換機與隊列綁定，并通過路由策略和routingKey將消息投遞到一個或多個隊列中

e、Queue：存放消息的隊列，FIFO，可持久化

f、Channel：信道，消費者通過信道消費消息，一個TCP連接上可同時創(chuàng)建成百上千個信道，作為消息隔離

2）延遲隊列實現：RabbitMQ的延遲隊列基于消息的存活時間TTL（Time To Live）和死信交換機DLE（Dead Letter Exchanges）實現

a、TTL：RabbitMQ支持對隊列和消息各自設置存活時間，取二者中較小的值，即隊列無消費者連接或消息在隊列中一直未被消費的過期時間

b、DLE：過期的消息通過綁定的死信交換機，路由到指定的死信隊列，消費者實際上消費的是死信隊列上的消息

3）缺點：

a、配置麻煩，額外增加一個死信交換機和一個死信隊列的配置

b、脆弱性，配置錯誤或者生產者消費者連接的隊列錯誤都有可能造成延遲失效

2、RocketMQ

1）簡介：來源于阿里，目前為Apache頂級開源項目，使用Java編寫，基于長輪詢的拉取方式，支持事務消息，并解決了順序消息和海量堆積的問題

a、Broker：存放Topic并根據讀取Producer的提交日志，將邏輯上的一個Topic分多個Queue存儲，每個Queue上存儲消息在提交日志上的位置

b、Name Server：無狀態(tài)的節(jié)點，維護Topic與Broker的對應關系以及Broker的主從關系

2）延遲隊列實現：RocketMQ發(fā)送延時消息時先把消息按照延遲時間段發(fā)送到指定的隊列中(rocketmq把每種延遲時間段的消息都存放到同一個隊列中)，然后通過一個定時器進行輪訓這些隊列，查看消息是否到期，如果到期就把這個消息發(fā)送到指定topic的隊列中

3）缺點：延遲時間粒度受限制（1s/5s/10s/30s/1m/2m/3m/4m/5m/6m/7m/8m/9m/10m/20m/30m/1h/2h）

3、Kafka

1）簡介：來源于Linkedin，目前為Apache頂級開源項目，使用Scala和Java編寫，基于zookeeper協調的分布式、流處理的日志系統，升級版為Jafka

2）延遲隊列實現：Kafka支持延時生產、延時拉取、延時刪除等，其基于時間輪和JDK的DelayQueue實現

a、時間輪(TimingWheel)：是一個存儲定時任務的環(huán)形隊列，底層采用數組實現，數組中的每個元素可以存放一個定時任務列表

b、定時任務列表(TimerTaskList)：是一個環(huán)形的雙向鏈表，鏈表中的每一項表示的都是定時任務項

c、定時任務項(TimerTaskEntry)：封裝了真正的定時任務TimerTask

d、層級時間輪：當任務的到期時間超過了當前時間輪所表示的時間范圍時，就會嘗試添加到上層時間輪中，類似于鐘表就是一個三級時間輪

e、JDK DelayQueue：存儲TimerTaskList，并根據其expiration來推進時間輪的時間，每推進一次除執(zhí)行相應任務列表外，層級時間輪也會進行相應調整

3）缺點：

a、延遲精度取決于時間格設置

b、延遲任務除由超時觸發(fā)還可能被外部事件觸發(fā)而執(zhí)行

4、ActiveMQ

1）簡介：基于JMS協議，Java編寫的Apache頂級開源項目，支持點對點和發(fā)布訂閱兩種模式。

a、點對點（point-to-point）：消息發(fā)送到指定的隊列，每條消息只有一個消費者能夠消費，基于拉模型

b、發(fā)布訂閱（publish/subscribe）：消息發(fā)送到主題Topic上，每條消息會被訂閱該Topic的所有消費者各自消費，基于推模型

2）延遲隊列實現：需要延遲的消息會先存儲在JobStore中，通過異步線程任務JobScheduler將到達投遞時間的消息投遞到相應隊列上

a、Broker Filter：Broker中定義了一系列BrokerFilter的子類構成攔截器鏈，按順序對消息進行相應處理

b、ScheduleBroker：當消息中指定了延遲相關屬性，并且jobId為空時，會生成調度任務存儲到JobStore中，此時消息不會進入到隊列

c、JobStore：基于BTree存儲，key為任務執(zhí)行的時間戳，value為該時間戳下需要執(zhí)行的任務列表

d、JobScheduler：取JobStore中最小的key執(zhí)行（調度時間最早的），執(zhí)行時間=當前時間，將該任務列表依次投遞到所屬的隊列，對于需要重復投遞和投遞失敗的會再次存入JobStore中。

注： 此處JobScheduler的執(zhí)行時間間隔可動態(tài)變化，默認0.5s，有新任務時會立即執(zhí)行（Object-notifyAll()）并設置時間間隔為0.1s，沒有新任務后，下次執(zhí)行時間為最近任務的調度執(zhí)行時間。

3）缺點：投遞到隊列失敗，將消息重新存入JobStore，消息調度執(zhí)行時間=系統當前時間+延遲時間，會導致消息被真實投遞的時間可能為設置的延遲時間的整數倍

5、Redis

1）簡介：基于Key-Value的NoSQL數據庫，由于其極高的性能常被當作緩存來使用，其數據結構支持：字符串、哈希、列表、集合、有序集合

2）延遲隊列實現：Redis的延遲隊列基于有序集合，score為執(zhí)行時間戳，value為任務實體或任務實體引用

3）缺點：

a、實現復雜，本身不支持

b、完全基于內存，延遲時間長浪費內存資源

6、消息隊列對比

1、公開課延遲隊列技術選型

1）業(yè)務場景：關閉超時未支付訂單、限時優(yōu)惠活動、拼團

2）性能要求：訂單、活動、拼團 數據量可控，上述MQ均能滿足要求

3）可靠性：使用ActiveMQ、RabbitMQ、RocketMQ作為延遲隊列更普遍

4）可用性：ActiveMQ、RocketMQ自身支持延遲隊列功能，且目前公開課業(yè)務中使用的中間件為ActiveMQ和Kafka

5）延遲時間靈活：活動的開始和結束時間比較靈活，而RocketMQ時間粒度較粗，Kafka會依賴時間格有精度缺失

結論： 最終選擇ActiveMQ來作為延遲隊列

2、業(yè)務場景：關閉未支付訂單

1）關閉微信未支付訂單

2）關閉IOS未支付訂單

3、ActiveMQ使用方式

1）activemq.xml中支持調度任務

2）發(fā)送消息時，設置message的延遲屬性

其中：

a、延遲處理

AMQ_SCHEDULED_DELAY：設置多長時間后，投遞給消費者（毫秒）

b、重復投遞

AMQ_SCHEDULED_PERIOD：重復投遞時間間隔（毫秒）

AMQ_SCHEDULED_REPEAT：重復投遞次數

c、指定調度計劃

AMQ_SCHEDULED_CRON：corn正則表達式

4、公開課使用中進行的優(yōu)化

1）可靠性：針對實際投遞時間可能翻倍的問題，結合ActiveMQ的重復投遞，在消費者邏輯中做冪等處理來保證延遲時間的準確性

2）可追溯性：延遲消息及消費情況做數據庫冗余存儲

3）易用性：業(yè)務上定義好延遲枚舉類型，直接使用JmsDelayTemplate發(fā)送，無需關心數據備份和參數等細節(jié)

1、無論是基于死信隊列還是基于數據先存儲后投遞，本質上都是將延遲待發(fā)送的消息數據與正常訂閱的隊列分開存儲，從而降低耦合度

2、無論是檢查隊頭消息TTL還是調度存儲的延遲數據，本質上都是通過定時任務來完成的，但是定時任務的觸發(fā)策略以及延遲數據的存儲方式決定了不同中間件之間的性能優(yōu)劣

張浩，2018年加入網易傳媒，高級Java開發(fā)工程師，目前在網易公開課主要做支付財務體系、版本迭代相關的工作。

消息中間件（一）MQ詳解及四大MQ比較

一、消息中間件相關知識

1、概述

消息隊列已經逐漸成為企業(yè)IT系統內部通信的核心手段。它具有低耦合、可靠投遞、廣播、流量控制、最終一致性等一系列功能，成為異步RPC的主要手段之一。當今市面上有很多主流的消息中間件，如老牌的ActiveMQ、RabbitMQ，炙手可熱的Kafka，阿里巴巴自主開發(fā)RocketMQ等。

2、消息中間件的組成

2.1 Broker

消息服務器，作為server提供消息核心服務

2.2 Producer

消息生產者，業(yè)務的發(fā)起方，負責生產消息傳輸給broker，

2.3 Consumer

消息消費者，業(yè)務的處理方，負責從broker獲取消息并進行業(yè)務邏輯處理

2.4 Topic

2.5 Queue

2.6 Message

消息體，根據不同通信協議定義的固定格式進行編碼的數據包，來封裝業(yè)務數據，實現消息的傳輸

3 消息中間件模式分類

3.1 點對點

PTP點對點:使用queue作為通信載體

說明：

消息生產者生產消息發(fā)送到queue中，然后消息消費者從queue中取出并且消費消息。

消息被消費以后，queue中不再存儲，所以消息消費者不可能消費到已經被消費的消息。 Queue支持存在多個消費者，但是對一個消息而言，只會有一個消費者可以消費。

說明：

queue實現了負載均衡，將producer生產的消息發(fā)送到消息隊列中，由多個消費者消費。但一個消息只能被一個消費者接受，當沒有消費者可用時，這個消息會被保存直到有一個可用的消費者。

4 消息中間件的優(yōu)勢

4.1 系統解耦

交互系統之間沒有直接的調用關系，只是通過消息傳輸，故系統侵入性不強，耦合度低。

4.2 提高系統響應時間

例如原來的一套邏輯，完成支付可能涉及先修改訂單狀態(tài)、計算會員積分、通知物流配送幾個邏輯才能完成；通過MQ架構設計，就可將緊急重要（需要立刻響應）的業(yè)務放到該調用方法中，響應要求不高的使用消息隊列，放到MQ隊列中，供消費者處理。

4.3 為大數據處理架構提供服務

通過消息作為整合，大數據的背景下，消息隊列還與實時處理架構整合，為數據處理提供性能支持。

4.4 Java消息服務——JMS

Java消息服務（Java Message Service，JMS）應用程序接口是一個Java平臺中關于面向消息中間件（MOM）的API，用于在兩個應用程序之間，或分布式系統中發(fā)送消息，進行異步通信。

5 消息中間件應用場景

5.1 異步通信

有些業(yè)務不想也不需要立即處理消息。消息隊列提供了異步處理機制，允許用戶把一個消息放入隊列，但并不立即處理它。想向隊列中放入多少消息就放多少，然后在需要的時候再去處理它們。

5.2 解耦

降低工程間的強依賴程度，針對異構系統進行適配。在項目啟動之初來預測將來項目會碰到什么需求，是極其困難的。通過消息系統在處理過程中間插入了一個隱含的、基于數據的接口層，兩邊的處理過程都要實現這一接口，當應用發(fā)生變化時，可以獨立的擴展或修改兩邊的處理過程，只要確保它們遵守同樣的接口約束。

5.3 冗余

有些情況下，處理數據的過程會失敗。除非數據被持久化，否則將造成丟失。消息隊列把數據進行持久化直到它們已經被完全處理，通過這一方式規(guī)避了數據丟失風險。許多消息隊列所采用的”插入-獲取-刪除”范式中，在把一個消息從隊列中刪除之前，需要你的處理系統明確的指出該消息已經被處理完畢，從而確保你的數據被安全的保存直到你使用完畢。

5.4 擴展性

因為消息隊列解耦了你的處理過程，所以增大消息入隊和處理的頻率是很容易的，只要另外增加處理過程即可。不需要改變代碼、不需要調節(jié)參數。便于分布式擴容。

5.5 過載保護

在訪問量劇增的情況下，應用仍然需要繼續(xù)發(fā)揮作用，但是這樣的突發(fā)流量無法提取預知；如果以為了能處理這類瞬間峰值訪問為標準來投入資源隨時待命無疑是巨大的浪費。使用消息隊列能夠使關鍵組件頂住突發(fā)的訪問壓力，而不會因為突發(fā)的超負荷的請求而完全崩潰。

5.6 可恢復性

系統的一部分組件失效時，不會影響到整個系統。消息隊列降低了進程間的耦合度，所以即使一個處理消息的進程掛掉，加入隊列中的消息仍然可以在系統恢復后被處理。

5.7 順序保證

在大多使用場景下，數據處理的順序都很重要。大部分消息隊列本來就是排序的，并且能保證數據會按照特定的順序來處理。

5.8 緩沖

在任何重要的系統中，都會有需要不同的處理時間的元素。消息隊列通過一個緩沖層來幫助任務最高效率的執(zhí)行，該緩沖有助于控制和優(yōu)化數據流經過系統的速度。以調節(jié)系統響應時間。

5.9 數據流處理

分布式系統產生的海量數據流，如：業(yè)務日志、監(jiān)控數據、用戶行為等，針對這些數據流進行實時或批量采集匯總，然后進行大數據分析是當前互聯網的必備技術，通過消息隊列完成此類數據收集是最好的選擇。

6 消息中間件常用協議

6.1 AMQP協議

AMQP即Advanced Message Queuing Protocol,一個提供統一消息服務的應用層標準高級消息隊列協議,是應用層協議的一個開放標準,為面向消息的中間件設計。基于此協議的客戶端與消息中間件可傳遞消息，并不受客戶端/中間件不同產品，不同開發(fā)語言等條件的限制。

優(yōu)點：可靠、通用

6.2 MQTT協議

MQTT（Message Queuing Telemetry Transport，消息隊列遙測傳輸）是IBM開發(fā)的一個即時通訊協議，有可能成為物聯網的重要組成部分。該協議支持所有平臺，幾乎可以把所有聯網物品和外部連接起來，被用來當做傳感器和致動器（比如通過Twitter讓房屋聯網）的通信協議。

優(yōu)點：格式簡潔、占用帶寬小、移動端通信、PUSH、嵌入式系統

6.3 STOMP協議

STOMP（Streaming Text Orientated Message Protocol）是流文本定向消息協議，是一種為MOM(Message Oriented Middleware，面向消息的中間件)設計的簡單文本協議。STOMP提供一個可互操作的連接格式，允許客戶端與任意STOMP消息代理（Broker）進行交互。

優(yōu)點：命令模式（非topic\queue模式）

6.4 XMPP協議

XMPP（可擴展消息處理現場協議，Extensible Messaging and Presence Protocol）是基于可擴展標記語言（XML）的協議，多用于即時消息（IM）以及在線現場探測。適用于服務器之間的準即時操作。核心是基于XML流傳輸，這個協議可能最終允許因特網用戶向因特網上的其他任何人發(fā)送即時消息，即使其操作系統和瀏覽器不同。

優(yōu)點：通用公開、兼容性強、可擴展、安全性高，但XML編碼格式占用帶寬大

6.5 其他基于TCP/IP自定義的協議

有些特殊框架（如：redis、kafka、zeroMq等）根據自身需要未嚴格遵循MQ規(guī)范，而是基于TCP\IP自行封裝了一套協議，通過網絡socket接口進行傳輸，實現了MQ的功能。

7 常見消息中間件MQ介紹

7.1 RocketMQ

阿里系下開源的一款分布式、隊列模型的消息中間件，原名Metaq，3.0版本名稱改為RocketMQ，是阿里參照kafka設計思想使用java實現的一套mq。同時將阿里系內部多款mq產品（Notify、metaq）進行整合，只維護核心功能，去除了所有其他運行時依賴，保證核心功能最簡化，在此基礎上配合阿里上述其他開源產品實現不同場景下mq的架構，目前主要多用于訂單交易系統。

具有以下特點：

官方提供了一些不同于kafka的對比差異：

7.2 RabbitMQ

使用Erlang編寫的一個開源的消息隊列，本身支持很多的協議：AMQP，XMPP, SMTP,STOMP，也正是如此，使的它變的非常重量級，更適合于企業(yè)級的開發(fā)。同時實現了Broker架構，核心思想是生產者不會將消息直接發(fā)送給隊列，消息在發(fā)送給客戶端時先在中心隊列排隊。對路由(Routing)，負載均衡(Load balance)、數據持久化都有很好的支持。多用于進行企業(yè)級的ESB整合。

7.3 ActiveMQ

Apache下的一個子項目。使用Java完全支持JMS1.1和J2EE 1.4規(guī)范的 JMS Provider實現，少量代碼就可以高效地實現高級應用場景。可插拔的傳輸協議支持，比如：in-VM, TCP, SSL, NIO, UDP, multicast, JGroups and JXTA transports。RabbitMQ、ZeroMQ、ActiveMQ均支持常用的多種語言客戶端 C++、Java、.Net,、Python、 Php、 Ruby等。

7.4 Redis

使用C語言開發(fā)的一個Key-Value的NoSQL數據庫，開發(fā)維護很活躍，雖然它是一個Key-Value數據庫存儲系統，但它本身支持MQ功能，所以完全可以當做一個輕量級的隊列服務來使用。對于RabbitMQ和Redis的入隊和出隊操作，各執(zhí)行100萬次，每10萬次記錄一次執(zhí)行時間。測試數據分為128Bytes、512Bytes、1K和10K四個不同大小的數據。實驗表明：入隊時，當數據比較小時Redis的性能要高于RabbitMQ，而如果數據大小超過了10K，Redis則慢的無法忍受；出隊時，無論數據大小，Redis都表現出非常好的性能，而RabbitMQ的出隊性能則遠低于Redis。

7.5 Kafka

Apache下的一個子項目，使用scala實現的一個高性能分布式Publish/Subscribe消息隊列系統，具有以下特性：

7.6 ZeroMQ

號稱最快的消息隊列系統，專門為高吞吐量/低延遲的場景開發(fā)，在金融界的應用中經常使用，偏重于實時數據通信場景。ZMQ能夠實現RabbitMQ不擅長的高級/復雜的隊列，但是開發(fā)人員需要自己組合多種技術框架，開發(fā)成本高。因此ZeroMQ具有一個獨特的非中間件的模式，更像一個socket library，你不需要安裝和運行一個消息服務器或中間件，因為你的應用程序本身就是使用ZeroMQ API完成邏輯服務的角色。但是ZeroMQ僅提供非持久性的隊列，如果down機，數據將會丟失。如：Twitter的Storm中使用ZeroMQ作為數據流的傳輸。

ZeroMQ套接字是與傳輸層無關的：ZeroMQ套接字對所有傳輸層協議定義了統一的API接口。默認支持 進程內(inproc) ，進程間(IPC) ，多播，TCP協議，在不同的協議之間切換只要簡單的改變連接字符串的前綴。可以在任何時候以最小的代價從進程間的本地通信切換到分布式下的TCP通信。ZeroMQ在背后處理連接建立，斷開和重連邏輯。

特性：

二、主要消息中間件的比較

新聞標題：消息中間件nosql對比的簡單介紹
文章地址：http://chinadenli.net/article44/dseoche.html

成都網站建設公司_創(chuàng)新互聯，為您提供搜索引擎優(yōu)化、自適應網站、網站營銷、云服務器、靜態(tài)網站、網站收錄

廣告

聲明：本網站發(fā)布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創(chuàng)新互聯