數(shù)據(jù)庫(kù)中間件使用場(chǎng)景分析

數(shù)據(jù)庫(kù)中間件使用場(chǎng)景分析數(shù)據(jù)庫(kù)場(chǎng)景比較PS:涉及到金錢(qián)方面的事務(wù)處理，建議使用Oracle。數(shù)據(jù)庫(kù)優(yōu)點(diǎn)缺點(diǎn)場(chǎng)景Oracle基本適合所有業(yè)務(wù)維護(hù)成本和License成本高電信，電力、銀行、支付以及涉及到金錢(qián)方面等綜合性企業(yè)。(事務(wù)型)MySQL結(jié)構(gòu)簡(jiǎn)單，部署方便，社區(qū)成熟，穩(wěn)定性非常好，良好的事務(wù)和SQL支持?jǐn)U展性差，軟件本身性能瓶頸大，沒(méi)有成熟的集群方案。Schema復(fù)制。百億以內(nèi)的數(shù)據(jù)存儲(chǔ)，對(duì)數(shù)據(jù)安全性和事務(wù)支持有要求。主要存儲(chǔ)對(duì)數(shù)據(jù)狀態(tài)有要求和更新頻繁的數(shù)據(jù)。(事務(wù)型)MongoDBSchema--free，快速開(kāi)發(fā)，本身支持集群如sharding，支持空間索引等；鎖的粒度大，并發(fā)性能差，性能受限于內(nèi)存，解決方案有待考驗(yàn)。1.LBS(基于位置服務(wù);地理坐標(biāo)，或大地坐標(biāo)),緩存，小文件存儲(chǔ)。2.CMS內(nèi)容管理系統(tǒng)；3.社交網(wǎng)絡(luò)圖數(shù)據(jù)庫(kù)設(shè)計(jì).4.MongoDB主要用于存儲(chǔ)計(jì)費(fèi)數(shù)據(jù)、日志數(shù)據(jù)和流水?dāng)?shù)據(jù)Hbase基于Hadoop生態(tài)系統(tǒng)，良好的擴(kuò)展性，高寫(xiě)入能力。數(shù)據(jù)自動(dòng)分片。架構(gòu)復(fù)雜，維護(hù)成本高。搜索，數(shù)據(jù)寫(xiě)入非常高，監(jiān)控?cái)?shù)據(jù)。1.典型互聯(lián)網(wǎng)搜索問(wèn)題2.捕獲增量數(shù)據(jù)3.內(nèi)容服務(wù)4.信息交換HBase主要用來(lái)做數(shù)據(jù)分析和存儲(chǔ)大數(shù)據(jù)內(nèi)容。Redis高性能，部署簡(jiǎn)單，非常的數(shù)據(jù)類型支持，支持?jǐn)?shù)據(jù)持久化，集群方案支持。性能受限于內(nèi)存，單進(jìn)程問(wèn)題。適合小數(shù)據(jù)高讀寫(xiě)場(chǎng)景。緩存服務(wù)。1.保存點(diǎn)擊數(shù)據(jù)(計(jì)數(shù)器)2.在哈希表中保存用戶信息3.用集合保存社交網(wǎng)站圈子數(shù)據(jù)MySQL還是PostgreSQL?1、如果你的應(yīng)用對(duì)數(shù)據(jù)的完整性和嚴(yán)肅性要求不高，但是追求處理的高速度。例如是一個(gè)論壇和社區(qū)，你應(yīng)該使用MySQL。2、你的應(yīng)用是一個(gè)嚴(yán)肅的商業(yè)應(yīng)用，對(duì)數(shù)據(jù)完整性要求很高。而且你希望對(duì)一些商業(yè)數(shù)據(jù)邏輯進(jìn)行很好的封裝，例如是一個(gè)網(wǎng)上銀行，你應(yīng)該使用PostgreSQL。3、你的應(yīng)用處理的是地理數(shù)據(jù)，由于R-TREES的存在，你應(yīng)該使用PostgreSQL。4、等等

