單機nosql,單機nosql引擎

互聯網背景下，為什么用NoSql

本文將從單機MySQL的場景出發，簡述一下隨著網站的訪問量越來越大，數據庫部署的演進過程，到為什么要用MySQL的必要性。

成都創新互聯是一家專注于網站制作、成都網站設計與策劃設計,鳳凰網站建設哪家好?成都創新互聯做網站,專注于網站建設十多年,網設計領域的專業建站公司;建站業務涵蓋:鳳凰等地區。鳳凰做網站價格咨詢:028-86922220

大數據時代的數據有3V的特點：海量Volume、多樣Variety、實時Velocity。

互聯網網站需求的3高的特點：高并發、高可擴、高性能。

一、單機MySql

當一個網站的訪問量不大時，用單個數據庫完全可以輕松應付。

在那個時候，更多的都是靜態網頁，動態交互類型的網站不多。

上述架構下，我們來看看數據存儲的瓶頸是什么？

1.數據量的總大小 一個機器放不下時

2.數據的索引（B+ Tree）一個機器的內存放不下時

3.訪問量(讀寫混合)一個實例不能承受

如果滿足了上述1 or 3個，進化......

二、Memcached（緩存）+Mysql+垂直拆分

后來，隨著訪問量的上升，幾乎大部分使用MySQL架構的網站在數據庫上都開始出現了性能問題，web程序不再僅僅專注在功能上，同時也在追求性能。程序員們開始大量的使用緩存技術來緩解數據庫的壓力，優化數據庫的結構和索引。開始比較流行的是通過文件緩存來緩解數據庫壓力，但是當訪問量繼續增大的時候，多臺web機器通過文件緩存不能共享，大量的小文件緩存也帶了了比較高的IO壓力。在這個時候，Memcached就自然的成為一個非常時尚的技術產品。

Memcached作為一個獨立的分布式的緩存服務器，為多個web服務器提供了一個共享的高性能緩存服務，在Memcached服務器上，又發展了根據hash算法來進行多臺Memcached緩存服務的擴展，然后又出現了一致性hash來解決增加或減少緩存服務器導致重新hash帶來的大量緩存失效的弊端

三、MySql主從復制讀寫分離

由于數據庫的寫入壓力增加，Memcached只能緩解數據庫的讀取壓力。讀寫集中在一個數據庫上讓數據庫不堪重負，大部分網站開始使用主從復制技術來達到讀寫分離，以提高讀寫性能和讀庫的可擴展性。Mysql的master-slave模式成為這個時候的網站標配了。

四、分庫分表+水平拆分+Mysql集群

在Memcached的高速緩存，MySQL的主從復制，讀寫分離的基礎之上，這時MySQL主庫的寫壓力開始出現瓶頸，而數據量的持續猛增，由于MyISAM使用表鎖，在高并發下會出現嚴重的鎖問題，大量的高并發MySQL應用開始使用InnoDB引擎代替MyISAM。

同時，開始流行使用分表分庫來緩解寫壓力和數據增長的擴展問題。這個時候，分表分庫成了一個熱門技術，是面試的熱門問題也是業界討論的熱門技術問題。也就在這個時候，MySQL推出了還不太穩定的表分區，這也給技術實力一般的公司帶來了希望。雖然MySQL推出了MySQL Cluster集群，但性能也不能很好滿足互聯網的要求，只是在高可靠性上提供了非常大的保證。

五、Mysql的擴展性瓶頸

MySQL數據庫也經常存儲一些大文本字段，導致數據庫表非常的大，在做數據庫恢復的時候就導致非常的慢，不容易快速恢復數據庫。比如1000萬4KB大小的文本就接近40GB的大小，如果能把這些數據從MySQL省去，MySQL將變得非常的小。關系數據庫很強大，但是它并不能很好的應付所有的應用場景。MySQL的擴展性差（需要復雜的技術來實現），大數據下IO壓力大，表結構更改困難，正是當前使用MySQL的開發人員面臨的問題。

六、為什么用Nosql

今天我們可以通過第三方平臺（如：Google,Facebook等）可以很容易的訪問和抓取數據。用戶的個人信息，社交網絡，地理位置，用戶生成的數據和用戶操作日志已經成倍的增加。我們如果要對這些用戶數據進行挖掘，那SQL數據庫已經不適合這些應用了, NoSQL數據庫的發展也卻能很好的處理這些大的數據。下面給大家看一下，web應用數據量的增長圖：

七、Nosql是什么

NoSQL(NoSQL = Not Only SQL )，意即“不僅僅是SQL”，

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

（例如谷歌或Facebook每天為他們的用戶收集萬億比特的數據）。這些類型的數據存儲不需要固定的模式，無需多余操作就可以橫向擴展。

八、Nosql的優勢

1.易擴展

NoSQL數據庫種類繁多，但是一個共同的特點都是去掉關系數據庫的關系型特性。

數據之間無關系，這樣就非常容易擴展。也無形之間，在架構的層面上帶來了可擴展的能力。

2.大數據量，高性能

NoSQL數據庫都具有非常高的讀寫性能，尤其在大數據量下，同樣表現優秀。

這得益于它的無關系性，數據庫的結構簡單。一般MySQL使用Query Cache，每次表的更新Cache就失效，是一種大粒度的Cache，在針對web2.0的交互頻繁的應用，Cache性能不高。而NoSQL的Cache是記錄級的，是一種細粒度的Cache，所以NoSQL在這個層面上來說就要性能高很多了。

3.多樣靈活的數據模型

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

九、Nosql數據庫的四大分類

鍵值(Key-Value)存儲

列存儲

文檔存儲

圖形存儲

常見的有：Redis、Memcache、MongoDB，這里就不一 一 介紹了。

elasticsearch可以代替NoSQL嗎

ES完全勝任MongoDB能干的事情，而且還加上了檢索功能，你可以選擇分詞檢索或者把你存的整個文檔當作一個詞，前者類似于搜索引擎，后者類似于數據庫，而且ES最擅長的就是用Facet和Agg做數據統計，當不分詞時，可以結合Redis等把詞條映射為整形數，查詢效率會非常高。而且數據分區更靈活，可以隨時以編碼的方式打開或關閉某部分數據節點。一般來說，把ES以數據庫的模式存儲，合理使用查詢語法，都可以秒級返回，不管多大的數據量，當然做統計肯定會慢一些。對有些特殊查詢注意一下就行了：比如用wildcard的 *keyword 模式就比 keyword*模式要慢很多，需要合理規劃自己的業務場景和數據的mapping映射方式。

NoSQL-HDFS-基本概念

Hadoop

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

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

文件存儲在哪里？硬盤

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

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

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

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

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

潛在問題

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

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

這是一張HDFS的架構簡圖：

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

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

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

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

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

讀取文件的流程：

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

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

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

文件寫入的流程：

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

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

3、client找到DataNode1、DataNode2、DataNode3、DataNode4，把數據寫到他們上面

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

潛在問題

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

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

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

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

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

兩個NameNode通過JournalNode實現同步editlog，保持狀態一致可以相互替換。

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

進行數據同步操作的過程如下：

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

優點：

缺點：

讀取時是直接I/O操作好，還是使用K-V式NoSQL

“直接生成html格式，客戶端只要直接請求就好”，不過這要看你的應用能不能做到了。高并發就很有可能數據量也很大，你file cache到單機？感覺還是nosql好點

當前名稱：單機nosql,單機nosql引擎
本文網址：http://m.kartarina.com/article12/dsespgc.html

成都網站建設公司_創新互聯，為您提供微信小程序、品牌網站制作、標簽優化、外貿建站、App開發、網站收錄

廣告

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