Massive Space database implementation policy-grid data 7

· Pyramid

In the analysis of some of the above factors, we have always used storage data without creating a pyramid for discussion. This is not a deliberate disregard of the pyramid's ability to increase the browsing speed. Instead, we hope to eliminate the influence of the pyramid to obtain information from a single angle we need.

Now let's take a look at the principle of the pyramid. By pre-sampling and storing the results at different scales, the pyramid avoids the real-time re-sampling process of the original raster data at a small scale. Therefore, this greatly improves the browsing efficiency of raster data at a small scale.

Figure 8 principle of the raster pyramid

However, we can see from the pyramid principle that, at a scale similar to the actual data resolution, the pyramid cannot accelerate the display process. Therefore, the previous chapter analyzes various phenomena without a pyramid, in which case they are fully compatible. At the same time, the above discussion is not meaningless when the scale of the pyramid is created. They can also provide reference values for the efficiency of the pyramid itself.

· Split

Is it better to store a large grid of data in a single place, or is it better to store a large number of small data records? In other words, is it necessary to splice a lot of raster data? A comparison is also made here.

For example, use the previously used GB big tiff data to split it into 16 raster files stored in the same TIFF format, and compare the efficiency of full preview and small-range preview respectively:

Compression format/compression ratio	Full graph preview time consumption	A small range of preview time
Single	26.7 seconds	0.08 seconds
Multiple (16)	17.7 seconds	0.08 seconds

It can be seen that a moderate split helps improve the efficiency of data access in a large range. However, if a pyramid is created, the efficiency of the two should be slightly different. In addition, in actual situations, the split image itself should have a problem of photo cap and color difference. Splicing may also reduce the storage space and improve access efficiency.

· Concurrent access

Some people may be skeptical about the ability to use the raster stored in the file format in the concurrent access environment. Here, we use files, file Geodatabase, and ArcSDE to store the same data, publish services on ArcGIS Server to run 20 instances, and then compare their performance with the concurrent access of 50 users:

Compression format/compression ratio	Time consumed by a single user	Concurrent access Response Time
File (TIFF)	2.2 seconds	0.76 seconds
Managed filegdb (JPEG/75%)	20.3 seconds	2.13 seconds
Armcsde (JPEG/75%)	20.3 seconds	1.78 seconds

It can be seen that the grid data stored in the file store does not have any problems in the concurrent access environment, and its performance is the same as that of single-user access. At the same time, although the performance of file Geodatabase and ArcSDE is similar to that of single-user access, the performance of ArcSDE is better under multi-user concurrency, which should be related to the database cache.

· Other factors

When considering how to store raster data, in addition to some performance considerations, we must also consider many other factors.

For example, in some cases, it may be more efficient not to store the raster data into the database, but in some cases, ArcSDE storage may be required, because ArcSDE provides security, multi-user access, data sharing, and other features.

In addition, for example, Mosaic dataset may not always have a pre-embedded raster dataset, however, you can use it to retain all original image information, use various types of multi-time and multi-resolution data, conveniently use raster computing functions, and directly publish them as image services, these functional advantages are much more important in many cases than simple access performance.

Figure 9 use the raster function of mosaic Dataset