Geodaten für Alle: Oracle Spatial: Toleranz und Performanz bei räumlichen Abfragen

In diesem Blogeintrag soll es um die Frage gehen, ob unterschiedliche Werte für den Toleranzparameter Einfluss auf die Performanz räumlicher Abfragen haben.

Die Datenbank arbeitet mit Toleranzen sowohl bei der Definition der SDO-Metadaten als auch bei räumlichen Abfragen. Die Toleranz steht dabei für den Abstand, den 2 (Stütz-)Punkte maximal haben dürfen, um sie als identisch anzusehen. Die Toleranz ist somit ein Mass für die Genauigkeit räumlicher Daten.

Testsituation

Um die anfangs aufgeworfene Frage zu beantworten, wurden zwei Testreihen aufgesetzt, bei denen verschiedene räumliche Funktionen mit skalierenden Toleranzen zur Anwendung kommen. Zwei Testreihen deshalb, um die Auswirkungen für einen relativ kleinen (~8.200 Sätze) und einen größeren Datenbestand (~830.000 Sätze) zu untersuchen.
Die Testdaten, ausschliesslich Polygone mit den 5-stelligen Postleitzahlgeometrien von Deutschland, wurden vom Oracle-Partner GfK GeoMarketing bereitgestellt. Das verwendete Koordinatensystem ist 8307, die Metadaten sind mit einer Toleranz von 0,05 (5 cm) registriert.

An räumlichen Funktionen wurden verwendet:

SDO_GEOM.RELATE
SDO_GEOM.SDO_ALPHA_SHAPE
SDO_GEOM.SDO_AREA
SDO_GEOM.SDO_BUFFER
SDO_GEOM.SDO_CENTROID
SDO_GEOM.SDO_CONCAVEHULL
SDO_GEOM.SDO_CONVEXHULL
SDO_GEOM.SDO_CONCAVEHULL
SDO_GEOM.SDO_DIFFERENCE
SDO_GEOM.SDO_DISTANCE
SDO_GEOM.SDO_INTERSECTION
SDO_GEOM.SDO_TRIANGULATE
SDO_GEOM.SDO_UION
SDO_GEOM.SIMPLIFY_GEOMETRY

Die Toleranz wurde angefangen mit dem Wert 0.1 (10 cm) pro Iteration verdoppelt bis zum Maximalwert von ~205 (m).

Für die Testsituation wurden nach dem Anlegen der Testtabellen aktuelle Statistiken berechnet.

begin 
  DBMS_STATS.GATHER_TABLE_STATS (
    ownname => '"GFK"',
    tabname => '"TEST_TOL_IMPACT"',
    estimate_percent => 100
  );
end;

Außerdem wurden bei jeder Iteration sowohl Shared Pool als auch Buffer Cache geleert.

alter system flush buffer_cache;
alter system flush shared_pool;
-- Hierfür benötigt der Nutzer alter system Recht

Dieses Vorgehen ist ausdrücklich nicht für produktive Umgebungen zu empfehlen, dient aber hier der Vergleichbarkeit der Ausführungszeiten.
Diese wurden gemessen, indem für jede räumliche Abfrage vorher als auch hinterher die Total Time sowie CPU Time mittels zweier PL/SQL Funktionen gemessen wurde.

-- Gesamtzeit
create or replace function measure_total_time 
return 
  pls_integer
is
begin
  return dbms_utility.get_time;
end measure_total_time;
/
-- CPU Zeit
create or replace function measure_cpu_time 
return 
  pls_integer
is
begin
  return dbms_utility.get_cpu_time;
end measure_cpu_time;
/
-- Für die Ausführung benötigt der Nutzer das Recht EXECUTE auf dem Package dbms_utility

Die Differenz der vorher und nachher gemessenen Werte jeweils geteilt durch 100 ergibt die Ausführungs- bzw. CPU-Zeit in Sekunden.

Alle Messwerte wurden in 2 Ergebnistabellen festgehalten, mit APEX-Bordmitteln ausgewertet und grafisch als 2D Line Charts mit je einer Serie pro räumlicher Funktion aufbereitet. Die Ergebnisse sind in den Abbildungen am Ende dieses Blogeintrags zu sehen.

Welche Erkenntnisse liefern die Messwerte?

Die Annahme, dass die Ausführungszeiten mit geringer werdenden Toleranzwerten (also höherer Genauigkeit) korreliert, hat sich bei keiner der räumlichen Funktionen bestät.
Die gemessenen Zeiten für Testreihe 2 (~830.000 Sätze) sind vergleichbar mit denen von Testreihe 1 (~8.200 ätze).
Mit gemessenen CPU-Zeiten bis maximal 0,3 sec und durchschnittlichen Gesamtzeiten von 1,3 (Testreihe 1) und 1,5 (Testreihe 2) waren die Abfragen trotz flush shared_pool und flush buffer_cache recht performant.
Als Testsystem diente ein 64bit Laptop mit Intel i5 Prozessor und 4 GB als maximaler SGA Grösse.

An dieser Stelle möchte ich noch mal darauf hinweisen, dass im Gegensatz zu den Ausführungszeiten die jeweiligen Ergebnismengen nicht im Fokus der Tests standen.