大數據技術原理與應用第五章NoSQL數據庫

第5章NoSQL數據庫提綱5.1NoSQL簡介5.2NoSQL興起的原因5.3NoSQL與關系數據庫的比較5.4NoSQL的四大類型5.5NoSQL的三大基石5.6從NoSQL到NewSQL數據庫5.7文檔數據庫MongoDB本章小結5.1NoSQL簡介通常，NoSQL數據庫具有以下幾個特點：（1）靈活的可擴展性（2）靈活的數據模型（3）與云計算緊密融合5.1NoSQL簡介現在已經有很多公司使用了NoSQL數據庫：GoogleFacebookMozillaAdobeFoursquareLinkedInDiggMcGraw-HillEducationVermontPublicRadio百度、騰訊、阿里、新浪、華為……5.2NoSQL興起的原因1、關系數據庫已經無法滿足Web2.0的需求。主要表現在以下幾個方面：（1）無法滿足海量數據的管理需求（2）無法滿足數據高并發的需求（3）無法滿足高可擴展性和高可用性的需求5.2NoSQL興起的原因復雜性：部署、管理、配置很復雜數據庫復制：MySQL主備之間采用復制方式，只能是異步復制，當主庫壓力較大時可能產生較大延遲，主備切換可能會丟失最后一部分更新事務，這時往往需要人工介入，備份和恢復不方便擴容問題：如果系統壓力過大需要增加新的機器，這個過程涉及數據重新劃分，整個過程比較復雜，且容易出錯動態數據遷移問題：如果某個數據庫組壓力過大，需要將其中部分數據遷移出去，遷移過程需要總控節點整體協調，以及數據庫節點的配合。這個過程很難做到自動化MySQL集群是否可以完全解決問題？5.2NoSQL興起的原因MySQL集群是否可以完全解決問題？5.2NoSQL興起的原因2、“Onesizefitsall”模式很難適用于截然不同的業務場景關系模型作為統一的數據模型既被用于數據分析，也被用于在線業務。但這兩者一個強調高吞吐，一個強調低延時，已經演化出完全不同的架構。用同一套模型來抽象顯然是不合適的Hadoop就是針對數據分析MongoDB、Redis等是針對在線業務，兩者都拋棄了關系模型5.2NoSQL興起的原因3、關系數據庫的關鍵特性包括完善的事務機制和高效的查詢機制。但是，關系數據庫引以為傲的兩個關鍵特性，到了Web2.0時代卻成了雞肋，主要表現在以下幾個方面：（1）Web2.0網站系統通常不要求嚴格的數據庫事務（2）Web2.0并不要求嚴格的讀寫實時性（3）Web2.0通常不包含大量復雜的SQL查詢（去結構化，存儲空間換取更好的查詢性能）5.3NoSQL與關系數據庫的比較比較標準RDBMSNoSQL備注數據庫原理完全支持部分支持RDBMS有關系代數理論作為基礎NoSQL沒有統一的理論基礎數據規模大超大RDBMS很難實現橫向擴展，縱向擴展的空間也比較有限，性能會隨著數據規模的增大而降低NoSQL可以很容易通過添加更多設備來支持更大規模的數據數據庫模式固定靈活RDBMS需要定義數據庫模式，嚴格遵守數據定義和相關約束條件NoSQL不存在數據庫模式，可以自由靈活定義并存儲各種不同類型的數據查詢效率快可以實現高效的簡單查詢，但是不具備高度結構化查詢等特性，復雜查詢的性能不盡人意RDBMS借助于索引機制可以實現快速查詢（包括記錄查詢和范圍查詢）很多NoSQL數據庫沒有面向復雜查詢的索引，雖然NoSQL可以使用MapReduce來加速查詢，但是，在復雜查詢方面的性能仍然不如RDBMS5.3NoSQL與關系數據庫的比較比較標準RDBMSNoSQL備注一致性強一致性弱一致性RDBMS嚴格遵守事務ACID模型，可以保證事務強一致性很多NoSQL數據庫放松了對事務ACID四性的要求，而是遵守BASE模型，只能保證最終一致性數據完整性容易實現很難實現任何一個RDBMS都可以很容易實現數據完整性，比如通過主鍵或者非空約束來實現實體完整性，通過主鍵、外鍵來實現參照完整性，通過約束或者觸發器來實現用戶自定義完整性但是，在NoSQL數據庫卻無法實現擴展性一般好RDBMS很難實現橫向擴展，縱向擴展的空間也比較有限NoSQL在設計之初就充分考慮了橫向擴展的需求，可以很容易通過添加廉價設備實現擴展可用性好很好RDBMS在任何時候都以保證數據一致性為優先目標，其次才是優化系統性能，隨著數據規模的增大，RDBMS為了保證嚴格的一致性，只能提供相對較弱的可用性大多數NoSQL都能提供較高的可用性5.3NoSQL與關系數據庫的比較比較標準RDBMSNoSQL備注標準化是否RDBMS已經標準化（SQL）NoSQL還沒有行業標準，不同的NoSQL數據庫都有自己的查詢語言，很難規范應用程序接口StoneBraker認為：NoSQL缺乏統一查詢語言，將會拖慢NoSQL發展技術支持高低RDBMS經過幾十年的發展，已經非常成熟，Oracle等大型廠商都可以提供很好的技術支持NoSQL在技術支持方面仍然處于起步階段，還不成熟，缺乏有力的技術支持可維護性復雜復雜RDBMS需要專門的數據庫管理員(DBA)維護NoSQL數據庫雖然沒有DBMS復雜，也難以維護5.3NoSQL與關系數據庫的比較總結（1）關系數據庫優勢：以完善的關系代數理論作為基礎，有嚴格的標準，支持事務ACID四性，借助索引機制可以實現高效的查詢，技術成熟，有專業公司的技術支持劣勢：可擴展性較差，無法較好支持海量數據存儲，數據模型過于死板、無法較好支持Web2.0應用，事務機制影響了系統的整體性能等5.3NoSQL與關系數據庫的比較總結（2）NoSQL數據庫優勢：可以支持超大規模數據存儲，靈活的數據模型可以很好地支持Web2.0應用，具有強大的橫向擴展能力等劣勢：缺乏數學理論基礎，復雜查詢性能不高，大都不能實現事務強一致性，很難實現數據完整性，技術尚不成熟，缺乏專業團隊的技術支持，維護較困難等5.3NoSQL與關系數據庫的比較總結關系數據庫和NoSQL數據庫各有優缺點，彼此無法取代關系數據庫應用場景：電信、銀行等領域的關鍵業務系統，需要保證強事務一致性NoSQL數據庫應用場景：互聯網企業、傳統企業的非關鍵業務（比如數據分析）5.3NoSQL與關系數據庫的比較總結采用混合架構案例：亞馬遜公司就使用不同類型的數據庫來支撐它的電子商務應用對于“購物籃”這種臨時性數據，采用鍵值存儲會更加高效當前的產品和訂單信息則適合存放在關系數據庫中大量的歷史訂單信息則適合保存在類似MongoDB的文檔數據庫中5.4NoSQL的四大類型NoSQL數據庫雖然數量眾多，但是，歸結起來，典型的NoSQL數據庫通常包括鍵值數據庫、列族數據庫、文檔數據庫和圖形數據庫5.4NoSQL的四大類型5.4NoSQL的四大類型5.4NoSQL的四大類型文檔數據庫圖數據庫鍵值數據庫列族數據庫5.4.1鍵值數據庫相關產品Redis、Riak、SimpleDB、Chordless、Scalaris、Memcached數據模型鍵/值對鍵是一個字符串對象值可以是任意類型的數據，比如整型、字符型、數組、列表、集合等典型應用涉及頻繁讀寫、擁有簡單數據模型的應用內容緩存，比如會話、配置文件、參數、購物車等存儲配置和用戶數據信息的移動應用優點擴展性好，靈活性好，大量寫操作時性能高缺點無法存儲結構化信息，條件查詢效率較低不適用情形不是通過鍵而是通過值來查：鍵值數據庫根本沒有通過值查詢的途徑需要存儲數據之間的關系：在鍵值數據庫中，不能通過兩個或兩個以上的鍵來關聯數據需要事務的支持：在一些鍵值數據庫中，產生故障時，不可以回滾使用者百度云數據庫（Redis）、GitHub（Riak）、BestBuy（Riak）、Twitter（Redis和Memcached）、StackOverFlow（Redis）、Instagram（Redis）、Youtube（Memcached）、Wikipedia（Memcached）5.4.1鍵值數據庫鍵值數據庫成為理想的緩沖層解決方案Redis有時候會被人們稱為“強化版的Memcached”支持持久化、數據恢復、更多數據類型5.4.2列族數據庫相關產品BigTable、HBase、Cassandra、HadoopDB、GreenPlum、PNUTS數據模型列族典型應用分布式數據存儲與管理數據在地理上分布于多個數據中心的應用程序可以容忍副本中存在短期不一致情況的應用程序擁有動態字段的應用程序擁有潛在大量數據的應用程序，大到幾百TB的數據優點查找速度快，可擴展性強，容易進行分布式擴展，復雜性低缺點功能較少，大都不支持強事務一致性不適用情形需要ACID事務支持的情形，Cassandra等產品就不適用使用者Ebay（Cassandra）、Instagram（Cassandra）、NASA（Cassandra）、Twitter（CassandraandHBase）、Facebook（HBase）、Yahoo!（HBase）5.4.3文檔數據庫“文檔”其實是一個數據記錄，這個記錄能夠對包含的數據類型和內容進行“自我描述”。XML文檔、HTML文檔和JSON文檔就屬于這一類。SequoiaDB就是使用JSON格式的文檔數據庫，它的存儲的數據是這樣的：關系數據庫：必須有schema信息才能理解數據的含義學生（學號，姓名，性別，年齡，系，年級）（1001，張三，男，20，計算機，2002）一個XML文檔：<configuration>

