· 金字塔
在對前面一些因素的分析中，我們始終採用了未創建金字塔的存儲數據進行討論。這並非是對金字塔可以提高瀏覽速度作用的故意無視，而是我們希望排除掉金字塔的影響來獲取我們需要的單個角度的信息。
現在，讓我們來看一下金字塔的原理。金字塔通過在不同的比例尺下預先進行重採樣並保存結果，避免了原始的柵格數據在小比例尺下實時重採樣的過程，因此，此舉能大大提高小比例尺下柵格數據的瀏覽效率。
圖 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的柵格函數