一、NoSQL數(shù)據(jù)庫簡(jiǎn)介

Web1.0的時(shí)代，數(shù)據(jù)訪問量很有限，用一夫當(dāng)關(guān)的高性能的單點(diǎn)服務(wù)器可以解決大部分問題。

在丹東等地區(qū)，都構(gòu)建了全面的區(qū)域性戰(zhàn)略布局，加強(qiáng)發(fā)展的系統(tǒng)性、市場(chǎng)前瞻性、產(chǎn)品創(chuàng)新能力，以專注、極致的服務(wù)理念，為客戶提供網(wǎng)站設(shè)計(jì)制作、網(wǎng)站設(shè)計(jì) 網(wǎng)站設(shè)計(jì)制作按需定制網(wǎng)站,公司網(wǎng)站建設(shè),企業(yè)網(wǎng)站建設(shè),品牌網(wǎng)站建設(shè),營銷型網(wǎng)站,成都外貿(mào)網(wǎng)站制作,丹東網(wǎng)站建設(shè)費(fèi)用合理。

隨著Web2.0的時(shí)代的到來，用戶訪問量大幅度提升，同時(shí)產(chǎn)生了大量的用戶數(shù)據(jù)。加上后來的智能移動(dòng)設(shè)備的普及，所有的互聯(lián)網(wǎng)平臺(tái)都面臨了巨大的性能挑戰(zhàn)。

NoSQL(NoSQL = Not Only SQL )，意即“不僅僅是SQL”，泛指非關(guān)系型的數(shù)據(jù)庫。

NoSQL 不依賴業(yè)務(wù)邏輯方式存儲(chǔ)，而以簡(jiǎn)單的key-value模式存儲(chǔ)。因此大大的增加了數(shù)據(jù)庫的擴(kuò)展能力。

Memcache Memcache Redis Redis MongoDB MongoDB 列式數(shù)據(jù)庫 列式數(shù)據(jù)庫 Hbase Hbase

HBase是Hadoop項(xiàng)目中的數(shù)據(jù)庫。它用于需要對(duì)大量的數(shù)據(jù)進(jìn)行隨機(jī)、實(shí)時(shí)的讀寫操作的場(chǎng)景中。

HBase的目標(biāo)就是處理數(shù)據(jù)量非常龐大的表，可以用普通的計(jì)算機(jī)處理超過10億行數(shù)據(jù)，還可處理有數(shù)百萬列元素的數(shù)據(jù)表。

Cassandra Cassandra

Apache Cassandra是一款免費(fèi)的開源NoSQL數(shù)據(jù)庫，其設(shè)計(jì)目的在于管理由大量商用服務(wù)器構(gòu)建起來的龐大集群上的海量數(shù)據(jù)集(數(shù)據(jù)量通常達(dá)到PB級(jí)別)。在眾多顯著特性當(dāng)中，Cassandra最為卓越的長(zhǎng)處是對(duì)寫入及讀取操作進(jìn)行規(guī)模調(diào)整，而且其不強(qiáng)調(diào)主集群的設(shè)計(jì)思路能夠以相對(duì)直觀的方式簡(jiǎn)化各集群的創(chuàng)建與擴(kuò)展流程。

主要應(yīng)用：社會(huì)關(guān)系，公共交通網(wǎng)絡(luò)，地圖及網(wǎng)絡(luò)拓譜(n*(n-1)/2)

如何學(xué)習(xí)及選擇大數(shù)據(jù)非關(guān)系型數(shù)據(jù)庫NoSQL

是的，NoSQL（非關(guān)系型數(shù)據(jù)庫）簡(jiǎn)單來說，關(guān)系模型指的就是二維表格模型，而一個(gè)關(guān)系型數(shù)據(jù)庫就是由二維表及其之間的聯(lián)系組成的一個(gè)數(shù)據(jù)組織。 NoSQL最普遍的解釋是“非關(guān)系型的”，強(qiáng)調(diào)Key-Value Stores和文檔數(shù)據(jù)庫的優(yōu)點(diǎn)，而不是單純的反對(duì)RDBMS。

