SQL Server 2008의 7 천만 포인트 클라우드에서 가장 가까운 인접 쿼리 최적화


16

SQL Server 2008 R2 Express 데이터베이스에 약 7 천 5 백만 개의 레코드가 있습니다. 각 값은 특정 값에 해당하는 위도입니다. 테이블에는 지리 열이 있습니다. 주어진 위도 경도 (점)에 대해 가장 가까운 이웃을 찾으려고합니다. 공간 인덱스가있는 쿼리가 이미 있습니다. 그러나 데이터베이스의 레코드 위치 (예 : 1 사분기 또는 마지막 분기)에 따라 쿼리는 가장 가까운 이웃을 찾는 데 약 3 ~ 30 초가 소요될 수 있습니다. 쿼리 또는 공간 인덱스를 최적화하여 훨씬 빠른 결과를 제공하도록 최적화 할 수 있다고 생각합니다. 지금은 기본 설정으로 공간 인덱스를 적용했습니다. 내 테이블과 쿼리는 다음과 같습니다.

CREATE TABLE lidar(
    [id] [bigint] IDENTITY(1,1) NOT NULL,
    [POINTID] [int] NOT NULL,
    [GRID_CODE] [numeric](17, 8) NULL,
    [geom] [geography] NULL,
 CONSTRAINT [PK_lidar_1] PRIMARY KEY CLUSTERED ([id] ASC)
 WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, IGNORE_DUP_KEY = OFF, 
 ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
) ON [PRIMARY]

내가 사용하는 공간 색인 :

CREATE SPATIAL INDEX [SPATIAL_lidar] ON [dbo].[lidar] ([geom]) USING  GEOGRAPHY_GRID 
WITH (
GRIDS =(LEVEL_1 = MEDIUM,LEVEL_2 = MEDIUM,LEVEL_3 = MEDIUM,LEVEL_4 = MEDIUM), 
CELLS_PER_OBJECT = 16, PAD_INDEX  = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF,  
ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]

사용중인 쿼리는 다음과 같습니다.

declare @ms_at geography = 'POINT (-95.66 30.04)';
select TOP(1) nearPoints.geom.STAsText()as latlon 
from
(
select r.geom
from lidar r With(Index(SPATIAL_lidar))
where r.geom.STIntersects(@ms_at.STBuffer(1000)) = 1
) nearPoints

내 데이터베이스의 위도 long 샘플이 있습니다. 정확성과 밀도에 대한 아이디어를 제공합니다. 7 천만 건의 모든 기록은 한 도시에 대한 것입니다 (Lidar 데이터).

POINT (-95.669434934023087 30.049513838913736)

이제이 쿼리는 위에서 설명한대로 결과를 제공하지만 가능한 한 성능을 향상시키고 싶습니다. 내 추측은 성능을보다 잘 최적화하기 위해 위에있을 수있는 공간 인덱스의 기본값을 조정하여 추측합니다. 이것에 대한 단서가 있습니까?

버퍼를 10에서 1000으로 변경하려고 시도했지만 거의 동일한 결과를 얻었습니다.

성능 향상을위한 다른 제안도 환영합니다.

다음은 현재 사용중인 시스템입니다.

Windows 7 64bit Professional
Intel(R) Core(TM)2 Quad CPU    Q9650  @ 3.00GHz (4 CPUs), ~3.0GHz
Ram: 8 GB
NVIDIA GeForce 9500 GT

1
이 라이더 데이터입니까? 그렇다면 lidar태그 추가를 고려하십시오 .
Kirk Kuykendall

2
SQL Server를 사용하지 않지만 쿼리에서 대상 지점의 1000 미터 버퍼 내에있는 모든 지점을 찾아야한다는 것은 잘 알고 있습니다. 이 포인트 인 폴리곤 테스트로가는 방법 느릴에서 제공되는 솔루션의 기반이 근접 테스트보다 이전 질문 .
whuber

@ whuber : 거리 기반 쿼리와 시간을 분 단위로 시도했습니다. 높은 길. 어딘가에 잘못 가고있을 수 있습니다. 이 점에서 다각형은 시간 (초)이 걸립니다. 10에서 10000까지 버퍼를 변경하더라도 시간에 거의 영향을 미치지 않습니다.
Shaunak

1
@Shaunak 그렇다면 거리 기반 쿼리에는 문제가 있습니다. 이론적으로 KD 트리 와 같은 적절한 인덱스를 사용하여 평균적으로 마이크로 초 (또는 더 나은) 및 밀리 초 (최악의 경우)로 수행 할 수 있기 때문 입니다. 포인트 인 버퍼 검색을 최적화하는 방법을 찾는 대신 개선에 대해 생각할 수 있습니다.
whuber

이 그리드 데이터입니까? 왜 래스터를 사용하지 않습니까?
Matthew Snape

답변:


9

공간 인덱스 사용 방법에 대한 자세한 내용을 보려면 sp_help_spatial_geography_index 저장 프로 시저를 실행하십시오 . 다음과 같은 것을 사용할 수 있어야합니다.

declare @ms_at geography = 'POINT (-95.66 30.04)'
set @ms_at = @ms_at.STBuffer(1000).STAsText()
exec sp_help_spatial_geography_index 'lidar', 'SPATIAL_lidar', 0, @ms_at;

질문에 결과를 게시하여 눈에 띄는 것이 있는지 확인하십시오. 각 항목의 의미는 여기에서 찾을 수 있습니다 .

좌표가 투영 된 경우 계산 된 X, Y 필드에 대해 간단한 비 공간 쿼리를 수행하고 X <MinX 및 X> MaxX 등을 검사 할 수도 있습니다.

(GEOMETRY 유형 필드에서) 좌표를 투영하면 성능을 상당히 향상시킬 수있는 데이터 범위로 공간 인덱스를 제한 할 수 있습니다. 세계 범위를 데이터 범위로 바꾸십시오.

CREATE SPATIAL INDEX [SPATIAL_lidar] ON [dbo].[lidar] ([geom]) USING  GEOMETRY_GRID 
WITH (
GRIDS =(LEVEL_1 = MEDIUM,LEVEL_2 = MEDIUM,LEVEL_3 = MEDIUM,LEVEL_4 = MEDIUM), 
CELLS_PER_OBJECT = 16, PAD_INDEX  = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF,  
ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON,
BOUNDING_BOX =(-90, -180, 90, 180),) ON [PRIMARY]

1
technet.microsoft.com/en-us/library/bb934196.aspx 에 따르면 BOUNDING_BOX는 GEOGRAPHY_GRID가 아닌 GEOMETRY_GRID에만 사용할 수 있습니다.
Kelso

1
답변이 업데이트되었습니다. BOUNDING_BOX를 설정할 수 있으므로 GEOMETRY 유형이 훨씬 빨라야합니다.
geographika

1

BufferwithTolerance로 버퍼 단순화를 고려하십시오 . 점이 밀집되어 있으면 시스템은 점이 경계의 어느 쪽인지 확인해야합니다. 그 라인이 간단할수록 기계의 작업이 줄어 듭니다.


당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.