언제 공간 인덱스를 사용해서는 안됩니까?

나는 주로 Oracle과 함께 일했기 때문에 이것을 묻고 있지만 지난 1 년간 PostGIS와 SQLServer 2008을 두 배로 늘 렸습니다. Oracle의 대부분의 공간 함수는 공간 인덱스가 ORA-13226 오류를 반환하지 않으면 작동하지 않습니다.

13226, 00000, "공간 인덱스없이 인터페이스가 지원되지 않습니다"// * 원인 : 기하학 테이블에 공간 인덱스가 없습니다. // * Action : 공간 연산자에서 참조 된 지오메트리 테이블에 공간 인덱스가 있는지 확인하십시오.

나에게 이것은 의미가 있습니다. 공간 쿼리를 실행합니다. 공간 인덱스가 있어야합니다. 그러나 내가 이해하는 한 SQL Serve가 아닌 PostGIS는 이것을 요구하지 않습니다. PostGIS는 공간 인덱스를 명시 적으로 사용하지 않는 함수 (_ * 예 : _STContains)를 가지고있는 것 같습니다.

따라서 공간 인덱스를 사용해서는 안되는 경우가 있습니까? '수용하거나 떠나는'접근 방식 일 필요는 없습니다. 즉, 차이를 만들지 않지만 공간 인덱스를 사용하지 않는 경우 성능이 저하되는 위치는 무엇입니까? 나에게 마지막 문장은 용어의 모순이지만 PostGIS가 왜 이러한 기능을 제공합니까?

마포 홀릭,

일반적으로 말해서, 실제로 작은 테이블을 다루지 않는 한 공간 인덱스없이 공간 쿼리를 수행 할 이유가 없습니다. 여전히 인덱스를 사용하지 않지만 && 인덱서 블 단락 상자 연산자가있는 ST_을 사용합니다. _ST로 시작하는 기능은 최종 사용자가 사용하도록되어 있지 않습니다. 그들이 존재하는 이유는 그들이 있어야하기 때문입니다. PostGIS 공간 인덱스는 SQL 인라인을 사용하여 인덱스를 강제로 사용합니다. _ST는 일반적으로 GEOS에 의해 수행되며 &&는 재정렬 될 수있는 인덱스입니다. 따라서 _ST는 실제로 구현 아티팩트입니다.

즉, 하나의 기능이 아니라 더 강렬한 공간 확인 전에 인덱스 작업을 한 번에 모두 수행하도록 순서를 다시 지정할 수 있습니다.

데이터 세트가 자주 추가되고 업데이트되는 경우 인덱스를 다시 작성하는 INSERT, DELETE 및 UPDATE 문으로 인해 데이터베이스 속도가 느려질 수 있습니다.

전체 OSM 데이터 세트를 데이터베이스에로드하는 것과 같은 대량 삽입의 경우 인덱스를 더 빨리 삭제하고 나중에 다시 작성할 수 있습니다.

인덱스를 무시하는 것이 더 효율적인 경우 (예 : 테이블이 메모리에로드되기에 충분히 작은 경우) 데이터베이스 쿼리 프로세서가이를 자동으로 수행해야합니다.

공간 인덱스없이 쿼리를 실행할 수있게하는 주된 이유는 인덱스를 삭제하지 않고도 인덱스를 사용하여 얻을 수있는 성능 이점을 측정하는 것입니다.

마지막으로 쿼리 및 맵 디스플레이의 성능을 대폭 향상 시키려면 시스템 개발시 적절한 시점으로 인덱스 생성을 지연시킬 수 있습니다.

나는 이것이 암시 적이라고 생각하지만, 대신 사용할 수있는 비 공간 인덱스가있을 때 쿼리에 공간 인덱스를 사용 하지 않을 것입니다. 예를 들어, 미국에 걸쳐 2,113,450 개의 점이 테이블에로드되어 있습니다. 알래스카 주 내의 모든 포인트를 가져 오려면 포인트 지오메트리에서 GIST 인덱스를 사용하여 알래스카 주 지오메트리와 비교 한 공간 쿼리를 수행하거나 OR을 사용할 수 있습니다. "state_alpha"= 'AK'인 모든 포인트를 반환하기 위해 포인트 데이터의 "state_alpha"필드 (인덱싱 됨)

"이것의 공간 부분은 어디에 있습니까?" 글쎄, 수집 한 후 Alaska_points에 대한 추가 공간 분석을 수행해야하는 경우 비 공간 쿼리를 사용하여 해당 포인트 형상을 수집하는 것이 더 빠릅니다. 또한 실제로 큰 데이터 세트의 경우 조회 필드 (또는 테이블)를 추가하면 이점이 있습니다. 다시 말하지만, 이것은 아마도 모든 사람들에게 명백 할 것이라는 것을 알고 있습니다. 과거에는 공간적으로 만 인덱스 된 전역 데이터 세트와 공통 쿼리가 "국가의 모든 기능"인 전역 데이터 세트에서 발생했기 때문에 언급했습니다. 인덱스 country_fips 필드를 추가하여 많은 성능을 얻었습니다.

아래는 EXPLAIN ANALYZE의 결과를 보여주는 몇 가지 결과입니다. (참고 : BBOX 쿼리를 사용하여 공간 쿼리를 최대한 효율적으로 만들려고했습니다. 상태 개요를 사용하면 속도가 느려졌습니다.)

# 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 

이 진술을 보았습니다.

나에게 이것은 의미가 있습니다. 당신은 공간 쿼리를 실행 = 공간 인덱스가 있어야합니다

나에게 이것은 전혀 이해가되지 않으며 SQL Server와 Postgis 모두 더 나은 작업을 수행하거나 최소한 성능 세부 사항을 방해하지 않는다고 생각합니다. 실제로 SQL Server와 Postgi는 공간 인덱스를 전혀 사용하지 않는 경우도 있습니다 (전체 테이블 스캔으로 되돌리기).

Oracle의 경우 인덱스를 작성해야하므로 user_sdo_geom_metadata를 채워야합니다.

이것을 영숫자 인덱스와 비교하면 성능상의 이유로 SQL 문이 있거나없는 SQL 문이 작동해야합니다.

Oracle 데이터베이스에서 인덱스를 삭제하면 공간 쿼리를 사용할 수 없어 작동하지 않는 많은 오류와 앱이 표시됩니다.