基于GIS的海量气象数据预处理技术研究论文

2024-06-15

基于GIS的海量气象数据预处理技术研究论文（精选7篇）

1.基于GIS的海量气象数据预处理技术研究论文篇一

大数据量，海量数据处理方法总结大数据量的问题是很多面试笔试中经常出现的问题，比如baidu google 腾讯这样的一些涉及到海量数据的公司经常会问到。

下面的方法是我对海量数据的处理方法进行了一个一般性的总结，当然这些方法可能并不能完全覆盖所有的问题，但是这样的一些方法也基本可以处理绝大多数遇到的问题。下面的一些问题基本直接来源于公司的面试笔试题目，方法不一定最优，如果你有更好的处理方法，欢迎与我讨论。1.Bloom filter 适用范围：可以用来实现数据字典，进行数据的判重，或者集合求交集

基本原理及要点：

对于原理来说很简单，位数组+k个独立hash函数。将hash函数对应的值的位数组置1，查找时如果发现所有hash函数对应位都是1说明存在，很明显这个过程并不保证查找的结果是100%正确的。同时也不支持删除一个已经插入的关键字，因为该关键字对应的位会牵动到其他的关键字。所以一个简单的改进就是 counting Bloom filter，用一个counter数组代替位数组，就可以支持删除了。还有一个比较重要的问题，如何根据输入元素个数n，确定位数组m的大小及hash函数个数。当hash函数个数k=(ln2)*(m/n)时错误率最小。在错误率不大于E的情况下，m至少要等于n*lg(1/E)才能表示任意n个元素的集合。但m还应该更大些，因为还要保证bit数组里至少一半为0，则m应该>=nlg(1/E)*lge 大概就是nlg(1/E)1.44倍(lg表示以2为底的对数)。举个例子我们假设错误率为0.01，则此时m应大概是n的13倍。这样k大概是8个。

注意这里m与n的单位不同，m是bit为单位，而n则是以元素个数为单位(准确的说是不同元素的个数)。通常单个元素的长度都是有很多bit的。所以使用bloom filter内存上通常都是节省的。

扩展：

Bloom filter将集合中的元素映射到位数组中，用k（k为哈希函数个数）个映射位是否全1表示元素在不在这个集合中。Counting bloom filter（CBF）将位数组中的每一位扩展为一个counter，从而支持了元素的删除操作。Spectral Bloom Filter（SBF）将其与集合元素的出现次数关联。SBF采用counter中的最小值来近似表示元素的出现频率。问题实例：给你A,B两个文件，各存放50亿条URL，每条URL占用64字节，内存限制是4G，让你找出A,B文件共同的URL。如果是三个乃至n个文件呢？根据这个问题我们来计算下内存的占用，4G=2^32大概是40亿*8大概是340亿，n=50亿，如果

按出错率0.01算需要的大概是650亿个bit。现在可用的是340亿，相差并不多，这样可能会使出错率上升些。另外如果这些urlip是一一对应的，就可以转换成ip，则大大简单了。2.Hashing 适用范围：快速查找，删除的基本数据结构，通常需要总数据量可以放入内存

基本原理及要点：

hash函数选择，针对字符串，整数，排列，具体相应的hash方法。

碰撞处理，一种是open hashing，也称为拉链法；另一种就是closed hashing，也称开地址法，opened addressing。

扩展：

d-left hashing中的d是多个的意思，我们先简化这个问题，看一看2-left hashing。2-left hashing指的是将一个哈希表分成长度相等的两半，分别叫做T1和T2，给T1和T2分别配备一个哈希函数，h1和h2。在存储一个新的key时，同时用两个哈希函数进行计算，得出两个地址h1[key]和h2[key]。这时需要检查T1中的h1[key]位置和T2中的h2[key]位置，哪一个位置已经存储的（有碰撞的）key比较多，然后将新key存储在负载少的位置。如果两边一样多，比如两个位置都为空或者都存储了一个key，就把新key 存储在左边的T1子表中，2-left也由此而来。在查找一个key时，必须进行两次hash，同时查找两个位置。问题实例： 1).海量日志数据，提取出某日访问百度次数最多的那个IP。

IP的数目还是有限的，最多2^32个，所以可以考虑使用hash将ip直接存入内存，然后进行统计。3.bit-map 适用范围：可进行数据的快速查找，判重，删除，一般来说数据范围是int的10倍以下基本原理及要点：使用bit数组来表示某些元素是否存在，比如8位电话号码

扩展：bloom filter可以看做是对bit-map的扩展问题实例： 1)已知某个文件内包含一些电话号码，每个号码为8位数字，统计不同号码的个数。

8位最多99 999 999，大概需要99m个bit，大概10几m字节的内存即可。

2)2.5亿个整数中找出不重复的整数的个数，内存空间不足以容纳这2.5亿个整数。将bit-map扩展一下，用2bit表示一个数即可，0表示未出现，1表示出现一次，2表示出现2次及以上。或者我们不用2bit来进行表示，我们用两个bit-map即可模拟实现这个2bit-map。

4.堆适用范围：海量数据前n大，并且n比较小，堆可以放入内存基本原理及要点：最大堆求前n小，最小堆求前n大。方法，比如求前n小，我们比较当前元素与最大堆里的最大元素，如果它小于最大元素，则应该替换那个最大元素。这样最后得到的n个元素就是最小的n个。适合大数据量，求前n小，n的大小比较小的情况，这样可以扫描一遍即可得到所有的前n元素，效率很高。

扩展：双堆，一个最大堆与一个最小堆结合，可以用来维护中位数。问题实例： 1)100w个数中找最大的前100个数。

用一个100个元素大小的最小堆即可。

5.双层桶划分适用范围：第k大，中位数，不重复或重复的数字

基本原理及要点：因为元素范围很大，不能利用直接寻址表，所以通过多次划分，逐步确定范围，然后最后在一个可以接受的范围内进行。可以通过多次缩小，双层只是一个例子。扩展：问题实例： 1).2.5亿个整数中找出不重复的整数的个数，内存空间不足以容纳这2.5亿个整数。有点像鸽巢原理，整数个数为2^32,也就是，我们可以将这2^32个数，划分为2^8个区域(比如用单个文件代表一个区域)，然后将数据分离到不同的区域，然后不同的区域在利用bitmap就可以直接解决了。也就是说只要有足够的磁盘空间，就可以很方便的解决。

2).5亿个int找它们的中位数。这个例子比上面那个更明显。首先我们将int划分为2^16个区域，然后读取数据统计落到各个区域里的数的个数，之后我们根据统计结果就可以判断中位数落到那个区域，同时知道这个区域中的第几大数刚好是中位数。然后第二次扫描我们只统计落在这个区域中的那些数就可以了。

