NoSQL非關(guān)系型數(shù)據(jù)庫技術(shù)和應(yīng)用

1、CONTENTS目 錄 ONTENTS123目 錄ONTENTSCONTENTS123NoSQL數(shù)據(jù)庫是非關(guān)系型數(shù)據(jù)存儲的廣義定義，它不同于符合ACID理論的關(guān)系型數(shù)據(jù)庫，數(shù)據(jù)存儲不需要固定的表結(jié)構(gòu)，通常也不存在連接操作。NoSQL數(shù)據(jù)庫不使用傳統(tǒng)的關(guān)系數(shù)據(jù)庫模型，而是使用如鍵值存儲數(shù)據(jù)庫、列存儲數(shù)據(jù)庫、文檔型數(shù)據(jù)庫、圖形數(shù)據(jù)庫等方式存儲數(shù)據(jù)模型?；A(chǔ)理論與架構(gòu)分類1NoSQL共同特征：1）不需要預(yù)定義模式：不需要事先定義數(shù)據(jù)模式，預(yù)定義表結(jié)構(gòu)。數(shù)據(jù)中的每條記錄都可能有不同的屬性和格式，當(dāng)插入數(shù)據(jù)時，并不需要預(yù)先定義它們的模式；2）無共享架構(gòu)：相對于將所有數(shù)據(jù)存儲的存儲區(qū)域網(wǎng)絡(luò)中的全共享架構(gòu)，

2、NoSQL往往將數(shù)據(jù)劃分后存儲在各個本地服務(wù)器上。因?yàn)閺谋镜卮疟P讀取數(shù)據(jù)的性能往往好于通過網(wǎng)絡(luò)傳輸讀取數(shù)據(jù)的性能，從而提高了系統(tǒng)的性能；基礎(chǔ)理論與架構(gòu)分類13）彈性可擴(kuò)展：可以在系統(tǒng)運(yùn)行的時候，動態(tài)增加或者刪除結(jié)點(diǎn)。不需要停機(jī)維護(hù)，數(shù)據(jù)可以自動遷移；4）分區(qū)：相對于將數(shù)據(jù)存放于同一個節(jié)點(diǎn)，NoSQL數(shù)據(jù)庫需要將數(shù)據(jù)進(jìn)行分區(qū)，將記錄分散在多個節(jié)點(diǎn)上面。并且通常分區(qū)的同時還要做復(fù)制。這樣既提高了并行性能，又能保證沒有單點(diǎn)失效的問題；基礎(chǔ)理論與架構(gòu)分類15）異步復(fù)制：和RAID存儲系統(tǒng)不同的是，NoSQL中的復(fù)制，往往是基于日志的異步復(fù)制。這樣，數(shù)據(jù)就可以盡快地寫入一個節(jié)點(diǎn)，而不會被網(wǎng)絡(luò)傳輸引起遲延

3、。缺點(diǎn)是并不總是能保證一致性，這樣的方式在出現(xiàn)故障的時候，可能會丟失少量的數(shù)據(jù)；6）BASE：相對于事務(wù)嚴(yán)格的ACID特性，NoSQL數(shù)據(jù)庫保證的是BASE特性?；A(chǔ)理論與架構(gòu)分類1NoSQL適用情況：1）數(shù)據(jù)模型比較簡單；2）需要靈活性更強(qiáng)的IT系統(tǒng)；3）對數(shù)據(jù)庫性能要求較高；4）不需要高度的數(shù)據(jù)一致性?；A(chǔ)理論與架構(gòu)分類1CAP理論：CAP解釋為一致性（consistency）、可用性（availability）和分區(qū)容忍性（partition tolerance）。一致性：一個數(shù)據(jù)系統(tǒng)如何處理讀寫操作的一致性問題。分布式系統(tǒng)對于一致性的要求為當(dāng)更新寫入操作完成時，其余讀取操作需要及時看到

