数据存储框架
① 数据的存储结构包括________。
数据的存储结构包括顺序存储和链式存储结构。
顺序存储结构是把逻辑上相邻的节点存储在物理位置上相邻的存储单元中，结点之间的逻辑关系由存储单元的邻接关系来体现。通常顺序存储结构是借助于计算机程序设计语言数组来描述的。主要优点是节省存储空间，可实现对节点的随机存取，即每一个节点对应一个序号。
链式存储结构在计算机中用一组任意的存储单元存储线性表的数据元素。链式存储结构通常借助于程序设计语言中的指针类型来实现。它不要求逻辑上相邻的元素在物理位置上相邻；每个节点是由数据域和指针域组成；由于簇是随机分配的，这也使数据删除后覆盖几率降低，恢复可能提高。
(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]黄