<property>

<name>hbase.rootdir</name>

<value>hdfs://localhost:9000/hbase</value>

</property></configuration>

5.4.3文檔數據庫數據是不規則的，每一條記錄包含了所有的有關“SequoiaDB”的信息而沒有任何外部的引用，這條記錄就是“自包含”的這使得記錄很容易完全移動到其他服務器，因為這條記錄的所有信息都包含在里面了，不需要考慮還有信息在別的表沒有一起遷移走同時，因為在移動過程中，只有被移動的那一條記錄（文檔）需要操作，而不像關系型中每個有關聯的表都需要鎖住來保證一致性，這樣一來ACID的保證就會變得更快速，讀寫的速度也會有很大的提升5.4.3文檔數據庫相關產品MongoDB、CouchDB、Terrastore、ThruDB、RavenDB、SisoDB、RaptorDB、CloudKit、Perservere、Jackrabbit數據模型鍵/值值（value）是版本化的文檔典型應用存儲、索引并管理面向文檔的數據或者類似的半結構化數據比如，用于后臺具有大量讀寫操作的網站、使用JSON數據結構的應用、使用嵌套結構等非規范化數據的應用程序優點性能好（高并發），靈活性高，復雜性低，數據結構靈活提供嵌入式文檔功能，將經常查詢的數據存儲在同一個文檔中既可以根據鍵來構建索引，也可以根據內容構建索引缺點缺乏統一的查詢語法不適用情形在不同的文檔上添加事務。文檔數據庫并不支持文檔間的事務，如果對這方面有需求則不應該選用這個解決方案使用者百度云數據庫（MongoDB）、SAP（MongoDB）、Codecademy（MongoDB）、Foursquare（MongoDB）、NBCNews（RavenDB）5.4.4圖形數據庫相關產品Neo4J、OrientDB、InfoGrid、InfiniteGraph、GraphDB數據模型圖結構典型應用專門用于處理具有高度相互關聯關系的數據，比較適合于社交網絡、模式識別、依賴分析、推薦系統以及路徑尋找等問題優點靈活性高，支持復雜的圖形算法，可用于構建復雜的關系圖譜缺點復雜性高，只能支持一定的數據規模使用者Adobe（Neo4J）、Cisco（Neo4J）、T-Mobile（Neo4J）5.4.5不同類型數據庫比較分析MySQL產生年代較早，而且隨著LAMP大潮得以成熟。盡管其沒有什么大的改進，但是新興的互聯網使用的最多的數據庫MongoDB是個新生事物，提供更靈活的數據模型、異步提交、地理位置索引等五花十色的功能HBase是個“仗勢欺人”的大象兵。依仗著Hadoop的生態環境，可以有很好的擴展性。但是就像象兵一樣，使用者需要養一頭大象(Hadoop),才能驅使他Redis是鍵值存儲的代表，功能最簡單。提供隨機數據存儲。就像一根棒子一樣，沒有多余的構造。但是也正是因此，它的伸縮性特別好。就像悟空手里的金箍棒，大可捅破天，小能成縮成針5.5NoSQL的三大基石5.5.1CAP所謂的CAP指的是：C（Consistency）：一致性，是指任何一個讀操作總是能夠讀到之前完成的寫操作的結果，也就是在分布式環境中，多點的數據是一致的，或者說，所有節點在同一時間具有相同的數據A:（Availability）：可用性，是指快速獲取數據，可以在確定的時間內返回操作結果，保證每個請求不管成功或者失敗都有響應；P（ToleranceofNetworkPartition）：分區容忍性，是指當出現網絡分區的情況時（即系統中的一部分節點無法和其他節點進行通信），分離的系統也能夠正常運行，也就是說，系統中任意信息的丟失或失敗不會影響系統的繼續運作。5.5.1CAPCAP理論告訴我們，一個分布式系統不可能同時滿足一致性、可用性和分區容忍性這三個需求，最多只能同時滿足其中兩個，正所謂“魚和熊掌不可兼得”。5.5.1CAP（a）初始狀態一個犧牲一致性來換取可用性的實例