4、數(shù)據(jù)的更新；基礎(chǔ)理論與架構(gòu)分類1可用性：一個系統(tǒng)能夠持續(xù)不間斷使用的問題。嚴(yán)格定義上的高性能可用性意味著一個系統(tǒng)從設(shè)計(jì)到實(shí)施都應(yīng)該能夠提供可持續(xù)的操作；分區(qū)容忍性：一個系統(tǒng)在提供持續(xù)性操作時分區(qū)處理的能力。一旦開始將數(shù)據(jù)和邏輯分布在不同的節(jié)點(diǎn)上，就有形成分區(qū)的風(fēng)險。假定網(wǎng)線被切斷，就形成分區(qū)，在不同分區(qū)的節(jié)點(diǎn)A和節(jié)點(diǎn)B無法通信。由于Web提供的這種分布式能力，臨時的分區(qū)是一個常見的情況，處理這種情況就屬于分區(qū)容忍性。基礎(chǔ)理論與架構(gòu)分類1基礎(chǔ)理論與架構(gòu)分類1表1 CAP理論應(yīng)用及實(shí)例基礎(chǔ)理論與架構(gòu)分類1表2 CAP理論數(shù)據(jù)庫應(yīng)用實(shí)例及功能分類BASE理論：傳統(tǒng)ACID模式對于數(shù)據(jù)的屬性要求非常高

5、，在分布式系統(tǒng)中比較難以達(dá)到。所以在CAP理論的基礎(chǔ)上，提出了BASE思想，對一致性進(jìn)行概化處理。要解釋BASE思想，首先要對ACID有一個了解，因?yàn)锽ASE是相對于DBMS中的ACID所提出來的新思想?；A(chǔ)理論與架構(gòu)分類1ACID指的是傳統(tǒng)數(shù)據(jù)庫對于數(shù)據(jù)特性的要求。原子性：即事務(wù)執(zhí)行作為原子，不可再分離，整個語句要么執(zhí)行，要么不執(zhí)行，不可能停在中間某個環(huán)節(jié)；一致性：在事務(wù)開始之前和事務(wù)結(jié)束之后，數(shù)據(jù)庫的完整性約束沒有被破壞；隔離性：兩個事務(wù)的執(zhí)行互不干擾，也不會發(fā)生交互，一個事務(wù)不可能看到其他事務(wù)運(yùn)行時中某一時刻的數(shù)據(jù)；持久性：在事務(wù)完成以后，該事務(wù)對數(shù)據(jù)庫所做的更改便持久地保存在數(shù)據(jù)庫之中

6、，并不會被回滾?；A(chǔ)理論與架構(gòu)分類1在數(shù)據(jù)庫系統(tǒng)中，事務(wù)的ACID屬性保證了數(shù)據(jù)庫的一致性，如銀行系統(tǒng)中，付款就是一個事務(wù)，從原賬戶扣除金額以及向目標(biāo)賬戶添加金額，這兩個數(shù)據(jù)庫操作的總和構(gòu)成一個完整的邏輯過程，為原子操作不可拆分，從而保證了整個系統(tǒng)中的總金額沒有變化。但是ACID特性對于大型的分布式系統(tǒng)來說，與高性能是不兼容的。如在線購買商品的時候，任何一個人購物的過程都為一個原子操作，不允許存在兩個人同時進(jìn)行購物的情況。很明顯對于絕大多數(shù)在線商城，這個方法并不適用?；A(chǔ)理論與架構(gòu)分類1BASE思想實(shí)際上是CAP理論中AP的衍伸。它通過犧牲高一致性，保證高可用性和分區(qū)容忍性。BASE思想的組成

7、有以下3個部分：基本可用、軟狀態(tài)、最終一致性。BASE模式指的是一個應(yīng)用在任意時間首先應(yīng)該能完成最基本化的工作（即基本可用），并不需要總是一致（即軟狀態(tài)），但最終應(yīng)該是一致（即最終一致性）的。ACID和BASE應(yīng)該被看作同一范疇內(nèi)的互相補(bǔ)充品，而不是替代品?；A(chǔ)理論與架構(gòu)分類1基礎(chǔ)理論與架構(gòu)分類1表3 BASE與ACID的優(yōu)缺點(diǎn)對比NoSQL大致可以分為四類，分別為鍵值存儲數(shù)據(jù)庫、列存儲數(shù)據(jù)庫、文檔型數(shù)據(jù)庫和圖形數(shù)據(jù)庫。鍵值存儲數(shù)據(jù)庫鍵值存儲典型實(shí)現(xiàn)的數(shù)據(jù)結(jié)構(gòu)一般為數(shù)組鏈表：先通過通過hash算法得出hashcode，找到數(shù)組的某一個位置，然后插入鏈表的第一個位置?；A(chǔ)理論與架構(gòu)分類1Bigt