非關(guān)系型數(shù)據(jù)庫特點(diǎn)

1.可以處理超大量的數(shù)據(jù)。

2.運(yùn)行在便宜的PC服務(wù)器集群上。PC集群擴(kuò)充起來非常方便并且成本很低，避免了“sharding”操作的復(fù)雜性和成本。

3.擊碎了性能瓶頸。NoSQL的支持者稱，通過NoSQL架構(gòu)可以省去將Web或Java應(yīng)用和數(shù)據(jù)轉(zhuǎn)換成SQL友好格式的時(shí)間，執(zhí)行速度變得更快。

4.沒有過多的操作。

5.支持者來源于社區(qū)。因?yàn)镹oSQL項(xiàng)目都是開源的，因此它們?nèi)狈?yīng)商提供的正式支持。這一點(diǎn)它們與大多數(shù)開源項(xiàng)目一樣，不得不從社區(qū)中尋求支持。

NoSQL-HDFS-基本概念

Hadoop

文件系統(tǒng)：文件系統(tǒng)是用來存儲(chǔ)和管理文件，并且提供文件的查詢、增加、刪除等操作。

直觀上的體驗(yàn)：在shell窗口輸入 ls 命令，就可以看到當(dāng)前目錄下的文件夾、文件。

文件存儲(chǔ)在哪里？硬盤

一臺(tái)只有250G硬盤的電腦，如果需要存儲(chǔ)500G的文件可以怎么辦？先將電腦硬盤擴(kuò)容至少250G，再將文件分割成多塊，放到多塊硬盤上儲(chǔ)存。

通過 hdfs dfs -ls 命令可以查看分布式文件系統(tǒng)中的文件，就像本地的ls命令一樣。

HDFS在客戶端上提供了查詢、新增和刪除的指令，可以實(shí)現(xiàn)將分布在多臺(tái)機(jī)器上的文件系統(tǒng)進(jìn)行統(tǒng)一的管理。

在分布式文件系統(tǒng)中，一個(gè)大文件會(huì)被切分成塊，分別存儲(chǔ)到幾臺(tái)機(jī)器上。結(jié)合上文中提到的那個(gè)存儲(chǔ)500G大文件的那個(gè)例子，這500G的文件會(huì)按照一定的大小被切分成若干塊，然后分別存儲(chǔ)在若干臺(tái)機(jī)器上，然后提供統(tǒng)一的操作接口。

看到這里，不少人可能會(huì)覺得，分布式文件系統(tǒng)不過如此，很簡(jiǎn)單嘛。事實(shí)真的是這樣的么？

潛在問題

假如我有一個(gè)1000臺(tái)機(jī)器組成的分布式系統(tǒng)，一臺(tái)機(jī)器每天出現(xiàn)故障的概率是0.1%，那么整個(gè)系統(tǒng)每天出現(xiàn)故障的概率是多大呢？答案是(1-0.1%)^1000=63%，因此需要提供一個(gè)容錯(cuò)機(jī)制來保證發(fā)生差錯(cuò)時(shí)文件依然可以讀出，這里暫時(shí)先不展開介紹。

如果要存儲(chǔ)PB級(jí)或者EB級(jí)的數(shù)據(jù)，成千上萬臺(tái)機(jī)器組成的集群是很常見的，所以說分布式系統(tǒng)比單機(jī)系統(tǒng)要復(fù)雜得多呀。

這是一張HDFS的架構(gòu)簡(jiǎn)圖：

client通過nameNode了解數(shù)據(jù)在哪些DataNode上，從而發(fā)起查詢。此外，不僅是查詢文件，寫入文件的時(shí)候也是先去請(qǐng)教N(yùn)ameNode，看看應(yīng)該往哪個(gè)DateNode中去寫。