5.5.1CAP（b）正常執行過程一個犧牲一致性來換取可用性的實例

5.5.1CAP(c)更新傳播失敗時的執行過程

一個犧牲一致性來換取可用性的實例

5.5.1CAP當處理CAP的問題時，可以有幾個明顯的選擇：CA：也就是強調一致性（C）和可用性（A），放棄分區容忍性（P），最簡單的做法是把所有與事務相關的內容都放到同一臺機器上。很顯然，這種做法會嚴重影響系統的可擴展性。傳統的關系數據庫（MySQL、SQLServer和PostgreSQL），都采用了這種設計原則，因此，擴展性都比較差CP：也就是強調一致性（C）和分區容忍性（P），放棄可用性（A），當出現網絡分區的情況時，受影響的服務需要等待數據一致，因此在等待期間就無法對外提供服務AP：也就是強調可用性（A）和分區容忍性（P），放棄一致性（C），允許系統返回不一致的數據5.5.1CAP圖5-5不同產品在CAP理論下的不同設計原則5.5.2BASEACIDBASE原子性(Atomicity)基本可用(Basically

Available)一致性(Consistency)軟狀態/柔性事務(Softstate)隔離性(Isolation)最終一致性(Eventualconsistency)持久性(Durable)

說起BASE（BasicallyAvailble,Soft-state,Eventualconsistency），不得不談到ACID。5.5.2BASE一個數據庫事務具有ACID四性：A（Atomicity）：原子性，是指事務必須是原子工作單元，對于其數據修改，要么全都執行，要么全都不執行C（Consistency）：一致性，是指事務在完成時，必須使所有的數據都保持一致狀態I（Isolation）：隔離性，是指由并發事務所做的修改必須與任何其它并發事務所做的修改隔離D（Durability）：持久性，是指事務完成之后，它對于系統的影響是永久性的，該修改即使出現致命的系統故障也將一直保持5.5.2BASEBASE的基本含義是基本可用（BasicallyAvailble）、軟狀態（Soft-state）和最終一致性（Eventualconsistency）：基本可用

