Go to content Go to navigation and search

Home

Current Oracle Spatial Blog Articles


Search

Browse

RSS / Atom

Email me

textpattern

Creative Commons License
All Blog Articles, Data Models and Free Source Code by Simon Greener, The SpatialDB Advisor is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.

Effects of Sdo_Geometry Ordinate Precision on Performance

Monday April 02 2012 at 17:59

Keywordsperformance improvement ordinate size rounding oracle spatial
Summary

This article shows how the rounding of ordinates has a definite benefit in reducing storage costs and that this benefit passes over into performance improvements especially for sdo_geometry objects with a large number of vertices.

In a previous article I showed how too many digits of precision for the ordinates of an sdo_geometry object – stored in its sdo_ordinate_array – has an effect on storage volume.

In this article I will revisit the question of storage size while examining the effect that storage size has on performance (search and retrieval).

Approach – MultiPoint Sdo_Geometry Objects

The simplest way to create an experimental framework where one wants to examine sdo_ordinate_array ordinate precision on storage and performance effects, is to base one’s experiments on the generation and use of MultiPoint geometry objects as it is easy to generate valid sdo_geometry object of a specific size.

The generation of the multipoint objects is in two steps:

  1. The cells of a standard sized rectangular grid is created in memory
  2. For each cell in the grid a single multipoint geometry is created containing a variable number of randomly generated ordinates.

This looks like this in SQL:

  1. CREATE TABLE &MPTableName. (
  2.   id   NUMBER,
  3.   geom sdo_geometry
  4. ) nologging;
  5. -- Now insert points
  6. SET timing ON
  7. INSERT INTO &MPTableName.
  8. WITH grids AS (
  9. SELECT rownum AS id,
  10.        200000 + ( 100 * c.column_value ) AS minx,
  11.        100 AS rangeX,
  12.        600000 + ( 100 * r.column_value ) AS miny,
  13.        100 AS rangeY
  14.   FROM TABLE(codesys.geom.generate_series(0,99,1)) c,
  15.        TABLE(codesys.geom.generate_series(0,99,1)) r
  16. )
  17. SELECT rownum AS id,
  18.        MultiPointFromRandom(&pointCount.,g.minx,g.miny,g.rangex,g.rangey,NULL) AS geom
  19.   FROM grids g;
  20. SET timing off
  21. COMMIT;
  22. ALTER TABLE &MPTableName. LOGGING;

Note: The grids generated by the “grids” CTE are NOT stored in any way.

The function, MultiPointFromRandom(), is as follows:

  1. CREATE OR REPLACE FUNCTION MultiPointFromRandom(p_pointCount IN pls_integer,
  2.                                                 p_minx       IN NUMBER,
  3.                                                 p_miny       IN NUMBER,
  4.                                                 p_rangex     IN NUMBER,
  5.                                                 p_rangey     IN NUMBER,
  6.                   p_srid       IN NUMBER DEFAULT NULL)
  7. RETURN MDSYS.SDO_GEOMETRY DETERMINISTIC
  8. AS
  9.   v_ordinates mdsys.sdo_ordinate_array;
  10. BEGIN
  11.   IF ( p_pointCount IS NULL ) THEN
  12.      RETURN NULL;
  13.   END IF;
  14.   v_ordinates := NEW mdsys.sdo_ordinate_array();
  15.   v_ordinates.EXTEND(ABS(p_pointCount) * 2);
  16.   FOR i IN 1..p_pointCount LOOP
  17.       v_ordinates((i*2)-1) := round(dbms_random.VALUE(p_minx, p_minx + p_rangex),12);
  18.       v_ordinates((i*2)  ) := round(dbms_random.VALUE(p_miny, p_miny + p_rangey),12);
  19.   END LOOP;
  20.   RETURN mdsys.sdo_geometry(2005,p_srid,NULL,sdo_elem_info_array(1,1,p_pointCount),v_ordinates);
  21. END MultiPointFromRandom;
  22. /
  23. SHOW errors

After creation of the multipoints, the following occurs:

  1. Space usage of table and LOBs is computed
  2. SDO_GEOM Metadata and an RTree Index is created
  3. Performance statistics are generated using a function called RandomSearchByExtent

Next the tests are repeated but against an ordinate rounded version of the MultiPoint geometry data just created via:

  1. CREATE TABLE &MPTableName.R (
  2.     ID     NUMBER(10,0),
  3.     GEOM   MDSYS.SDO_GEOMETRY
  4. ) NOLOGGING;
  5. -- Create points by rounding the ordinates of the first table
  6. --
  7. INSERT /*+append*/ INTO &MPTableName.R (ID,GEOM)
  8. SELECT ID,CODESYS.ROUNDORDINATES(p.GEOM,2)
  9.   FROM &MPTableName. p;
  10. COMMIT;
  11. ALTER TABLE &MPTableName.R LOGGING;

All these steps have been put into a single SQL file called MultiPoint.sql.

Running the Tests

A set of tests are created which test multipoint geometries with a variety of sizes. Each test calls the single SQL file described above.

  1. @multipoint MP_250_O 250
  2. @multipoint MP_500_O 500
  3. @multipoint MP_1000_O 1000
  4. @multipoint MP_2500_O 2500
  5. @multipoint MP_5000_O 5000
  6. @multipoint MP_7500_O 7500
  7. @multipoint MP_10000_O 10000
  8. @multipoint MP_50000_O 50000
  9. @multipoint MP_100000_O 100000

After running the tests, the output CSV data was loaded into a spreadsheet and processed to create two graphs.

Graph One: Storage before and After Rounding

As can be seen, there is the potential for large savings in storage.

Graph Two: Percentage Performance Improvement After Rounding

Except for a few “outlying” results (250, 2500 and 5000), the results are encouraging. The effect on performance of ordinate rounding is muted for sdo_geometry objects with small vertex counts, but there appears to be a solid effect for larger objects that indicates that ordinate rounding could be considered “best practice” in spatial data management.

I hope this is of use to someone.
sql

Creative Commons License

post this at del.icio.uspost this at Diggpost this at Technoratipost this at Redditpost this at Farkpost this at Yahoo! my webpost this at Windows Livepost this at Google Bookmarkspost this to Twitter

Comment