從Oracle轉(zhuǎn)向MySQL主要是出于三個(gè)方面的原因：第一，降低運(yùn)維成本。Oracle數(shù)據(jù)庫(kù)自動(dòng)化運(yùn)維實(shí)現(xiàn)難度和成本較高，而MySQL運(yùn)維自動(dòng)化難度和成本相對(duì)較低，當(dāng)數(shù)據(jù)庫(kù)實(shí)例不斷成倍增長(zhǎng)的時(shí)候，使用MySQL可以在有限人力的情況下維護(hù)更多的數(shù)據(jù)庫(kù)實(shí)例。第二，降低軟件成本。OracleLicense成本較高，MySQL及其分支目前是免費(fèi)的。第三，提高可擴(kuò)展性。MySQL是開(kāi)源數(shù)據(jù)庫(kù)，便于有技術(shù)能力的公司根據(jù)業(yè)務(wù)發(fā)展情況自己開(kāi)發(fā)定制一些數(shù)據(jù)庫(kù)周邊服務(wù)，使數(shù)據(jù)庫(kù)使用的擴(kuò)展性提高，而Oracle對(duì)這方面的支持比較一般。

Hbase場(chǎng)景說(shuō)明捕獲增量數(shù)據(jù)數(shù)據(jù)通常是細(xì)水長(zhǎng)流，累加到已有數(shù)據(jù)庫(kù)以備將來(lái)使用，例如分析，處理和服務(wù)。許多HBase使用場(chǎng)景屬于這個(gè)類別——使用HBase作為數(shù)據(jù)存儲(chǔ)，捕獲來(lái)自于各種數(shù)據(jù)源的增量數(shù)據(jù)。例如，這種數(shù)據(jù)源可能是網(wǎng)頁(yè)爬蟲(chóng)，可能是記錄用戶看了什么廣告和多長(zhǎng)時(shí)間的廣告效果數(shù)據(jù)，也可能是記錄各種參數(shù)的時(shí)間序列數(shù)據(jù)。我們討論幾個(gè)成功的使用場(chǎng)景和公司。1.捕獲監(jiān)控參數(shù)服務(wù)于數(shù)百萬(wàn)用戶的WEB產(chǎn)品的后臺(tái)基礎(chǔ)架構(gòu)一般都有數(shù)百或數(shù)千臺(tái)服務(wù)器。這些服務(wù)器承擔(dān)了各種功能——服務(wù)流量，捕獲日志，存儲(chǔ)數(shù)據(jù)，處理數(shù)據(jù)等等。為了保持產(chǎn)品正常運(yùn)行，監(jiān)控服務(wù)器和上面運(yùn)行軟件的健康狀態(tài)是至關(guān)重要的（從OS到用戶交互應(yīng)用）。大規(guī)模監(jiān)控整個(gè)環(huán)境需要能夠采集和存儲(chǔ)來(lái)自于不同數(shù)據(jù)源的各種參數(shù)的監(jiān)控系統(tǒng)。每個(gè)公司有自己的辦法。一些公司使用商業(yè)工具來(lái)收集和展示參數(shù)；而其他一些公司采用開(kāi)源框架。2.捕獲用戶交互數(shù)據(jù)捕獲監(jiān)控?cái)?shù)據(jù)是一種使用方式。還有一種是捕獲用戶交互數(shù)據(jù)。如何跟蹤數(shù)百萬(wàn)用戶在網(wǎng)站上的活動(dòng)？怎么知道哪一個(gè)網(wǎng)站功能是最受歡迎的？怎樣使得這一次的網(wǎng)頁(yè)瀏覽直接影響到下一次？例如，誰(shuí)看了什么？某個(gè)按鈕被點(diǎn)擊了多少次？還記得Facebook和Stumble里的Like按鈕和StumbleUpon里的+1按鈕嗎？是不是聽(tīng)起來(lái)像是一個(gè)計(jì)數(shù)問(wèn)題？每次用戶Like一個(gè)特定主題計(jì)數(shù)器增加一次。

3.廣告效果和點(diǎn)擊流過(guò)去的十年，在線廣告成為互聯(lián)網(wǎng)產(chǎn)品的一個(gè)主要收入來(lái)源。提供免費(fèi)服務(wù)給用戶，在用戶使用服務(wù)的時(shí)侯投放廣告給目標(biāo)用戶。這種精準(zhǔn)投放需要針對(duì)用戶交互數(shù)據(jù)做詳細(xì)的捕獲和分析，以便于理解用戶的特征。基于這種特征，選擇并投放廣告。精細(xì)的用戶交互數(shù)據(jù)帶來(lái)更好的模型，進(jìn)而導(dǎo)致更好的廣告投放效果和更多的收入。但這類數(shù)據(jù)有兩個(gè)特點(diǎn)：它以連續(xù)流的形式出現(xiàn)，它很容易按用戶劃分。理想情況下，這種數(shù)據(jù)一旦產(chǎn)生就能夠馬上使用，用戶特征模型可以沒(méi)有延遲地持續(xù)優(yōu)化——也就是說(shuō)，以在線方式使用。