基本可用，是指一個分布式系統的一部分發生問題變得不可用時，其他部分仍然可以正常使用，也就是允許分區失敗的情形出現軟狀態

“軟狀態（soft-state）”是與“硬狀態（hard-state）”相對應的一種提法。數據庫保存的數據是“硬狀態”時，可以保證數據一致性，即保證數據一直是正確的。“軟狀態”是指狀態可以有一段時間不同步，具有一定的滯后性5.5.2BASEBASE的基本含義是基本可用（BasicallyAvailble）、軟狀態（Soft-state）和最終一致性（Eventualconsistency）：最終一致性

一致性的類型包括強一致性和弱一致性，二者的主要區別在于高并發的數據訪問操作下，后續操作是否能夠獲取最新的數據。對于強一致性而言，當執行完一次更新操作后，后續的其他讀操作就可以保證讀到更新后的最新數據；反之，如果不能保證后續訪問讀到的都是更新后的最新數據，那么就是弱一致性。而最終一致性只不過是弱一致性的一種特例，允許后續的訪問操作可以暫時讀不到更新后的數據，但是經過一段時間之后，必須最終讀到更新后的數據。最常見的實現最終一致性的系統是DNS（域名系統）。一個域名更新操作根據配置的形式被分發出去，并結合有過期機制的緩存；最終所有的客戶端可以看到最新的值。5.5.3最終一致性

