Wann sollten Sie KEINEN räumlichen Index verwenden?


29

Ich frage dies, weil ich hauptsächlich mit Oracle gearbeitet habe, aber im letzten Jahr habe ich mich mit PostGIS und SQLServer 2008 verdoppelt. Die meisten räumlichen Funktionen in Oracle funktionieren nicht ohne einen räumlichen Index, der den ORA-13226-Fehler zurückgibt:

13226, 00000, "Schnittstelle ohne räumlichen Index nicht unterstützt" // * Ursache: Die Geometrietabelle hat keinen räumlichen Index. // * Aktion: Stellen Sie sicher, dass die Geometrietabelle, auf die im räumlichen Operator verwiesen wird, einen räumlichen Index enthält.

Für mich macht das Sinn. Sie führen eine räumliche Abfrage aus = Sie müssen einen räumlichen Index haben. Soweit ich weiß, ist dies jedoch weder für PostGIS noch für SQL Server erforderlich. PostGIS scheint sogar Funktionen zu haben (_ * zB _STContains), die den räumlichen Index AUSSCHLIESSLICH nicht verwenden.

Die Frage ist also: Gibt es Fälle, in denen Sie keinen räumlichen Index verwenden sollten? Nicht unbedingt, ob es sich um einen Take-It- oder einen Leave-It-Ansatz handelt, dh, er macht keinen Unterschied, aber wo wird die Leistung beeinträchtigt, wenn der räumliche Index NICHT verwendet wird? Für mich ist der letzte Satz ein Widerspruch, aber warum würde PostGIS sonst diese Funktionen bereitstellen?


3
Wenn Sie sehen möchten, wo ein Index die Dinge in PostGIS verlangsamt, SETze enable_seqscan = off. Dadurch wird PostgreSQL gezwungen, jedes Mal Indizes zu verwenden. Vergleichen Sie die Geschwindigkeiten damit.
Sean

Danke, dass du diesen Thread gestartet hast. Ich habe die Informationen im Internet überflutet und versucht herauszufinden, warum meine Organisation (Regierung) keine räumlichen (oder sogar Attribut-) Indizes für ihre Oracle / SDE-Feature-Classes und -Tabellen verwendet. Jetzt muss ich ihnen ein paar Argumente vorlegen, damit ich mir nicht die Haare aus dem Kopf reißen muss und darauf warte, dass sich eine Anfrage von selbst erledigt.
Mike

Antworten:


12

mapoholic,

Im Allgemeinen gibt es keinen Grund, eine räumliche Abfrage ohne räumlichen Index durchzuführen, es sei denn, Sie haben es mit wirklich kleinen Tabellen zu tun. Trotzdem würden Sie den ST_ verwenden, der keinen Index verwendet, aber die indizierbaren Kurzschlussboxoperatoren hat. Die Funktionen, die mit _ST beginnen, sind nicht für Endbenutzer gedacht. Der Grund, warum sie existieren, ist, weil sie müssen. PostGIS-räumliche Indizes verwenden SQL-Inlining, um die Verwendung des Index zu erzwingen - der _ST wird normalerweise von GEOS ausgeführt und der && ist der Index, der möglicherweise neu sortiert wird. Die _ST sind also wirklich ein Implementierungsartefakt.

Kurz gesagt, es ist keine einzige Funktion, sodass die Indexoperation so angeordnet werden kann, dass sie vor der intensiveren räumlichen Prüfung auf einmal erfolgt.


Prost LR1234567. Ich denke, das ist es, wonach ich gesucht habe.
Mapoholic

25

Wenn Ihr Dataset häufig hinzugefügt und aktualisiert wird, verlangsamen INSERT-, DELETE- und UPDATE-Anweisungen, die die Neuerstellung des Index bewirken, möglicherweise die Datenbank.

Bei Masseneinfügungen, z. B. beim Laden des gesamten OSM-Datasets in eine Datenbank, können die Indizes möglicherweise schneller gelöscht und anschließend neu erstellt werden.

Wenn es effizienter ist, einen Index zu ignorieren (zum Beispiel ist die Tabelle klein genug, um in den Speicher geladen zu werden), sollte der Datenbankabfrageprozessor dies automatisch tun.

Ich gehe davon aus, dass der Hauptgrund für die Ausführung von Abfragen ohne räumlichen Index darin besteht, den Leistungsvorteil zu messen, den Sie durch die Verwendung eines Index erzielen, ohne ihn löschen zu müssen.

Wenn Sie Abfragen und Kartenanzeigen eine enorme Leistungssteigerung bieten möchten, sollten Sie die Erstellung von Indizes zu einem günstigen Zeitpunkt in der Systementwicklung verschieben ...


3
(+1) Erkenne ich in dieser letzten Bemerkung einen kleinen Zynismus? :-)
whuber

Gar nicht ;-) Aber das Löschen / Neuerstellen sorgfältig abgestimmter Indizes ist eine nützliche Antwort auf die Frage "Warum wurde X viel Zeit für Datenbankänderungen aufgewendet?"
Geographika

