개인 지오 데이터베이스는 파일 지오 데이터베이스보다 인덱싱 된 속성을 빠르게 쿼리하는 데 더 적합합니까?

주소를 검색하기 위해 데이터를 쿼리하는 ArcGIS Engine 애플리케이션에 대한 데이터를 준비 중입니다. 때때로 우리는 거리 이름 필드, 집 번호 필드 또는 둘 다에서 검색합니다. 개인 지오 데이터베이스 또는 SDE 지오 데이터베이스를 사용하는 경우 단일 열 인덱스 외에도 다중 열 속성 인덱스를 추가 할 수 있습니다. 어떤 이유로 인해 속성 색인 작성 ESRI 기사 에 따르면 파일 지오 데이터베이스를 사용할 때 다중 열 속성 색인을 사용할 수 없습니다. 그들은 이것이 왜 그런지 언급하지 않습니다. 어쩌면 파일 지오 데이터베이스는 어떤 이유로 필요하지 않습니까?

집 번호 필드와 거리 이름 필드의 다중 열 인덱스는 두 필드를 한 번에 검색 할 때 이론적으로 쿼리 성능을 향상시켜야하지만 개인 지오 데이터베이스를 사용하여 전환 할 가치가 있습니까? 개인 지오 데이터베이스를 사용하면 단점으로 인해 다중 열 인덱스의 이점이 무효화 될 수 있습니다.

Esri가 개인 지오 데이터베이스에서 벗어나기를 원한다는 인상을 받았지만 개인 지오 데이터베이스가 더 나은 옵션입니까? 이것에 대해 경험이 있으시면 알고 싶습니다.

질문의 첫 번째 부분에 답하기 위해 다중 열 인덱스에 대한 속성 인덱스 만들기 도움말 파일의 추가 텍스트를 보는 것이 도움이된다고 생각합니다.

여러 열 인덱스에 필드가 나타나는 순서가 중요합니다. 열 A 앞에 열 B가있는 다중 열 인덱스에서 열 A는 초기 검색을 수행하는 데 사용됩니다. 또한 이러한 인덱스는 열 B와 관련된 쿼리보다 열 A와 관련된 쿼리에 훨씬 유용합니다.
A와 B에서 다중 열 인덱스를 만듭니다.이 인덱스는 일반적으로 두 열이 모두 포함 된 쿼리에 더 효율적입니다. A 만 포함 된 쿼리의 경우이 인덱스는 A의 인덱스보다 느립니다. 이 인덱스는 B에만 관련된 쿼리에는 거의 쓸모가 없습니다. 보상하기 위해 B에 추가 인덱스를 만들 수 있습니다.

이 두 구절은 다중 컬럼 인덱스가 특수 용도에 더 우수함을 보여줍니다. 또한 이러한 인덱스를 사용하여 포함 된 열 중 하나만 정렬하면 실제로 성능이 저하 될 수 있습니다. 이러한 이유로 다중 열 인덱스에 포함 된 각 특성에 개별 열 인덱스가 필요할 수 있습니다.

ESRI 에서 Personal GDB를 통해 File을 선택해야하는 9 가지 이유를 언급 한 오래되었지만 흥미로운 문서에 대한 링크를 찾았습니다 . 특히 성능을 한 가지 이유로 부릅니다. 이 성능 향상의 일부는 파일 기반 스토리지 시스템 때문입니다. 나는 이것이 다중 열 지원 부족으로 이어질 수 있다고 생각합니다. 단일 파일 인 Personal GDB와 달리 File GDB의 인덱스는 GDB 구조에서 별도의 파일로 저장됩니다. 이는 특정 피쳐 클래스에 대한 인덱스 파일과 속성 파일이 서로 링크되고 함께 액세스되어야 함을 의미합니다. 다중 열 인덱스가 인덱스와 속성 파일간에 앞뒤로 이동하여 인덱싱 성능 향상보다 성능 저하가 발생할 수있는 위치를 알 수 있습니다.

개인 GDB에 비해 File GDB의 성능이 이미 상당히 높기 때문에 다중 열 인덱스를 구현할 가치가 없었을 것입니다.

두 가지 GDB 유형을 모두 사용한 경험에서 Personal GDB가 파일보다 약 50 % 더 크게 실행되는 것을 보았습니다. File GDB와 관련하여 제공 한 데이터를 기반으로 PGDB로 변환하는 경우 최대 300MB Personal GDB로 끝날 수 있습니다. 내가 본 것에서 ESRI 제품 내에서 또는 별도로 MS Access 데이터베이스를 사용하면 ".mdb"파일의 크기가 100MB 이상 크게 증가하면 성능이 저하되기 시작합니다.

