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