最終一致性根據更新數據后各進程訪問到數據的時間和方式的不同，又可以區分為：因果一致性：如果進程A通知進程B它已更新了一個數據項，那么進程B的后續訪問將獲得A寫入的最新值。而與進程A無因果關系的進程C的訪問，仍然遵守一般的最終一致性規則“讀己之所寫”一致性：可以視為因果一致性的一個特例。當進程A自己執行一個更新操作之后，它自己總是可以訪問到更新過的值，絕不會看到舊值單調讀一致性：如果進程已經看到過數據對象的某個值，那么任何后續訪問都不會返回在那個值之前的值5.5.3最終一致性

最終一致性根據更新數據后各進程訪問到數據的時間和方式的不同，又可以區分為：會話一致性：它把訪問存儲系統的進程放到會話（session）的上下文中，只要會話還存在，系統就保證“讀己之所寫”一致性。如果由于某些失敗情形令會話終止，就要建立新的會話，而且系統保證不會延續到新的會話單調寫一致性：系統保證來自同一個進程的寫操作順序執行。系統必須保證這種程度的一致性，否則就非常難以編程了5.5.3最終一致性如何實現各種類型的一致性？對于分布式數據系統：N—數據復制的份數W—更新數據是需要保證寫完成的節點數R—讀取數據的時候需要讀取的節點數如果W+R>N，寫的節點和讀的節點重疊，則是強一致性。例如對于典型的一主一備同步復制的關系型數據庫，N=2,W=2,R=1，則不管讀的是主庫還是備庫的數據，都是一致的。一般設定是R＋W=N+1，這是保證強一致性的最小設定如果W+R<=N，則是弱一致性。例如對于一主一備異步復制的關系型數據庫，N=2,W=1,R=1，則如果讀的是備庫，就可能無法讀取主庫已經更新過的數據，所以是弱一致性。5.5.3最終一致性對于分布式系統，為了保證高可用性，一般設置N>=3。不同的N,W,R組合，是在可用性和一致性之間取一個平衡，以適應不同的應用場景。如果N=W,R=1，任何一個寫節點失效，都會導致寫失敗，因此可用性會降低，但是由于數據分布的N個節點是同步寫入的，因此可以保證強一致性。實例：HBase是借助其底層的HDFS來實現其數據冗余備份的。HDFS采用的就是強一致性保證。在數據沒有完全同步到N個節點前，寫操作是不會返回成功的。也就是說它的W＝N，而讀操作只需要讀到一個值即可，也就是說它R＝1。像Voldemort，Cassandra和Riak這些類Dynamo的系統，通常都允許用戶按需要設置N，R，W三個值，即使是設置成W＋R<=N也是可以的。也就是說他允許用戶在強一致性和最終一致性之間自由選擇。而在用戶選擇了最終一致性，或者是W<N的強一致性時，則總會出現一段“各個節點數據不同步導致系統處理不一致的時間”。為了提供最終一致性的支持，這些系統會提供一些工具來使數據更新被最終同步到所有相關節點。5.6從NoSQL到NewSQL數據庫圖5-6大數據引發數據處理架構變革5.6從NoSQL到NewSQL數據庫圖5-7關系數據庫、NoSQL和NewSQL數據庫產品分類圖5.7文檔數據庫MongoDB5.7.1MongoDB簡介5.7.2MongoDB概念解析5.7.3安裝MongoDB5.7.1MongoDB簡介MongoDB是由C++語言編寫的，是一個基于分布式文件存儲的開源數據庫系統。在高負載的情況下，添加更多的節點，可以保證服務器性能。MongoDB旨在為WEB應用提供可擴展的高性能數據存儲解決方案。MongoDB將數據存儲為一個文檔，數據結構由鍵值(key=>value)對組成。MongoDB文檔類似于JSON對象。字段值可以包含其他文檔，數組及文檔數組。5.7.1MongoDB簡介5.7.1MongoDB簡介提供了一個面向文檔存儲，操作起來比較簡單和容易可以設置任何屬性的索引來實現更快的排序具有較好的水平可擴展性支持豐富的查詢表達式，可輕易查詢文檔中內嵌的對象及數組可以實現替換完成的文檔（數據）或者一些指定的數據字段MongoDB中的Map/Reduce主要是用來對數據進行批量處理和聚合操作支持各種編程語言:RUBY，PYTHON，JAVA，C++，PHP，C#等語言MongoDB安裝簡單主要特點5.7.2MongoDB概念解析SQL術語/概念MongoDB術語/概念解釋/說明databasedatabase數據庫tablecollection數據庫表/集合rowdocument數據記錄行/文檔columnfield數據字段/域indexindex索引tablejoins

