VC6.0在32位机中对大数据量文件操作扩展.docVIP

VC6.0在32位机中对大数据量文件操作扩展 　　摘 要：目前，随着计算机在各个产业部门的逐渐普及、计算机运算能力的逐步提高以及各种新型需求的诞生，对文件存储以及访问的需求也随之升高，人们已经不能满足于基于兆级的数据文件的访问，更大的数据文件的访问和支持能力对开发人员提出了更高的要求，但是，受计算机硬件条件、系统软件的版本以及软件开发版本的约束，我们并不能大刀阔斧的对软件进行彻底修改，否则会对软件的兼容性造成非常严重的危害，因此我们需要针对不同情况来分别对各种大型数据进行遍历，从而保证软件在不同配置的计算机上能够顺利运行。 　　关键词：新型需求 彻底修改 遍历 　　中图分类号：TP3 文献标识码：A 文章编号：1672-3791（2013）01（b）-0024-01 　　在石油及矿产勘探领域，经常使用不同方式对地层进行探测，随着探测手段日益增强，衍生出的数据量也越来越大，从早期的几十兆到现在的几个G的级别，不仅对计算机的要求日益提高，同时对软件开发人员也提出了更高的要求：开发人员要花费大量精力来优化内存以及CPU的使用，并且还要针对一些数据结构不能操作大型数据进行扩展。本文针对某油田测井数据格式的大数据量文件的操作，分别阐述了几种不同情况的处理方法。 　　本程序是基于VC6.0开发的，其运行环境为32位Windows系统。 　　1 修改数据描述格式 　　首先，我们需要面对的是数据格式不能满足需求的问题，对所有标识文件数据块大小的字段进行类型的修改，原有的代码中没有考虑到大数据量的可能性，对数据块大小的描述都是采用的整型int型或长整型long格式，由于采用的是有符号整型，所以其只能标识-2147483648～2147483648的文件块大小，这对于一般的线性数据块大小是足够的，但是对于大范围的波列数据以及矩阵类型数据的描述就捉襟见肘了。本程序采用了一种叫做ULONGLONG的据格式，该格式为无符号64位数据格式，理论上可以达到0～18446744073709551616的存储长度，这样的话对于任意可能存在的数据长度，该格式都是足够描述的。 　　2 采用内存映射 　　其次，我们采用了内存映射方式来克服大块内存的分配问题：对于内存分配，我们的数据格式是连续存储的，对于每块特定的数据内容，其读取和写入也必须是连续的，因此在处理大数据量的数据操作时，常常会遇到需要分配巨大内存空间的问题，而对于32位操作系统，系统本身可识别的内存仅为4G，除掉其他程序耗费掉的内存，系统在分配大内存空间上就显得力不从心，即使能够分配成功，其程序的执行效率也会变得极低。除此之外，在多次处理大数据量的数据过程中，还发现了一个特殊的现象，即Windows系统中的内存碎片是影响内存分配的，我们在分配大数据量的内存前，如果已经有一些进程运行，那么可能会把整个的内存空间打破，如果这些破碎的内存任何一块不足以分配我们所需的内存空间，则系统无法分配内存，从而导致内存分配失败，为此我们采用了内存映射的手段来克服大数据量数据的操作难题，过程如下。 　　（1）首先我们把需要操作的数据文件File1进行一个复制操作，生成一个新的临时文件File1Copy。 　　（2）然后声明一个内存映射对象CMem MapFile mmf。 　　（3）声明一个指针，用来指示共享内存中的文件位置LPVOID pDataVoid。 　　（4）用CMemMapFile对象打开临时文件if（mmf.MapFile（tempName，TRUE，FILE_SHARE_READ）） 　　{pDataVoid=mmf.Open（）；} 　　（5）使用pDataVoid指针可以任意读取数据，并且可以把难以分配的大块数据空间进行分割操作，从而获得较好的运行效率。 　　（6）数据操作完毕，删除临时文件，释放mmf.UnMap（）。 　　通过使用内存映射，我们有效的规避的大块内存分配的瓶颈，同时可以使得读取和写入文件更加灵活。 　　3 采用CFile64遍历文件 　　目前巨大文件越来越多，对于本软件所需要操作的数据文件，由于大量的波列和矩阵数据的加入，突破G的文件也是越来越多，甚至有很多已经达到了MFC中CFile类可操作数据的上限4GB，原因是CFile类中使用了32位整型来处理文件，从而导致了最大处理能力仅为4GB，为了能够处理这种巨大的文件，我们采用了一种CFile64的文件读取类，该类继承于CFile，对其中的整型数据int转换为ULONGLONG格式，并且对其中的Seek、Read、Write函数进行了重载，从而使得CFile64理论上能够支B的文件操作，这显然完全能够胜任我们的需求，对于CFile64类的使用与原有的MFC中的标准CFile