实际上，如果不是int是int64，我们可以经过3次这样的划分即可降低到可以接受的程度。即可以先将int64分成2^24个区域，然后确定区域的第几大数，在将该区域分成2^20个子区域，然后确定是子区域的第几大数，然后子区域里的数的个数只有2^20，就可以直接利用direct addr table进行统计了。6.数据库索引适用范围：大数据量的增删改查基本原理及要点：利用数据的设计实现方法，对海量数据的增删改查进行处理。扩展：问题实例： 7.倒排索引(Inverted index)适用范围：搜索引擎，关键字查询基本原理及要点：为何叫倒排索引？一种索引方法，被用来存储在全文搜索下某个单词在一个文档或者一组文档中的存储位置的映射。

以英文为例，下面是要被索引的文本： T0 = “it is what it is” T1 = “what is it” T2 = “it is a banana” 我们就能得到下面的反向文件索引： “a”: {2} “banana”: {2} “is”: {0, 1, 2} “it”: {0, 1, 2} “what”: {0, 1}

检索的条件“what”, “is” 和 “it” 将对应集合的交集。正向索引开发出来用来存储每个文档的单词的列表。正向索引的查询往往满足每个文档有序频繁的全文查询和每个单词在校验文档中的验证这样的查询。在正向索引中，文档占据了中心的位置，每个文档指向了一个它所包含的索引项的序列。也就是说文档指向了它包含的那些单词，而反向索引则是单词指向了包含它的文档，很容易看到这个反向的关系。扩展：问题实例：文档检索系统，查询那些文件包含了某单词，比如常见的学术论文的关键字搜索。8.外排序适用范围：大数据的排序，去重基本原理及要点：外排序的归并方法，置换选择败者树原理，最优归并树

扩展：

问题实例： 1).有一个1G大小的一个文件，里面每一行是一个词，词的大小不超过16个字节，内存限制大小是1M。返回频数最高的100个词。这个数据具有很明显的特点，词的大小为16个字节，但是内存只有1m做hash有些不够，所以可以用来排序。内存可以当输入缓冲区使用。9.trie树适用范围：数据量大，重复多，但是数据种类小可以放入内存基本原理及要点：实现方式，节点孩子的表示方式扩展：压缩实现。问题实例： 1).有10个文件，每个文件1G，每个文件的每一行都存放的是用户的query，每个文件的query都可能重复。要你按照query的频度排序。

2).1000万字符串，其中有些是相同的(重复),需要把重复的全部去掉，保留没有重复的字符串。请问怎么设计和实现？

3).寻找热门查询：查询串的重复度比较高，虽然总数是1千万，但如果除去重复后，不超过3百万个，每个不超过255字节。10.分布式处理 mapreduce 适用范围：数据量大，但是数据种类小可以放入内存

基本原理及要点：将数据交给不同的机器去处理，数据划分，结果归约。

扩展：

问题实例： 1).The canonical example application of MapReduce is a process to count the appearances of

each different word in a set of documents:

void map(String name, String document):

// name: document name

// document: document contents

for each word w in document: EmitIntermediate(w, 1);void reduce(String word, Iterator partialCounts): // key: a word // values: a list of aggregated partial counts int result = 0;for each v in partialCounts: result += ParseInt(v);Emit(result);Here, each document is split in words, and each word is counted initially with a “1” value by

the Map function, using the word as the result key.The framework puts together all the pairs

with the same key and feeds them to the same call to Reduce, thus this function just needs to

sum all of its input values to find the total appearances of that word.2).海量数据分布在100台电脑中，想个办法高效统计出这批数据的TOP10。

3).一共有N个机器，每个机器上有N个数。每个机器最多存O(N)个数并对它们操作。如何找到N^2个数的中数(median)？经典问题分析上千万or亿数据（有重复），统计其中出现次数最多的前N个数据,分两种情况：可一次读入内存，不可一次读入。

可用思路：trie树+堆，数据库索引，划分子集分别统计，hash，分布式计算，近似统计，外排序

所谓的是否能一次读入内存，实际上应该指去除重复后的数据量。如果去重后数据可以放入内存，我们可以为数据建立字典，比如通过 map，hashmap，trie，然后直接进行统计即可。当然在更新每条数据的出现次数的时候，我们可以利用一个堆来维护出现次数最多的前N个数据，当然这样导致维护次数增加，不如完全统计后在求前N大效率高。

如果数据无法放入内存。一方面我们可以考虑上面的字典方法能否被改进以适应这种情形，可以做的改变就是将字典存放到硬盘上，而不是内存，这可以参考数据库的存储方法。

当然还有更好的方法，就是可以采用分布式计算，基本上就是map-reduce过程，首先可以根据数据值或者把数据hash(md5)后的值，将数据按照范围划分到不同的机子，最好可以让数据划分后可以一次读入内存，这样不同的机子负责处理各种的数值范围，实际上就是map。得到结果后，各个机子只需拿出各自的出现次数最多的前N个数据，然后汇总，选出所有的数据中出现次数最多的前N个数据，这实际上就是reduce过程。实际上可能想直接将数据均分到不同的机子上进行处理，这样是无法得到正确的解的。因为一个数据可能被均分到不同的机子上，而另一个则可能完全聚集到一个机子上，同时还可能存在具有相同数目的数据。比如我们要找出现次数最多的前100个，我们将1000万的数据分布到10台机器上，找到每台出现次数最多的前 100个，归并之后这样不能保证找到真正的第100个，因为比如出现次数最多的第100个可能有1万个，但是它被分到了10台机子，这样在每台上只有1千个，假设这些机子排名在

1000个之前的那些都是单独分布在一台机子上的，比如有1001个，这样本来具有1万个的这个就会被淘汰，即使我们让每台机子选出出现次数最多的1000个再归并，仍然会出错，因为可能存在大量个数为1001个的发生聚集。因此不能将数据随便均分到不同机子上，而是要根据hash 后的值将它们映射到不同的机子上处理，让不同的机器处理一个数值范围。

而外排序的方法会消耗大量的IO，效率不会很高。而上面的分布式方法，也可以用于单机版本，也就是将总的数据根据值的范围，划分成多个不同的子文件，然后逐个处理。处理完毕之后再对这些单词的及其出现频率进行一个归并。实际上就可以利用一个外排序的归并过程。

另外还可以考虑近似计算，也就是我们可以通过结合自然语言属性，只将那些真正实际中出现最多的那些词作为一个字典，使得这个规模可以放入内存。

2.基于GIS的海量气象数据预处理技术研究论文篇二