為了某一份數(shù)據(jù)只寫入到一個(gè)Datanode中，而這個(gè)Datanode因?yàn)槟承┰虺鲥e(cuò)無法讀取的問題，需要通過冗余備份的方式來進(jìn)行容錯(cuò)處理。因此，HDFS在寫入一個(gè)數(shù)據(jù)塊的時(shí)候，不會(huì)僅僅寫入一個(gè)DataNode，而是會(huì)寫入到多個(gè)DataNode中，這樣，如果其中一個(gè)DataNode壞了，還可以從其余的DataNode中拿到數(shù)據(jù)，保證了數(shù)據(jù)不丟失。

實(shí)際上，每個(gè)數(shù)據(jù)塊在HDFS上都會(huì)保存多份，保存在不同的DataNode上。這種是犧牲一定存儲(chǔ)空間換取可靠性的做法。

接下來我們來看一下完整的文件寫入的流程：

大文件要寫入HDFS，client端根據(jù)配置將大文件分成固定大小的塊，然后再上傳到HDFS。

讀取文件的流程：

1、client詢問NameNode，我要讀取某個(gè)路徑下的文件，麻煩告訴我這個(gè)文件都在哪些DataNode上？

2、NameNode回復(fù)client，這個(gè)路徑下的文件被切成了3塊，分別在DataNode1、DataNode3和DataNode4上

3、client去找DataNode1、DataNode3和DataNode4，拿到3個(gè)文件塊，通過stream讀取并且整合起來

文件寫入的流程：

1、client先將文件分塊，然后詢問NameNode，我要寫入一個(gè)文件到某個(gè)路徑下，文件有3塊，應(yīng)該怎么寫？

2、NameNode回復(fù)client，可以分別寫到DataNode1、DataNode2、DataNode3、DataNode4上，記住，每個(gè)塊重復(fù)寫3份，總共是9份

3、client找到DataNode1、DataNode2、DataNode3、DataNode4，把數(shù)據(jù)寫到他們上面

出于容錯(cuò)的考慮，每個(gè)數(shù)據(jù)塊有3個(gè)備份，但是3個(gè)備份快都直接由client端直接寫入勢(shì)必會(huì)帶來client端過重的寫入壓力，這個(gè)點(diǎn)是否有更好的解決方案呢？回憶一下mysql主備之間是通過binlog文件進(jìn)行同步的，HDFS當(dāng)然也可以借鑒這個(gè)思想，數(shù)據(jù)其實(shí)只需要寫入到一個(gè)datanode上，然后由datanode之間相互進(jìn)行備份同步，減少了client端的寫入壓力，那么至于是一個(gè)datanode寫入成功即成功，還是需要所有的參與備份的datanode返回寫入成功才算成功，是可靠性配置的策略，當(dāng)然這個(gè)設(shè)置會(huì)影響到數(shù)據(jù)寫入的吞吐率，我們可以看到可靠性和效率永遠(yuǎn)是“魚和熊掌不可兼得”的。

潛在問題

NameNode確實(shí)會(huì)回放editlog，但是不是每次都從頭回放，它會(huì)先加載一個(gè)fsimage，這個(gè)文件是之前某一個(gè)時(shí)刻整個(gè)NameNode的文件元數(shù)據(jù)的內(nèi)存快照，然后再在這個(gè)基礎(chǔ)上回放editlog，完成后，會(huì)清空editlog，再把當(dāng)前文件元數(shù)據(jù)的內(nèi)存狀態(tài)寫入fsimage，方便下一次加載。

這樣，全量回放就變成了增量回放，但是如果NameNode長(zhǎng)時(shí)間未重啟過，editlog依然會(huì)比較大，恢復(fù)的時(shí)間依然比較長(zhǎng)，這個(gè)問題怎么解呢？

SecondNameNode是一個(gè)NameNode內(nèi)的定時(shí)任務(wù)線程，它會(huì)定期地將editlog寫入fsimage，然后情況原來的editlog，從而保證editlog的文件大小維持在一定大小。

