分类：
2008-04-24 10:44:34
spatial extender 提供了一个 index advisor，以帮助您调优空间索引。index advisor 可以通过命令行工具gseidx 访问，它的语法比较罗嗦，这一点跟 SQL 本身一样。该工具不仅可用于获得关于各种不同网格大小的建议，还可以用于收集一个已有的或计划中的（虚）索引的统计信息。所以，可以提取关于在选择某种网格大小时在哪个网格层次上将生成多少索引项的信息，而不必真正创建和物化索引。您应该注意到，Index Advisor 提供的建议可以作为索引优化的出发点。
清单 17. Spatial Extender index advisor 的示例输出
| $ gseidx "CONNECT TO testdb GET GEOMETRY STATISTICS FOR COLUMN roads(shape) USING GRID SIZES (0.5) SHOW HISTOGRAM WITH 10 BUCKETS" Number of Rows: 110979 Number of non-empty Geometries: 110979 Number of empty Geometries: 0 Number of null values: 0 Extent covered by data: Minimum X: -31.257690 Maximum X: 66.074104 Minimum Y: 34.824085 Maximum Y: 72.000000 Grid Level 1 ------------ Grid Size : 0.5 Number of Geometries : 110973 Number of Index Entries : 147461 Number of occupied Grid Cells : 6596 Index Entry/Geometry ratio : 1.328801 Geometry/Grid Cell ratio : 16.824287 Maximum number of Geometries per Grid Cell: 257 Minimum number of Geometries per Grid Cell: 1 Index Entries : 1 2 3 4 10 --------------- ------ ------ ------ ------ ------ Absolute : 82240 24962 236 3361 174 Percentage (%): 74.11 22.49 0.21 3.03 0.16 Grid Level X ------------ Number of Geometries : 6 Number of Index Entries : 6 Histogram: ---------- MBR Size Geometry Count -------------------- -------------------- 0.340000 105777 0.680000 4750 1.020000 334 1.360000 80 1.700000 22 2.040000 4 2.380000 5 2.720000 5 3.400000 2 $ gseidx "CONNECT TO testdb GET GEOMETRY STATISTICS FOR COLUMN roads(shape) ADVISE GRID SIZES" Query Window Size: Suggested Grid Sizes: Index Entry Cost: -------------------- ----------------------------- ---------------------- 0.01: 0.27, 0.54, 1.6 8.3 0.02: 0.27, 0.54, 1.6 8.7 0.05: 0.27, 0.54, 1.6 9.9 0.1: 0.27, 0.54, 1.6 12 0.2: 0.17, 0.51, 1.8 17 0.5: 0.17, 0.51, 1.8 40 1: 0.27, 0.68, 1.7 100 2: 0.43, 1.1, 2.2 290 5: 0.68, 2.4, 4.8 1300 10: 1.1, 5, 0 4500 20: 1.7, 10, 0 15000 |
如果您熟悉空间数据和网格索引，那么结果就无需解释了。关于空间网格索引机制和 Index Advisor 的更多细节可以在 DB2 Spatial Extender User's Guide and Reference（请参阅 参考资料 一节）中找到。值得一提的是，过去的经验表明，与精细调优的网格索引相比，根据空间属性聚集数据和使用一个适当定义的缓冲池更能对空间性能产生显著的影响 —— 只要索引的参数大致在适当的范围内。
选择表空间类型
如果有很多数据修改操作，而查询较少，那么应该将注意力放在好的写性能上。DB2 将数据库中的所有数据都放在表空间中。管理员可以选择表空间的类型和组成表空间的容器的类型。表空间的类型可以是 database managed（DMS）或 system managed（SMS），表空间类型的选择对空间数据的写性能有一定的影响。
建议为 LONG 数据选择 DMS 类型的表空间，换句话说，选择存放 LOB 的表空间。这样做的效果是，大对象化的空间数据将被放入到那个表空间。做出这一决定的原因在于 DB2 的内部工作原理。这可以以一种更异步的方式将 LOB 写到 DMS 表空间中，而将 LOB 写到 SMS 表空间则要求同步的文件 I/O。
一旦将数据放在 DMS 表空间上，就可以根据表空间的容器进一步选择是使用原始设备还是文件系统。对于大对象化的空间数据，通常使用文件系统更好一些。理由是：对基于容器的文件系统的访问要经过操作系统内核，而操作系统带有一个文件系统缓存，可以加快对文件的重复访问。而对原始设备的访问则没有缓存，导致物理设备上的直接读写操作。现在，对于一般的数据库操作，不必考虑文件系统缓存，因为 DB2 实现了缓冲池，这些缓冲池已经做了必要的缓存。但是对于 LOB 情况又不同了。由于不同的内部存储模型和潜在的巨大对象（大到 2GB），这里没有缓冲池。所以文件系统缓存可以很大程度上帮助避免对磁盘的读写操作。
性能比较
清单 18 展示了不同表空间类型的影响。首先在一个 SMS 表空间上执行导入操作，一次使用一个较小的 inline length，一次使用都以内联形式存储的空间值，然后在一个 DMS 表空间上再次使用不同的 inline length 设置重复上述过程。可以使用 tableCreationParameters 选项指定目标表空间。最后，在两个表（使用较小的 inline length）上运行空间查询，以显示查询性能不受表空间的影响。
清单 18. SMS 与 DMS 表空间的性能比较
| $ time db2se import_shape testdb -fileName /home/stolze/europe/roads -srsName WGS84_SRS_1003 -tableName roads_sms -tableCreationParameters "IN userspace1" -createTableFlag 1 -spatialColumn shape -typeName ST_LineString -inlineLength 292 -idColumn id -commitScope 1500 GSE0000I The operation was completed successfully. real 3m5.618s user 0m0.056s sys 0m0.026s $ time db2se import_shape testdb -fileName /home/stolze/europe/roads -srsName WGS84_SRS_1003 -tableName roads_sms -tableCreationParameters "IN userspace1" -createTableFlag 1 -spatialColumn shape -typeName ST_LineString -inlineLength 2000 -idColumn id -commitScope 1500 GSE0000I The operation was completed successfully. real 1m56.643s user 0m0.049s sys 0m0.026s $ time db2se import_shape testdb -fileName /home/stolze/europe/roads -srsName WGS84_SRS_1003 -tableName roads_dms -tableCreationParameters "IN dms" -createTableFlag 1 -spatialColumn shape -typeName ST_LineString -inlineLength 292 -idColumn id -commitScope 1500 GSE0000I The operation was completed successfully. real 0m49.310s user 0m0.053s sys 0m0.028s $ time db2se import_shape testdb -fileName /home/stolze/europe/roads -srsName WGS84_SRS_1003 -tableName roads_dms -tableCreationParameters "IN dms" -createTableFlag 1 -spatialColumn shape -typeName ST_LineString -inlineLength 2000 -idColumn id -commitScope 1500 GSE0000I The operation was completed successfully. real 0m38.766s user 0m0.054s sys 0m0.024s $ db2batch -d testdb -f test_tablespace.sql -i complete -s on --------------------------------------------- Statement number: 1 SELECT id FROM roads_sms WHERE db2gse.ST_Intersects(shape, db2gse.ST_LineString( 'linestring(10 50, 20 40)', 1003)) = 1 Prepare Time is: 0.000 seconds Execute Time is: 0.942 seconds Fetch Time is: 0.000 seconds Elapsed Time is: 0.943 seconds --------------------------------------------- Statement number: 2 SELECT id FROM roads_dms WHERE db2gse.ST_Intersects(shape, db2gse.ST_LineString( 'linestring(10 50, 20 40)', 1003)) = 1 Prepare Time is: 0.000 seconds Execute Time is: 0.953 seconds Fetch Time is: 0.000 seconds Elapsed Time is: 0.954 seconds --------------------------------------------- |
与 SMS 表空间相比，将数据插入 DMS 表空间上的表中花费的时间大约只有四分之一。在解释这些数值的时候，必须记住 DMS 和 SMS 表空间之间的基本不同点。DMS 表空间是在创建表空间时预先分配的。这意味着存放数据的页是已经存在的。而 SMS 表空间是在运行时动态伸缩的，导入操作会导致很多新的页被分配，同时表空间（和它的文件）也随之增长。所以，性能提升的很大一部分要归功于 DMS 上页的预先分配。但是，当比较使用不同 inline length 取得的运行时间时，我们发现，如果使用较小的 inline length（即更多的大对象化几何图形），那么将 SMS 换成 DMS 可以获得 73% 的性能提升。如果使用较大的 inline length，则性能提升只有 66%。所以附加的性能提升显然源自对大对象化数据更好的处理。
结束语
在本文中，我们展示了一些提升空间数据库性能的重要技巧。文中谈到了各种调优步骤，包括基本的系统调优，设置空间数据的 inline length，根据空间属性聚集一个表中的行，调优空间网格索引，以及选择适当的表空间类型。我们还解释了一些决策的原因，并给出了通用的指导原则。此外，我们还在一个非常简单的场景中演示了各个选项的效果。应用建议的指导原则所得到的结果取决于数据库中实际的数据，以及整个系统和数据库的配置。