关键词：电子商务,数据处理,数据分析

1 电子商务数据的特点

1.1 数据量大

从TB级别跃升到PB乃至EB级别。要知道目前的数据量有多大, 我们先来看看一组公式。1024GB=1TB;1024TB=1PB;1024PB=1EB;1024EB=1ZB;1024ZB=YB。到目前为止, 人类生产的所有印刷材料的数据量是200PB, 而历史上全人类说过的所有的话的数据量大约是5EB。

1.2 类型繁多

这种类型的多样性也让数据被分为结构化数据和非结构化数据。相对于以往便于存储的以文本为主的结构化数据, 越来越多的非结构化数据的产生给所有厂商都提出了挑战。

1.3 价值密度低

价值密度的高低与数据总量的大小成反比。以视频为例, 一部1 h的视频, 在连续不间断监控过程中, 可能有用的数据仅仅只有一两秒。如何通过强大的机器算法更迅速地完成数据的价值“提纯”是目前大数据汹涌背景下亟待解决的难题。

1.4 速度快时效高

这是大数据区分于传统数据挖掘最显著的特征。根据IDC的一份名为“数字宇宙”的报告, 预计到2020年全球数据使用量将会达到35.2ZB。在如此海量的数据面前, 处理数据的效率就是企业的生命。

2 电子商务平台海量数据处理的相关技术介绍

2.1 对海量数据进行分区操作

对海量数据进行分区操作十分必要, 例如针对按年份存取的数据, 我们可以按年进行分区, 不同的数据库有不同的分区方式, 不过处理机制大体相同。例如SQL Server的数据库分区是将不同的数据存于不同的文件组下, 而不同的文件组存于不同的磁盘分区下, 这样将数据分散开, 减小磁盘I/O, 减小了系统负荷, 而且还可以将日志, 索引等放于不同的分区下。

2.2 建立广泛的索引

对海量的数据处理, 对大表建立索引是必行的, 建立索引要考虑到具体情况, 例如针对大表的分组、排序等字段, 都要建立相应索引。结构化数据具有统一的纲要, 关系表中的每个元组都有相同的属性和数据类型 (比如数值或字符串) , 关系数据库可以对它们进行统一的存储和管理。

2.3 使用文本格式进行处理

对一般的数据处理可以使用数据库, 如果对复杂的数据处理, 必须借助程序, 那么在程序操作数据库和程序操作文本之间选择, 是一定要选择程序操作文本的, 原因为:程序操作文本速度快;对文本进行处理不容易出错;文本的存储不受限制等。

2.4 使用临时表和中间表

数据量增加时, 处理中要考虑提前汇总。这样做的目的是化整为零, 大表变小表, 分块处理完成后, 再利用一定的规则进行合并, 处理过程中的临时表的使用和中间结果的保存都非常重要, 如果对于超海量的数据, 大表处理不了, 只能拆分为多个小表。如果处理过程中需要多步汇总操作, 可按汇总步骤一步步来, 不要一条语句完成, 一口气吃掉一个胖子。

2.5 优化查询SQL语句

在对海量数据进行查询处理过程中, 查询的SQL语句的性能对查询效率的影响是非常大的, 编写高效优良的SQL脚本和存储过程是数据库工作人员的职责, 也是检验数据库工作人员水平的一个标准, 在对SQL语句的编写过程中, 例如减少关联, 少用或不用游标, 设计好高效的数据库表结构等都十分必要。笔者在工作中试着对1亿行的数据使用游标, 运行3 h没有出结果, 这是一定要改用程序处理了。

2.6 定制强大的清洗规则和出错处理机制

海量数据中存在着不一致性, 极有可能出现某处的瑕疵。例如, 同样的数据中的时间字段, 有的可能为非标准的时间, 出现的原因可能为应用程序的错误, 系统的错误等, 这是在进行数据处理时, 必须制定强大的数据清洗规则和出错处理机制。

2.7 使用数据仓库和多维数据库存储

数据量加大是一定要考虑OLAP的, 传统的报表可能5、6h出来结果, 而基于Cube的查询可能只需要几分钟, 因此处理海量数据的利器是OLAP多维分析, 即建立数据仓库, 建立多维数据集, 基于多维数据集进行报表展现和数据挖掘等。

2.8 使用采样数据, 进行数据挖掘

基于海量数据的数据挖掘正在逐步兴起, 面对着超海量的数据, 一般的挖掘软件或算法往往采用数据抽样的方式进行处理, 这样的误差不会很高, 大大提高了处理效率和处理的成功率。一般采样时要注意数据的完整性和, 防止过大的偏差。

3 结语

随着电子商务平台用户数量的不断增长, 人们需求的不断提高以及商户服务种类与项目的日益增多, 电子商务平台的数据量还会不断的增大。如何针对电子商务平台海量的数据进行分析和处理是一项艰巨而复杂的任务。

参考文献

[1]亿邦动力网.零售商认为大数据有利于电子商务[EB/OL].[2012-10-18].http://www.ebrun.com/20121018/58764.shtml.

3.基于GIS的海量气象数据预处理技术研究论文篇三

【关键字】线实体；数据处理；质量检查；八叉树结构；弧拓扑；面拓扑

引导语

众所周知，GIS的最主要的功能即是其较为完善的空间分析能力，这种能力也是传统的计算机制图和GIS之间的最大的差异。空间分析对于GIS是至关重要的一个环节，在这个过程中不仅要用到计算机科学，还要用到图论、空间统计学、拓扑学、计算几何学等复杂的数学工具。空间分析在多学科集成的帮助之下对实体的空间以及空间中的物体的构成使用拓扑学以及其他学科的描述方法进行描述，并使用空间统计学对其进行分析，以获得所需要的模型数据，这些模型数据既包括了目标的空间的描述的数字化模型，又包括了目标空间中的各物体及其与空间以及与其他物体之间的关系。这些数字化的模型数据是计算机辨识空间、搜寻目标、快速定位的理论依据，这些数据模型帮助计算机理解实体空间与模型空间的映射路径与拓扑关系。在此基础上就可以实现相对空间之间的距离的计算，坐标的确认、速度的转换、方向、角度等相关数据的交互。

1、概述