表連接,MongoDB不支持primarykeyprimarykey主鍵,MongoDB自動將_id字段設置為主鍵在mongodb中基本的概念是文檔、集合、數據庫5.7.2MongoDB概念解析通過下圖實例，我們也可以更直觀的的了解MongoDB中的一些概念：iduser_nameemailagecity1MarkHanksmark@25LosAngeles2RichardPeterrichard@31Dallas{"_id":ObjectId("5146bb52d8524270060001f3"),"age":25,"city":"LosAngeles","email":"mark@","user_name":"MarkHanks"}{ "_id":ObjectId("5146bb52d8524270060001f2"), "age":31, "city":"Dallas", "email":"richard@", "user_name":"RichardPeter"}5.7.2MongoDB概念解析舉例2：在一個關系型數據庫中，一篇博客（包含文章內容、評論、評論的投票）會被打散在多張數據表中。在文檔數據庫MongoDB中，能用一個文檔來表示一篇博客，評論與投票作為文檔數組，放在正文主文檔中。這樣數據更易于管理，消除了傳統關系型數據庫中影響性能和水平擴展性的“JOIN”操作。author:blogposts:comments:5.7.2MongoDB概念解析{“id”:1,“author”:”Jane”,“blogposts”:{“tile”:”MyFirstPost”,“comment”:{“by”:”Ada”,”text”:”Goodpost”}}}關系數據庫中的其中一條記錄，在文檔數據庫MongoDB中的存儲方式類似如下：5.7.2MongoDB概念解析數據庫一個mongodb中可以建立多個數據庫。MongoDB的默認數據庫為"db"，該數據庫存儲在data目錄中。MongoDB的單個實例可以容納多個獨立的數據庫，每一個都有自己的集合和權限，不同的數據庫也放置在不同的文件中。5.7.2MongoDB概念解析文檔文檔是一個鍵值(key-value)對(即BSON)。MongoDB的文檔不需要設置相同的字段，并且相同的字段不需要相同的數據類型，這與關系型數據庫有很大的區別，也是MongoDB非常突出的特點。一個簡單的文檔例子如下：{“site”:“”,“name”:“中北大學軟件學院實驗室"}

5.7.2MongoDB概念解析下表列出了RDBMS與MongoDB對應的術語：RDBMSMongoDB數據庫數據庫表格集合行文檔列字段表聯合嵌入文檔主鍵主鍵(MongoDB提供了key為_id)數據庫服務和客戶端Mysqld/Oraclemongodmysql/sqlplusmongo5.7.2MongoDB概念解析集合集合就是MongoDB文檔組，類似于RDBMS（關系數據庫管理系統：RelationalDatabaseManagementSystem)中的表格。集合存在于數據庫中，集合沒有固定的結構，這意味著你在對集合可以插入不同格式和類型的數據，但通常情況下我們插入集合的數據都會有一定的關聯性。比如，我們可以將以下不同數據結構的文檔插入到集合中：{"site":""}{“site”:“”,“name”:“中北大學軟件學院實驗室"}

{"site":"","name":"菜鳥教程","num":5}5.7.2MongoDB概念解析MongoDB數據類型數據類型描述String字符串。存儲數據常用的數據類型。在MongoDB中，UTF-8編碼的字符串才是合法的。Integer整型數值。用于存儲數值。根據你所采用的服務器，可分為32位或64位。Boolean布爾值。用于存儲布爾值（真/假）。Double雙精度浮點值。用于存儲浮點值。Min/Maxkeys將一個值與BSON（二進制的JSON）元素的最低值和最高值相對比。Arrays用于將數組或列表或多個值存儲為一個鍵。Timestamp時間戳。記錄文檔修改或添加的具體時間。Object用于內嵌文檔。Null用于創建空值。Symbol符號。該數據類型基本上等同于字符串類型，但不同的是，它一般用于采用特殊符號類型的語言。Date日期時間。用UNIX時間格式來存儲當前日期或時間。你可以指定自己的日期時間：創建Date對象，傳入年月日信息。ObjectID對象ID。用于創建文檔的ID。BinaryData二進制數據。用于存儲二進制數據。Code代碼類型。用于在文檔中存儲JavaScript代碼。Regularexpression正則表達式類型。用于存儲正則表達式。5.7.3安裝MongoDBWindow平臺安裝

MongoDBMongoDB提供了可用于32位和64位系統的預編譯二進制包，你可以從MongoDB官網下載安裝，MongoDB預編譯二進制包下載地址：/downloads注意：在MongoDB2.2版本后已經不再支持WindowsXP系統。5.7.3安裝MongoDBLinux平臺安裝MongoDBMongoDB提供了linux平臺上32位和64位的安裝包，你可以在官網下載安裝包。下載地址：/downloads啟動MongoDB服務只需要在MongoDB安裝目錄的bin目錄下執行'mongod'即可5.7.4訪問MongoDB

使用MongoDBshell訪問MongoDB

使用Java程序訪問MongoDB

使用MongoDBshell訪問MongoDBmongodb://localhost使用MongoDBshell來連接MongoDB服務器使用用戶名和密碼連接登陸到指定數據庫：mongodb://admin:123456@localhost/test

使用MongoDBshell訪問MongoDBMongoDB創建數據庫MongoDB創建數據庫的語法格式如下：useDATABASE_NAME如果數據庫不存在，則創建數據庫，否則切換到指定數據庫。如果你想查看所有數據庫，可以使用

showdbs

命令創建集合MongoDB沒有單獨創建集合名的shell命令，在插入數據的時候，MongoDB會自動創建對應的集合。

使用MongoDBshell訪問MongoDBMongoDB

插入文檔文檔的數據結構和JSON基本一樣。所有存儲在集合中的數據都是BSON格式。BSON是一種類JSON的一種二進制形式的存儲格式,簡稱BinaryJSON。MongoDB使用insert()或save()方法向集合中插入文檔，語法如下：db.COLLECTION_NAME.insert(document)

使用MongoDBshell訪問MongoDB實例>db.col.insert({title:

'MongoDB教程',

description:

'MongoDB是一個Nosql數據庫',

by:

‘廈門大學數據庫實驗室',

url:

'http://',

tags:

['mongodb',

'database',

'NoSQL'],

likes:

100

})

使用Java程序訪問MongoDBMongoDBJava環境配置在Java程序中如果要使用MongoDB，需要確保已經安裝了Java環境及MongoDBJDBC驅動。首先必須下載mongojar包，下載地址：/mongodb/mongo-java-driver/downloads,請確保下載最新版本。需要將mongo.jar包含在你的classpath中使用Java程序訪問MongoDB（1）連接數據庫importcom.mongodb.MongoClient;……//這里省略其他需要導入的包publicclassMongoDBJDBC{publicstaticvoidmain(Stringargs[]){try{ //連接到mongodb服務

MongoClientmongoClient=newMongoClient("localhost",27017);//連接到數據庫

DBdb=mongoClient.getDB("test"); System.out.println("Connecttodatabasesuccessfully");booleanauth=db.authenticate(myUserName,myPassword); System.out.println("Authentication:"+auth);}catch(Exceptione){ System.err.println(e.getClass().getName()+":"+e.getMessage()); }}}使用Java程序訪問MongoDB（2）創建集合publicclassMongoDBJDBC{publicstaticvoidmain(Stringargs[]){try{ //連接到mongodb服務

MongoClientmongoClient=newMongoClient("localhost",27017);//連接到數據庫

DBdb=mongoClient.getDB("test"); System.out.println("Connecttodatabasesuccessfully");booleanauth=db.authenticate(myUserName,myPassword); System.out.println("Authentication:"+auth);

DBCollectioncoll=db.createCollection("mycol"