NameNode掛了， SecondNameNode并不能替代NameNode，所以如果集群中只有一個(gè)NameNode，它掛了，整個(gè)系統(tǒng)就掛了。hadoop2.x之前，整個(gè)集群只能有一個(gè)NameNode，是有可能發(fā)生單點(diǎn)故障的，所以hadoop1.x有本身的不穩(wěn)定性。但是hadoop2.x之后，我們可以在集群中配置多個(gè)NameNode，就不會(huì)有這個(gè)問題了，但是配置多個(gè)NameNode，需要注意的地方就更多了，系統(tǒng)就更加復(fù)雜了。

俗話說“一山不容二虎”，兩個(gè)NameNode只能有一個(gè)是活躍狀態(tài)active，另一個(gè)是備份狀態(tài)standby，我們看一下兩個(gè)NameNode的架構(gòu)圖。

兩個(gè)NameNode通過JournalNode實(shí)現(xiàn)同步editlog，保持狀態(tài)一致可以相互替換。

因?yàn)閍ctive的NameNode掛了之后，standby的NameNode要馬上接替它，所以它們的數(shù)據(jù)要時(shí)刻保持一致，在寫入數(shù)據(jù)的時(shí)候，兩個(gè)NameNode內(nèi)存中都要記錄數(shù)據(jù)的元信息，并保持一致。這個(gè)JournalNode就是用來在兩個(gè)NameNode中同步數(shù)據(jù)的，并且standby NameNode實(shí)現(xiàn)了SecondNameNode的功能。

進(jìn)行數(shù)據(jù)同步操作的過程如下：

active NameNode有操作之后，它的editlog會(huì)被記錄到JournalNode中，standby NameNode會(huì)從JournalNode中讀取到變化并進(jìn)行同步，同時(shí)standby NameNode會(huì)監(jiān)聽記錄的變化。這樣做的話就是實(shí)時(shí)同步了，并且standby NameNode就實(shí)現(xiàn)了SecondNameNode的功能。

優(yōu)點(diǎn)：

缺點(diǎn)：

【軟件架構(gòu)篇】互聯(lián)網(wǎng)架構(gòu)模板

架構(gòu)圖如下圖所示。這張圖基本涵蓋了互聯(lián)網(wǎng)技術(shù)公司的大部分技術(shù)點(diǎn)，不同公司只是在具體的技術(shù)實(shí)現(xiàn)上稍有差異，但不會(huì)跳出這個(gè)框架的范疇。

SQL： 常用的有mysql，用于存儲(chǔ)業(yè)務(wù)數(shù)據(jù)。互聯(lián)網(wǎng)發(fā)展初期，各個(gè)業(yè)務(wù)一般都會(huì)獨(dú)立運(yùn)營mysql集群，但隨著業(yè)務(wù)越來越多，mysql集群規(guī)模越來越大，那就有必要做成SQL平臺(tái)。

NoSQL: 翻譯為Not Only SQL，作為mysql的一種補(bǔ)充。Nosql一般本身就提供集群，且使用起來很方便，公司業(yè)務(wù)發(fā)展初期沒有必要。一般Nosql集群的數(shù)量越來越多，那就有必要做成Nosql平臺(tái)。

小文件： 互聯(lián)網(wǎng)中有很多小文件，比如商品圖片，F(xiàn)acebook的圖片。這類小文件具有數(shù)據(jù)小、數(shù)量巨大、訪問大的特點(diǎn)。如果每個(gè)業(yè)務(wù)都去考慮小文件存儲(chǔ)的話，就會(huì)出現(xiàn)重復(fù)造輪子現(xiàn)象，那就有必要做成小文件平臺(tái)了。