我们人类生存在四维的立体空间之中，在三维的立体空间中加上时间这一T维坐标系，就构成了整个人类的历史，我们无法穿越过去与未来，我们只能活在现在。虽然我们无法在四维空间中任意穿梭，但是，幸运的是，我们可以在三维空间中任意往来。也正是基于这一基本的需求，才导致了GIS的诞生。这种较为先进的空间系统可以通过数字化模型对空间中的任意一点进行定位、搜寻、分析。我们人类生存于其中的三维空间与任何其他的三维空间都一样，都可以分解为点、线、面这三种最常见的元素。我们每个人所在的位置就可以看做是一个点，那么两个点之间就可以连成一条线，而一整个区域，比如一片街区就可以看做是一个面，当然这个面在某种情况下也可以成为一个点。比全国的GIS系统中，比较小的城市就可以暂时看做一个点。打开这个点，一个城市的坐标系统就显现出来，这个点一瞬间就变成了一个面。点、线、面三者之间以及彼此互相之间还可以形成多达十三种的较为复杂的拓扑关系。这十三种关系之中，较为常用的有相邻、相交、相接、重叠、包含、分离等几种关系。这些关系是如此的复杂，以至于我们不得不将点、线、面这三种基本元素分开来加以讨论。因此本文将重点论述这三种基本元素之中的线元素，也叫线实体的相关问题。

线实体可以是包括直线、线段、弧、链、串、不规则线型、规则线型等在内的任何线实体。线实体的数学表示通常可以用函数f（x）来表示。在GIS中通常可以用线实体来标注线状的地形、线状的地貌、线状的道路、线状的河流等。线实体之间的系系就没有点、线、面三者之间的关系复杂。线实体之间的主要关系可以描述为自相交线检、重复线检查、伪节点检查、悬挂点检查与处理等。下面我们就分别对结的关系进行阐述。

2、悬挂节点的检查与处理

悬挂节点即指只与一条经相交的一个节点，这个节点即称之为悬挂节点。如果与该节点相交的不是一条线而是一条弧，则称这个弧为悬挂弧。悬挂节点的通常由于地图数字化时候的定位不准确，造成的定位误差。

（1）获取检查图层（Layer），確认是否为线图元图层，是则读入一条线图元（LineFeature），否则返回提示信息告知检验员。

（2）对读入的线图元，提取其两个端点数据（PointMin和PointMax），并分别进行是否为悬挂节点的判断。

（3）对每个端点，首先判断是否满足了悬挂节点的必要条件，即只与一条线图元相连接。判断的依据是对该端点做空间分析。

（4）在与该端点只与一条线图元相连接的情况下，这时有两种情况存在，一种确实为悬挂节点，而另一种则为线图元起始点或终止点。

（5）对判断出来的悬挂点进行错误记录，记录在错误信息列表中。

（6）判断读入的线图元的两个端点是否全部完成检查，如果还未全部完成。

（7）检查完成后，将错误信息以列表的形式告知检验员，由检验员通过人机交互的方式进行错误确认并改正。

3、伪节点的检查与处理

伪节点的定义：伪节点使一条完整的线变成两段，造成伪节点的原因常常是没有一次录入完毕一条线。

对于伪节点的自动检查算法：

（1）获取检查图层（Layer），确认是否为线图元图层，是则读入一条线图元（LineFeature）。

（2）对每个需要检查的线图元图层，需要确定该图层的主属性字段的名称。

（3）对读入的线图元，提取其两个端点数据（PointMin和PointMax），并分别进行是否为伪节点的判断。

（4）对每个端点，首先判断是否满足了伪节点的必要条件，即与多于一条线图元相连接。

（5）在与该端点连接的线图元大于一条的情况下，这时有两种情况存在，一种确实为伪节点，而另一种则为线图元起始点或终止点。

（6）对判断出来的伪点进行错误记录，记录在错误信息列表中。

（7）判断读入的线图元的两个端点是否全部完成检查，如果还未全部完成。

（8）检查完成后，将错误信息以列表的形式告知检验员，由检验员通过人机交互的方式进行错误确认并改正。

4、重复线的检查与处理

重复线的定义：如果同一层内，同类地物的边界被重复输入两次或多次，造成空间数据冗余并影响GIS分析的结果。粗线、细线分别代表两次数字化得到的结果，具体算法如下：

（1）获取检查图层（Layer），确认是否为线图元图层，是则读入一条线图元（LineFeature），否则返回提示信息告知检验员。

（2）对读入的线图元，提取其所有的组成节点数据，去除该线图元的首尾节点，将所有的非首尾节点存放于节点数组中（PointArray），并将节点总数记录于PointCount中。

结束语

4.基于GIS的海量气象数据预处理技术研究论文篇四

1 海量数据发展历史与现状

在当今的信息化时代, 信息量过大已成为我国各行各业所必须面对的问题。如何在庞大的信息中寻求对企业或者个人有用的信息来推动经济的发展, 已成为我国学者所共同关注的问题。要想让信息资源真正成为一个企业的经济推动因素, 只有通过将信息与该企业的业务发展和战略的运行相结合, 假如一味注重信息的筛选而抛开企业的实际情况来研究, 不但不能提高信息的使用效率, 还会对企业的绩效产生影响。在信息技术如此发达的今天, 企业只有通过完善信息系统的设计开发来制定项目的分析决策, 才能有效应对来自国内国外市场“数据信息量严重膨胀”的压力, 为此, 数据挖掘和知识发现技术在此背景下应运而生, 并且得以持续的发展, 在国家的经济发展中显示出重要的地位, 为企业带来了不可忽视的经济利益。由于篇幅问题, 笔者在此只介绍数据挖掘的相关内涵。

数据挖掘就是从大量的、不完全的、有噪声的、模糊的、随机的数据中, 提取隐含在其中的、人们事先不知道的、但又是潜在有用的信息和知识的过程, 就是从存放在数据库、数据仓库或其他信息库中的大量数据中挖掘有趣知识的过程。在学术界上, 与数据挖掘相关表达还有几个:如从数据库中发现知识、数据分析、数据融合以及决策支持等。人们将原始数据比作形成知识的源泉, 挖掘数据就好像是在矿石中进行采矿一样。原始数据主要有两种类型:一是结构化的, 就如关系型数据库中的数据;二是半结构化的, 就像我们计算机上常见的文本、图形和图像数据, 另外, 分布在网络上的异构型数据也属于半结构化的原始数据。常见发现知识的方法有四种:数学、非数学、演绎和归纳等。通过发现挖掘的知识可以运用于信息管理、查询优化、决策支持和过程控制等方方面面。可见, 数据挖掘是一门综合性的学科, 对于开发数据库和数理统计员等相关工作人员的要求都比较高。

2 海量数据储存与访问问题研究