8、ableBigtable是一個稀疏、分布式、持久化存儲的多維有序映射表，表的索引是行關(guān)鍵字、列關(guān)鍵字和時間戳。Bigtable中存儲的表項(xiàng)都是未經(jīng)解析的字節(jié)數(shù)組，其數(shù)據(jù)模型如下： (row:string, column:string,time:int64)-string 基礎(chǔ)理論與架構(gòu)分類1示例：一個存儲了大量網(wǎng)頁及其相關(guān)信息的表Webtable，Webtable使用URL作為行關(guān)鍵字，使用網(wǎng)頁的某些屬性作為列名，網(wǎng)頁的內(nèi)容存入contents列中，并使用獲取該網(wǎng)頁的時間戳標(biāo)識同一個網(wǎng)頁的不同版本?；A(chǔ)理論與架構(gòu)分類11）行關(guān)鍵字 行關(guān)鍵字可以是任意字符串，目前最大支持64KB。Bigtabl

9、e按照行關(guān)鍵字的字典序組織數(shù)據(jù)，利用這個特性可以通過選擇合適的行關(guān)鍵字，使數(shù)據(jù)訪問具有良好的局部性。表的行區(qū)間可以動態(tài)劃分，每個行區(qū)間稱為一個子表。子表是數(shù)據(jù)分布和負(fù)載均衡的基本單位，不同的子表可以有不同的大小?；A(chǔ)理論與架構(gòu)分類12）列族 列關(guān)鍵字一般都表示一種數(shù)據(jù)類型，列關(guān)鍵字的集合稱作列族，列族是訪問控制的基本單位。存儲在同一列族下的數(shù)據(jù)屬于同一種類型，列族下的數(shù)據(jù)被壓縮在一起保存。數(shù)據(jù)在被存儲之前必須先創(chuàng)建列族，并且表中的列族不宜過多，通常幾百個，但表中可以有無限多個列?；A(chǔ)理論與架構(gòu)分類13）時間戳 Bigtable中的表項(xiàng)可以包含同一數(shù)據(jù)的不同版本，采用時間戳進(jìn)行索引。時間戳是64

10、位整型，既可以由系統(tǒng)賦值也可由用戶指定。為了簡化多版本數(shù)據(jù)的管理，每個列族都有兩個設(shè)置參數(shù)用于版本的自動回收，用戶可以指定保存最近 N 個版本，或保留足夠新的版本（如最近7天的內(nèi)容）?；A(chǔ)理論與架構(gòu)分類1列存儲數(shù)據(jù)庫列數(shù)據(jù)庫是對應(yīng)并區(qū)別于行數(shù)據(jù)庫的概念。行數(shù)據(jù)庫就是我們所熟知的傳統(tǒng)關(guān)系型數(shù)據(jù)庫，即數(shù)據(jù)按記錄存儲，每一條記錄的所有屬性都存儲在一起，如果要查詢一條記錄的一個屬性值，需要先讀取整條記錄的數(shù)據(jù)。而列數(shù)據(jù)庫是按數(shù)據(jù)庫記錄的列來組織和存儲數(shù)據(jù)的，數(shù)據(jù)庫中每個表由一組頁鏈的集合組成，每條頁鏈對應(yīng)表中的一個存儲列，而該頁鏈中每一頁存儲的是該列的一個或多個值?；A(chǔ)理論與架構(gòu)分類1HBaseHba

11、se是運(yùn)行在由多個節(jié)點(diǎn)構(gòu)成的服務(wù)集群基礎(chǔ)之上，為TB級甚至PB級別的數(shù)據(jù)存儲提供支持，并為用戶提供基于Row Key的高效查詢機(jī)制，它是由一個一個Row Key作為唯一標(biāo)識，并包含任意多例的一張表來根據(jù)存儲的數(shù)據(jù)量以大小被分割成一個或多個稱為 region 的子表基礎(chǔ)理論與架構(gòu)分類1基礎(chǔ)理論與架構(gòu)分類1一個HBase集群通常由一個master和多個region組成，且每個region Server管理一個或多個由master分配的region，而master則負(fù)責(zé)維護(hù)每個region的元信息，以及region和region Server之間的映射關(guān)系?；A(chǔ)理論與架構(gòu)分類1region中的數(shù)據(jù)最

12、終將被存放在Hadoop的多副本分布式文件系統(tǒng)HDFS中，且每個值出現(xiàn)一個region，使得同一時間t內(nèi)每個region只被分配給一臺region服務(wù)器，就讓所有行內(nèi)的mutation操作都是原子操作，所有的put操作要么完全成功、要么完全失敗，以及通過任何API返回行的內(nèi)容總是一個完整的行，最后就使得跨行的mutation操作不是原子操作?；A(chǔ)理論與架構(gòu)分類1進(jìn)一步地，對于HBase的表與region表現(xiàn)為：表被動態(tài)地分割成region，且放在一個或多個region服務(wù)上，當(dāng)region隨著增大時，它們會被切分并平均分布在region服務(wù)器上，使得切分操作接近實(shí)時，則表現(xiàn)為從高負(fù)載節(jié)點(diǎn)遷移走

