海量空间数据库实施策略-栅格数据 8

I. 设计策略示例

· 单幅大影像

数据源：单幅58.1G大小的NTF数据。

这是一个无压缩的DEM数据，虽然数据没有压缩，但是对于NTF这种数据格式直接访问的性能，我们未必有把握断言，因此，首先需要对这个数据本身读取的效率进行一定的度量。

参考前面的讨论和一些数据，我们知道一个4.72G大小的无压缩TIFF在数据分辨率下进行一个预览的耗时仅有0.08秒。现在首先来看一下这个近60G的无压缩NTF数据的效率：

图 10 使用Map Service Publishing查看出图效率

在栅格数据的分辨率比例尺下，通过预览工具进行渲染耗时0.05秒，可见，NTF格式无压缩数据的读取效率没有问题。

但是，该数据并没有金字塔，在小比例尺下的效率很低，因此，必须对其进行创建金字塔的操作。对于这个近60G的数据，创建全比例尺的金字塔耗时39分钟，生成了2G大小的金字塔。

直接用这个数据进行配图发布服务，使用50个并发用户进行动态出图的压力测试，可以达到5M/秒的吞吐量。

图 11 通过ArcGIS JavaScript API访问包含栅格数据的Map Service

· 多幅小影像

数据源：146幅总量23.3G的MrSID数据。

这是一个本身包含金字塔的压缩数据，其未压缩大小约为750G。在这里首先面临的一个选择就是，是不是需要解压这个数据？要做这个选择的前提是需要估计解压缩这个数据需要的时间、数据以后更新的频率和存储空间的富余情况。其中最重要的可能还是解压缩的耗时。

我们取其中一幅数据进行测试，其未压缩大小为5.2G，源数据大小为200M。测试将其解压为无压缩含金字塔的TIFF格式总共耗时1小时23分，这样保守估算所有数据如果导出为无压缩格式大概需要160小时（一周）。在这里，我只想将其作为底图，因此配置为地图服务后还会进行切片缓存，完全没有必要花这么多时间在数据解压上。

那么，接下来的工作就是直接基于MrSID数据了，因为数据分幅比较多，我们希望可以用更方便地方式进行管理。但是，我们不要导出数据，当然也不希望进行托管入库操作，因为托管的过程肯定比导出无压缩格式更加耗时。这时，我们就只有两个选择，一个是File Geodatabase结合非托管模式或Mosaic Dataset、另一个是ArcSDE结合Mosaic Dataset。

这里我选择ArcSDE，在ArcSDE中新建了一个Mosaic Dataset，然后将所有的MrSID数据直接添加到这个数据集中，耗时37分11秒，也就是说每大约15秒可以导入一个栅格的信息到这个Mosaic Dataset中。

在ArcGIS 10中，我们可以直接将这个Mosaic Dataset发布成Image Service，对这个服务使用50个并发用户进行动态出图的压力测试，可以达到2.5M/秒的吞吐量。

图 12 通过ArcGIS JavaScript API访问栅格数据发布的Image Service