采用较为先进的数据库管理技术和大容量存储管理技术, 在满足数据查询需求的前提下, 把所需的数据细分为近期、中期和远期三个不同的阶段来进行相应的管理, 常见的做法是, 把访问时间较近和较频繁的数据存储在磁盘阵列中, 并向这部分数据提供相对告诉的访问响应;同理, 把访问时间较远和访问的次数较少的数据存储在保存成本较低并且容量较大的扩展光盘库设备中, 在保证其运行速度不受影响的前提下使系统的运行成本降到最低。为了更好的实现数据储存管理的高效工作, 系统提供了对磁盘、光盘数据的一致性访问接口, 对系统中的数据提供统一、透明的访问机制:计算机系统同时为内部管理机制创造了数据迁移, 确保数据能够从磁盘以较高的透明性迁移到光盘。

目前, 我国对海量数据的访问, 采用比较原始的做法, 由相关的技术工作人员将已经存放至磁带上的数据倒回数据库, 根据数据使用者的意愿来查找所需要的记录, 这种查询方式一般是通过手工来完成也就意味着其运行效率比较低, 对人工成本的依赖比较大。此外, 由于查询范围和时间上都受到其他因素的限制, 历史数据的作用就不太明显。不少用户就希望通过在生产系统外建立起一个独立的历史数据归档和查询系统, 借此系统把历史数据进行自动归档, 并从主机上分离出来, 减轻主机的负担。当时, 这种分离工作要确保历史数据能够单独使用, 被用户直接访问。

3 海量数据的数据库处理研究

如今, 关系型数据库在众多类型的数据库使用得最为广泛, 成为了当今数据库的主流。关系型数据库最初的推出是为了满足基于主机/终端方式的大型机的使用, 因此其应用范围也是相当有限的, 但是随着计算机产业的发展, 客户机/服务器方式逐渐普及开来, 关系数据库便进入了客户机/服务器时代, 并且其发展空间得到极大的提升。随后, 在Internet的普及应用, Internet上信息资源所表现出来的冗杂性和欠规范性, 导致关系型数据库在进入网络市场时表现得较为滞后, 在面对网络上更加庞大的文档型和多媒体型数据资源, 其管理模式显然已无法跟上步伐。直到一段时间后, 关系数据库开始不断完善其自身的发展, 并满足过去的需求上作出了一定的调整, 比方说增加数据库的面向对象成分以增加处理多种复杂数据类型的能力, 增加各种中间件 (主要包括CGI、ISAPI、ODBC、JDBC、ASP等技术) 以扩展基于Internet应用能力, 同时可以利用应用服务器解释执行各种HTML中嵌入脚本的技术, 可以解决Internet应用过程中数据库在显示、维护和HTML格式转换等一系列问题。关系型数据库已经发展为基于Internet应用的模式, 常见的类型有一种三层或四层的多层结构。基于这种多层结构的体系, 关系数据库的发展得到了极大的进步, 解决了Internet应用方面的问题, 将关系数据库稳定地应用于网上各种资源的开发与利用。我国的信息化程度将会越来越高, 相信在不久的将来会有更加完善的数据库来取代当前的关系型数据库, 在迎接新的数据库诞生的同时, 做好信息技术的竞争准备。

4 结语

海量数据技术对于我国经济和社会的发展都起到了促进作用, 同时, 为我国的日常工作带来了极大的方便, 然而, 科技进步无止境, 我们要解决好当前海量数据处理技术上存在问题, 进一步来完善他的发展。

参考文献

[1]赵浩然.论数据分区对海量数据处理的必要性[J].科学之友, 2011 (22) .

[2]周开乐, 丁帅, 胡小建.面向海量数据应用的物联网信息服务系统研究综述[J].计算机应用研究, 2012 (1) .

[3]王桂强.海量数据分析处理方法的研究[D].上海:上海交通大学, 2010.

5.基于GIS的海量气象数据预处理技术研究论文篇五

关键词：海量数据存储;分布式数据库;MPP架构;并行处理

目前海量数据处理还是一个比较新的研究方向，大多数都是各公司或者是组织各自研究自己的处理方法，国际上没有通用的标准，研究的方式和结果也都是各有千秋。针对项目中带有复杂业务逻辑的海量数据存储，主要从容量扩展和并行处理两个方面考虑。前文己论述过NoSQL分布式数据库由于其数据结构简单、不善于做JOIN连接等复杂操作，存在数据迁移问题，并不适用于本项目，所以本解决方案依旧从关系型数据库入手。其次为了支持多样的切分策略，本论文将实现range、list、consis

tent-hash模式。最后系统借鉴MPP并行处理架构，使得整个项目能部署在便宜的PC集群上，不仅能保证稳定性，还节省项目成本。

物理设施包含数据库服务器的基础架构、web服务器的选择，以及资源分配管理服务器的选择。这三者分别负责数据的存取、数据的分析处理以及资源工作的均衡分配，它们协同合作，共同搭建一个高效的协同的后端服务管理，使存储系统均衡工作、高效运行。

作为解决海量数据的存储方案，首要必须考虑是存放海量数据的需求。根据前文可知，分布式数据库的出现其根本原因是解决存放不下数据的问题，故而将数据依照策略存放在不同的数据库服务器上，存放数据的策略以及数据之间的并行查询处理是研究的重点。第二个问题是分布式处理方案，现有技术从各个方面进行过尝试，有的基于关系型数据库提出了多种shard

ing方案。将关系型数据库迁移到非关系型数据库上代价太大，所以本解决方案基于关系型数据库的系统。

根据以上的设计思路与实现目标，设计出分布式海量数据存储解决方案。该系统主要包含以下四个模块：

SQL解析模块。SQL语句复杂、格式多样、形式多变，解析结果作为数据切分的依据。解析SQL语句的方法是编译成字节码，生成语法树，这种方式的优点是准确率高、数据层次清晰、结构正确，但设计到相关语法树知识，比解析字符串更难以理解。

数据分发模块。如果集群系统中没有进行数据切分，则多台数据库服务器存储的是完全一样的数据，这实际上是对硬件资源的浪费，也在同步数据保持一致上浪费了更多的时间和效能。而且一旦数据再上升一个等级，很可能一台服务器就无法存储下大量数据。所以合适的数据切分策略是迟早的，本解决方案将结合现有的数据切分策略，结合业务逻辑，提供多样的切分策略，并且预留切分接口使用户灵活地自定义自实现，系统的可用性更高。

并行处理模块。由分发服务器和多台数据库服务器构成。相对于集中式数据库来说，分布式査询代价需要考虑以下因素：

CPU处理时间，I/O消耗时间，还有数据在网络上的传输时间。在设计系统的时候，应该根据分布式数据库中各个数据库的地理位置的不同情况来设计。在局域网且传输率高的系统中，通信代价和局部处理的开销差别不大，在优化中则应平等对待;在数据传输率较低和通信网速度较慢的系统中，网络传输可能会比花费在查询中的CPU及I/O的开销更大，则应首要考虑优化网络通信。