13、，并且使錯誤的region節(jié)點(diǎn)會重新部署到正常節(jié)點(diǎn)上。同時，HBase采用 Zookeeper協(xié)調(diào)服務(wù)，保存Hadoop的集群狀態(tài)、故障或變更通知，并集成MapReduce，Jruby的命令外殼，使得HBase避開了HDFS只能append的限制，將最近更新的數(shù)據(jù)保存在內(nèi)存中，逐步重寫數(shù)據(jù)至新的文件中，并進(jìn)行智能拆分與合并。基礎(chǔ)理論與架構(gòu)分類1文檔型數(shù)據(jù)庫文檔型數(shù)據(jù)庫的靈感是來自于Lotus Notes辦公軟件的，而且它同第一種鍵值存儲相類似。該類型的數(shù)據(jù)模型是版本化的文檔、半結(jié)構(gòu)化的文檔以特定的格式存儲，例如JSON。文檔型數(shù)據(jù)庫可以看作是鍵值數(shù)據(jù)庫的升級版，允許之間嵌套鍵值。而文檔型數(shù)據(jù)庫

14、比鍵值數(shù)據(jù)庫的查詢效率更高，如：CouchDB，MongoDb。國內(nèi)也有文檔型數(shù)據(jù)庫SequoiaDB，已經(jīng)開源?；A(chǔ)理論與架構(gòu)分類1MongoDBMongoDB是10gen公司研發(fā)的面向文檔的開源的NoSQL數(shù)據(jù)庫系統(tǒng)，用C+語言編寫。它提供一種強(qiáng)大、靈活、可擴(kuò)展的數(shù)據(jù)存儲方式。它擴(kuò)展了關(guān)系型數(shù)據(jù)庫的眾多功能，如輔助索引、范圍查詢和排序。MongoDB的功能非常豐富，比如內(nèi)置的對MapReduce聚合的支持，以及對地理空間索引的支持。基礎(chǔ)理論與架構(gòu)分類1MongoDB的主要特性1）數(shù)據(jù)類型豐富。MongoDB是面向文檔的數(shù)據(jù)庫，放棄關(guān)系模型的一個主要原因是為了獲得更加靈活的擴(kuò)展性。它是無模式

15、的，文檔的鍵不會事先定義也不會固定不變，應(yīng)用層可以方便地處理新增的鍵或丟失的鍵，為開發(fā)者變更數(shù)據(jù)模型提供極大的便利；2）功能豐富。支持輔助索引、存儲JavaScript和MapReduce等其他聚合工具的獨(dú)特功能；基礎(chǔ)理論與架構(gòu)分類13）容易擴(kuò)展。MongoDB在設(shè)計(jì)時考慮了系統(tǒng)擴(kuò)展的問題，面向文檔的數(shù)據(jù)模型可以自動在多臺服務(wù)器之間進(jìn)行分割。通過其Auto-Sharding機(jī)制，可以自動實(shí)現(xiàn)集群的數(shù)據(jù)和負(fù)載均衡；4）性能卓越。MongoDB對文檔進(jìn)行自動動態(tài)填充，預(yù)分配數(shù)據(jù)文件，用空間換取性能的穩(wěn)定。默認(rèn)的存儲引擎中使用了內(nèi)存映射文件，將內(nèi)存的管理工作交給操作系統(tǒng)去處理?；A(chǔ)理論與架構(gòu)分類15

16、）管理簡便。盡可能的讓服務(wù)器自動配置，通過復(fù)制機(jī)制來提升系統(tǒng)的可靠性。MongoDB的核心概念是文檔，多個鍵及其相應(yīng)的值有序地存放在一起組成文檔，文檔類似于關(guān)系型數(shù)據(jù)庫中的元組。多個文檔組成集合，集合如同關(guān)系型數(shù)據(jù)庫中的表。多個集合組成數(shù)據(jù)庫，一個MongoDB的實(shí)例可以承載多個數(shù)據(jù)庫，每個數(shù)據(jù)庫之間是完全獨(dú)立的?；A(chǔ)理論與架構(gòu)分類1基礎(chǔ)理論與架構(gòu)分類1MongoDB的文檔采用BSON格式存儲，BSON是Binary JSON的簡寫，是一種類似于JSON文檔的二進(jìn)制序列化方案。用BSON格式來存儲數(shù)據(jù)具有如下三個優(yōu)勢：輕量級、容易遍歷和高效?；A(chǔ)理論與架構(gòu)分類1基礎(chǔ)理論與架構(gòu)分類1圖形數(shù)據(jù)庫圖