4.在線VS離線系統(tǒng)在線和離線的術(shù)語(yǔ)多次出現(xiàn)。在線系統(tǒng)需要低延遲。某些情況下，系統(tǒng)哪怕給出沒(méi)有答案的響應(yīng)，也要比花了很長(zhǎng)時(shí)間給出正確答案的響應(yīng)好。你可以把在線系統(tǒng)想象為一個(gè)跳著腳的沒(méi)有耐心的用戶。離線系統(tǒng)不需要低延遲，用戶可以等待答案，不期待馬上給出響應(yīng)。當(dāng)實(shí)現(xiàn)應(yīng)用系統(tǒng)時(shí)在線或者離線的目標(biāo)影響著許多技術(shù)決策。HBase是一個(gè)在線系統(tǒng)。和HadoopMapReduce的緊密結(jié)合又賦予它離線訪問(wèn)的能力。

HBase非常適合收集這種用戶交互數(shù)據(jù)，HBase已經(jīng)成功地應(yīng)用在這種場(chǎng)合，它可以增量捕獲第一手點(diǎn)擊流和用戶交互數(shù)據(jù)，然后用不同處理方式（MapReduce是其中一種）來(lái)處理數(shù)據(jù)（清理、裝飾、使用數(shù)據(jù)）。************************************************內(nèi)容服務(wù)一方面是用戶使用內(nèi)容UserConsumingContent，對(duì)應(yīng)另一面是用戶生成內(nèi)容UserGenerateContent。Tweete、Facebook帖子、Instagram圖片和微博等都是這樣的例子。他們相同的地方是使用和生成了許多內(nèi)容。大量用戶通過(guò)應(yīng)用系統(tǒng)來(lái)使用和生成內(nèi)容，而這些應(yīng)用系統(tǒng)需要Hbase作為基礎(chǔ)。集中的內(nèi)容系統(tǒng)系統(tǒng)CMS可以存儲(chǔ)內(nèi)容和提供服務(wù)。但是當(dāng)用戶越來(lái)越多，生成內(nèi)容越來(lái)越多的時(shí)候，就需要一個(gè)更具擴(kuò)展性的CMS解決方案。這種可擴(kuò)展的CMS往往使用Hbase作為基礎(chǔ)，再加上其他的開(kāi)源框架，例如Solr，構(gòu)成一個(gè)完整的功能組合。(1)URL短鏈最近一段時(shí)間URL短鏈非常流行，許多類似產(chǎn)品破土而出。StumbleUpon使用名字為su.pr.的短鏈產(chǎn)品，這個(gè)產(chǎn)品以HBase為基礎(chǔ)。這個(gè)產(chǎn)品用來(lái)縮短URL，存儲(chǔ)大量的短鏈以及和原始長(zhǎng)鏈接的映射關(guān)系，HBase幫助產(chǎn)品實(shí)現(xiàn)擴(kuò)展能力。(2)用戶模型服務(wù)經(jīng)過(guò)HBase處理過(guò)的內(nèi)容往往并不直接提交給用戶使用，而是用來(lái)決定應(yīng)該提交給用戶什么內(nèi)容。這種中間處理數(shù)據(jù)用來(lái)豐富用戶的交互。還記得前面提到的廣告服務(wù)場(chǎng)景里的用戶模式嗎？用戶模式（或者說(shuō)模型）就是來(lái)自于HBase。這種模型多種多樣，可以用于多種不同場(chǎng)景，例如，針對(duì)特定用戶投放什么廣告的決定，用戶在電商門(mén)戶購(gòu)物時(shí)實(shí)時(shí)報(bào)價(jià)的決定，用戶在搜索引擎檢索時(shí)增加背景信息和關(guān)聯(lián)內(nèi)容，等等。很多這種使用案例可能不便于公開(kāi)討論，說(shuō)多了我們就麻煩了。當(dāng)用戶在電商網(wǎng)站上發(fā)生交易時(shí)，用戶模型服務(wù)可以用來(lái)實(shí)時(shí)報(bào)價(jià)。這種模型需要基于不斷產(chǎn)生的新用戶數(shù)據(jù)持續(xù)優(yōu)化。***********************************************************信息交換各種社交網(wǎng)絡(luò)破土而出，世界變得越來(lái)越小。社叫網(wǎng)站的一個(gè)重要作用就是幫助人們進(jìn)行交互。有時(shí)交互在群組內(nèi)發(fā)生（小規(guī)模和大規(guī)模）；有時(shí)交互在兩個(gè)個(gè)人之見(jiàn)發(fā)生。想想看，數(shù)億人通過(guò)社交網(wǎng)絡(luò)進(jìn)行對(duì)話的場(chǎng)面。只是和遠(yuǎn)處的人通話是不夠的，人們還想看看和其他人通話的歷史記錄。社交網(wǎng)絡(luò)公司感到幸運(yùn)的是，存儲(chǔ)很廉價(jià)，大數(shù)據(jù)領(lǐng)域的創(chuàng)新可以幫助他們充分利用廉價(jià)的存儲(chǔ)。Facebook短信系統(tǒng)經(jīng)常被公開(kāi)討論，他也可能極大地驅(qū)動(dòng)了HBase的發(fā)展。當(dāng)你使用Facebook時(shí)，某個(gè)時(shí)候你可能會(huì)收到或者發(fā)送短信給你的朋友。Facebook的這個(gè)特性完全依賴于HBase。用戶讀寫(xiě)的所有短信都存儲(chǔ)在HBase里。支持Facebook短信的系統(tǒng)需要具備：高的寫(xiě)吞吐量，極大的表，數(shù)據(jù)中心內(nèi)的強(qiáng)一致性。除了短信系統(tǒng)之外，使用HBase的其他應(yīng)用系統(tǒng)另外要求：高的讀吞吐量，計(jì)數(shù)器吞吐量，自動(dòng)分庫(kù)。工程師們發(fā)現(xiàn)HBase是個(gè)理想的解決方案，因?yàn)樗С炙羞@些要求，他擁有一個(gè)活躍的用戶社區(qū)，F(xiàn)acebook運(yùn)營(yíng)團(tuán)隊(duì)在Hadoop部署上有豐富經(jīng)驗(yàn)，等等。在“HadoopgoesrealtimeatFacebook”這篇文章里，F(xiàn)acebook工程師解釋了這個(gè)決定背后的邏輯和顯示了他們使用Hadoop和HBase建設(shè)在線系統(tǒng)的經(jīng)驗(yàn)。