汇总处理糢块。结果汇总大致分为两种情况：单机单库情况下，直接返回结果;多机多库的情况则需要在转发节点处进行一个汇总。

基于架构的工作流程大致如下：首先，转发节点收到客户端发来的SQL语句，将依据各个解析节点当前工作量、预计完成解析工作的时间、本条查询语句预估需要时间、历史响应需求时间等因素，将SQL语句转发给各个解析节点，对其进行语法解析。当所有的工作量都经过这个转发节点的时候，必然会产生高并发的问题。在存在多个分发节点的情形下，为了消除单个转发节点的性能瓶颈，本文设计多个分发节点，每个节点都可以将任务转发到不同的解析节点。采用RoundRobin策略将任务依次分发给每个解析节点，让工作量保持均衡。其次，解析节点解析本次查询的SQL语句，生成便于理解的SQL对象，通过调用相应的接口方法可以实现对SQL语句的操作。最后，各个数据库服务器执行了 SQL语句，便对查询结果进行一个汇总并返回，划分倘若是单机查询，那么处理的结果可直接返回给客户端。

SQL解析、数据切分以及转发归并的工作都由以上四个模块协同完成。

基于MPP架构的设计了关系型数据库的海量数据分布式存储解决方案。本章采用解析SQL语句、分发SQL语句，并行处理、归并汇总处理结果的方式完成整个框架。与MySQL

Cluster的区别在于采用的存储引擎就是MySQL，适应于本身就釆用MySQL进行存储的集中式数據库的改造，或是业务逻辑复杂的报表展示等，无论是业务的扩展，迁移都十分方便。

参考文献：

[1]姜宇鸣.海量数据存储系统研究.《电脑知识与技术》2011年08期

6.基于GIS的海量气象数据预处理技术研究论文篇六

目前，GIS得到了越来越广泛的应用，出现了多种多样的开发平台，如MapInfo、ArcInfo、GeoMedia等。但是，由于不同GIS平台并没有一个统一的数据表达的标准规范，开发的大部分系统又都是针对某一类特定的GIS数据集及其相关的应用而设计开发的，信息数据库和应用系统都是一一对应的关系，所以存在着大量的重复建设，难于实现数据共享和信息共享。随着网络技术的发展，把GIS应用当作一项服务来调用就成为GIS的发展方向，那么如何将异构的多数据源进行数据共享就变得越来越重要。Web Service技术以其平台独立、用户透明和轻松穿透防火墙及松耦合等特点为问题的解决提供了新的模式。

1 Web Service及相关协议

Web Service是构建互联网分布式系统的基本部件，它正成为企业应用集成(Enterprise Application Integration)的有效平台。人们可以使用互联网中提供的Web Service构建应用程序，而不必考虑这些Web Service是怎样运行的[1]。

Web Service使用SOAP协议实现应用与服务之间的通信,用WSDL文件对服务进行标准的描述。SOAP和WSDL都是基于XML的,同时SOAP一般使用标准的HTTP协议,因此可以透明地穿越合作企业防火墙。应用服务可以在Web上发布,发布的服务可以在UDDI上进行注册以便于被检索,满足了企业之间松散耦合的要求。

(1)SOAP简单对象访问协议,定义了Web服务参与者之间标准的交互协议,它的主要作用是为XML描述的消息提供一个简单统一的传输机制。

(2)WSDL服务描述语言,提供了一种描述服务接口的标准方法。它定义了一种描述接口的抽象语言,使服务的接口定义独立于底层协议和编码方式。

(3)UDDI通用描述、发现和集成,是分布式Web服务的信息注册规范。它提出了标准的规范,用来对Web服务提供动态注册功能。

(4)XML规范是Web Service的技术基础,XML采用文本标记的形式定义数据结构,利用标准的网络协议进行传输,使得数据层在XML技术的支持下统一起来。

它们之间的关系如图一所示。

2 OWS服务框架

OGC(Open GIS Consortium)是国际上比较早的对Web Service技术应用于GIS服务的理论和技术进行研究的组织。为了更好地将地理信息服务的概念扩展到网络上来，以Web Service的方式提供服务，OGC建立了OWS计划。OGC Web Services(OWS)指的是一个基于开放标准的在线地理空间服务框架,这个框架允许无缝集成在线地学处理和位置处理。它提供了一组通用接口和厂商无关的互操作框架，用来进行基于Web的发现、存取、集成、分析、利用和可视化地理数据、传感器感知的信息、位置信息和地学处理能力等,是在发布、查找、绑定模式下关于OGC各规范的一个总体框架[2]。

OWS服务框架可以分为以下五个部分:

(1)客户端应用服务:用户通过搜索和发现机制，查找GIS服务和地理空间数据资源。

(2)注册服务:提供一个通用机制来分类、注册、描述、查找、维护和访问网络资源信息、数据和服务。

(3)过程处理服务:对地理空间数据和元数据进行操作，并通过转换、综合和创造数据为应用提供增值服务。

(4)绘图服务:提供地理空间信息的可视化，可以接受一个或多个输入并产生地图渲染输出。绘制服务可以使用已经配置的好样式规划，也可以使用在运行时由应用服务动态指定样式规则。

(5)数据服务:空间数据服务是指能够通过网络直接提供原始空间数据的一种空间信息Web服务。

OWS服务框架中，对于GIS数据的获取，首先是以服务的方式用Web Service描述语言WSDL对服务进行描述，然后将这些服务进行注册，客户通过客户端应用服务使用搜索和发现机制来实现对这些服务进行调用。

3 基于Web Service的GIS数据共享模型

根据OWS服务框架，可将基于Web Service的GIS数据共享模型分为五层，分别为客户应用层、统一管理层、服务注册层、数据管理层、异构数据层，模型框架如图三所示[3]。

框架中对异构数据源的查询结果统一以GML的形式表达，GML是用XML对现实世界中地理特征对象的几何数据和属性数据进行编码,它继承了XML的特性,提供一个开放的、用来定义空间地理数据的框架，但只描述地图的“内容”(例如地图中对象的位置、几何形状、属性等)，而不提供如何显示这些地图数据的信息[4]。GML提供了与地理特征对象相应的几何元素,比如它可用Point元素编码Point几何类的实例,LineString元素来表示折线,Polygon元素表示多边形等。GML还提供几何属性的编码,这样可以对各种各样的地理空间信息解析和编码，使用GML还可以把不同的GML子文档按照一定格式整合。

客户端应用层集中了各种类型的与系统进行交互的用户终端组件,包括:地图查看器、影像利用客户、传感器客户等。

