DB2 Spatial Extender 性能调优（2）

核心提示： 性能比较清单 18 展示了不同表空间类型的影响，首先在一个 SMS 表空间上执行导入操作，DB2 Spatial Extender 性能调优（2）(9)，一次使用一个较小的 inline length，一次使用都以内联形式存储的空间值，我们还在一个非常简单的场景中演示了各个选项的效果，应用

性能比较

清单 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，根据空间属性聚集一个表中的行，调优空间网格索引，以及选择适当的表空间类型。我们还解释了一些决策的原因，并给出了通用的指导原则。此外，我们还在一个非常简单的场景中演示了各个选项的效果。应用建议的指导原则所得到的结果取决于数据库中实际的数据，以及整个系统和数据库的配置。