ZooKeeper實(shí)現(xiàn)的案例HDFSHA(QJM)Hadoop2.x之前的版本，HDFS集群中Namenode是整個(gè)集群的中央元數(shù)據(jù)存儲(chǔ)和服務(wù)節(jié)點(diǎn)，它存在SPOF的問(wèn)題。在2.x版本中，提出了各種HA方案，避免Namenode的SPOF問(wèn)題，其中基于QJM（QuorumJournalManager）的方案可以解決這個(gè)問(wèn)題：使用QJM的方案中，HDFS集群中存在兩類節(jié)點(diǎn)，一類是Namenode節(jié)點(diǎn)（包括Active狀態(tài)的Namenode，和Standby狀態(tài)的Namenode），另一類是JournalNode，進(jìn)行容錯(cuò)。當(dāng)Active狀態(tài)的Namenode元數(shù)據(jù)發(fā)生改變時(shí)，通過(guò)JournalNode進(jìn)程（ZooKeeper集群中）來(lái)監(jiān)視這種變化，然后同步到Standby狀態(tài)的Namenode節(jié)點(diǎn)（實(shí)際上同步的是EditLog鏡像文件內(nèi)容的變更）。當(dāng)Active狀態(tài)的節(jié)點(diǎn)發(fā)生故障后，Standby節(jié)點(diǎn)的Namenode自動(dòng)切換，并接管HDFS集群中Active狀態(tài)Namenode的服務(wù)，用來(lái)向客戶端提供元數(shù)據(jù)服務(wù)。SolrSolr是一個(gè)開(kāi)源的分布式搜索引擎，支持索引的分片和復(fù)制，可以根據(jù)需要來(lái)線性增加節(jié)點(diǎn)，擴(kuò)展集群。Solr使用ZooKeeper主要實(shí)現(xiàn)如下功能：配置文件的管理：每個(gè)Collection都有對(duì)應(yīng)的配置文件，多個(gè)分片共享配置文件（schema.xml、solrconfig.xml）Collection管理：一個(gè)Solr集群可以有多個(gè)邏輯上獨(dú)立的Collection，每個(gè)Collection又包括多個(gè)分片和副本集群節(jié)點(diǎn)管理：Solr集群中有哪些活躍的節(jié)點(diǎn)可以使用，每個(gè)節(jié)點(diǎn)上都有Collection的分片（Shard）Leader分片選舉：一個(gè)Collection的多個(gè)分片可以設(shè)置冗余的副本，一個(gè)分片的多個(gè)副本中只有一個(gè)Leader可以進(jìn)提供服務(wù)，如果某個(gè)存儲(chǔ)Leader分片的節(jié)點(diǎn)宕機(jī)，Solr基于ZooKeeper來(lái)重新選出一個(gè)Leader分片，持續(xù)提供服務(wù)HBaseHBase是一個(gè)基于Hadoop平臺(tái)的開(kāi)源NoSQL數(shù)據(jù)庫(kù)，它使用ZooKeeper主要實(shí)現(xiàn)如下功能：Master選舉：HBase基于Master-Slave模式架構(gòu)，可以有多個(gè)HMaster，使用ZooKeeper實(shí)現(xiàn)了SPOF下Master的選舉租約管理：客戶端與RegionServer交互時(shí)，會(huì)生成租約，該租約對(duì)象具有有效期表元數(shù)據(jù)管理：HBase中包括用戶表及其兩個(gè)特殊的表：-ROOT-表和.META.表（例如，管理-ROOT-表中l(wèi)ocation信息，一個(gè)-ROOT-表只有一個(gè)Region，它保存了RegionServer的地址信息。）協(xié)調(diào)RegionServer節(jié)點(diǎn)：數(shù)據(jù)變更會(huì)通過(guò)ZooKeeper同步復(fù)制到其他節(jié)點(diǎn)LilyLily是一個(gè)分布式數(shù)據(jù)管理平臺(tái)，它基于Hadoop、HBase、Solr、ZooKeeper實(shí)現(xiàn)。使用ZooKeeper來(lái)注冊(cè)LilyNode，從而管理集群節(jié)點(diǎn)的狀態(tài)信息。DubboDubbo是阿里巴巴開(kāi)源的分布式服務(wù)框架，它可以選擇使用ZooKeeper作為服務(wù)注冊(cè)中心。Dubbo服務(wù)基于Provider-Consumer模型，在服務(wù)發(fā)布的時(shí)候可以選擇使用ZooKeeper作為注冊(cè)中心來(lái)管理注冊(cè)的服務(wù)，包括Provider發(fā)布的服務(wù)和Consumer訂閱的服務(wù)。KattaKatta實(shí)現(xiàn)了Lucene的分布式索引，能夠提供數(shù)據(jù)的實(shí)時(shí)訪問(wèn)。Katta使用ZooKeeper實(shí)現(xiàn)了集群節(jié)點(diǎn)的管理，Master的選舉，以及Lucene索引的管理。StromStorm流式計(jì)算框架使用ZooKeeper來(lái)協(xié)調(diào)整個(gè)計(jì)算集群，Storm計(jì)算集群存在Nimbus和Supervisor兩類節(jié)點(diǎn)。Nimbus負(fù)責(zé)分配任務(wù)（Topology），將任務(wù)信息寫(xiě)入ZooKeeper存儲(chǔ)，然后Supervisor從ZooKeeper中讀取任務(wù)信息。另外，Nimbus也監(jiān)控集群中的計(jì)算任務(wù)節(jié)點(diǎn)，Supervisor也會(huì)發(fā)送心跳信息（包括狀態(tài)信息）到ZooKeeper中，使得Nimbus可以實(shí)現(xiàn)狀態(tài)的監(jiān)控，任何計(jì)算節(jié)點(diǎn)出現(xiàn)故障，只要重新啟動(dòng)之后，繼續(xù)從ZooKeeper中獲取數(shù)據(jù)即可繼續(xù)執(zhí)行計(jì)算任務(wù)。BookKeeperBookKeeper是ApacheZooKeeper項(xiàng)目的一個(gè)子項(xiàng)目。它是一個(gè)用來(lái)可靠地記錄流數(shù)據(jù)的系統(tǒng)，主要用于存儲(chǔ)WAL（WriteAheadLog）。我們知道，HadoopNamenode用來(lái)存儲(chǔ)HDSF集群的元數(shù)據(jù)，其中存在一個(gè)用于寫(xiě)就花數(shù)據(jù)的EditLog文件，和一個(gè)存在于內(nèi)存中的FsImage鏡像，每當(dāng)客戶端與HDFS集群交互時(shí)，對(duì)于集群中數(shù)據(jù)的變更都會(huì)記錄在Namen