统一管理层是整个模型的控制中心。当有数据请求时,统一管理层将会在UDDI注册表中查找相应服务,每个服务信息代表了一个Web Service的调用实例。查找完成后，统一管理层再通过SOAP协议来找到对应服务的信息,再由搜索到的Web Service信息进行服务调用,也就是对异构数据源GIS数据访问的调用,最终获得用GML文档描述的GIS数据[5]。

服务注册层将各异构数据源所提供的服务用WSDL进行描述，然后在UDDI注册表上进行注册,使得各异构数据源能够把自身所提供的标准服务信息注册在对应的UDDI注册表上,以便统一管理层UDDI注册表搜索到自己需要的服务。如果有新的异构数据源加入的时候,只要该数据源实现了标准服务并且服务被注册,那么就可以实现统一管理层的自动调用,从而实现对异构数据的良好扩展性。

数据管理层负责将异构数据转换为统一的XML/GML的数据结构以实现数据共享。具体方法是采用基于XML的中介器系统[6]。中介器能够将查询分解，并能将查询结果根据查询的定义对异构数据库进行逻辑集成，并最终形成XML/GML文档形式的结果。

在整个集成模型中,Web Service的发布、发现和绑定都是在可扩展标注语言XML的基础上定义的。集成模型中的Web Service的调用(SOAP技术)、Web Service界面的描述(WSDL技术)以及Web Service的发现(UDDI技术),均使用XML作为对信息描述和交换的手段。

该模型的主要特征有以下几个方面:

(1)松散耦合性：建立在Web服务基础上的分布式系统具有很好的松散耦合性,当一个Web服务的实现发生变更的时候,只要Web服务提供的接口不变,Web服务内部发生的任何变化,对Web服务的调用者都没有任何影响。在系统中,开发人员可能会对Web Services进行更新,如果接口没有变化,那么对使用者不会有任何影响。

(2)完好的封装性：Web服务是一种部署在Web上的对象,具备对象的良好封装性,对于使用者而言,能且仅能看到该对象提供的功能列表及接口参数,不必也无法探究其实现细节。

(3)可以充分利用现有的网络和数据资源，实现异构数据源的集成和共享。

(4)利用XML和GML标准作为系统内部的统一格式，可以避免异构GIS数据源之间直接转换造成的数据损失，又有良好的可扩展性。

4 结束语

随着互联网的蓬勃发展，GIS领域异构数据源之间的数据传递和信息沟通变得越来越普遍，开发人员和广大用户都感到GIS数据共享的必要性。在这种情况下，Web Service给深受困扰的空间地理信息共享、互操作和集成问题带来了新的解决途径，是当前可以预见的最佳的解决方案。在未来的社会里，GIS软件将被服务所代替，GIS借助于Web Service方便地实现异构数据共享，将最终实现数字地球的战略构想。

参考文献

[1]柴晓路.Web Service架构与开放互操作技术[M].北京:清华大学出版社,2002.

[2]熊庆文,边馥苓.以应用服务器为中心的GIS多层体系结构研究[J].测绘信息与工程,2005,(01).

[3]李军怀,周明全,耿国华等.XML在异构数据集成中的应用研究[J].计算机应用,2002,9(22):18-24.

[4]王颖,刘国华,林亮亮.WebGIS中异构数据源的集成[J].计算机工程,2005,31(z1):122-124.

[5]邬伦,唐大仕,刘瑜.基于Web Service的分布式互操作的GIS[J].地理与地理信息科学,2003,19(4).

7.基于GIS的海量气象数据预处理技术研究论文篇七

海底声学探测技术[1]应用十分广泛, 在研究海底地形地貌、揭示地质结构和构造、研究第四纪地层层序、圈定工程地质单元、识别海底地质灾害等方面, 有着其它调查手段无法比拟的优势。由于使用的探测设备不同, 导致数据存储格式各异, 标准不统一, 甚至有些数据仅能在厂家提供的专用软件平台上进行处理和使用, 海底声学探测数据具有如下特点:格式标准不统一、数据类型复杂、数据量庞大、查询检索困难。针对目前声学探测数据的特点, 如何有效组织声学数据存储结构, 实现对声学数据查询检索多样化的应用需求, 是目前面临的主要问题。目前, 声学探测数据的管理方式较大多数采用传统文件管理, 即对采集的数据不做处理或只进行简单处理后整存整取, 这种管理方式虽然简单, 但是数据查询检索繁琐, 数据利用率比较低, 并且难以区分各种类型数据之间的关系, 资源浪费严重。因此, 研究一种方便检索以及调用声学探测数据的管理方法, 具有十分重要的意义。

一、GIS数据库

1.1 GIS定义。地理信息系统 (Geographic Information System, 简称GIS) 是一种特定的十分重要的空间信息系统。它是一种基于计算机的技术, 对整个地球表层的地理数据进行采集、存储、管理、运算、分析、显示和描述的软件系统[2]。GIS技术集合地图的视觉化效果与一般的数据库操作, 进行地理分析操作, 并结合相关的地理信息属性, 满足用户在地理空间信息方面的各种需要。

1.2 GIS数据库特点。一个系统的应用目的、数据类型决定了该系统的工作方式和数据库组成。GIS与一般管理信息系统最大的区别在于, GIS数据具有空间分布的特性, 即数据带有空间坐标属性。对于地理信息系统而言, 其数据不仅具有空间属性, 而且系统的分析和应用也都与地理环境直接相关。GIS的这一基本特征, 在数据的结构、数据库的设计、数据分析算法和系统的输入和输出方面具有深远影响。

数据库是在文件管理系统的基础上逐步发展形成的, 是数据管理的高级阶段, 它是为一定的目的服务, 并以特定的数据存储相关联的数据集合。GIS数据库 (或称地理数据库) 是对某一特定区域内一些地理特征要素的数据集合[3]。地理数据库是对空间数据有组织的集合, 它与普通数据库相比, 具有以下特征[4]: (1) 地理数据库不仅具有普通数据库数据性质相似的地理要素, 还有数据的地理要素空间分布位置的信息, 即坐标信息, 并且这两种数据信息之间联系紧密。 (2) 地理数据库十分复杂, 通过数据来描述各种地理要素, 在数据的空间位置信息方面, 其数据量尤其突出。 (3) 地理数据库的应用面十分广泛, 在地理研究、海洋探测、资源开发规划、市政管理、城市建设等方面都有所涉及。

通过对地理数据库上述特点的分析, 在建立GIS数据库时, 一方面应该学习一般数据库的在数据管理方面的原理和方法, 另一方面还必须开发一种特殊的技术, 来实现对数据空间信息的管理。