17、形數(shù)據(jù)庫就是將數(shù)據(jù)存儲在圖（Graph）結(jié)構(gòu)中。圖示是一個簡單的有向無環(huán)圖。其中，節(jié)點(diǎn)表示一個實(shí)體。例如人或商品。邊表示點(diǎn)與點(diǎn)之間的連接關(guān)系，可以是有方向和無向的。如用戶買了商品表示；如果用戶與用戶相互都認(rèn)識，這種關(guān)系就是雙向的，表示為 。屬性表示點(diǎn)和邊所附帶的屬性。例如用戶姓名、年齡等。需要注意的是每個點(diǎn)或邊的屬性是動態(tài)可變的?；A(chǔ)理論與架構(gòu)分類1圖形數(shù)據(jù)庫可以看作是結(jié)點(diǎn)與關(guān)系的集合，圖形數(shù)據(jù)庫就是將數(shù)據(jù)存儲在擁有屬性的結(jié)點(diǎn)中，并用關(guān)系將這些結(jié)點(diǎn)組織起來?；A(chǔ)理論與架構(gòu)分類1數(shù)據(jù)存儲的重要目的是為了檢索。圖的查找與搜索可以通過遍歷算法完成，根據(jù)算法，從開始結(jié)點(diǎn)到與之相連的結(jié)點(diǎn)查詢諸如“我好友

18、的好友是哪些人”等問題。所以通過遍歷算法可以對圖進(jìn)行導(dǎo)航與操作，從而確定結(jié)點(diǎn)之間的路徑?；A(chǔ)理論與架構(gòu)分類1鍵值存儲數(shù)據(jù)庫適用的場景 儲存用戶信息，比如會話、配置文件、參數(shù)、購物車等等。這些信息一般都和ID（鍵）掛鉤，這種情景下鍵值數(shù)據(jù)庫是個很好的選擇?；A(chǔ)理論與架構(gòu)分類1不適用場景 1）取代通過鍵查詢，而是通過值來查詢。Key-Value數(shù)據(jù)庫中根本沒有通過值查詢的途徑。2）需要儲存數(shù)據(jù)之間的關(guān)系。在Key-Value數(shù)據(jù)庫中不能通過兩個或以上的鍵來關(guān)聯(lián)數(shù)據(jù)。3）事務(wù)的支持。在Key-Value數(shù)據(jù)庫中故障產(chǎn)生時不可以進(jìn)行回滾?；A(chǔ)理論與架構(gòu)分類1列存儲數(shù)據(jù)庫 適用的場景 1）日志。因?yàn)槲覀?/p>

19、可以將數(shù)據(jù)儲存在不同的列中，每個應(yīng)用程序可以將信息寫入自己的列族中。2）博客平臺。我們儲存每個信息到不同的列族中。舉個例子，標(biāo)簽可以儲存在一個，類別可以在一個，而文章則在另一個。基礎(chǔ)理論與架構(gòu)分類1不適用場景 1）如果需要ACID事務(wù)。Vassandra就不支持事務(wù)；2）原型設(shè)計(jì)。如果我們分析Cassandra的數(shù)據(jù)結(jié)構(gòu)，我們就會發(fā)現(xiàn)結(jié)構(gòu)是基于我們期望的數(shù)據(jù)查詢方式而定。在模型設(shè)計(jì)之初，我們根本不可能去預(yù)測它的查詢方式，而一旦查詢方式改變，我們就必須重新設(shè)計(jì)列族?；A(chǔ)理論與架構(gòu)分類1面向文檔型數(shù)據(jù)庫 適用的場景 1）日志。企業(yè)環(huán)境下，每個應(yīng)用程序都有不同的日志信息。Document-Orien