Vielen Dank geographica- und ich stimme der Bemerkung von whuber zu! ;-) Ich verstehe, dass Sie räumliche Indizes beim Massenladen löschen / deaktivieren würden - oder alle Indizes für die Angelegenheit, aber Sie können sich keinen Grund vorstellen, warum Sie jemals eine räumliche Abfrage OHNE Verwendung eines räumlichen Index durchführen würden? Wenn eine Tabelle klein genug ist, macht die Verwendung des Index möglicherweise keinen Unterschied - fair genug -, aber wenn Sie sich dafür entscheiden, den Index nicht zu verwenden ?. Weiß nicht, ich glaube, die PostGIS-Funktionen, die keine räumlichen Indizes enthalten, haben mich nur noch mehr verwirrt ...
mapoholic

2
Wenn eine Tabelle klein genug ist und in den Arbeitsspeicher passt, ist für die Verwendung eines Index ein wahlfreier Datenträgerzugriff erforderlich, der teurer ist als die Ausführung eines sequentiellen Scans. wiki.postgresql.org/wiki/…
Sean

2
@mapoholic - die _ST_Contains konnten von übrig bleiben, als Sie manuell einen Vorfilter Ihrer Daten durchführen mussten, nach old.nabble.com/…
geographika

10

Ich denke , das wird angedeutet, aber ich würde nicht einen räumlichen Index für eine Abfrage verwenden , wenn ich einen nicht-räumlichen Index hatte , dass ich stattdessen verwenden könnte. Zum Beispiel habe ich 2.113.450 Punkte, die sich über die Vereinigten Staaten erstrecken und in eine Tabelle geladen sind. Wenn ich alle Punkte ziehen wollte, die sich im Bundesstaat Alaska befanden, konnte ich entweder eine räumliche Abfrage durchführen, die den GIST-Index für die Punktgeometrien verwendete, um sie mit der Geometrie des Bundesstaates Alaska zu vergleichen, ODER ich konnte sie nur verwenden Das Feld "state_alpha" in den Punktdaten (die ebenfalls indiziert sind), um alle Punkte mit "state_alpha" = "AK" zurückzugeben.

"Wo ist der räumliche Teil davon", fragen Sie? Wenn ich nach dem Sammeln weitere räumliche Analysen der Alaska_Punkte durchführen muss, ist es schneller, diese Punktgeometrien zuerst mit einer nicht räumlichen Abfrage zu erfassen. Dies bedeutet auch, dass Sie bei sehr großen Datenmengen vom Hinzufügen eines Nachschlagefelds (oder einer Tabelle) profitieren. Auch hier weiß ich, dass dies wahrscheinlich für jeden sofort offensichtlich ist. Ich erwähne es nur, weil ich es in der Vergangenheit mit globalen Datensätzen erlebt habe, die nur räumlich indiziert wurden und bei denen eine gemeinsame Abfrage "Alle Features in einem Land" lautete. Durch das Hinzufügen eines indizierten country_fips-Felds haben wir eine Menge Leistung gewonnen.

Nachfolgend einige Ergebnisse von EXPLAIN ANALYZE, die den Punkt belegen. (HINWEIS: Ich habe versucht, die räumliche Abfrage mithilfe einer BBOX-Abfrage so effizient wie möglich zu gestalten. Die Verwendung der Statuskonturen hätte sie nur verlangsamt.)

# explain analyze select count(*) from gnis_names where state_alpha = 'AK';
Aggregate  (cost=57359.45..57359.46 rows=1 width=0) (actual time=76.606.. 76.607 rows=1 loops=1)
<snip>
Total runtime: 76.676 ms

# explain analyze select count(*) from gnis_names where the_geom && GeomFromText('POLYGON((-179.14734 51.219862,-179.14734 71.3525606439998,179.77847 71.3525606439998,179.77847 51.219862,-179.14734 51.219862))',4326);
Aggregate  (cost=27699.86..27699.87 rows=1 width=0) (actual time=86.523..86.524 rows=1 loops=1)
<snip>
Total runtime: 86.584 ms 

vielen Dank dafür. Es mag offensichtlich erscheinen, wenn Sie es sagen, aber mein erster Gedanke wäre, eine räumliche Abfrage auszuführen, nicht nur ein Attribut. +1 dafür!
Mapoholic

0

Ich habe diese Aussage gerade bemerkt

Für mich macht das Sinn. Sie führen eine räumliche Abfrage aus = Sie müssen einen räumlichen Index haben

Für mich macht das überhaupt keinen Sinn und ich denke, dass sowohl SQL Server als auch Postgis einen besseren Job machen oder Sie zumindest nicht mit Leistungsdetails belästigen. Tatsächlich verwenden SQL Server und Postgis manchmal nicht einmal den räumlichen Index (kehren Sie zum vollständigen Tabellenscan zurück).

Für Oracle müssen Sie den Index erstellen und daher user_sdo_geom_metadata ausfüllen.

Wenn Sie dies nur mit alphanumerischen Indizes vergleichen, gibt es sie aus Leistungsgründen. Ihre SQL-Anweisung sollte mit und ohne sie funktionieren.

Wenn Sie den Index in einer Oracle-Datenbank löschen, werden zahlreiche Fehler und Apps angezeigt, die keine räumlichen Abfragen verwenden können und daher nicht funktionieren.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.