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

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

專注于為中小企業(yè)提供成都網(wǎng)站制作、成都網(wǎng)站建設(shè)服務(wù),電腦端+手機端+微信端的三站合一,更高效的管理,為中小企業(yè)鹿城免費做網(wǎng)站提供優(yōu)質(zhì)的服務(wù)。我們立足成都，凝聚了一批互聯(lián)網(wǎng)行業(yè)人才，有力地推動了上千家企業(yè)的穩(wěn)健成長，幫助中小企業(yè)通過網(wǎng)站建設(shè)實現(xiàn)規(guī)模擴充和轉(zhuǎn)變。

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

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

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

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

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

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

Cassandra Cassandra

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

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

NoSQL-HDFS-基本概念

Hadoop

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

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

文件存儲在哪里？硬盤

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

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

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

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

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

潛在問題

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

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

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

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

為了某一份數(shù)據(jù)只寫入到一個Datanode中，而這個Datanode因為某些原因出錯無法讀取的問題，需要通過冗余備份的方式來進(jìn)行容錯處理。因此，HDFS在寫入一個數(shù)據(jù)塊的時候，不會僅僅寫入一個DataNode，而是會寫入到多個DataNode中，這樣，如果其中一個DataNode壞了，還可以從其余的DataNode中拿到數(shù)據(jù)，保證了數(shù)據(jù)不丟失。

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

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

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

讀取文件的流程：

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

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

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

文件寫入的流程：

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

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

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

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

潛在問題

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

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

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

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

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

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

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

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

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

優(yōu)點：

缺點：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

測試平臺的核心目的是提升測試效率。

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

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

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

nosql數(shù)據(jù)庫的四種類型

一般將NoSQL數(shù)據(jù)庫分為四大類：鍵值(Key-Value)存儲數(shù)據(jù)庫、列存儲數(shù)據(jù)庫、文檔型數(shù)據(jù)庫和圖形(Graph)數(shù)據(jù)庫。它們的數(shù)據(jù)模型、優(yōu)缺點、典型應(yīng)用場景。

鍵值(Key-Value)存儲數(shù)據(jù)庫Key指向Value的鍵值對，通常用hash表來實現(xiàn)查找速度快數(shù)據(jù)無結(jié)構(gòu)化(通常只被當(dāng)作字符串或者二進(jìn)制數(shù)據(jù))內(nèi)容緩存，主要用于處理大量數(shù)據(jù)的高訪問負(fù)載，也用于一些日志系統(tǒng)等。

列存儲數(shù)據(jù)庫，以列簇式存儲，將同一列數(shù)據(jù)存在一起查找速度快，可擴展性強，更容易進(jìn)行分布式擴展功能相對局限分布式的文件系統(tǒng)。

文檔型數(shù)據(jù)庫，Key-Value對應(yīng)的鍵值對，Value為結(jié)構(gòu)化數(shù)據(jù)，數(shù)據(jù)結(jié)構(gòu)要求不嚴(yán)格，表結(jié)構(gòu)可變(不需要像關(guān)系型數(shù)據(jù)庫一樣需預(yù)先定義表結(jié)構(gòu))，查詢性能不高，而且缺乏統(tǒng)一的查詢語法，Web應(yīng)用。

圖形(Graph)數(shù)據(jù)庫，圖結(jié)構(gòu)，利用圖結(jié)構(gòu)相關(guān)算法(如最短路徑尋址，N度關(guān)系查找等)，很多時候需要對整個圖做計算才能得出需要的信息，而且這種結(jié)構(gòu)不太好做分布式的集群方案，社交網(wǎng)絡(luò)，推薦系統(tǒng)等。