在幾乎所有的數(shù)據(jù)庫系統(tǒng)中，使運行在系統(tǒng)上的工作負載取得良好的性能是一項十分重要的任務(wù)。依靠 IBM DB2 Spatial Extender 的幫助，你可以在數(shù)據(jù)庫中將空間數(shù)據(jù)和你希望存儲的其他數(shù)據(jù)無縫的集成在一起。該擴展器提供了一組數(shù)據(jù)類型來表示空間信息。但是，DB2 Universal Database™（DB2 UDB）數(shù)據(jù)庫引擎還不能識別空間數(shù)據(jù)的確切屬性，并且也沒有提供內(nèi)建的專用數(shù)據(jù)類型。所以，在為獲得最佳性能而調(diào)優(yōu)空間數(shù)據(jù)庫時，需要比通常調(diào)優(yōu)其他 DB2 UDB 數(shù)據(jù)庫時考慮更多的東西。本文介紹了在使用 DB2 Spatial Extender 時應(yīng)該考慮的基本優(yōu)化步驟，并對此作了具體解釋。簡介DB2 UDB for Linux®、UNIX® 和 Windows® 從 7.1 版開始就提供了 DB2 Spatial Extender，用于支持空間數(shù)據(jù)的存儲、治理和修改（請參閱 參考資料 一節(jié)，下載 DB2 Spatial Extender）。可以用專用于空間信息及其屬性的結(jié)構(gòu)來擴展已有的數(shù)據(jù)類型。對于每個數(shù)據(jù)庫系統(tǒng)，無論它支持的功能有多好，假如不能為構(gòu)建在系統(tǒng)上的應(yīng)用程序提供所要求的性能，就毫無價值。因此，性能調(diào)優(yōu)是一項非常要害的任務(wù)。這不僅是數(shù)據(jù)庫治理員的任務(wù)，也是應(yīng)用程序開發(fā)人員的任務(wù)。DB2 UDB 已經(jīng)提供了各種各樣的工具來幫助調(diào)優(yōu)和監(jiān)視系統(tǒng)，例如“Configuration Advisor和“Design Advisor。它們都可以通過 Control Center 訪問。DB2 Spatial Extender 附帶了一個 Index Advisor，可以用它來優(yōu)化包含空間數(shù)據(jù)的列上定義的索引。然而，索引調(diào)優(yōu)只是性能調(diào)優(yōu)的一部分，還可以通過調(diào)整其他一些參數(shù)來提高空間操作的性能，例如 inline length、聚集或表空間類型。在下面幾節(jié)中，我們將解釋其中每個參數(shù)，并展示它們相對于未經(jīng)修改的系統(tǒng)的效果。我們在一臺配有 1.2 GHz CPU 和 1 GB 物理內(nèi)存的 IBM ThinkPad T30 上進行了評測。操作系統(tǒng)是 SUSE Linux 9.3，所有評測都基于帶 FixPak 9 的 DB2 UDB Version 8.2。請注重，我們沒有執(zhí)行實際的基準測試，而是集中在單個更改上，這樣做只是為了展示特定調(diào)優(yōu)選項的效果。您不能簡單地將結(jié)果中顯示的數(shù)據(jù)與其他系統(tǒng)進行比較。 12345678910下一頁 基本性能調(diào)優(yōu)在任何性能調(diào)優(yōu)過程中，第一步是為系統(tǒng)取得一個良好的基線。運行 DB2 Configuration Advisor 對該任務(wù)有所幫助（請參閱 參考資料 一節(jié)，獲得對 DB2 Configuration Advisor 的介紹和關(guān)于調(diào)優(yōu)數(shù)據(jù)庫性能的信息）。可以從 Control Center 中通過右鍵單擊一個數(shù)據(jù)庫來啟動 Configuration Advisor，如圖 1 所示。圖 1. 啟動 Configuration Advisor您只需回答關(guān)于整個系統(tǒng)的一些簡單問題，在任何情況下您應(yīng)該都知道這些問題。下面是這些問題的一個簡化列表，并提供了我們作出的選擇，后者以 斜體 顯示。從我們的選擇中可以看出，我們從一開始就關(guān)注性能。您具有的場景可能要求不同的選擇，例如對于鎖和恢復(fù)方面的問題就是如此。您想將多少內(nèi)存用于 DB2 實例？ 809 MB（80%）。您將執(zhí)行更多的數(shù)據(jù)倉庫操作，還是執(zhí)行更多的事務(wù)性操作？ 都有。您的事務(wù)是長還是短？一分鐘預(yù)期有多少事務(wù)？ 較短的事務(wù)；一分鐘 60 個。對您來說，更快的恢復(fù)與更快的事務(wù)哪個優(yōu)先？ 更快的事務(wù)。數(shù)據(jù)庫已經(jīng)包含了數(shù)據(jù)嗎？ 還沒有包含數(shù)據(jù)。本地和遠程連接的平均數(shù)量是多少？ 平均 5 個本地連接，2 個遠程連接。您想使用哪種隔離級別？ Cursor stability （更少的鎖）。在回答這組問題之后，Configuration Advisor 將提供對建議修改項的總結(jié)。現(xiàn)在您可以立即應(yīng)用建議的修改，或?qū)⒁粋€任務(wù)保存在任務(wù)中心。您應(yīng)該檢查每一項修改，確定它們對系統(tǒng)是否有意義。假如想根據(jù)自己的需要進行調(diào)整，那么可以在任務(wù)中心創(chuàng)建一個包含配置修改的任務(wù)，然后按照自己的需要修改任務(wù)腳本。在系統(tǒng)上運行 Configuration Advisor 之后可以得到如圖 2 所示的結(jié)果。最值得注重的是對缺省緩沖池大小的修改。增加緩沖池大小通常是提高系統(tǒng)整體性能的最重要的決定，因為它指定可以將多少數(shù)據(jù)緩存在內(nèi)存中，從而減少對（較慢的）磁盤 I/O 的需要。 上一頁1234567下一頁 圖 2. Configuration Advisor 的建議其他更改主要針對將可用內(nèi)存劃分出一些必要的緩存，例如包緩存和編目緩存，或者調(diào)整短事務(wù)的設(shè)置（日志記錄和排序）。除了減少輔助日志文件的決定之外，所有更改都將被接受，不需任何人為干涉。我們將輔助日志文件的數(shù)量設(shè)為 10，以避免在空間導(dǎo)入操作期間可能發(fā)生的問題。取決于您的系統(tǒng)以及在那組問題中給出的答案，您得到的建議可能不同。性能比較首先在一個新安裝的系統(tǒng)上，在應(yīng)用建議的配置更改之前，我們運行一組空間操作。這些操作的執(zhí)行時間通過操作系統(tǒng)命令 time 或 DB2 的 db2batch 工具來測量。最后，我們清除數(shù)據(jù)庫，應(yīng)用 DB2 Configuration Advisor 建議的配置，并重復(fù)相同的操作。為得到比較可靠的結(jié)果，我們多次執(zhí)行導(dǎo)入操作和查詢，對測量到的時間取平均值。這些空間操作如下所示：使用 Spatial Extender 命令行工具 db2se 從 DB2 Spatial Extender 附帶的第一張 Data & Maps CD 中將 shapefile 文件 europe/roads.shp 導(dǎo)入一個名為 ROADS 的表中。執(zhí)行一個空間操作，該操作使用一個簡單的空間查詢將這個表中所有的幾何圖形與一個固定的 linestring 進行比較。在空間列上創(chuàng)建一個網(wǎng)格索引。清單 1 展示了確切的步驟和它們產(chǎn)生的性能結(jié)果。可以在 下載 一節(jié)中找到 SQL 腳本 test_config_advisor.sql。清單 1. 未調(diào)優(yōu)的數(shù)據(jù)庫上的空間操作$ time db2se import_shape testdb -fileName /home/stolze/europe/roads-srsName WGS84_SRS_1003 -tableName roads -createTableFlag 1-spatialColumn shape -typeName ST_LineString -idColumn id-commitScope 1500 -messagesFile /home/stolze/import.msgGSE0000I　The operation was completed successfully.real2m19.086suser0m0.050ssys 0m0.021s$ db2batch -d testdb -f test_config_advisor.sql -i complete -s on---------------------------------------------Statement number: 1SELECT idFROM　 roadsWHERE　db2gse.ST_Intersects(shape, db2gse.ST_LineString(　'linestring(10 50, 20 40)', 1003)) = 1Prepare Time is:　 0.000　secondsExecute Time is:　 1.248　secondsFetch Time is: 0.000　secondsElapsed Time is:　 1.248　seconds---------------------------------------------Statement number: 2CREATE INDEX roads_grid_index ON roads(shape)　 EXTEND USING db2gse.spatial_index(0.27, 0.54, 1.6)Elapsed Time is:　 25.503 seconds--------------------------------------------- 上一頁12345678下一頁 注重，測試系統(tǒng)使用的配置是次優(yōu)的，因為導(dǎo)入的數(shù)據(jù)是從與數(shù)據(jù)庫和數(shù)據(jù)庫日志在同一個硬盤驅(qū)動器上的文件中讀取的。因而，讀操作與日志寫和緩沖池中的數(shù)據(jù)頁的寫操作之間存在競爭。可能需要將各種特定于磁盤的任務(wù)分配到不同的文件系統(tǒng)上。當(dāng)使用 DB2 Spatial Extender 導(dǎo)入工具導(dǎo)入 shapefile 文件時，建議不要嘗試直接從 CD 裝載數(shù)據(jù)，而是先將它復(fù)制到一個硬盤上。CD-ROM 驅(qū)動器不是很適合讀 shapefile 文件的訪問模式，因此整個操作的速度會急劇降慢。在應(yīng)用了 Configuration Advisor 的建議之后，重復(fù)前面列出的步驟就產(chǎn)生了清單 2 中的結(jié)果。可以看到，僅僅是導(dǎo)入操作的性能就提高了 11%，查詢的速度快了 28%，甚至創(chuàng)建索引所花的時間也只有之前的 90%。所以不應(yīng)當(dāng)忽視最基本的性能調(diào)優(yōu)。清單 2. 調(diào)優(yōu)后的數(shù)據(jù)庫上的空間操作$ time db2se import_shape testdb -fileName /home/stolze/europe/roads-srsName WGS84_SRS_1003 -tableName roads -createTableFlag 1-spatialColumn shape -typeName ST_LineString -idColumn id-commitScope 1500 -messagesFile /home/stolze/import.msgGSE0000I　The operation was completed successfully.real2m2.848suser0m0.051ssys 0m0.027s$ db2batch -d testdb -f test_config_advisor.sql -i complete -s on---------------------------------------------Statement number: 1SELECT idFROM　 roadsWHERE　db2gse.ST_Intersects(shape, db2gse.ST_LineString(　'linestring(10 50, 20 40)', 1003)) = 1Prepare Time is:　 0.000　secondsExecute Time is:　 0.895　secondsFetch Time is: 0.000　secondsElapsed Time is:　 0.895　seconds---------------------------------------------Statement number: 2CREATE INDEX roads_grid_index ON roads(shape)　 EXTEND USING db2gse.spatial_index(0.27, 0.54, 1.6)Elapsed Time is:　 22.980 seconds--------------------------------------------- 上一頁123456789下一頁 DB2 內(nèi)部對空間數(shù)據(jù)的處理空間數(shù)據(jù)可能變得非常復(fù)雜，需要很多空間來存儲一個幾何圖形中各個點的信息。例如，表示整個美國的區(qū)域的幾何圖形由 60 個多邊形組成，總共有 198569 個點來定義那些多邊形。按照 Spatial Extender 內(nèi)部格式，這個幾何圖形的完整定義要使用 0.9 MB 的磁盤空間（使用了壓縮）。假如幾何圖形按照 ESRI 幾何圖形格式編碼，那么它實際上需要 3.1 MB 的磁盤空間（請參閱 參考資料 一節(jié)，了解關(guān)于 ESRI 幾何圖形格式的更多信息）。所有信息封裝在一個 ST_Geometry 值中，這意味著這個值在數(shù)據(jù)庫中也需要大約 1 MB 的磁盤空間。另一個例子是只表示一個點的空間值。對于 X 和 Y 維，我們只有用于兩個浮點值的 8 個字節(jié)。將一個點表示成 ST_Point 值會增加一些開銷，但是我們談?wù)摃r仍然當(dāng)作是幾個字節(jié)。DB2 表中一個行中存儲的所有值的總大小不能超過表空間的頁寬。一個例外是大型對象（LOB），它最大可達 2 GB。DB2 支持的最大頁寬是 32K。所以存儲需要 1 MB 空間的幾何圖形需要類似于 LOB 的存儲機制。但總是為點數(shù)據(jù)使用那種機制就過分了。為了解決千差萬別的需求，DB2 實現(xiàn)了一種用于存儲空間數(shù)據(jù)（或通常的結(jié)構(gòu)數(shù)據(jù)）的混合方法。假如一個空間值超過了某個大小（即所謂的 inline length），那么這個值就被存儲為 BLOB。否則，這個值就存儲為 VARCHAR FOR BIT DATA 值。下一節(jié) 將具體討論如何為空間列設(shè)置 inline length，以及通過更改設(shè)置可以獲得的好處。之后，我們討論 空間數(shù)據(jù)聚集，為 編寫空間 SQL 查詢、調(diào)優(yōu) 空間網(wǎng)格索引 提供指南，最后我們解釋假如經(jīng)常要修改數(shù)據(jù)，則建議使用哪種 表空間類型。設(shè)置空間列的 inline length在 上一節(jié) 中，我們解釋了 DB2 存儲需求多變的空間數(shù)據(jù)的內(nèi)部機制。確定幾何圖形是存儲為 VARCHAR FOR BIT DATA 還是 BLOB 的決定因素就是所謂的 inline length，這個參數(shù)適用于任何表中的空間列。假如空間值的內(nèi)部表示需要的字節(jié)數(shù)少于 inline length 設(shè)置中指定的值，那么它將以 內(nèi)聯(lián)（inline） 的方式存儲為 VARCHAR FOR BIT DATA。否則，這個值將被 大對象化（lobify），并在該表的 LONG 表空間中存儲為 LOB。 上一頁12345678910下一頁 應(yīng)該記住，以內(nèi)聯(lián)方式存儲數(shù)據(jù)比以大對象化方式存儲數(shù)據(jù)要可取得多。原因是，內(nèi)聯(lián)的數(shù)據(jù)當(dāng)作 VARCHAR FOR BIT DATA 對待。這個值與同一行中所有其他屬性一起存儲在一個數(shù)據(jù)頁中。一旦數(shù)據(jù)存儲在那樣一個頁上，那一頁將通過緩沖池來訪問，這樣可以利用先進的緩存技術(shù)，從而盡量避免文件 I/O。而對于 LOB 則截然不同，它總是直接從磁盤讀取。所以經(jīng)驗法則非常簡單：將 inline length 設(shè)置得盡可能高，以便讓盡可能多的空間值以內(nèi)聯(lián)方式存儲。當(dāng)然，實際情況并不像看上去的那么簡單。高的 inline length 值告訴 DB2 空間值實際上可以在單獨一行中占用很多字節(jié)。每一行的最大大小要受到針對表定義的頁寬和屬性（列）的限制。例如，假如有一個頁寬為 4 KB（4096）的表空間，那么一行的最大大小不能超過 4005 字節(jié)（請參閱 參考資料 一節(jié)，了解關(guān)于 SQL 限制的更多信息）。假如這個表有一個不能為空的 INTEGER 列和一個可以為空的 VARCHAR(100) 列，再加上一個空間列，那么最多可以將 inline length 設(shè)置為 4005 - 6 - 4 - (1+2+100) - 1 = 3891，其中 6 個字節(jié)用于行的前綴，4 個字節(jié)是 INTEGER 列需要的空間，(1+2+100) 個字節(jié)是為 VARCHAR(100) 預(yù)留的，最后 1 個字節(jié)用于空間列的 NULL 指示符（請參閱 參考資料 一節(jié)，找到關(guān)于數(shù)據(jù)庫對象和 CREATE TABLE 語句的一本書）。可以看到，其他列的長度和 inline length 實際上是相互競爭的。為了進一步增加 inline length，可以將表放在頁寬為 8K、16K 甚至 32K 的表空間上。這樣，對于之前的例子，就可以分別將 inline length 設(shè)為 7987、16179 或 32563 字節(jié)。inline length當(dāng)在數(shù)據(jù)庫中創(chuàng)建一個新的結(jié)構(gòu)類型時，DB2 將根據(jù)類型定義中指定的屬性計算那個數(shù)據(jù)類型的缺省 inline length。可以在系統(tǒng)編目視圖 SYSCAT.DATATYPES 的 INLINE_LENGTH 列上找到一個結(jié)構(gòu)類型的缺省 inline length。假如在 CREATE TABLE 或 ALTER TABLE ... ADD COLUMN ... 語句中定義表的列時沒有顯式地指定 inline length，那么將沿用缺省值。 上一頁234567891011下一頁 可以使用 ALTER TABLE ... ALTER COLUMN ... SET INLINE LENGTH ... 語句修改（增加）已有空間列的 inline length。除非通過 REORG TABLE 語句 加 LONGLOBDATA 選項重組存儲在表中的數(shù)據(jù)，否則這種修改只影響 DB2 編目和隨后的數(shù)據(jù)修改。假如值的大小小于新的 inline length，那么這個重組過程將把大對象化的空間值轉(zhuǎn)換成內(nèi)聯(lián)值。選擇適當(dāng)?shù)?inline length在將所有空間數(shù)據(jù)存儲到 32K 的表空間上并且將 inline length 設(shè)置成盡可能大的值之前，應(yīng)該首先分析您的數(shù)據(jù)實際上有多大以及其他參數(shù)可能對頁寬產(chǎn)生的影響。假如只有 ST_Point 值，那么每個點將需要最多 245 字節(jié)的物理存儲，如清單 3 所示。在這種情況下，甚至 減少 inline length 更有幫助，因為可以使用更小的頁寬和/或在表中使用更多的列。但是要注重，ALTER TABLE 語句只答應(yīng)增加 inline length。假如想使用更小的值，那么必須在創(chuàng)建表的時候指定。Spatial Extender 導(dǎo)入過程答應(yīng)顯式地為空間列指定 inline length。在結(jié)構(gòu)類型中嵌套 LOB雖然 points 屬性被定義為 BLOB，但是 DB2 并不會單獨地存儲它。相反，整個幾何圖形信息（包括 BLOB 數(shù)據(jù)）都存儲在一起 —— 至于存儲為內(nèi)聯(lián)值還是大對象化值，則取決于列的 inline length。結(jié)構(gòu)類型的實現(xiàn)使所有屬性值并置到一個二進制流中，任何添加的必要的元信息和產(chǎn)生的二進制流在物化（也就是存儲到一個表中）的時候，或者存儲為內(nèi)聯(lián)值，或者存儲為大對象化值。這種方法使任何處理 LOB 的應(yīng)用程序可以以內(nèi)聯(lián)方式存儲短的 LOB 值，并利用 DB2 的緩沖池。清單 3 展示了如何計算每個幾何圖形在以內(nèi)聯(lián)方式存儲時需要多少磁盤空間。我們假設(shè)所有幾何圖形都存儲在一個名為 SPATIAL_DATA 的表的 GEOMETRY 列中。第一個查詢使用 LENGTH 函數(shù)。該函數(shù)顯示以內(nèi)聯(lián)方式存儲的值的寬度。假如是大對象化的值，那么它顯示引用實際值的定位符的寬度。所以只有知道所有空間值都是內(nèi)聯(lián)值時，才可以放心地使用該函數(shù)。因此，下面的查詢根據(jù)空間數(shù)據(jù)類型的屬性來計算數(shù)據(jù)的寬度。關(guān)于屬性的信息可以從 DB2 編目視圖 SYSCAT.DATATYPES 和 SYSCAT.ATTRIBUTES 獲得。假如空間數(shù)據(jù)是使用結(jié)構(gòu)類型實現(xiàn)的，那么在 SQL Reference 中關(guān)于 CREATE TYPE 語句的解釋中提到的判定結(jié)構(gòu)類型值寬度的法則同樣適用（請參閱 參考資料 一節(jié)，了解關(guān)于 CREATE TYPE 語句的信息）。具體地說，ST_Geometry 類型定義 16 個屬性，它的子類型都沒有添加自己的屬性。除了三個屬性外，所有屬性都是所謂的 短屬性。其中兩個非短屬性 anno_text 和 ext 沒有被使用，第三個非短屬性 points 包含內(nèi)部編碼為 BLOB 的幾何圖形信息。除了實際的數(shù)據(jù)外，DB2 需要維護強制的 null 指示符（1 個字節(jié)）和長度信息（4 個字節(jié)）。因此，幾何圖形的大小可以通過公式 “32 + 16*10 + 5 + LENGTH(points) = 197 + LENGTH(points) 得出。 上一頁3456789101112下一頁 清單 3. 幾何圖形的空間需求-- maximum space requirement for spatial point dataCREATE TABLE test ( p db2gse.ST_Point INLINE LENGTH 3800 )@INSERT INTO test VALUES ( db2gse.ST_Point( 1234567890123456, 1234567890123456, 1234567890123456, 1234567890123456, 0) )@SELECT LENGTH(p) FROM test@1-----------245　1 record(s) selected.-- determining the size of all geometries in a tableSELECT 197 + LENGTH(geometry..points)FROM　 spatial_data@-- calculating #geometries that would be stored inline/lobified-- for a given inline lengthSELECT SUM(inline) AS inline, COUNT(*) - SUM(inline) AS lobifiedFROM　 ( SELECT CASE　 WHEN 197 + LENGTH(geometry..points) <= <inline_length>　 THEN 1　 ELSE 0END FROM　 spatial_data ) AS t(inline)@性能比較為了演示小的 inline length 與大的 inline length 的效果，我們首先將 shapefile 文件 europe/roads.shp 導(dǎo)入到一個 inline length 為 292 的表中。這是 DB2 答應(yīng)的最小值。接著運行一個 SQL 腳本，該腳本確定有多少幾何圖形以內(nèi)聯(lián)方式存儲，有多少幾何圖形必須以大對象化的方式存儲。然后測量執(zhí)行一個簡單空間查詢的時間，并顯示在執(zhí)行期間產(chǎn)生的語句快照的一個摘錄，以揭示影響性能的最突出的因素。整個過程在 inline length 為 2000 的情況下再重復(fù)一遍，2000 這個值足以導(dǎo)致那個 shapefile 文件中的所有幾何圖形都以內(nèi)聯(lián)方式存儲。下載 一節(jié)中包含了我們運行 db2batch 時使用的腳本 test_inline_length.sql。 上一頁45678910111213下一頁 清單 4. 不同 inline length 設(shè)置的效果$ time db2se import_shape testdb -fileName /home/stolze/europe/roads-srsName WGS84_SRS_1003 -tableName roads -createTableFlag 1-spatialColumn shape -typeName ST_LineString -inlineLength 292-idColumn id -commitScope 1500GSE0000I　The operation was completed successfully.real3m15.604suser0m0.050ssys 0m0.026s$ db2batch -d testdb -f test_inline_length.sql -i complete -s on---------------------------------------------Statement number: 1SELECT SUM(inline) AS inline_storage,　 COUNT(*) - SUM(inline) AS lobified_storageFROM　 ( SELECT CASE　 WHEN 197 + LENGTH(shape..points) <=　 ( SELECT inline_length FROM　 syscat.columns WHERE　colname = 'SHAPE' ANDtabname = 'ROADS' )　 THEN 1　 ELSE 0END FROM　 roads ) AS t(inline)INLINE_STORAGE LOBIFIED_STORAGE　-------------- ---------------- 8959521384---------------------------------------------Statement number: 2SELECT idFROM　 roadsWHERE　db2gse.ST_Intersects(shape, db2gse.ST_LineString(　'linestring(10 50, 20 40)', 1003)) = 1Prepare Time is:　 0.000　seconds　Execute Time is:　 0.854　seconds　Fetch Time is: 0.000　seconds　Elapsed Time is:　 0.855　secondsBuffer pool data logical reads　 = 16818Buffer pool index logical reads　= 19731Direct reads = 3088Direct read requests = 1544Direct read elapsed time (ms)= 18---------------------------------------------$ db2 "DROP TABLE roads"$ time db2se import_shape testdb -fileName /home/stolze/europe/roads-srsName WGS84_SRS_1003 -tableName roads -createTableFlag 1-spatialColumn shape -typeName ST_LineString -inlineLength 2000-idColumn id -commitScope 1500GSE0000I　The operation was completed successfully.real1m57.212suser0m0.049ssys 0m0.027s$ db2batch -d testdb -f test_inline_length.sql -i complete -s on---------------------------------------------Statement number: 1SELECT SUM(inline) AS inline_storage,　 COUNT(*) - SUM(inline) AS lobified_storageFROM　 ( SELECT CASE　 WHEN 197 + LENGTH(shape..points) <=　 ( SELECT inline_length FROM　 syscat.columns WHERE　colname = 'SHAPE' ANDtabname = 'ROADS' )　 THEN 1　 ELSE 0END FROM　 roads ) AS t(inline)INLINE_STORAGE LOBIFIED_STORAGE　-------------- ----------------1109790　---------------------------------------------Statement number: 2SELECT idFROM　 roadsWHERE　db2gse.ST_Intersects(shape, db2gse.ST_LineString(　'linestring(10 50, 20 40)', 1003)) = 1Prepare Time is:　 0.000　secondsExecute Time is:　 0.792　secondsFetch Time is: 0.000　secondsElapsed Time is:　 0.792　secondsBuffer pool data logical reads　 = 17337Buffer pool index logical reads　= 19731Buffer pool index physical reads = 0Direct reads = 2Direct read requests = 1Direct read elapsed time (ms)= 0--------------------------------------------- 上一頁567891011121314下一頁 從結(jié)果中可以看出，對于重要操作，較大的 inline length 可以增加 40% 的速度，對樣本數(shù)據(jù)的查詢也快了 7%。這兩種差異的底層原因是，當(dāng)使用較小的 inline length 時，有超過 20000 個幾何圖形（大約 20% 的數(shù)據(jù)）以大對象化的方式存儲。DB2 直接從磁盤讀（寫） LOB 數(shù)據(jù)。而在第二種場景中，大部分的直接讀是不需要的，因為可以用存儲在緩沖池中的內(nèi)聯(lián)數(shù)據(jù)來滿足查詢。注重，大對象化的數(shù)據(jù)所占的 20% 的比例實際上不算很壞。假如由于稍微復(fù)雜一點兒的幾何圖形導(dǎo)致更多的數(shù)據(jù)不能以內(nèi)聯(lián)方式存儲，那么這里演示的差異還要大大增加。聚集空間數(shù)據(jù)根據(jù)某個屬性聚集數(shù)據(jù)是一種常見的、也是非常有用的技術(shù)，這種技術(shù)可以物理地組織一個表的數(shù)據(jù)。通過對底層的觀察可以發(fā)現(xiàn)，具有相似值的數(shù)據(jù)經(jīng)常一起被訪問。所以，可以將類似的數(shù)據(jù)存儲在接近的位置，使得對那些數(shù)據(jù)的訪問不必分散到表空間中很多不同的頁上，而是分布在臨近的幾個頁上。根據(jù)空間數(shù)據(jù)的空間屬性或幾何圖形間的距離聚集空間數(shù)據(jù)是很自然的。空間查詢是展示局部數(shù)據(jù)訪問（換句話說，現(xiàn)實中臨近的幾何圖形經(jīng)常被一起訪問）的最好例子之一。例如，假如您看一個城市的街道地圖，那么很可能對那個城市的所有街道感愛好，而對地區(qū)另一邊某個其他城市的街道不感愛好。所以在物理上將那個城市的一些行存儲在相鄰的位置的確很有意義。在 DB2 中建立數(shù)據(jù)聚集屬性的方法是根據(jù)一個索引對表進行重組。然而，假如由于空間索引的復(fù)雜性質(zhì)導(dǎo)致 DB2 REORG TABLE 命令不理解空間索引，事情就不會那么輕易了。關(guān)于這個問題有一個輕易的方法，即使用一個列，這個列的值是根據(jù)涉及的圖形計算的。這個列上聲明的數(shù)據(jù)類型必須保證 DB2 能在這個列上創(chuàng)建一個本地 B- 樹索引。這里使用空間填充曲線來保存空間和拓撲屬性（請參閱 參考資料 一節(jié)，找到 H. Sagan 撰寫的書籍）。我們在幾何圖形上取一個點，即形心點， 計算那個點在空間填充曲線上的值，并將結(jié)果存儲在一個附加的列中。最后，在附加列上創(chuàng)建一個索引，并根據(jù)那個索引對表進行重組。 上一頁6789101112131415下一頁