大文件： 互聯(lián)網(wǎng)的大文件主要分為兩類：一類是業(yè)務(wù)上的大數(shù)據(jù)，例如Youtube的視頻、電影網(wǎng)站的電影；另一類是海量的日志數(shù)據(jù)，例如各種訪問日志。實(shí)力雄厚的一些大公司會(huì)基于開源方案做成大數(shù)據(jù)平臺(tái)。

開發(fā)框架： 比如常見的Spring框架。

Web服務(wù)器： 常見的有tomcat、jetty等。

容器： Docker可以極大降低運(yùn)維成本，以及在實(shí)現(xiàn)動(dòng)態(tài)擴(kuò)容上非常方便。

配置中心： 故名思義，配置中心就是集中管理各個(gè)系統(tǒng)的配置。

服務(wù)中心： 解決跨系統(tǒng)依賴的配置和調(diào)度問題。比如有10個(gè)系統(tǒng)依賴A系統(tǒng)的x接口，此時(shí)A系統(tǒng)實(shí)現(xiàn)了一個(gè)y接口可以更好地支持x接口，那么如果直接更新10個(gè)系統(tǒng)依賴的配置將會(huì)很麻煩。

消息隊(duì)列： 支持系統(tǒng)解耦。

負(fù)載均衡： 充當(dāng)任務(wù)分配器的職責(zé)。

CDN： 可以對(duì)一些常用文件進(jìn)行就近緩存，來提高訪問速度。

多機(jī)房： 多機(jī)房的主要目的是備災(zāi)，當(dāng)機(jī)房故障時(shí)可以快速地將業(yè)務(wù)切換到另外一個(gè)機(jī)房，這種切換操作允許一定時(shí)間的中斷，比如10分鐘，1個(gè)小時(shí)。

多中心： 多中心的要求就更高了，要求同時(shí)對(duì)外提供服務(wù)，且業(yè)務(wù)能夠自動(dòng)在多中心之間切換，故障后不需人工干預(yù)或者很少的人工干預(yù)就能自動(dòng)恢復(fù)。

用戶管理： 對(duì)各個(gè)系統(tǒng)的用戶進(jìn)行統(tǒng)一管理。

消息推送： 根據(jù)不同途徑分為短信、郵件、站內(nèi)信、App推送。

存儲(chǔ)云： 實(shí)現(xiàn)是CDN+小文件存儲(chǔ)。

圖片云： 實(shí)現(xiàn)也是CDN+小文件存儲(chǔ)。為何不與存儲(chǔ)云統(tǒng)一一套系統(tǒng)呢？這是因?yàn)閳D片業(yè)務(wù)的復(fù)雜性導(dǎo)致的。圖片涉及的業(yè)務(wù)會(huì)更多，包括裁剪、壓縮、美化、審核、水印等。

業(yè)務(wù)千差萬別，各個(gè)互聯(lián)網(wǎng)業(yè)務(wù)面對(duì)的主要問題是復(fù)雜度越來越高。此時(shí)就要用到拆和合的技術(shù)。拆即將一個(gè)大系統(tǒng)拆分為多個(gè)子系統(tǒng)，降低復(fù)雜度。當(dāng)子系統(tǒng)越來越多，有可能就需要采用合的技術(shù)。

測(cè)試平臺(tái)的核心目的是提升測(cè)試效率。

運(yùn)維平臺(tái)的核心職責(zé)分為四大塊：配置、部署、監(jiān)控、應(yīng)急。

數(shù)據(jù)平臺(tái)的核心職責(zé)主要包含三部分：數(shù)據(jù)管理、數(shù)據(jù)分析和數(shù)據(jù)應(yīng)用。

管理平臺(tái)的核心職責(zé)就是權(quán)限管理。

網(wǎng)站欄目：nosql怎樣組建集群的簡(jiǎn)單介紹
轉(zhuǎn)載源于：http://chinadenli.net/article5/dseppii.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供企業(yè)建站、動(dòng)態(tài)網(wǎng)站、電子商務(wù)、做網(wǎng)站、App設(shè)計(jì)、用戶體驗(yàn)

廣告

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