20、ted數(shù)據(jù)庫并沒有固定的模式，所以我們可以使用它儲存不同的信息。2）分析。鑒于它的弱模式結(jié)構(gòu)，不改變模式下就可以儲存不同的度量方法及添加新的度量?；A(chǔ)理論與架構(gòu)分類1不適用場景 在不同的文檔上添加事務(wù)。文檔型數(shù)據(jù)庫并不支持文檔間的事務(wù)，如果對這方面有需求則不應(yīng)該選用這個解決方案。基礎(chǔ)理論與架構(gòu)分類1圖形數(shù)據(jù)庫 適用的場景 1）在一些關(guān)系性強(qiáng)的數(shù)據(jù)中；2）推薦引擎。如果我們將數(shù)據(jù)以圖的形式表現(xiàn)，那么將會非常有益于推薦的制定。不適用場景 不適合的數(shù)據(jù)模型。圖數(shù)據(jù)庫的適用范圍很小，因?yàn)楹苌儆胁僮魃婕暗秸麄€圖?；A(chǔ)理論與架構(gòu)分類1目 錄ONTENTS213CONTENTS部署方案與性能分析2數(shù)據(jù)存儲案

21、例：1）使用文檔型數(shù)據(jù)庫MongoDB深度挖掘天氣現(xiàn)象數(shù)據(jù)內(nèi)在價值：探究如何通過MongoDB實(shí)現(xiàn)對數(shù)據(jù)的存儲；2）基于Hbase的地震大數(shù)據(jù)存儲研究：探究通過Hbase對數(shù)據(jù)存儲的效率。部署方案與性能分析2使用文檔型數(shù)據(jù)庫MongoDB深度挖掘天氣現(xiàn)象數(shù)據(jù)內(nèi)在價值地面氣象觀測基本資料中的天氣現(xiàn)象數(shù)據(jù)與氣溫、雨量、氣壓等其他結(jié)構(gòu)化數(shù)據(jù)不同，天氣現(xiàn)象數(shù)據(jù)更像是一種非結(jié)構(gòu)化數(shù)據(jù)，它模式不固定，由現(xiàn)象符號編碼與表示方位、起始終止時間等內(nèi)容的字符串組合而成。部署方案與性能分析2天氣現(xiàn)象數(shù)據(jù)的存儲1）建立數(shù)據(jù)庫以及集合在MongoDB的Shell界面中，使用命令Use dbname，該命令建立數(shù)據(jù)庫db

22、name，也同時將當(dāng)前工作切換到名為dbname的數(shù)據(jù)庫中。集合類似于RDBMS中的“表”（table）。集合是不需要顯式建立的，當(dāng)存入數(shù)據(jù)時，使用某個新的集合名，數(shù)據(jù)庫會自動建立這個新的集合。例如db.test.save(數(shù)據(jù)文檔)，就會自動建立一個名為test的集合。部署方案與性能分析22）將原始數(shù)據(jù)編碼成BSON格式文檔一個文檔就是一條記錄，比如有以下表1是A文件（全國地面氣象資料基本格式文件）中兩天的天氣現(xiàn)象原始數(shù)據(jù)，為了保存入MongoDB數(shù)據(jù)庫，我們通過Java語言編程從 A 文件中讀取出原始數(shù)據(jù)，然后分別編碼成兩個BSON格式文檔如表2所示。部署方案與性能分析2部署方案與性能分析

23、2部署方案與性能分析23）存儲操作（1）首先把鍵值日期“rq”建立成唯一索引，保證在一個集合中不會出現(xiàn)重復(fù)日期的文檔。使用Shell命令db.test.ensureIndex(“rq”:1,“unique”:true,“dropDups”:true)；建立該唯一索引以后，當(dāng)插入或存入文檔鍵值“rq”有重復(fù)時，將會返回錯誤，若需跟新數(shù)據(jù)，只有刪除存在的文檔再插入，或者通過 update 命令更新已存在的文檔。這與RDBMS中的使用主鍵類似；部署方案與性能分析2（2）使用db.test.save（文檔）命令或者db.test.insert（文檔）命令，將編碼后的天氣現(xiàn)象數(shù)據(jù)存儲到MongoDB系統(tǒng)

24、dbname數(shù)據(jù)庫中的test集合中；（3）使用update命令更新已經(jīng)存入的文檔。例如需要修改日期為“20120719”的文檔的天氣現(xiàn)象數(shù)據(jù),使用命令db.test.update (“rq”:”20120719”,$set:“ww”:天氣現(xiàn)象文檔數(shù)組)；部署方案與性能分析2（4）使用remove命令刪除已經(jīng)存入的文檔。例如需要刪除 日 期 為 “ 2 0 1 2 0 7 1 9 ” 的 文 檔 ， 使 用 命 令db.test.remove(“rq”:”20120719”)。部署方案與性能分析22. 基于Hbase的地震大數(shù)據(jù)存儲研究1） 存儲原理Hbase表是一個分布式多維表，表中的數(shù)據(jù)通