1.3 GIS数据库管理机制。根据地理信息数据的特点, 可将GIS数据分为地理空间数据和属性数据两大类, 对这两类数据的管理机制可以分为三种[5]: (1) 通过关系型数据库管理机制来对属性数据进行管理。地理空间数据以文件的形式进行存储, 由空间数据管理软件进行操作, 通过指针或关键字在地理空间数据文件和关系型数据库之间建立联系。 (2) 增加关系型数据库功能, 对其进行完善, 使关系型数据库能够同时管理属性数据和地理空间这两类数据。 (3) 将面向对象技术引入关系型数据库[6], 将数据库改造成对象关系型或纯对象数据库, 对象关系与底层数据分离, 空间属性与非空间属性平行处理, 对属性数据和空间数据进行一体化管理。

通过分析上述三种机制, 第一种分开管理属性数据和空间数据, 在数据的完整性和一致性方面不能保证;第二种对属性数据和空间数据统一管理, 但在处理地理数据进行空间分析方面存在缺陷;第三种方法最为合理, 实现了地理数据和空间数据的一体化管理, 同时以面向对象技术处理空间数据, 提高了运算效率。

二、声学探测数据管理系统

在GIS数据库研究的基础上, 结合声学探测数据格式多样、标准不一、数据量庞大大、难以查询检索的特点, 对声学探测数据的管理方法进行了深入探讨, 研究了一种关于声学探测数据管理的新方法, 即声学探测数据管理系统。

2.1功能。声学探测数据管理系统是专门为了管理声学数据而开发的系统, 功能结构可划分为三大部分, 分别为原始数据归档管理功能、图像化查询检索功能和产品成果数据管理功能, 每个大功能下由细分为多个小功能。

原始数据归档管理功能负责对原始数据进行格式的解编, 数据存储和性能优化处理, 使原始数据方便进行存储管理, 容易查询。

产品成果数据管理功能是对经过处理后的数据结果进行管理, 包括对产品成果的加载入库, 产品成果入库后的管理, 对数据结构的维护及报告报表的输出等子功能。

2.2特点。声学探测数据管理系统包含侧扫声呐、海洋地震、浅剖、多波束四种声学数据的存储与管理, 通过把声学原始数据完全关解编, 把单一的原始文件根据文件组成结构分解成一道 (Ping) 、一包的数据, 使用关系型数据库进行存储。

采取此种方式的好处是多方面的, 具体表现如下: (1) 数据查询检索方便, 更容易精确定位所需的数据。 (2) 无论测区还是测线都可方便进行统计管理。 (3) 测线轨迹管理, 在GIS系统中可直接显示测线轨迹, 可回放、导出测线轨迹。 (4) 原始数据文件重组, 可通过时间、起始Ping终止Ping等方式进行原始数据文件的重组。

2.3结构。数据库是整个声学探测数据管理系统中管理和储存数据的部分, 基于客户端/服务器 (C/S) 模式, 采用当今流行的关系型数据库[7], 建立不同的数据表, 并运用索引、视图优化等数据库技术[8], 使数据具有了空间地理属性, 提高了数据的管理和查询检索应用水平。数据库模型如图2-1所示。

近年来, 国外已经出现了以关系型数据库为模型的测线数据管理系统, 这种管理系统访问速度很快, 并且大部分已经商品化;而我国在此方面起步较晚, 还没有比较成熟的产品出现, 因此设计一种具有自主知识产权的、高效的数据库模型, 具有十分重要的意义。

原始数据库模型主要有两大模块组成:

(1) 数据存储模型:原始数据库。 (2) 数据访问模型:原始数据访问层。

三、关键技术

3.1格式解编。格式解编功能是对原始数据进行解编, 针对不同的数据格式, 将数据解编成易于存储的一包、一Ping的数据。主要分为以下三种标准格式的解编:侧扫声呐数据使用SSF数据格式 (Side Scan Sonar Data Format) 、海洋地震、浅剖数据使用MSSF数据格式 (Marine seismic and sub-bottom data standard format) 、声学探测数据管理系统中采用的数据文件格式为MBF格式。

为了便于数据的存储和管理, 数据的组织形式可以通过定义一些数据结构来表现, 这里所讲的结构是指C语言中的一种数据类型, 可以由用户自己定义。以SSF文件为例, 定义了如下的数据结构, 如表3-1所示。

3.2数据存储。声学探测数据是采用二进制进行存储, 因此在数据库中既要存储二进制结构化数据, 也需要从数据结构中提取必要的项进行存储。

原始数据的存储采用Mysql数据库[8], 采用Mysql作为数据库引擎最大的优点是存储速度快, 尤其是二进制格式的文件存储。经过我们大量的实践, 相对于Oracle数据库[9]无论二进制文件的存储还是读取, Mysql数据库的速度明显快于Oracle数据库。

3.3性能优化。 (1) 通过建立索引提高数据查询速度, 在不改变数据表物理结构的状况下, 直接访问特定的数据列, 大大节省了数据访问的时间。 (2) 对于汇交数据来说, 合理进行大数据表分割。 (3) 使用MYSQL集群技术[10,11]管理大量数据。My SQL集群是由多台计算机构成, 每一台计算机上都运行着多种数据处理进程, My SQL集群包括My SQL服务器、NDB集群的数据节点、管理服务器, 以及专门的数据访问程序。

四、结论

声学探测数据管理涉及C/S结构、Mysql数据服务器、业务系统运行工作站等多个环节, 需要解决一系列的技术问题, 才能实现对声学探测数据的方便式管理。

参考文献

[1]金翔龙.海洋地球物理研究与海底探测声学技术的发展[C].地球物理学进展, 2007:1243-1249.

[2]谢元礼, 胡斌.浅谈GIS的发展历程与趋势[J].北京测绘, 2001 (01) :10-13.

[3]陈军, 刘万增, 张剑清, 潘励.GIS数据库更新模型与方法研究进展[J].地理信息世界, 2008 (3) :85-89.

[4]刘颖, 李树军.GIS数据库与普通地理数据库[J].海洋测绘, 2001 (03) :52-54.

[5]张立人.GIS中几种数据管理方式的比较[J].测绘与空间地理信息, 2009 (01) :15-19.

[6]张莹.从关系数据库到面向对象数据库的发展概述[J].电脑知识与技术, 2011 (21) :43-47.

[7]孔冬艳.基于对象关系型空间数据库理论的GIS实现[D].中国地质大学 (北京) , 2006.

[8]李立功, 赵扬编著.My SQL程序设计与数据库管理[M].科学出版社, 2001.

[9]赵大力, 赵梅.Oracle数据库优化解决方案[J].石油化工自动化, 2005 (03) :35-37.