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

· 金字塔

在对前面一些因素的分析中，我们始终采用了未创建金字塔的存储数据进行讨论。这并非是对金字塔可以提高浏览速度作用的故意无视，而是我们希望排除掉金字塔的影响来获取我们需要的单个角度的信息。

现在，让我们来看一下金字塔的原理。金字塔通过在不同的比例尺下预先进行重采样并保存结果，避免了原始的栅格数据在小比例尺下实时重采样的过程，因此，此举能大大提高小比例尺下栅格数据的浏览效率。

图 8 栅格金字塔的原理

但是，从金字塔的原理可以知道，在与数据实际分辨率相近的比例尺下，金字塔并不能起任何加速显示的过程，因此，前面的章节中分析了没有金字塔情况下的各种现象，在这种情况下完全符合。同时，在创建了金字塔的比例尺下，前面的讨论也并非没有意义，它们同样也可以对金字塔本身的效率提供参考的价值。

· 分幅

一个大的栅格数据，到底是用单幅存储比较好呢，还是存为多幅较小的数据较好？换句话说，有时候拿到很多分幅的栅格数据，是不是有必要将它们都拼接起来？这里也进行一个比较。

比如用上面使用过的4.72G的大TIFF数据，分割成16幅同样以TIFF格式存储的栅格文件，分别进行全图预览和小范围预览的效率比较：

压缩格式/压缩比	全图预览耗时	某小范围预览耗时
单幅	26.7秒	0.08秒
多幅（16幅）	17.7秒	0.08秒

可见，适度的分幅有助于提高大范围数据访问的效率。不过，如果创建了金字塔，两者的效率应该区别不大。另外，在实际情况中，本身分幅的影像应该会有压盖和色差的问题，通过拼接也可能减小存储的空间和提高访问效率。

· 并发访问

对于使用文件形式存储的栅格，或许有人会对其在并发访问环境下的能力有所怀疑。在这里，分别使用文件、File Geodatabase和ArcSDE存储相同的数据，在ArcGIS Server上发布服务运行 20个实例，然后比较他们在50个用户并发访问下的性能：

压缩格式/压缩比	单用户访问耗时	并发访问响应时间
文件（TIFF）	2.2秒	0.76秒
托管FileGDB（JPEG/75%）	20.3秒	2.13秒
ArcSDE（JPEG/75%）	20.3秒	1.78秒

可见，使用文件存储的栅格数据在并发访问的环境下不会有任何问题，其性能和单用户访问时一样都是比较好的。同时，虽然单用户访问下File Geodatabase和ArcSDE的性能差不多，但是在多用户并发情况下ArcSDE的性能会更好一些，这应该和数据库的缓存有关。

· 其它因素

在考虑栅格数据如何存储的时候，除了一些性能上的考虑，还必须考虑许多其它方面的因素。

比如，虽然在一些情况下不将栅格数据入库的效率可能较好，但是有些场合下可能还必须使用ArcSDE存储，因为ArcSDE可以提供安全、多用户访问、数据共享等方面的特性。

另外，比如Mosaic Dataset有时候性能不一定有预先镶嵌的Raster Dataset好，但是使用它可以保留所有的原始影像信息、同时使用各种类型多时相多分辨率的数据、方便地使用栅格计算函数、可以直接发布为Image Service，这些功能性的优势在很多场合下比单纯的访问性能好一点要重要得多。

图 9 使用Mosaic Dataset的栅格函数