25、過一個行關(guān)鍵 字 （ R o w K e y ） 、 一 個 列 族 和 一 個 列 名 （Colunmfamily:column name）以及一個時間戳進(jìn)行索引和查詢定位。其關(guān)鍵在于設(shè)計(jì)好Row Key，以方便數(shù)據(jù)查詢和數(shù)據(jù)分析。部署方案與性能分析2地震信息的業(yè)務(wù)邏輯是通過臺網(wǎng)（Netid）、臺站（Stationid）、測點(diǎn)（Pointid）、儀器（Intrid）、測項(xiàng)（Itenid）、采樣率（Samplerate）、產(chǎn)品類別（Protype）和時間戳（Timestamp）進(jìn)行查詢的。部署方案與性能分析2假設(shè)地震業(yè)務(wù)數(shù)據(jù)庫中有一個Obs觀測數(shù)據(jù)表，按照傳統(tǒng)的RDBMS，Obs表中的列是不能

26、隨意改變的，比如Schema定義了Netid、Stationid、Pointid、Intrid、Itenid、Samplerate、Protype、Timestamp等屬性，Obs表的屬性是不能動態(tài)增加的。而對于Hbase列存儲數(shù)據(jù)庫，在創(chuàng)建Obs表時，再為它定義一個info列族，Obs的數(shù)據(jù)便可以表示為info:value=23.4。如果要增加新的字段屬性，只需要通過添加一個info:newProperty就可以了。部署方案與性能分析2因此，如果采用傳統(tǒng)關(guān)系數(shù)據(jù)庫存儲將非常復(fù)雜，且會造成一些為空值的存儲浪費(fèi)。而Hbase就不會出現(xiàn)該問題，列存儲的每一個列單元如果是空值，則不占用存儲空間。部署

27、方案與性能分析2因此Hbase的基于列存儲數(shù)據(jù)模型非常適合地震數(shù)據(jù)頻繁擴(kuò)展的場景。另外Hbase數(shù)據(jù)庫還能自動切分?jǐn)?shù)據(jù)，當(dāng)Obs表中的數(shù)據(jù)超過某一個閥值時，Hbase就會自動切分?jǐn)?shù)據(jù)，使查詢具有伸縮性。再加上Hbase的弱事務(wù)性，使得Hbase的數(shù)據(jù)寫入效率非常高。Row Key是類似關(guān)系數(shù)據(jù)庫中的主鍵，在Hbase中的存儲也是根據(jù)Row Key來排序的。另外Hbase不支持條件查詢和Order by等查詢方式，故Row Key的設(shè)計(jì)要根據(jù)應(yīng)用系統(tǒng)的查詢需求而定。部署方案與性能分析2根據(jù)上述地震業(yè)務(wù)需求，觀測數(shù)據(jù)表Obs的Row Key可以由以下幾個部分構(gòu)成：、。當(dāng)要查詢某個臺網(wǎng)某個時間段數(shù)據(jù)

28、時，就可以指定起始Row Key為，終止Row Key為。其他各種組合需求，比如要查詢某個自然測點(diǎn)數(shù)據(jù)、某臺儀器的數(shù)據(jù)、某個學(xué)科數(shù)據(jù)、某個測項(xiàng)分量數(shù)據(jù)等，都可以非常高效地檢索出來。部署方案與性能分析22）存儲方法實(shí)現(xiàn)從數(shù)據(jù)結(jié)構(gòu)角度，地震數(shù)據(jù)可劃分為兩類：觀測產(chǎn)生的結(jié)構(gòu)化數(shù)據(jù)和文件、圖像等非結(jié)構(gòu)化數(shù)據(jù)。部署方案與性能分析2（1）結(jié)構(gòu)化數(shù)據(jù)存儲地震典型的普通結(jié)構(gòu)化數(shù)據(jù)就是前兆，存放在Oracle數(shù)據(jù)庫和測震存放在MySQL數(shù)據(jù)庫的關(guān)系型觀測數(shù)據(jù)，主要包括前兆各學(xué)科（形變、重力、GNSS、地下流體、地電、地磁等）和測震學(xué)（地震目錄、觀測報告、事件波形、連續(xù)波形等）數(shù)據(jù)。這些觀測數(shù)據(jù)，分別從前兆Ora

