建站
咨詢
售后
建站咨詢
新聞中心
NoSQL-HDFS-基本概念
Hadoop
在華州等地區(qū)，都構(gòu)建了全面的區(qū)域性戰(zhàn)略布局，加強(qiáng)發(fā)展的系統(tǒng)性、市場前瞻性、產(chǎn)品創(chuàng)新能力，以專注、極致的服務(wù)理念，為客戶提供成都網(wǎng)站建設(shè)、網(wǎng)站制作 網(wǎng)站設(shè)計制作按需求定制設(shè)計,公司網(wǎng)站建設(shè),企業(yè)網(wǎng)站建設(shè),品牌網(wǎng)站建設(shè),營銷型網(wǎng)站建設(shè),成都外貿(mào)網(wǎng)站建設(shè)公司,華州網(wǎng)站建設(shè)費用合理。
文件系統(tǒng)：文件系統(tǒng)是用來存儲和管理文件，并且提供文件的查詢、增加、刪除等操作。
直觀上的體驗：在shell窗口輸入 ls 命令，就可以看到當(dāng)前目錄下的文件夾、文件。
文件存儲在哪里？硬盤
一臺只有250G硬盤的電腦，如果需要存儲500G的文件可以怎么辦？先將電腦硬盤擴(kuò)容至少250G，再將文件分割成多塊，放到多塊硬盤上儲存。
通過 hdfs dfs -ls 命令可以查看分布式文件系統(tǒng)中的文件，就像本地的ls命令一樣。
HDFS在客戶端上提供了查詢、新增和刪除的指令，可以實現(xiàn)將分布在多臺機(jī)器上的文件系統(tǒng)進(jìn)行統(tǒng)一的管理。
在分布式文件系統(tǒng)中，一個大文件會被切分成塊，分別存儲到幾臺機(jī)器上。結(jié)合上文中提到的那個存儲500G大文件的那個例子，這500G的文件會按照一定的大小被切分成若干塊，然后分別存儲在若干臺機(jī)器上，然后提供統(tǒng)一的操作接口。
看到這里，不少人可能會覺得，分布式文件系統(tǒng)不過如此，很簡單嘛。事實真的是這樣的么？
潛在問題
假如我有一個1000臺機(jī)器組成的分布式系統(tǒng)，一臺機(jī)器每天出現(xiàn)故障的概率是0.1%，那么整個系統(tǒng)每天出現(xiàn)故障的概率是多大呢？答案是(1-0.1%)^1000=63%，因此需要提供一個容錯機(jī)制來保證發(fā)生差錯時文件依然可以讀出，這里暫時先不展開介紹。
如果要存儲PB級或者EB級的數(shù)據(jù)，成千上萬臺機(jī)器組成的集群是很常見的，所以說分布式系統(tǒng)比單機(jī)系統(tǒng)要復(fù)雜得多呀。
這是一張HDFS的架構(gòu)簡圖：
client通過nameNode了解數(shù)據(jù)在哪些DataNode上，從而發(fā)起查詢。此外，不僅是查詢文件，寫入文件的時候也是先去請教N(yùn)ameNode，看看應(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)點：
缺點：
請分析“大數(shù)據(jù)”的存儲方式及主要業(yè)務(wù)跟課中所講解的關(guān)系型數(shù)據(jù)庫有何區(qū)別？
大數(shù)據(jù)的存儲方式主要使用noSQL
這種數(shù)據(jù)庫有幾個特點，一個是針對大數(shù)據(jù)環(huán)境，它是分布式的，另一個他的操作非常原始，只有Keyvalue讀寫
關(guān)系數(shù)據(jù)庫呢，一般都是單機(jī)的，因為關(guān)系數(shù)據(jù)庫最強(qiáng)大的就是事務(wù)，事物在分布式環(huán)境很難實現(xiàn)，所以關(guān)系數(shù)據(jù)庫通常都是單機(jī)版，另外一個是關(guān)系數(shù)據(jù)庫，它的計算層次更高，是表格上的運算
nosql數(shù)據(jù)庫是什么 具有代表性以key-value的形式存儲的
NoSQL，泛指非關(guān)系型的數(shù)據(jù)庫。隨著互聯(lián)網(wǎng)web2.0網(wǎng)站的興起，傳統(tǒng)的關(guān)系數(shù)據(jù)庫在應(yīng)付web2.0網(wǎng)站，特別是超大規(guī)模和高并發(fā)的SNS類型的web2.0純動態(tài)網(wǎng)站已經(jīng)顯得力不從心，暴露了很多難以克服的問題，而非關(guān)系型的數(shù)據(jù)庫則由于其本身的特點得到了非常迅速的發(fā)展。NoSQL數(shù)據(jù)庫的產(chǎn)生就是為了解決大規(guī)模數(shù)據(jù)集合多重數(shù)據(jù)種類帶來的挑戰(zhàn)，尤其是大數(shù)據(jù)應(yīng)用難題。
鍵值(Key-Value)存儲數(shù)據(jù)庫
這一類數(shù)據(jù)庫主要會使用到一個哈希表，這個表中有一個特定的鍵和一個指針指向特定的數(shù)據(jù)。Key/value模型對于IT系統(tǒng)來說的優(yōu)勢在于簡單、易部署。但是如果DBA只對部分值進(jìn)行查詢或更新的時候，Key/value就顯得效率低下了。[3] 舉例如：Tokyo Cabinet/Tyrant, Redis, Voldemort, Oracle BDB.
列存儲數(shù)據(jù)庫。
這部分?jǐn)?shù)據(jù)庫通常是用來應(yīng)對分布式存儲的海量數(shù)據(jù)。鍵仍然存在，但是它們的特點是指向了多個列。這些列是由列家族來安排的。如：Cassandra, HBase, Riak.
文檔型數(shù)據(jù)庫
文檔型數(shù)據(jù)庫的靈感是來自于Lotus Notes辦公軟件的，而且它同第一種鍵值存儲相類似。該類型的數(shù)據(jù)模型是版本化的文檔，半結(jié)構(gòu)化的文檔以特定的格式存儲，比如JSON。文檔型數(shù)據(jù)庫可 以看作是鍵值數(shù)據(jù)庫的升級版，允許之間嵌套鍵值。而且文檔型數(shù)據(jù)庫比鍵值數(shù)據(jù)庫的查詢效率更高。如：CouchDB, MongoDb. 國內(nèi)也有文檔型數(shù)據(jù)庫SequoiaDB，已經(jīng)開源。
圖形(Graph)數(shù)據(jù)庫
圖形結(jié)構(gòu)的數(shù)據(jù)庫同其他行列以及剛性結(jié)構(gòu)的SQL數(shù)據(jù)庫不同，它是使用靈活的圖形模型，并且能夠擴(kuò)展到多個服務(wù)器上。NoSQL數(shù)據(jù)庫沒有標(biāo)準(zhǔn)的查詢語言(SQL)，因此進(jìn)行數(shù)據(jù)庫查詢需要制定數(shù)據(jù)模型。許多NoSQL數(shù)據(jù)庫都有REST式的數(shù)據(jù)接口或者查詢API。[2] 如：Neo4J, InfoGrid, Infinite Graph.
因此，我們總結(jié)NoSQL數(shù)據(jù)庫在以下的這幾種情況下比較適用：1、數(shù)據(jù)模型比較簡單；2、需要靈活性更強(qiáng)的IT系統(tǒng)；3、對數(shù)據(jù)庫性能要求較高；4、不需要高度的數(shù)據(jù)一致性；5、對于給定key，比較容易映射復(fù)雜值的環(huán)境。
什么是nosql
nosql是not only sql的意思。是近今年新發(fā)展起來的存儲系統(tǒng)。當(dāng)前使用最多的是key-value模型，用于處理超大規(guī)模的數(shù)據(jù)。
以下是摘自百度百科中的一部分
NoSQL 是非關(guān)系型數(shù)據(jù)存儲的廣義定義。它打破了長久以來關(guān)系型數(shù)據(jù)庫與ACID理論大一統(tǒng)的局面。NoSQL 數(shù)據(jù)存儲不需要固定的表結(jié)構(gòu)，通常也不存在連接操作。在大數(shù)據(jù)存取上具備關(guān)系型數(shù)據(jù)庫無法比擬的性能優(yōu)勢。該術(shù)語在 2009 年初得到了廣泛認(rèn)同。
當(dāng)今的應(yīng)用體系結(jié)構(gòu)需要數(shù)據(jù)存儲在橫向伸縮性上能夠滿足需求。而 NoSQL 存儲就是為了實現(xiàn)這個需求。Google 的BigTable與Amazon的Dynamo是非常成功的商業(yè) NoSQL 實現(xiàn)。一些開源的 NoSQL 體系，如Facebook 的Cassandra， Apache 的HBase，也得到了廣泛認(rèn)同。從這些NoSQL項目的名字上看不出什么相同之處：Hadoop、Voldemort、Dynomite，還有其它很多。
NoSQL與關(guān)系型數(shù)據(jù)庫設(shè)計理念比較
關(guān)系型數(shù)據(jù)庫中的表都是存儲一些格式化的數(shù)據(jù)結(jié)構(gòu)，每個元組字段的組成都一樣，即使不是每個元組都需要所有的字段，但數(shù)據(jù)庫會為每個元組分配所有的字段，這樣的結(jié)構(gòu)可以便于表與表之間進(jìn)行連接等操作，但從另一個角度來說它也是關(guān)系型數(shù)據(jù)庫性能瓶頸的一個因素。而非關(guān)系型數(shù)據(jù)庫以鍵值對存儲，它的結(jié)構(gòu)不固定，每一個元組可以有不一樣的字段，每個元組可以根據(jù)需要增加一些自己的鍵值對，這樣就不會局限于固定的結(jié)構(gòu)，可以減少一些時間和空間的開銷。
網(wǎng)頁題目：NOSQL儲存方式,NoSql 數(shù)據(jù)存儲
URL網(wǎng)址：http://fisionsoft.com.cn/article/dsdpgse.html