다른 문제는 속성 검색 속도를 높일 수 있더라도 데이터 프레임에서 이동하고보기를 새로 고치는 것과 관련하여 성능이 크게 저하 될 수 있다는 것입니다. 레이어가 PGDB에 있다면 레이어는 그리 빨리 그리지 않습니다. 지오 데이터베이스 유형을 비교하는이 기사에서는 성능 차이에 대한 자세한 정보를 제공합니다.

많은 것들과 마찬가지로 최선의 선택은 궁극적으로 유스 케이스에 달려 있습니다. 액세스 인터페이스에서 수행 할 수있는 쿼리 및 업데이트와 같이 수행하려는 데이터베이스 특정 작업이 많으면 Personal GDB가 더 나을 수 있습니다. 일부 쿼리 만 계획하고 주로 공간 데이터를 시각화하려는 경우 성능은 File GDB 측면에서 확실히 떨어집니다.

개인 지오 데이터베이스보다 파일 지오 데이터베이스를 사용해야하는 9 가지 이상의 이유가 있습니다. 불행히도, 오래된 PGDB를 유지해야 할 더 많은 이유가 여전히 있습니다. 당신의 딜레마는 그들 중 하나입니다. (이 주제에 대한 ESRI 출판물 없음)

PGDB를 통한 FGDB의 주요 목적은 다중 열 "속성"인덱스 및 기타 고급 SQL 함수와 같은 기능이 아니라 스토리지 용량 및 공간 데이터 성능 (그리기 속도, 검색, 공간 인덱싱, 공간 쿼리 등)이라고 생각합니다. 일반적으로 DBMS의 필수적인 부분입니다. (MS 액세스 기반 PGDB는 ESRI 네이티브 FGDB는 그렇지 않습니다) 부수적으로; MS Access 데이터베이스의 최대 파일 크기 제한은 2GB이며 단일 PGDB의 최대 크기이기도합니다. 반대로 FGDB 파일 크기 제한은 1TB에서 256TB로 확장 할 수 있습니다.

ESRI는 또한 다음과 같이 설명합니다. SQL 표현식을 작성하는 데 사용하는 구문은 데이터 소스에 따라 다릅니다. SQL이 표준이지만 모든 데이터베이스 소프트웨어가 동일한 SQL 방언을 구현하지는 않기 때문입니다. 및 파일 지오 데이터베이스, 적용 범위, 쉐이프 파일, 정보 테이블의 dBASE 테이블, CAD 및 VPF 데이터를 포함하려면 쿼리 파일 기반 데이터는, 당신은 기능과 개인에서 사용할 수있는 기능의 일부를 지원는 ArcGIS에서 구현 SQL의 방언을 사용 ArcSDE 지오 데이터베이스.

다시 말해 DBMS를 기반으로하는 지오 데이터베이스가이 기능을 지원한다면 PGDB와 ArcSDE GDB는 그 증거입니다 . 그렇기 때문에 기본 MS Access 데이터베이스가있는 PGDB에서 다중 열 인덱스를 만들 수 있습니다. 이 기능을 지원하는 기본 DBMS가있는 ArcSDE 지오 데이터베이스와 동일합니다.

File Geodabase는 ; 상기 9.2 FGDB 자료 ESRI는 빗대 이러한 특징과 기능의 일부는, 인용 미래 FGDB 릴리스에 추가 될 수 있음; "파일 지오 데이터베이스는 개인 지오 데이터베이스에 사용 가능한 모든 기능을 지원하지 않습니다. ArcGIS 9.2에서 파일 지오 데이터베이스가 지원하지 않는 가장 일반적으로 사용되는 기능은 DISTINCT, GROUP BY 및 ORDER BY 및 설정 기능 AVG, COUNT, MIN, MAX 및 SUM은 하위 쿼리 외부에서 지원되지 않습니다. 이들 중 일부에 대한 지원은 향후 릴리스에서 추가 될 것입니다. "

4 년 후 버전 10에서는 이러한 기능과 기능을 사용할 수 없습니다. ( 사용 가능한 기능 목록 )

FGDB는 현재 진행중인 작업으로, 필요한 모든 SQL DBMS 함수가 필요한만큼 다중 열 인덱싱 기능이 필요합니다. ESRI 개발자가 기능을 FGDB로 확장하는 것이 중요하다고 결정할 때까지 PGDB에 갇히게 될 것 같습니다.

이 스레드 / 문제를 되풀이하면서 가능한 경우 FGDB와 PGDB를 결합하는 것이 유용 할 수 있다는 것을 알았습니다. 예를 들어, 스크래치 지오 데이터베이스를 PGDB로 만들면 쿼리 성능이 크게 향상되었습니다. 위에서 언급 한 것처럼 PGDB의 크기가 너무 커지지 않아야합니다.