數據存儲框架
① 數據的存儲結構包括________。
數據的存儲結構包括順序存儲和鏈式存儲結構。
順序存儲結構是把邏輯上相鄰的節點存儲在物理位置上相鄰的存儲單元中，結點之間的邏輯關系由存儲單元的鄰接關系來體現。通常順序存儲結構是藉助於計算機程序設計語言數組來描述的。主要優點是節省存儲空間，可實現對節點的隨機存取，即每一個節點對應一個序號。
鏈式存儲結構在計算機中用一組任意的存儲單元存儲線性表的數據元素。鏈式存儲結構通常藉助於程序設計語言中的指針類型來實現。它不要求邏輯上相鄰的元素在物理位置上相鄰；每個節點是由數據域和指針域組成；由於簇是隨機分配的，這也使數據刪除後覆蓋幾率降低，恢復可能提高。
(1)數據存儲框架擴展閱讀：
順序存儲結構的基本原理
在順序存儲中，每個存儲空間含有所存元素本身的信息，元素之間的邏輯關系是通過數組下標位置簡單計算出來的線性表的順序存儲，若一個元素存儲在對應數組中的下標位置為i，則它的前驅元素在對應數組中的下標位置為i-1，它的後繼元素在對應數組中的下標位置為i+1。
在鏈式存儲結構中，存儲結點不僅含有所存元素本身的信息，而且含有元素之間邏輯關系的信息。
② 什麼是「數據存儲結構」
向上 向下
指針 數據位 指針
---- ------ -----
數據存儲結構
數據結構(data structure):
是相互之間存在一種或多種特定關系的數據元素的集合。數據結構是一個二元組，記為:
data_structure=(D,S).其中D為數據元素的集合，S是D上關系的集合。
數據元素相互之間的關系稱為結構（structure）。根據數據元素之間關系的不同特性，通常由下列四類基本結構：
（1）集合:數據元素間的關系是同屬一個集合。
（2）線性結構:數據元素間存在一對一的關系。
（3）樹形結構：結構中的元素間的關系是一對多的關系。
（4）圖（網）狀結構：結構中的元素間的關系是多對多的關系。
③ 數據的存儲結構
存儲結構就是物理結構，這沒有錯
存儲結構是邏輯結構的存放方式，這沒有錯
邏輯結構是看不見摸不著的，但是計算機又要對數據進行邏輯結構的操作，那這就很尷尬了，咋辦。
這時候存儲結構（也就是數據的物理結構）挺身而出，「哥來給你表示你的位置」
存儲結構的位置可以用數組或指針具體表示的
這時候就可以根據物理結構的存儲位置來對數據的邏輯結構進行操作
那麼二者肯定是要有聯系的
聯系：
邏輯結果是存儲結構（物理結構）的映射
存儲結構（物理結構）是邏輯結構的映像
就好比風是邏輯機構，縹緲見不著
那要把控它的位置，進行風向預測
那麼氣象台就根據某些手段進行控制，把風的具體位置給彰顯出來了。
④ 現代資料庫中最常用的數據存儲結構是什麼
目前是最常用的四類資料庫是:
關系型資料庫,是按鏈表或是順序結果進行存儲的.
樹型資料庫,是按樹型結構進行存儲的.
網狀資料庫,是按圖結構進行存儲的
對象資料庫,是按順序結構或是鏈表結構下的塊方式進行存儲的!每一個對象存儲在一個單獨的塊單元中.
目前最常用的是關系型與對象資料庫.
刪除學生表中所有男生信息.
查詢學生表中所有總分大於85的學生的姓名與總分.
⑤ 數據的儲存結構主要有哪兩種有什麼主要區別
數據的儲存結構主要有：順序存儲結構和鏈式存儲結構。
主要區別
一、存儲單元的連續性不同
鏈式存儲結在構計算機中用一組任意的存儲單元存儲線性表的數據元素(這組存儲單元可以是連續的,也可以是不連續的)。
順序存儲結構在計算機中用一組地址連續的存儲單元依次存儲線性表的各個數據元素。
二、優缺點不同
空間上
順序比鏈式節約空間。是因為鏈式結構每一個節點都有一個指針存儲域。
存儲操作上：
順序支持隨機存取，方便操作
插入和刪除上：
鏈式的要比順序的方便（因為插入的話順序表也很方便，問題是順序表的插入要執行更大的空間復雜度，包括一個從表頭索引以及索引後的元素後移，而鏈表是索引後，插入就完成了）
三、適用方向不同
鏈式存儲適用於在較頻繁地插入、刪除、更新元素時，而順序存儲結構適用於頻繁查詢時使用。
⑥ 選擇什麼樣的數據倉庫架構比較好如何選擇呢
一直想整理一下這塊內容，既然是漫談，就想起什麼說什麼吧。我一直是在互聯網行業，就以互聯網行業來說。
先大概列一下互聯網行業數據倉庫、數據平台的用途：
整合公司所有業務數據，建立統一的數據中心；
提供各種報表，有給高層的，有給各個業務的；
為網站運營提供運營上的數據支持，就是通過數據，讓運營及時了解網站和產品的運營效果；
為各個業務提供線上或線下的數據支持，成為公司統一的數據交換與提供平台；
分析用戶行為數據，通過數據挖掘來降低投入成本，提高投入效果；比如廣告定向精準投放、用戶個性化推薦等；
開發數據產品，直接或間接為公司盈利；
建設開放數據平台，開放公司數據；
。。。。。。
上面列出的內容看上去和傳統行業數據倉庫用途差不多，並且都要求數據倉庫/數據平台有很好的穩定性、可靠性；但在互聯網行業，除了數據量大之外，越來越多的業務要求時效性，甚至很多是要求實時的 ，另外，互聯網行業的業務變化非常快，不可能像傳統行業一樣，可以使用自頂向下的方法建立數據倉庫，一勞永逸，它要求新的業務很快能融入數據倉庫中來，老的下線的業務，能很方便的從現有的數據倉庫中下線；
其實，互聯網行業的數據倉庫就是所謂的敏捷數據倉庫，不但要求能快速的響應數據，也要求能快速的響應業務；
建設敏捷數據倉庫，除了對架構技術上的要求之外，還有一個很重要的方面，就是數據建模，如果一上來就想著建立一套能兼容所有數據和業務的數據模型，那就又回到傳統數據倉庫的建設上了，很難滿足對業務變化的快速響應。應對這種情況，一般是先將核心的持久化的業務進行深度建模（比如：基於網站日誌建立的網站統計分析模型和用戶瀏覽軌跡模型；基於公司核心用戶數據建立的用戶模型），其它的業務一般都採用維度+寬表的方式來建立數據模型。這塊是後話。
整體架構下面的圖是我們目前使用的數據平台架構圖，其實大多公司應該都差不多：
邏輯上，一般都有數據採集層、數據存儲與分析層、數據共享層、數據應用層。可能叫法有所不同，本質上的角色都大同小異。
我們從下往上看：
數據採集數據採集層的任務就是把數據從各種數據源中採集和存儲到數據存儲上，期間有可能會做一些簡單的清洗。
數據源的種類比較多：
網站日誌：
作為互聯網行業，網站日誌占的份額最大，網站日誌存儲在多台網站日誌伺服器上，
一般是在每台網站日誌伺服器上部署flume agent，實時的收集網站日誌並存儲到HDFS上；
業務資料庫：
業務資料庫的種類也是多種多樣，有Mysql、Oracle、SqlServer等，這時候，我們迫切的需要一種能從各種資料庫中將數據同步到HDFS上的工具，Sqoop是一種，但是Sqoop太過繁重，而且不管數據量大小，都需要啟動MapRece來執行，而且需要Hadoop集群的每台機器都能訪問業務資料庫；應對此場景，淘寶開源的DataX，是一個很好的解決方案（可參考文章 《異構數據源海量數據交換工具-Taobao DataX 下載和使用》），有資源的話，可以基於DataX之上做二次開發，就能非常好的解決，我們目前使用的DataHub也是。
當然，Flume通過配置與開發，也可以實時的從資料庫中同步數據到HDFS。
來自於Ftp/Http的數據源：
有可能一些合作夥伴提供的數據，需要通過Ftp/Http等定時獲取，DataX也可以滿足該需求；
其他數據源：
比如一些手工錄入的數據，只需要提供一個介面或小程序，即可完成；
數據存儲與分析毋庸置疑，HDFS是大數據環境下數據倉庫/數據平台最完美的數據存儲解決方案。
離線數據分析與計算，也就是對實時性要求不高的部分，在我看來，Hive還是首當其沖的選擇，豐富的數據類型、內置函數；壓縮比非常高的ORC文件存儲格式；非常方便的SQL支持，使得Hive在基於結構化數據上的統計分析遠遠比MapRece要高效的多，一句SQL可以完成的需求，開發MR可能需要上百行代碼；
當然，使用Hadoop框架自然而然也提供了MapRece介面，如果真的很樂意開發Java，或者對SQL不熟，那麼也可以使用MapRece來做分析與計算；Spark是這兩年非常火的，經過實踐，它的性能的確比MapRece要好很多，而且和Hive、Yarn結合的越來越好，因此，必須支持使用Spark和SparkSQL來做分析和計算。因為已經有Hadoop Yarn，使用Spark其實是非常容易的，不用單獨部署Spark集群，關於Spark On Yarn的相關文章，可參考：《Spark On Yarn系列文章》
實時計算部分，後面單獨說。
數據共享這里的數據共享，其實指的是前面數據分析與計算後的結果存放的地方，其實就是關系型資料庫和NOSQL資料庫；
前面使用Hive、MR、Spark、SparkSQL分析和計算的結果，還是在HDFS上，但大多業務和應用不可能直接從HDFS上獲取數據，那麼就需要一個數據共享的地方，使得各業務和產品能方便的獲取數據；和數據採集層到HDFS剛好相反，這里需要一個從HDFS將數據同步至其他目標數據源的工具，同樣，DataX也可以滿足。
另外，一些實時計算的結果數據可能由實時計算模塊直接寫入數據共享。
數據應用
業務產品
業務產品所使用的數據，已經存在於數據共享層，他們直接從數據共享層訪問即可；
報表
同業務產品，報表所使用的數據，一般也是已經統計匯總好的，存放於數據共享層；
即席查詢
即席查詢的用戶有很多，有可能是數據開發人員、網站和產品運營人員、數據分析人員、甚至是部門老大，他們都有即席查詢數據的需求；
這種即席查詢通常是現有的報表和數據共享層的數據並不能滿足他們的需求，需要從數據存儲層直接查詢。
即席查詢一般是通過SQL完成，最大的難度在於響應速度上，使用Hive有點慢，目前我的解決方案是SparkSQL，它的響應速度較Hive快很多，而且能很好的與Hive兼容。
當然，你也可以使用Impala，如果不在乎平台中再多一個框架的話。
OLAP
目前，很多的OLAP工具不能很好的支持從HDFS上直接獲取數據，都是通過將需要的數據同步到關系型資料庫中做OLAP，但如果數據量巨大的話，關系型資料庫顯然不行；
這時候，需要做相應的開發，從HDFS或者HBase中獲取數據，完成OLAP的功能；
比如：根據用戶在界面上選擇的不定的維度和指標，通過開發介面，從HBase中獲取數據來展示。
其它數據介面
這種介面有通用的，有定製的。比如：一個從Redis中獲取用戶屬性的介面是通用的，所有的業務都可以調用這個介面來獲取用戶屬性。
實時計算現在業務對數據倉庫實時性的需求越來越多，比如：實時的了解網站的整體流量；實時的獲取一個廣告的曝光和點擊；在海量數據下，依靠傳統資料庫和傳統實現方法基本完成不了，需要的是一種分布式的、高吞吐量的、延時低的、高可靠的實時計算框架；Storm在這塊是比較成熟了，但我選擇Spark Streaming，原因很簡單，不想多引入一個框架到平台中，另外，Spark Streaming比Storm延時性高那麼一點點，那對於我們的需要可以忽略。
我們目前使用Spark Streaming實現了實時的網站流量統計、實時的廣告效果統計兩塊功能。
做法也很簡單，由Flume在前端日誌伺服器上收集網站日誌和廣告日誌，實時的發送給Spark Streaming，由Spark Streaming完成統計，將數據存儲至Redis，業務通過訪問Redis實時獲取。
任務調度與監控在數據倉庫/數據平台中，有各種各樣非常多的程序和任務，比如：數據採集任務、數據同步任務、數據分析任務等；
這些任務除了定時調度，還存在非常復雜的任務依賴關系，比如：數據分析任務必須等相應的數據採集任務完成後才能開始；數據同步任務需要等數據分析任務完成後才能開始；這就需要一個非常完善的任務調度與監控系統，它作為數據倉庫/數據平台的中樞，負責調度和監控所有任務的分配與運行。
前面有寫過文章，《大數據平台中的任務調度與監控》,這里不再累贅。
總結在我看來架構並不是技術越多越新越好，而是在可以滿足需求的情況下，越簡單越穩定越好。目前在我們的數據平台中，開發更多的是關注業務，而不是技術，他們把業務和需求搞清楚了，基本上只需要做簡單的SQL開發，然後配置到調度系統就可以了，如果任務異常，會收到告警。這樣，可以使更多的資源專注於業務之上。
⑦ 數據處理框架分類都有哪些
就目前而言，不管是系統中的歷史數據，還是持續不斷接入系統中的實時數據，只要數據是可訪問的，我們就能夠處理這些數據。按照處理的數據形式和得到結果的時效性進行分類，數據處理框架就可以分為兩類：批處理系統和流處理系統。
數據處理框架中的批處理就是一種用來計算大規模數據集的方法。批處理的過程包括將任務分解為較小的任務，分別在每個計算機上進行計算運行，根據數據分析的結果對數據的重新組合，然後通過計算機的計算出組合數據的最終結果。當處理非常巨大的數據集時，批處理系統是最有效的。而流處理就是對由連續不斷的單條數據項組成的數據流進行計算，注重數據處理結果的時效性。
一、批處理系統
批處理系統在大數據中有很長的歷史。批處理系統主要操作大量靜態的數據，並且等到全部處理完成後才能得到返回的結果。批處理系統中的數據集一般符合以下特徵：
1、有限： 數據集中的數據必須是有限的。
2、持久： 批處理系統處理的數據一般存儲在某個儲存器上。
3、海量： 一般來說只有海量的數據才能用批處理系統進行分析，並且海量的數據通常只能使用批處理系統來處理。
由於批處理系統在處理海量的持久數據方面表現出色，而歷史數據的數量是很多的，所以它通常被用來處理歷史數據，但是由於海量數據的處理需要耗費很多時間，所以批處理系統一般不用於即時性場景需求以及對延時要求較高的場景。
二、流處理系統
批處理系統好理解，那什麼是流處理系統呢？流處理系統與批處理系統所處理的數據不同之處在於，流處理系統並不是針對已經存在的數據集進行操作，而是處理對從外部系統接入的的數據。流處理系統一般分為兩種：
1、逐項處理： 每次處理一條數據，是真正意義上的流處理。
2、微批處理： 這種處理方式把一小段時間內的數據當作一個微批次，對這個微批次內的數據進行處理。
不論是哪種處理方式，其實時性都要遠遠好於批處理系統。因此，流處理系統非常適合應用於對實時性要求較高的場景，由於很多情況下，我們想要盡快看到計算結果，所以近些年流處理系統的應用越來越廣泛。
相信大家看了這篇文章以後已經知道了數據處理框架上面的相關情況了吧，一般來說，數據的處理里不來批處理和流處理，批處理適用於歷史數據的分析，而流處理適用於即時數據的分析，兩者都有各自的優缺點。希望本文能夠幫到大家。
⑧ 什麼是大數據的主流框架
市場上有許多可用的框架。其中一些更受歡迎，例如Spark，Hadoop，Hive和Storm。Presto在效用指數上得分很高，而Flink具有巨大的潛力。
1. Apache Hadoop
Hadoop是基於Java的平台。這是一個開放源代碼框架，可跨集群排列的一組硬體機器提供批處理數據處理和數據存儲服務。Hadoop同樣適用於可靠，可擴展和分布式的計算。但是，它也可以用作通用文件存儲。它可以存儲和處理PB的信息。Hadoop由三個主要組件組成。
2. Apache Spark
Spark框架由加利福尼亞大學伯克利分校成立。它是具有改進的數據流處理的批處理框架。藉助完整的內存計算以及處理優化，它保證了極其快速的集群計算系統。
3.Apache Storm
Apache Storm是另一個引人注目的解決方案，專注於處理巨大的實時數據流。Storm的主要亮點是可伸縮性和停機後的迅速恢復能力。
4. Apache Flink
Apache Flink是一個開源框架，同樣適用於批處理和流數據處理。它最適合於集群環境。該框架基於轉換–流概念。它也是大數據的4G。它比Hadoop – Map Rece快100倍。
5. Presto
Presto是最適合較小數據集的開源分布式SQL工具。Presto配備了協調員以及各種工人。當客戶提交查詢時，將對這些查詢進行解析，分析，計劃執行並分配給協調員在工作人員之間進行處理。
6. Samza
Apache Samza是有狀態的流，准備與Kafka共同開發的大數據系統。Kafka提供數據服務，緩沖和容錯能力。
⑨ 大數據下的地質資料信息存儲架構設計
頡貴琴 胡曉琴
(甘肅省國土資源信息中心)
摘要 為推進我國地質資料信息服務集群化產業化工作，更大更好地發揮地質資料信息的價值，本文針對我國現有的地質資料信息集群化共享服務平台存在的缺陷和問題，基於現有系統的存儲架構，設計了一種大數據下的地質資料信息存儲架構，以便於我國地質資料信息服務集群化產業化工作能夠適應大數據時代的數據存儲。
關鍵詞 大數據 地質資料 存儲 NoSQL 雙資料庫
0 引言
新中國成立60多年來，我國形成了海量的地質資料信息，為國民經濟和社會發展提供了重要支撐。但在地質資料管理方面長期存在資料信息分散、綜合研究不夠、數字化信息化程度不高、服務渠道不暢、服務能力不強等問題，使地質資料信息的巨大潛在價值未能得到充分發揮。為進一步提高地質工作服務國民經濟和社會發展的能力，充分發揮地質資料信息的服務功能，擴大服務領域，國土資源部根據國內外地質工作的先進經驗，做出了全面推進地質資料信息服務集群化產業化工作的部署。
目前，全國各省地質資料館都在有條不紊地對本省成果、原始和實物地質資料進行清理，並對其中重要地質資料進行數字化和存儲工作。然而，由於我國地質資源豐富，經過幾十年的積累，已經形成了海量的地質資料，數據量早已經超過了幾百太位元組(TB)。在進行地質資料信息服務集群化工作中，隨著共享數據量的不斷增大，傳統的數據存儲方式和管理系統必然會展現出存儲和檢索方面的不足以及系統管理方面的缺陷。為了解決該問題，需要設計更加先進的數據存儲架構來實現海量地質資料的存儲。
而大數據(Big Data)作為近年來在雲計算領域中出現的一種新型數據，科技工作者在不斷的研究中，設計了適合大數據存儲管理的非關系型資料庫NoSQL進行大數據的存儲和管理。本文將針對我國現有的地質資料信息集群化共享服務平台存在的缺陷和問題，利用大數據存儲管理模式的思想，提出一種海量地質資料存儲架構，改進現有系統存儲架構，以便於我國全面推進地質資料信息服務集群化產業化工作。
1 工作現狀
1.1 國內外地質資料信息的存儲現狀
在美國，主要有兩大地質資料公共服務平台，分別是地球科學信息中心(ESIC)、地球資源觀測和科學中心(EROS)，其目的是通過為社會和政府提供更加便利、快速的地質信息服務。20世紀90年代初，澳大利亞出台了國家地球科學填圖協議，採用先進的科學方法和技術進行數據存儲，從而形成了第二代澳大利亞陸地地質圖。
目前，我國地質資料信息服務集群化產業化工作剛剛起步，雖然國土資源部信息中心已經開發了地質資料信息集群化共享服務平台，並倡導各地方用戶使用該系統。但由於各個地方早期的工作背景不一致，因此各地方所使用的存儲系統也不盡相同，主要有Access、SQL Server、Oracle、MySQL等系統。本文以國土資源部信息中心開發的地質資料信息集群化共享服務平台的存儲系統MySQL為例說明。該系統是基於關系資料庫管理系統MySQL的一套分布式存儲檢索系統。該系統的部署使得我國地質資料信息服務集群化產業化工作取得了重大進展，同時也為我國建立標准統一的地質資料信息共享服務平台和互聯互通的網路服務體系奠定了堅實的基礎。然而，該系統的研發並沒有考慮到地質資料信息進一步集群化以及在未來地質資料信息進入大數據時代的信息共享和存儲管理問題，也沒有給出明確的解決方案。
1.2 大數據的存儲架構介紹
大數據是近年在雲計算領域中出現的一種新型數據，具有數據量大、數據結構不固定、類型多樣、查詢分析復雜等特點。傳統關系型資料庫管理系統在數據存儲規模、檢索效率等方面已不再適合大數據存儲。NoSQL(Not Only SQL)是與關系資料庫相對的一類資料庫的總稱。這些資料庫放棄了對關系資料庫的支持，轉而採用靈活的、分布式的數據存儲方式管理數據，從而可以滿足大數據存儲和處理的需求。NoSQL基於非關系型數據存儲的設計理念，以鍵值對進行存儲，採用的數據字的結構不固定，每一個元組可以有不一樣的欄位，且每個元組可以根據自己的需要增加一些自己的鍵值對，可以減少一些檢索時間和存儲空間。目前，應用廣泛的 NoSQL 資料庫有 Google BigTable、HBase、MongoDB、Neo4 j、Infinite Graph等。
2 大數據下的地質資料信息存儲架構設計
根據國土資源部做出的全面推進地質資料信息服務集群化產業化工作的部署，國土資源部倡導全國地質資料館使用國土資源部信息中心開發的地質資料信息集群化共享服務平台，實現地質資料信息的存儲和共享。該系統採用了資料庫管理系統MySQL作為數據存儲系統。
為了與現有系統和現有的工作進行對接，並為將來地質資料進入大數據時代後的存儲工作做准備，本文設計了一種能用於海量地質資料信息存儲並且兼容MySQL的分布式的數據存儲架構(圖1)。
整個系統可以根據不同的用戶等級分為不同的用戶管理層，由於圖幅限制，在圖1 中僅僅展示了3級：國家級管理層(即共享服務平台用戶層)、省級管理層以及市級管理層(可根據實際需要延伸至縣級)。
每級管理層的每個用戶可以單獨管理一個伺服器。如國土資源部信息中心可以單獨管理一個伺服器；甘肅省國土資源信息中心可以單獨管理一個伺服器，陝西省國土資源信息中心可以單獨管理一個伺服器；甘肅的若干個市級國土資源局可以根據需要分別管理各自的伺服器。
在伺服器上分別安裝兩套資料庫管理系統，一套是原有的MySQL資料庫管理系統，另一套是為大數據存儲而配備的NoSQL型資料庫管理系統。在伺服器上還專門開發一個資料庫管理器中間件，用於進行用戶層和資料庫的通信以及兩套資料庫之間的通信。
由於各個管理層都各自維護自己的資料庫和數據。當用戶需要進行數據存儲時，他所影響的資料庫僅僅是本地資料庫，存儲效率較高；當用戶需要從多個資料庫讀取數據時，頂層的共享服務平台會根據用戶需求進行任務分解，將任務分發給下層的管理層進行資料庫讀取，由於各個資料庫並行讀取，從而提高了資料庫讀取效率。
圖1 大數據下的地質資料信息存儲架構框圖
2.1 用戶管理層
用戶管理層根據許可權范圍，分為多層(本文以3層為例)。
位於頂層的國家級管理層(共享服務平台用戶層)負責用戶訪問許可權的分配、與其直接關聯的資料庫的訪問、下級管理層任務的分配等工作。
用戶訪問許可權的分配是指為訪問本共享服務平台的個人用戶和單位用戶分配數據的使用許可權、安全性的設計等。
與其直接關聯的資料庫訪問是指直接存儲在其本地資料庫上的數據的訪問。在該資料庫中不僅要存儲所需要的地質資料，還要存儲注冊用戶信息等數據。
下級管理層任務分配是指如果用戶需要訪問多個下層資料庫，用戶只需要輸入查詢這幾個下層資料庫的命令，而如何查找下層資料庫則由該功能來完成。例如某用戶要查找甘肅、陝西、上海、北京的鐵礦分布圖，則用戶只需要輸入這幾個地方及鐵礦等查詢條件，系統將自動把各個省的資料庫查詢任務分派到下級管理層。
同理，位於下層的省級管理層和市級管理層除了沒有用戶訪問許可權功能外，其餘功能與國家級管理層是相同的。各層之間的資料庫通過互聯網相互連接成分布式的資料庫系統。
2.2 MySQL和NoSQL的融合
MySQL是關系型資料庫，它支持SQL查詢語言，而NoSQL是非關系型資料庫，它不支持SQL查詢語言。用戶要想透明地訪問這兩套資料庫，必須要設計資料庫管理器中間件，作為用戶訪問資料庫的統一入口和兩套資料庫管理系統的通信平台。本文所設計的資料庫管理器簡單模型如圖2所示。
圖2 資料庫管理器模型
伺服器管理器通過用戶程序介面與應用程序進行通訊，通過MySQL資料庫介面與MySQL伺服器通訊，通過NoSQL資料庫介面與NoSQL資料庫介面通訊。當應用程序介面接收到一條資料庫訪問命令之後，交由資料庫訪問命令解析器進行命令解析，從而形成MySQL訪問命令或者NoSQL訪問命令，通過相應的資料庫介面訪問資料庫；資料庫返回訪問結果後經過匯總，由應用程序介面返回給應用程序。
兩套資料庫可以通過雙資料庫通信協議進行相互的通信和互訪。此通信協議的建立便於地質工作人員將已經存入MySQL資料庫的不適合結構化存儲的數據轉存到NoSQL資料庫中，從而便於系統的升級和優化。
2.3 系統的存儲和檢索模式
在本存儲框架設計中，系統採用分布式網路存儲模式，即採用可擴展的存儲結構，利用分散在全國各地的多台獨立的伺服器進行數據存儲。這種方式不僅分擔了伺服器的存儲壓力，提高了系統的可靠性和可用性，還易於進行系統擴展。另外，由於地質資料信息存儲的特殊性，各地方用戶的數據存儲工作基本都是在本地伺服器進行，很少通過網路進行遠程存儲，所以數據存儲效率較高。
在一台資料庫伺服器上安裝有MySQL和NoSQL型兩套資料庫管理系統，分別用於存儲地質資料信息中的結構化數據和非結構化數據。其中，NoSQL型資料庫作為主資料庫，用於存儲一部分結構化數據和全部的非結構化數據；而MySQL資料庫作為輔助資料庫，用於存儲一部分結構化的數據，以及舊系統中已經存儲的數據。使用兩套資料庫不僅可以存儲結構化數據而且還可以適用於大數據時代地質資料信息的存儲，因此系統具有很好的適應性和靈活性。
2.4 安全性設計
地質資料信息是國家的機密，地質工作人員必須要保證它的安全。地質資料信息進入數字化時代之後，地質資料常常在計算機以及網路上進行傳輸，地質資料信息的安全傳輸和保存更是地質工作人員必須關注和解決的問題。在本存儲架構的設計中設計的安全問題主要有資料庫存儲安全、數據傳輸安全、數據訪問安全等問題。
資料庫設計時採用多邊安全模型和多級安全模型阻止資料庫中信息和數據的泄露來提高資料庫的安全性能，以保障地質信息在資料庫中的存儲安全；當用戶登錄系統訪問資料庫時，必須進行用戶甄別和實名認證，這主要是對用戶的身份進行有效的識別，防止非法用戶訪問資料庫；在對地質資料進行網路傳輸時，應該首先將數據進行加密，然後再進行網路傳輸，以防止地質信息在傳輸過程中被竊取。
3 結語
提高地質資料數字化信息化水平，是國外地質工作強國的普遍做法。為推進我國地質資料信息服務集群化產業化工作，本文針對我國現有的地質資料信息集群化共享服務平台存在的缺陷和問題，利用大數據存儲管理模式的思想，基於現有系統的存儲架構，設計了一種大數據下的地質資料信息存儲架構，以便於我國地質資料信息服務集群化產業化工作能夠適應大數據時代的數據存儲。該存儲架構的設計只涉及了簡單模型的構建，具體詳細復雜的功能設計和軟體實現還需要在進一步的研究工作中完成。
參考文獻
[1]吳金朋.一種大數據存儲模型的研究與應用[D].北京：北京郵電大學計算機學院，2012.
[2]吳廣君，王樹鵬，陳明，等.海量結構化數據存儲檢索系統[J].計算機研究與發展，2012，49(Suppl)：1～5.
[3]黃