13518219792
No SQL DB是一種和關系型數據庫相對應的對象數據庫。按照數據模型保存性質將當前NoSQL分為四種：
讓客戶滿意是我們工作的目標，不斷超越客戶的期望值來自于我們對這個行業的熱愛。我們立志把好的技術通過有效、簡單的方式提供給客戶，將通過不懈努力成為客戶在信息化領域值得信任、有價值的長期合作伙伴，公司提供的服務項目有：域名注冊、虛擬空間、營銷軟件、網站建設、莆田網站維護、網站推廣。
1.Key-value stores鍵值存儲, 保存keys+BLOBs
2.Table-oriented 面向表, 主要有Google的BigTable和Cassandra.
3.Document-oriented面向文本, 文本是一種類似XML文檔，MongoDB 和 CouchDB
4.Graph-oriented 面向圖論. 如Neo4J.
關系型數據庫的弊端：
關系型數據庫的歷史已經有30余年了，因此，在某些情況下，關系型數據庫的弱點就會暴露出來：
1. “對象-關系 阻抗不匹配”。關系模型和面向對象模型在概念上存在天然的不匹配的地方，比如對象模型當中特有的“繼承”，“組合”，“聚合”，“依賴”的概念在關系模型當中是不存在的。
2. “模式演進”。即隨著時間的推移，需要對數據庫模式進行調整以便適應新的需求，然而，對數據庫模式的調整是的成本很高的動作，因此很多設計師在系統設計之初會設計一個兼容性很強的數據庫模式，以應對將來可能出現的需求，然而在現在的web系統開發過程中，系統的變更更加頻繁，幾乎無法預先設計出一種“萬能”的數據庫模式以滿足所有的需求，因此 模式演進的弊端就愈發凸顯。
3. 關系型數據庫處理 稀疏表時的性能非常差。
4. network-oriented data 很適合處理 人工智能、社交網絡中的一些需求。
所以，各種各樣的No SQL DB 出現了，這里只簡單介紹下Neo4J 的基本知識。
Neo 數據模型
Neo4J 是一個基于圖實現的No SQL DB, 其基本的數據類型有如下幾種：
Node, Relationship, Property.
Node 對應于圖中的 節點，Relationship 對應圖中的邊，Node 和 Relationship 都可以擁有Property，
Property 的數據結構為。
數據遍歷
Neo 提供了Traverser對數據中的數據進行遍歷。
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的功能。
優點：
缺點：
而傳統的關系數據庫在應付web2.0網站，特別是超大規模和高并發的SNS類型的web2.0純動態網站已經顯得力不從心，暴露了很多難以克服的問題，例如：
1、High performance - 對數據庫高并發讀寫的需求
web2.0網站要根據用戶個性化信息來實時生成動態頁面和提供動態信息，所以基本上無法使用動態頁面靜態化技術，因此數據庫并發負載非常高，往往要達到每秒上萬次讀寫請求。關系數據庫應付上萬次SQL查詢還勉強頂得住，但是應付上萬次SQL寫數據請求，硬盤IO就已經無法承受了。其實對于普通的BBS網站，往往也存在對高并發寫請求的需求。
2、Huge Storage - 對海量數據的高效率存儲和訪問的需求
對于大型的SNS網站，每天用戶產生海量的用戶動態，以國外的Friendfeed為例，一個月就達到了2.5億條用戶動態，對于關系數據庫來說，在一張2.5億條記錄的表里面進行SQL查詢，效率是極其低下乃至不可忍受的。再例如大型web網站的用戶登錄系統，例如騰訊，盛大，動輒數以億計的帳號，關系數據庫也很難應付。
3、High Scalability High Availability- 對數據庫的高可擴展性和高可用性的需求
在基于web的架構當中，數據庫是最難進行橫向擴展的，當一個應用系統的用戶量和訪問量與日俱增的時候，你的數據庫卻沒有辦法像web server和app server那樣簡單的通過添加更多的硬件和服務節點來擴展性能和負載能力。對于很多需要提供24小時不間斷服務的網站來說，對數據庫系統進行升級和擴展是非常痛苦的事情，往往需要停機維護和數據遷移，為什么數據庫不能通過不斷的添加服務器節點來實現擴展呢？
在上面提到的“三高”需求面前，關系數據庫遇到了難以克服的障礙，而對于web2.0網站來說，關系數據庫的很多主要特性卻往往無用武之地，例如：
1、數據庫事務一致性需求
很多web實時系統并不要求嚴格的數據庫事務，對讀一致性的要求很低，有些場合對寫一致性要求也不高。因此數據庫事務管理成了數據庫高負載下一個沉重的負擔。
2、數據庫的寫實時性和讀實時性需求
對關系數據庫來說，插入一條數據之后立刻查詢，是肯定可以讀出來這條數據的，但是對于很多web應用來說，并不要求這么高的實時性。
3、對復雜的SQL查詢，特別是多表關聯查詢的需求
任何大數據量的web系統，都非常忌諱多個大表的關聯查詢，以及復雜的數據分析類型的復雜SQL報表查詢，特別是SNS類型的網站，從需求以及產品設計角度，就避免了這種情況的產生。往往更多的只是單表的主鍵查詢，以及單表的簡單條件分頁查詢，SQL的功能被極大的弱化了。
因此，關系數據庫在這些越來越多的應用場景下顯得不那么合適了，為了解決這類問題的非關系數據庫應運而生。
NoSQL 是非關系型數據存儲的廣義定義。它打破了長久以來關系型數據庫與ACID理論大一統的局面。NoSQL 數據存儲不需要固定的表結構，通常也不存在連接操作。在大數據存取上具備關系型數據庫無法比擬的性能優勢。該術語在 2009 年初得到了廣泛認同。
當今的應用體系結構需要數據存儲在橫向伸縮性上能夠滿足需求。而 NoSQL 存儲就是為了實現這個需求。Google 的BigTable與Amazon的Dynamo是非常成功的商業 NoSQL 實現。一些開源的 NoSQL 體系，如Facebook 的Cassandra， Apache 的HBase，也得到了廣泛認同。
1、打開計算機桌面，單擊[開始]，[程序]，[Microsoft SQL Server]，[企業管理器]，然后打開企業管理器軟件。
2、單擊工具欄中的[運行向導]。
3、選擇[創建視圖向導]的功能選項。
4、輸入視圖以創建歡迎向導。
5、單擊“下一步”并選擇數據庫。在這里選擇pubs。
6、選擇數據庫對象，這里我們選擇jobs。
7、這里我們選擇三個領域的選項。
8、為視圖命名，即為視圖指定名稱，然后單擊“下一步”。
9、完成視圖創建，視圖名稱為jobs_VIEW。創建語句如下圖。
10、單擊“完成”以完成提示視圖創建。
11、打開PUBS數據庫，打開視圖，可以看到我們創建的視圖顯示。
NoSQL，泛指非關系型的數據庫。隨著互聯網web2.0網站的興起，傳統的關系數據庫在應付web2.0網站，特別是超大規模和高并發的SNS類型的web2.0純動態網站已經顯得力不從心，暴露了很多難以克服的問題，而非關系型的數據庫則由于其本身的特點得到了非常迅速的發展。NoSQL數據庫的產生就是為了解決大規模數據集合多重數據種類帶來的挑戰，尤其是大數據應用難題。
雖然NoSQL流行語火起來才短短一年的時間，但是不可否認，現在已經開始了第二代運動。盡管早期的堆棧代碼只能算是一種實驗，然而現在的系統已經更加的成熟、穩定。不過現在也面臨著一個嚴酷的事實：技術越來越成熟——以至于原來很好的NoSQL數據存儲不得不進行重寫，也有少數人認為這就是所謂的2.0版本。這里列出一些比較知名的工具，可以為大數據建立快速、可擴展的存儲庫。
NoSQL(NoSQL = Not Only SQL )，意即“不僅僅是SQL”，是一項全新的數據庫革命性運動，早期就有人提出，發展至2009年趨勢越發高漲。NoSQL的擁護者們提倡運用非關系型的數據存儲，相對于鋪天蓋地的關系型數據庫運用，這一概念無疑是一種全新的思維的注入。
對于NoSQL并沒有一個明確的范圍和定義，但是他們都普遍存在下面一些共同特征：
不需要預定義模式：不需要事先定義數據模式，預定義表結構。數據中的每條記錄都可能有不同的屬性和格式。當插入數據時，并不需要預先定義它們的模式。
無共享架構：相對于將所有數據存儲的存儲區域網絡中的全共享架構。NoSQL往往將數據劃分后存儲在各個本地服務器上。因為從本地磁盤讀取數據的性能往往好于通過網絡傳輸讀取數據的性能，從而提高了系統的性能。
彈性可擴展：可以在系統運行的時候，動態增加或者刪除結點。不需要停機維護，數據可以自動遷移。
分區：相對于將數據存放于同一個節點，NoSQL數據庫需要將數據進行分區，將記錄分散在多個節點上面。并且通常分區的同時還要做復制。這樣既提高了并行性能，又能保證沒有單點失效的問題。
異步復制：和RAID存儲系統不同的是，NoSQL中的復制，往往是基于日志的異步復制。這樣，數據就可以盡快地寫入一個節點，而不會被網絡傳輸引起遲延。缺點是并不總是能保證一致性，這樣的方式在出現故障的時候，可能會丟失少量的數據。
BASE：相對于事務嚴格的ACID特性，NoSQL數據庫保證的是BASE特性。BASE是最終一致性和軟事務。
NoSQL數據庫并沒有一個統一的架構，兩種NoSQL數據庫之間的不同，甚至遠遠超過兩種關系型數據庫的不同。可以說，NoSQL各有所長，成功的NoSQL必然特別適用于某些場合或者某些應用，在這些場合中會遠遠勝過關系型數據庫和其他的NoSQL。
在SequoiaDB巨杉數據庫聯合創始人兼CTO王濤看來，目前只有少量的NoSQL數據庫支持事務機制，如VoltDB、RavenDB、SequoiaDB、MarkLogic。并且，“NoSQL支持事務（ACID）是未來的趨勢，不支持事務的NoSQL會大大縮小其應用場景。”對于ACID來說，是指數據庫事務機制正確執行的四大基本要素，包含了：原子性（Atomicity）、一致性（Consistency）、隔離性（Isolation）、持久性（Durability）。