29、cle庫、測震MySQL庫讀取出來，通過上述存儲方法存儲至Hbase設(shè)計(jì)的Obs表中進(jìn)行統(tǒng)一存儲管理。部署方案與性能分析2（2）非結(jié)構(gòu)化數(shù)據(jù)存儲地震非結(jié)構(gòu)化數(shù)據(jù)存儲時，Hbase有著不可取代的優(yōu)勢：更有效地存儲小文件（小于16MB）；提供更高層和更可靠的接口，可以方便實(shí)現(xiàn)數(shù)據(jù)的增刪查改功能；提供失敗自動重試機(jī)制，有效地保證數(shù)據(jù)的一致性。部署方案與性能分析2Hadoop開發(fā)了Hbase大對象LOB（large objectstorage）存儲功能，方便用戶在Hbase中存儲各種類型的大對象。存儲時，LOB Store是列族級別的存儲單元，每個LOB Store可以存儲幾百萬個文件，而LOB St

30、ore的底層存儲在LOB File中。讀寫方面，其插入性能提高到100%，插入延時減少90%，讀取的隨機(jī)性能可達(dá)到200%。部署方案與性能分析23）對比測試（1）測試平臺環(huán)境為對比Hbase-0.94.6和MySQL-5.1.48的存儲、查詢等性能指標(biāo)，由3臺配置相同服務(wù)器的Hadoop集群組成分布式文件系統(tǒng)，構(gòu)成一個邏輯Hbase集群，同時由其中一臺機(jī)器單機(jī)測試MySQL。部署方案與性能分析2部署方案與性能分析2（2）結(jié)構(gòu)化數(shù)據(jù)存儲性能對比將兩者針對結(jié)構(gòu)化觀測數(shù)據(jù)的存儲進(jìn)行效能測試，在關(guān)鍵代碼處添加秒表，記錄執(zhí)行命令的時間。數(shù)據(jù)量（條）分別為50、100、1 000、10 000、100 0

31、00，每次插入保存完畢把所耗時長寫入日志文件。連續(xù)多次測試，取平均值。部署方案與性能分析2通過反復(fù)測試與效率對比發(fā)現(xiàn)，觀測數(shù)據(jù)讀取性能較高情況為：測震連續(xù)波形數(shù)據(jù)，每條記錄保存10min長度數(shù)據(jù)；前兆分鐘以上采樣率觀測數(shù)據(jù)，每條記錄保存1h長度數(shù)據(jù)。部署方案與性能分析2（3）非結(jié)構(gòu)化數(shù)據(jù)存儲性能對比分別對Hbase-0.94.6和MySQL-5.1.48做10、50、100、200、500、1 000次文件寫入試驗(yàn)，文件大小約30KB/個，兩者的二進(jìn)制文件存儲耗時性能對比結(jié)果如圖所示。部署方案與性能分析2（4）查詢性能對比分別對Hbase-0.94.6和MySQL-5.1.48做數(shù)據(jù)量為1 0

32、00、2 000、10 000、100 000、500 000的查詢性能測試。目 錄ONTENTS321CONTENTS發(fā)展現(xiàn)狀與未來趨勢3發(fā)展現(xiàn)狀與未來趨勢3DB-Engines Ranking發(fā)展現(xiàn)狀與未來趨勢3NoSQL得到如此廣泛的普及主要有3個驅(qū)動力。首先是需求。在過去的幾年間，互聯(lián)網(wǎng)與移動的流量呈現(xiàn)出了爆發(fā)性的增長，現(xiàn)在很多大公司所處理的數(shù)據(jù)規(guī)模是幾年前我們幾乎不曾想到的。傳統(tǒng)的關(guān)系型數(shù)據(jù)庫在設(shè)計(jì)時從未考慮過能夠比較容易地實(shí)現(xiàn)跨節(jié)點(diǎn)可伸縮這一特性，因此NoSQL在那些需要能夠?qū)崿F(xiàn)快速、輕松且低成本可伸縮的公司中開始流行起來； 發(fā)展現(xiàn)狀與未來趨勢3其次是可用性。在過去幾年間，開源軟件真的開始成熟起來了，現(xiàn)在已經(jīng)出現(xiàn)了很多成熟的開源NoSQL存儲，這樣公司就可以輕松找到滿足其需求的數(shù)據(jù)存儲方案了； 最后是新興性?，F(xiàn)在一定存在使用NoSQL構(gòu)建，但關(guān)系型數(shù)據(jù)庫卻更加適合的應(yīng)用。然而，隨著NoSQL逐漸從新生事物變成主流，技術(shù)人員在選擇適合其應(yīng)用場景的解決方案時會變得更理性一些。 發(fā)展現(xiàn)狀與未來趨勢3目前，NoSQL對大型企