海量空间数据库实施策略.pptx

海量空间数据库实施策略,吴泳锋刘锋,序言空间数据库设计矢量数据实施策略栅格数据的实施策略,内容,序言什么是GDB什么算是海量数据谁能胜任空间数据库设计矢量数据实施策略栅格数据的实施策略,内容,什么是GDB,用来存储，查询，管理空间数据的数据库或者文件PersonalGDB(access)FileGDBRDBMSDB2InformixOraclePostgreSQLSQLServer,什么数据算是海量？,数据量大？1TLayer,Why?,应用管理维护,谁能胜任,PersonalGDB(access)FileGDBRDBMSDB2InformixOraclePostgreSQLSQLServer,序言空间数据库设计设计流程数据建模数据组织矢量数据实施策略栅格数据的实施策略,内容,设计流程,数据建模,主要任务逻辑模型物理模型,数据建模,目标建立一套适合于自己应用的数据结构，包括表，关系，元信息，拓扑规则等工具Visio2002BLOB_SIZEPOINTS-2086Bytes130.375个,B表，S表，Index表空间分离,DBTUNEDB2UI_TEXT“UserInterfacetextforDEFALUTSB_RUNSTATSYESB_STORAGEinregtbsINDEXinidxtbsLONGINlobtbsOracle:UI_TEXTUserInterfacetextforDEFAULTSS_STORAGEPCTFREE0INITRANS4TABLESPACES_TBSGEOMETRY_STORAGEST_GEOMETRY“B_STORAGEPCTFREE0INITRANS4TABLESPACEB_TBS“B_INDEX_ROWIDPCTFREE0INITRANS4NOLOGGINGINDEX_TBS“,索引策略,属性索引空间索引GRID(DB2,OracleST_GEOMETRY,SQLSERVER)R-TREE(Informix,PostGSQL,OracleSDO_GEOMETRY),Grid索引,空间索引(GRID)调整策略,DB2gseidxOraclesdelayerosi_stats,索引调整策略,一级索引足够，除非你的Feature面积变化非常大索引的记录数/feature的记录数2每个网格中的Feature数量在100-300为最好，尽量不要超过4000一个Feature尽量不要跨越多个网格,CACHE策略1,PACKAGEPACKAGEBODYTYPETYPEBODYSEQUENCE(高并发编辑)USER_OBJECTSEXECDBMS_SHARED_POOL.KEEP(:NAME,:FLAG)?/rdbms/admin/dbmspool,CACHE策略2,索引表缓存ST_GEOMETRY-S_IDX$SDO_GEOMETRY-MDRT_ID$USER_INDEX_GEOM_METAALTERTABLETABLE_NAMECACHE.,存储大小(ORACLE),CACHE与非CACHE结果比较,单用户大比例尺浏览,多用户大比例尺浏览,序言空间数据库设计矢量数据实施策略栅格数据的实施策略,内容,栅格数据模型,Geodatabase中组织栅格的方式,RasterDatasetRasterCatalogMosaicDatasetFeature的栅格字段,ArcGIS10,RasterDataset与RasterCatalog,RasterDataset可以被认为是单幅栅格数据。单张影像导入多张影像导入Mosaic,RasterCatalog可以被认为是RasterDataset的集合,FileGDB中的RasterDataset,FileGDB中RasterDataset由若干个文件组成的主要在gdbtable文件中保存所有的栅格像素值,FileGDB中的RasterCatalog,在FileGeodatabase中创建RasterCatalog时有一个很重要的选项：管理类型MANAGED和UNMANAGED,MANAGED（托管）意味着所有的数据都将被“物理”地导入到Geodatabase中UNMANAGED（非托管）则对应将数据保存在文件中，而在Geodatabase中只存储指向这个真实数据的信息。如果选择托管方式，那么最后在FileGeodatabase中包含了若干组文件存储了这些RasterCatalog中的栅格数据的信息数据量最大的所有栅格的像素数据全部存储在其中的一个gdbtable中,从数据管理的角度上，非托管的模式导入数据非常快，因为它无需真正将数据存储到Geodatabase中；而托管模式意味着传统的“入库”，需要耗费相当的时间,ArcSDE中的RasterDataset和RasterCatalog,ArcSDE中不存在非托管的方式，所有的数据都必须物理地进行导入，但是在数据库中存在不同的存储类型。以Oracle为例，栅格数据可以以LONGRAW（将被Oracle废弃）、BLOB、ST_Raster或SDO_GeoRaster等类型进行存储。下面看看BLOB类型存储的RasterDataset和RasterCatalog在数据库中是如何组织的。,以BLOB存储的RasterDataset/Catalog在数据库中存储在若干张相互关联的表中，其中真正存储栅格数据的表包括：Auxiliary表、Block表、Band表和RasterAttribute表。,SDE_AUX_为Auxiliary表，它存储了颜色映射、图像统计信息等信息SDE_RAS_为RasterAttribute表，它存储了RasterDataset/Catalog中包含的“Raster”的属性，表中应该包含一条（RasterDataset）或多条（RasterCatalog）记录SDE_BND_为Band表，它存储了所有“Raster”的所有波段信息SDE_BLK_为Block表、它是真正存储栅格像素值的表，RasterDataset/Catalog中所有的栅格数据（包括金字塔）全部都以切片的形式存储在每一条记录中，一般这是数据最多的表。其中为RASTER_COLUMNS表中记录的RASTERCOLUMN_ID,MosaicDataset,在ArcGIS10中出现了一种新的数据模型MosaicDataset。在某种程度上有点类似RasterCatalog，可以管理多个栅格。不管是在FileGeodatabase还是在ArcSDE中，MosaicDataset都可以将数据保留在外部而仅在Geodatabase中保存数据的引用。在ArcSDE中，MosaicDataset模型其实就存储在一些相关的表中：,总的来说，在数据库中存储的MosaicDataset模型的数据量是很小的。,一些影响因素,压缩格式与压缩比,在导入栅格数据的时候，可以根据需要选择不同的压缩格式和压缩比常见的有无压缩、LZ77、JPEG、JPEG2000等对于有损压缩格式还可以选择不同的压缩质量对于不同的压缩格式和压缩比下的栅格数据的存储和质量，下面有一个简单的比较。,以一个4.72G大小的TIFF格式无压缩无金字塔的栅格数据为数据源，将其导出成若干个不同压缩格式和压缩比的数据：,大栅格数据无压缩文件存储的效率非常好,大栅格数据采用LZ77、JPEG等压缩文件存储的读取效率非常不好,LZ77压缩算法压缩非常有限,JPEG压缩算法选用75%的压缩质量是个比较好的平衡点,JPEG压缩算法不同质量的压缩耗时相差并不太大,FileGeodatabase存储大栅格数据，即使采用JPEG压缩读取效率也不会有太大下降,ArcSDE反而压缩存储比无压缩的性能要好，可见数据库存储栅格对性能影响最大的因素是读取数据的多少,栅格切片尺寸,在TiledTIFF或ArcSDE中，栅格是以切片形式存储的。ArcSDE中存储的SDE_BLK_表中，每条记录代表了一个切片。默认这个切片的尺寸大小是128128像素。,如果我们在导入栅格的时候选择的压缩方式为None或者默认的LZ77，数据（基本）没有被压缩。128128像素大小的一个栅格切片应该包含16K个像素。对于最常见的8Bit深度的栅格，每个像素占据1个字节；因此，这个切片将在数据库中占据16KB存储空间。,Oracle，默认创建数据库的数据块大小为8K。上面的切片占据了两个数据块，Oracle如果要读取这个切片就需要做2个I/O操作。在数据库中，I/O操作尽量需要减少，因此，所有都采用默认的设置可能并不符合实际的情况，特别是在数据量非常大的情况下。,其它存储格式,除了最常见的TIFF、JPEG等格式，栅格数据还可以以一些压缩格式进行存储，比如MrSID等。这些格式可能有惊人的压缩比和出色的读取效率。因此，在获取一些特殊的栅格存储格式的时候，最好可以比较一下它们和无压缩栅格的效率。,比如这里有一个17M的MrSID数据，将其导出为未压缩的TIFF后，两者的小范围数据预览比较如下：,非常高的压缩比，同时数据访问的效率也不错,金字塔,金字塔通过在不同的比例尺下预先进行重采样并保存结果。避免了原始的栅格数据在小比例尺下实时重采样的过程，因此，提高小比例尺下栅格数据的浏览效率。,从金字塔的原理可以知道，在与数据实际分辨率相近的比例尺下，金字塔并不能起任何加速显示的过程。因此，前面的章节中分析了没有金字塔情况下的各种现象，在这种情况下完全符合。同时，在创建了金字塔的比例尺下，前面的讨论也并非没有意义，它们同样也可以对金字塔本身的效率提供参考的价值。,分幅,一个大的栅格数据，到底是用单幅存储比较好呢，还是存为多幅较小的数据较好？换句话说，有时候拿到很多分幅的栅格数据，是不是有必要将它们都拼接起来？这里也进行一个比较。,比如用上面使用过的4.72G的大TIFF数据，分割成16幅同样以TIFF格式存储的栅格文件，分别进行全图预览和小范围预览的效率比较：,适度的分幅有助于提高大范围数据访问的效率。不过，如果创建了金字塔，两者的效率应该区别不大。另外，还会有压盖和色差的问题。,并发访问,对于使用文件形式存储的栅格，或许有人会对其在并发访问环境下的能力有所怀疑。在这里，分别使用文件、FileGeodatabase和ArcSDE存储相同的数据，在ArcGISServer上发布服务运行20个实例，然后比较他们在50个用户并发访问下的性能：,设计策略示例,单幅大影像,数据源：单幅58.1G大小的NTF数据。这是一个无压缩的DEM数据但是对于NTF这种数据格式直接访问的性能，我们未必有把握断言，因此，首先需要对这个数据本身读取的效率进行一定的度量。参考前面的讨论和一些数据，我们知道一个4.72G大小的无压缩TIFF在数据分辨率下进行一个预览的耗时仅有0.08秒。现在首先来看一下这个近60G的无压缩NTF数据的效率：,在栅格数据的分辨率比例尺下，通过预览工具进行渲染耗时0.05秒，可见，NTF格式无压缩数据的读取效率没有问题。,但是，该数据并没有金字塔，在小比例尺下的效率很低，因此，必须对其进行创建金字塔的操作。对于这个近60G的数据，创建全比例尺的金字塔耗时39分钟，生成了2G大小的金字塔。直接用这个数据进行配图发布服务，使用50个并发用户进行动态出图的压力测试，可以达到5M/秒的吞吐量。,多幅小影像,数据源：146幅总量23.3G的MrSID数据。这是一个本身包含金字塔的压缩数据，其未压缩大小约为750G。首先面临的一个选择就是，是不是需要解压这个数据？要做这个选择的前提是需要估计解压缩这个数据需要的时间、数据以后更新的频率和存储空间的富余情况。其中最重要的可能还是解压缩的耗时。,我们取其中一幅数据进行测试，其未压缩大小为5.2G，源数据大小为200M。测试将其解压为无压缩含金字塔的TIFF格式总共耗时1小时23分，这样保守估算所有数据如果导出为无压缩格式大概需要160小时（一周）。在这里，我只想将其作为底图，因此配置为地图服务后还会进行切片缓存，完全没有必要花这么多时间在数据解压上。,接下来的工作就直接基于MrSID数据。因为数据分幅比较多，我们希望可以用更方便地方式进行管理。但是，我们不要导出数据，当然也不希望进行托管入库操作，因为托管的过程肯定比导出无压缩格式更加耗时。这时，我们就只有两个选择，一个是FileGeodatabase结合非托管模式或MosaicDataset、另一个是ArcSDE结合MosaicDataset。这里我选择ArcSDE。,在ArcSDE中新建了一个MosaicDataset，然后将所有的MrSID数据直接添加到这个数据集中，耗时37分11秒，也就是说每大约15秒可以导入一个栅格的信息到这个MosaicDataset中。在ArcGIS10中，我们可以直接将这个MosaicDataset发布成ImageService，对这个服务使用50个并发用户进行动态出图的压力测试，可以达到2.5M/秒的吞吐量。,