http://a.deveria.com/caniuse/
'분류 전체보기'에 해당되는 글 72건
- 2010.02.03 브라우져 별 호환성 관련 사이트 5
- 2010.02.02 HTML 5 Offline Application Cache 2
- 2009.12.29 Projecting data
- 2009.12.29 Spatial Indexing
- 2009.12.29 Spatial Indexing
- 2009.12.29 Spatial Joins
- 2009.10.27 G-DRAGON - Heartbreaker
- 2009.10.15 윈도우 XP 커맨드 exe계열
- 2009.10.15 윈도우즈 커맨드 cpl 계열 커맨드 모음
- 2009.10.15 Msc 커맨드 모음
아이폰 OS 2.1버전의 사파리 4.0이후 버전부터 사파리는 오프라인 어플리케이션 캐시(offline application cache)를 제공한다. 이 캐시는 사용자들의 컴퓨터나 웹이 가능한 디바이스가 인터넷에 접속할 수 없는 환경에 처해 있어도 동작될 수 있는 웹 기반의 어플리케이션을 만들게 해준다.
이 기술은 두 개의 파트로 구성된다: manifest file과 JavaScript 인터페이스.
manifest파일은 캐시가 되어질 리소스 자원들의 리스트를 포함하고 있는 텍스트 파일이다.
JavaScript 프로그래밍 인터페이스들은 캐시된 파일이 원하는 경우에 업데이트가 동작 되도록 한다.
Manifest File 생성하기
manifest 파일은 어플리케이션 캐시에 다운로드 되고 저장되어 질 HTML, JavaScript, CSS, 이미지 파일들과 같은 리소스들을 기술한다. 웹 페이지가 첫 번째로 로딩이 된 후 부터 , manifest 파일에 기술되어진 리소스 파일들은 웹 서버가 아닌 application cache에 의해 획득되어 진다.
manifest 파일은 다음과 같은 속성들을 가지고 있다:
- MIME-Type이 text/cache-manifest와 같이 제공되어야 한다.
- 첫 번째 줄에는 CACHE MANIFEST라는 텍스트를 포함하고 있어야 한다.
- 그 다음 줄들은 캐시할 각각의 리소스의 URL이나 주석을 포함하고 있다.
- 주석문들은 # 문자로 시작하고 한 줄로 와야한다.
- URL들은 로컬에 캐시로 다운로드를 원하는 리소스에 대한 파일 경로이다. 파일 경로는 manifest 파일에 대한 상대,절대경로로 표현되어야 한다 —CSS에서 사용되는 파일 경로와 유사
- manifest는 반드시 온라인일 시에 접근해야 하는 모든 외부 리소스들에 상응하는 접두어를 포함하고 있는 whitelist를 선언하야 한다. 이 whitelist는 그 자신이 한 줄을 구성하는 NETWORK:라는 식별자와 함께 시작한다.
또한 network 엔트리 뒤에 그 자신이 한 줄을 구성하는 CACHE:라는 식별자를 삽입함으로써 추가적인 cache 엔트리를 선언할 수 있다.manifest는 만약 원한다면 fallback 섹션들을 둘 수 있다. 이 섹션들은 FALLBACK: 이라는 식별자와 시작할 수 있고, 두 개의 URI들을 포함하고 있는 연속되는 타이들을 포함하고 있다. 두 번째 URI는 브라우져가 첫 번째 URI에 접근하지 못할 때 사용한다. URI들은 반드시 둘 다 manifest 그 자신과 같은 origin을 가지고 있어야 한다. 두 개의 URI 모두 부분적인 경로(partial URIs)만 포함한다.(prefixes);
예를 들어 아래 예제는 만약 /files/projects 가 찾아지지 않는다면, 클라이언트는 다시 /files/projects/를 /projects로 대체해서 찾는다
FALLBACK: /files/projects /projects |
- "Manifest 파일 선언하기"에 설명 되어진 대로, manifest파일을 선언한 HTML 파일은 자동적으로 application cache에 포함되게 된다. 당신은 그것을 manifest 파일에 추가할 필요가 없다.
예를 들어, "Creating the index.html file"은 몇몇 이미지 리소스에 대한 URL을 포함하고 있는 manifest 파일을 보여준다.
CACHE MANIFEST # This is a comment. # Cache manifest version 0.0.1 # If you change the version number in this comment, # the cache manifest is no longer byte-for-byte # identical.
demoimages/clownfish.jpg demoimages/clownfishsmall.jpg demoimages/flowingrock.jpg demoimages/flowingrocksmall.jpg demoimages/stones.jpg
NETWORK: # All URLs that start with the following lines # are whitelisted. http://example.com/examplepath/ http://www.example.org/otherexamplepath/
CACHE: # Additional items to cache. demoimages/stonessmall.jpg
FALLBACK: demoimages/ images/ |
Manifest 파일 선언하기
manifest 파일을 생성한 후, HTML 파일에 선언을 해 주어야 한다. 다음과 같이 <html>태그에 manifest 속성을 추가함으로써 할 수 있다.
<html manifest="demo.manifest"> |
manifest 속성의 인자 값은 manifest 파일의 상대경로 혹은 절대경로이다.
중요: 특정 브라우져들에서,HTML5 DOCTYPE 선언형식을 쓰지 않는 경우 application cache가 원활하게 작동되지 않을 수 있다. 이 경우, HTML5 DOCTYPE 선언을 사용하여라
|
대부분의 경우에, manifest 파일을 생성하는 것과 선언하는 것이 application cache를 생성하는데 필요한 전부이다. 이것을 한 후에, 리소스들은 자동적으로 웹 페이지가 처음 보여질 때에 캐시에 저장되고, 그 후에 다수의 브라우져 세션마다 캐쉬에서 로딩되어 진다. JavaScript로부터 캐시를 조종하고 싶다면 다음 섹션을 읽어 보아라.
Cache 업데이트하기
당신은 application cache가 자동적으로 업데이트되기를 기다리거나 혹은 수동적으로 JavaScript를 이용하여 업데이트를 유발시킬 수 있다. application cache는 manifest 파일이 변했을 경우만 자동적으로 업데이트 된다. manifest에 있는 열거 되어진 리소스 파일이 변경된 경우에는 자동적으로 업데이트가 일어나지 않는다.
manifest 파일은 byte-for-byte로 같다면 이전 버전에서 변하지 않은 것으로 간주된다; manifest 파일의 수정 날짜를 고치는 것은 update를 유발시키지 않는다. 반드시 manifest 파일의 콘텐츠를 바꾸어야 한다(주석문을 바꾸는 것도 충분하다).
에러가 application cache를 업데이트 할 때 발생할 수 있음에 주의 하여라. 만약에 manifest 파일을 다운로드 받거나 manifest 파일에 명시된 리소스들을 다운로드 받는데 실패하면, 전체적인 업데이트 프로세스는 실패로 돌아간다. 만약 업데이트 프로세스가 실패하면, 현재 application cache는 방해 받지 않는다 —브라우저가 계속해서 이전 버전의 application cache를 쓴다. 만약 업데이트가 성공적이면, 웹 페이지는 그 들이 다시 로딩될 시에 새로운 캐시를 이용한다.
아래 나오는 JavaScript 클래스를 이용하면 application cache의 업데이트를 유발시킬 수 있고, 그들의 상태를 확인할 수 있다. 페이지 별 DOMApplicationCache 클래스의 인스턴스로 표현되는 application cache가 있다. application cache는 DOMWindow 오브젝트의 프로퍼티이다.
예를 들어, 다음과 같이 DOMApplicationCache 오브젝트를 얻을 수 있다:
cache = window.applicationCache; |
application cache의 상태를 다음과 같이 확인할 수 있다:
If(window.applicationCache.status == window.applicationCache.UPDATEREADY)… |
만약 application cache가 UPDATEREADY 상태이면, 다음과 같이 update() 메시지를 보냄으로써 업데이트 할 수 있다:
Window.applicationCache.update(); |
만약 업데이트가 성공적이었다면, 다음과 같이 이전 캐시를 새로운 캐시로 대체한다:
Window.applicationCache.swapCache(); |
캐시는 UPDATEREADY 상태를 반환할 때 사용할 수 있다. 다른 상태 값을 보려면 DOMApplicationCache 문서를 보아라.
캐시 이벤트 다루기
JavaScript를 이용하여 application cache의 이벤트를 알 수 있다. 이벤트는 application cache의 상태가 바뀌거나, 업데이트 프로세스가 실패할 때 보내어 진다. 당신은 이벤트를 등록할 수 있고 적절한 행동을 취할 수 있다.
예를 들어, application cache가 업데이트 되어질 준비가 되어 졌는지 알기 위해 updateready 이벤트를 등록한다. 또한 error 이벤트를 등록하는 것은 업데이트 프로세스가 실패했을 경우 조치를 취할 수 있게 한다.—예를 들어, console을 이용하여 에러 메시지를 기록하는 것.
cache = window.applicationCache; cache.addEventListener('updateready', cacheUpdateReadyListener, false); cache.addEventListenser('error', cacheErrorListener, false); |
이벤트 타입들에 대한 모든 리스트를 보기 위해서는 DOMApplicationCache 문서를 보아라.
본 글은 아래 글을 번역해 놓은 것입니다 : http://developer.apple.com/safari/library/documentation/iPhone/Conceptual/SafariJSDatabaseGuide/OfflineApplicationCache/OfflineApplicationCache.html#//apple_ref/doc/uid/TP40007256-CH7-SW1
우리는 이미 measurement function들을 설명할 때 투영에 관한 개념에 대해 언급하였다. PostGIS가 투영된 좌표와 투영되지 않은 좌표(위경도) 모두에서 간단한 거리를 다룰 수 있는 함수를 가지고 있는 반면에, 좀 더 복잡한 요청, 예를 들면 면적이나, 점이 아닌 것들에 대한 거리는 투영에 대한 고려 없이 측정될 수 있다. 심지어 투영되지 않은 것의 길이를 재는 함수는 데이터가 측량 되어진 타원체에 대한 정보를 필요로 한다. 잘못된 절차는 불분명하고 오해의 소지가 있다.
우리는 어떻게 다음결과를 해석할 수 있을까?
이 경우 투영(SRID:2270)은 피트(feet) 단위이고, ST_Length함수의 결과도 역시 그와 같다. PostGIS는 투영이 수행하는 데에 필요로 하는 간단한 함수를 제공한다. 예를 들어 미터(m)단위의 거리는 ST_Transform을 통하여 지오메트리를 미터단위를 사용하는 투영법(SRID:2839)으로 변환하여 결정할 수 있다.
하지만 우리가 어떻게 첫 번째 장소의 투영법을 알았을까? 간단한 방법은 앞에 섹션에서도 봤듯이 geometry_columns 테이블을 살펴보는 것이다.
위의 방법은 대게 적절하지만 테이블 레코드 자체는 지오메트리에 geometry_columns테이블에 열거되어진 투영법의 srid(spatial reference ID)를 강요 받지는 않는다. 열거된 srid가 맞는지 확실하게 하기 위해서는 앞서 언급했던 AddGeometryColumns 함수를 이용하여 지오메트리 컬럼에 대해서 제약조건을 확인하는 것이다. 이 함수는 또한 지오메트리 타입과 좌표계의 차원을 확인하는 제약조건을 생성한다.
만약에 이런한 제약조건이 나타나지 않는다면, 마지막으로 지오메트리의 srid를 확인하는 방법이 있다; ST_SRID 함수를 이용에 바로 질의하는 것이다.
당신이 사용하고 있는 투영법이 일관성을 가지고 있는지 확인하는 것은 measurement 함수를 이용하는 것 이외에도 많은 이유가 있다. PostGIS는 일반적으로 결과 값이 의미 없는 값이 되는 다른 srid를 가지고 있는 지오메트리 간에 많은 함수를 사용하는 것을 단순하게 거절한다.
데이터가 로드되기 전에 srid가 세팅되지 않았는데 머하고 있는가? 그것이 잘못 설정된 것을 눈치 챘는가? 이 경우들에 대해서는 PostGIS가 ST_SetSRID 함수를 제공한다. 이 함수는 투영 과정 없이 지오메트리에 대해 srid를 선언하게 해준다.
위의 ST_SetSRID를 이용한 방법은 소규모 작업에 적합한 반면, 언제나 적합한 srid를 알 고 있기 때문에 데이터베이스를 업데이트 할 때는 UpdateGeometrySRID 함수를 이용한다. 이 함수는 테이블 이름과, 지오메트리 컬럼 이름, srid 값, 선택적으로 스키마(schema) 이름을 취하고, 테이블에 있는 모든 레코드를 새로운 srid로 갱신하고, 제약조건을 추가하고, geometry_columns 테이블 레코드를 추가한다.
공간인덱스(Spatial index)들은 PostGIS의 가장 큰 자산들이다. 우리가 이전에 살펴본 ST_DWithin 에서 볼 수 있듯이, 두 개의 지오메트리(geometry) 사이의 관계를 결정하는 것은 먼저 지오메트리의 바운딩박스(bounding box)를 결정함으로써 속도가 향상될 수 있다. 인덱스는 이러한 바운딩 박스와 지오메트리사이의 관계를 정하는 개념과 더불어 지오메트리의 바운딩 박스를 인덱싱하는 절차를 갖게 된다.
PostGIS 에서 공간인덱스를 생성하는 것은 간단하다. 아래의 커맨드들은 jacksonco_streets table의 지오메트리 컬럼에 인덱스를 생성할 것이다.
CREATE INDEX jacksonco_streets_gix ON jacksonco_streets USING GIST (the_geom);
Note
인덱스를 생성할 때 GIST 절을 이용하는 것은 PostgreSQL가 generic index structure (GIST)인덱스를 사용하게 하는 것이다. 이것은 기본 인덱스 타입이 B-Tree 타입이기 때문에 중요하다. B-Tree 인덱스들은 GIST 인덱스가 하는 것과 같은 lossy (inexact)타입이 아니기 때문이다. 이것은 GIST 인덱스가 지오메트리의 바운딩박스를 인덱싱하는 반면에, B-Tree 반드시 인덱스가 처리할 수 있는 것보다 클 수도 있는 모든 지오메트리를 인덱싱하는 것을 의미한다. 만약 인덱스 생성시에 "ERROR: index row requires 11340 bytes, maximum size is 8191" 이라는 에러가 나오면 USING GIST 절을 쓰는 것을 소흘히 해서 생긴 것이다.
우리가 공간인덱스를 사용할 때 실제 무슨 일이 인덱스가 생성될 때 발생하는지 살펴보자.
왼쪽에 있는 그림의 하나의 폴리곤(polygon)과 세 개의 선(line)이다. 오직 빨간선만이 폴리곤을 가로지르고 있음을 확인할 수 있고, 나머지 두 개의 선은 접하거나 겹치지 않는다. 가운데 있는 그림은 같은 오브젝트들이 바운딩 박스(bounding box )라고도 하는 MBR(minimum bounding rectangle)에 있는 것을 보여준다. 마지막으로 오른쪽의 그림은 바운딩 박스이다.
이 경우에서 우리는 바운딩 박스가 필터가 폴리곤과 라인스트링(linestring)이 빨간선과 파랑선에 교차하는가와 녹색선이 교차(intersection )하지 않는 것을 조회한다는 것을 확인할 수 있다. 바운딩박스 교차 연산자는 &&이고, 이것은 아래 보이는 쿼리의 WHERE 절에 추가 되어졌다.
&& 연산자는 그 자체만으로는 지오메트리들끼리 교차되었는지 보장하지는 못하고, 단지 바운딩 박스가 교차되었다는 것만을 보장할 수 있다. 그런 입장에서 && 연산자는 거의 독립적으로 쓰이지는 않는다. 이러한 이유로 대부분의 관련 함수들이 && 연산자를 쿼리의 일부분으로서 포함할 것이다. ST_DWithin 의 예를 보면 두 개의 && 연산자가 다른 것의 바운딩 박스 확장과 각각의 지오메트리의 바운딩 박스와 어울려 사용된다.
R-Tree 인덱스에 바운딩 박스를 저장하므로써, 박스들은 빠르게 위치하고, 비교되고, 지오메트리가 디스크로부터 읽혀지기 전에 비교되어질 전체 지오메트리의 숫자는 줄어든다.
우리의 인덱스는 이제 생성되어질 것이다. 데이터베이스가 쿼리 계획을 세울 때 사용되어지는 통계를 업데이트 하기 위해서는 우리는 반드시 다음과 같은 커맨드를 실행하여야 한다.
VACUUM ANALYZE jacksonco_streets;
ANALYZE 커맨드는 PostgreSQL이 테이블을 가로지르고 쿼리 수행계획 추정에 사용될 내부 통계의 업데이트를 요청한다. VACUUM 커맨드는 PostgreSQL이 레코드에 대한 업데이트와 삭제에 의해 남겨진 테이블 페이지에 있는 사용하지 않는 공간의 개선을 요청한다. VACUUM ANALZE 커맨드는 위의 두 가지를 모드 수행한다.
여기서는 VACUUM ANALYZE 커맨드를 이용할 것이며, 이것을 GUI를 통해서 하는 방법도 있다.
테이블에서 오른쪽 마우스를 클릭하고 "관리(M)" 옵션을 선택한다. 선택을 하면 아래 화면과 같이 VACUUM, ANALYZE, REINDEX 커맨드 옵션을 볼 수 있다. VACUUM을 선택하고 ANALYZE 옵션에 체크를 하면 우리가 위에서 했던 쿼리와 같은 것을 수행하게 된다. 이 "관리"화면은 데이터베이스, 테이블, 인덱스 레벨에서 실행될 수 있다.
자 이제 쿼리를 다시 실행 시켜 보자.
이제 우리는 속도의 엄청난 향상을 보았다. 많은 관계 연산자를 PostGIS가 내장형 바운딩 박스 오퍼레이션으로 제공하고 있다. 잠시 다른 공간 컬럼들에도 인덱스를 생성하여 보자
CREATE INDEX jacksonco_schools_gix ON jacksonco_schools USING GIST (the_geom);
CREATE INDEX jacksonco_taxlots_gix ON jacksonco_taxlots USING GIST (the_geom);
CREATE INDEX medford_buildings_gix ON medford_buildings USING GIST (the_geom);
CREATE INDEX medford_citylimits_gix ON medford_citylimits USING GIST (the_geom);
CREATE INDEX medford_hydro_gix ON medford_hydro USING GIST (the_geom);
CREATE INDEX medford_parks_gix ON medford_parks USING GIST (the_geom);
CREATE INDEX medford_planzone_gix ON medford_planzone USING GIST (the_geom);
CREATE INDEX medford_stormdrain_gix ON medford_stormdrain USING GIST (the_geom);
CREATE INDEX medford_wards_gix ON medford_wards USING GIST (the_geom);
CREATE INDEX medford_wetlands_gix ON medford_wetlands USING GIST (the_geom);
CREATE INDEX medford_zoning_gix ON medford_zoning USING GIST (the_geom);
CREATE INDEX tracts_gix ON
tracts USING
GIST (the_geom);
Vacuuming
PostgreSQL을 효과적으로 사용하려면 인덱스 생성만으로는 부족하다. VACUUM은 새로운 인덱스가 생성되거나 다수의 UPDATE, INSERT, DELETE가 테이블에 생겼을 때, 반드시 수행되어 져야한다. 효율적인 운영을 위해서 PostgreSQL이 "autovacuum" 옵션을 테이블이 업데이트될 때마다 기능을 수행하기 위해서 자동적으로 수행한다는 것은 매우 중요하다.
Autovacuum은 기본 값으로 실행되게 되어 있으며, 활동 레벨에 의해 결정되어 측정되어진 감지할 수 있는 간격마다 vacuum과 analyze(update statistics) 가 테이블에 실행된다. 이것은 많은 트랜젝션이 발생하는 데이터베이스에 필수인 반면에, 인덱스를 추가한 후나, 데이터의 벌크 로딩이 수행된 후 autovacuum을 기다리는 것은 권장하고 싶지 않다.
데이터베이스의 vacuum과 analyzing은 취향에 따라 따로따로 수행되어질 수 있다. VACUUM 커맨드를 수행하는 것은 데이터베이스 통계를 업데이트 시키지는 않는다. 이와 비슷하게 ANALYZE 커맨드를 수행하는 것도 테이블에서 사용하지 않는 행을 복구하는 것은 아니다. 이 두 커맨드 모두 전체 데이터베이스나, 하나의 테이블, 하나의 컬럼에 수행될 수 있다.
Clustering Data
클러스터링(clustering)은 테이블을 인덱스 기반으로 디스크에 저장하게 하는 PostgreSQL의 특징이다. 아래는 숫자나 텍스트 필드 등의 전형적인 B-Tree 인덱스를 이해시키기 위한 간단한 방법이다.
테이블은 필수적으로 초기의 정렬되지 않은 상태에서 정렬된 상태로 재배열 되어 져야 한다. 이것은 유사한 속성들이 같은 페이지에서 찾게 높은 가능성을 부여하고, 특정 쿼리 타입에 메모리에 읽혀져야만 하는 페이지 수를 줄여주는 역할을 해준다. 인덱스가 선형적인 순서를 가지고 있지 않기 때문에, 이것을 공간데이터로 가시화 시키기는 힘들다. 하지만 효과는 같다. 서로 가까이에 있는 지오메트리는 디스크에서도 서로 가까이 있게 된다.
아래 커맨드는 매우 간단하다.
CLUSTER
jacksonco_streets USING jacksonco_streets_gix;
데이터베이스통계는 테이블 정렬순서에 대한 정보를 가지고 있기 때문에, 클러스터링 후에 테이블을 Analyze하는 것을 매우 권장되는 바이다. Vacuuming은 불필요 하다.
ANALYZE jacksonco_streets;
공간인덱스(Spatial index)들은 PostGIS의 가장 큰 자산들이다. 우리가 이전에 살펴본 ST_DWithin 에서 볼 수 있듯이, 두 개의 지오메트리(geometry) 사이의 관계를 결정하는 것은 먼저 지오메트리의 바운딩박스(bounding box)를 결정함으로써 속도가 향상될 수 있다. 인덱스는 이러한 바운딩 박스와 지오메트리사이의 관계를 정하는 개념과 더불어 지오메트리의 바운딩 박스를 인덱싱하는 절차를 갖게 된다.
PostGIS 에서 공간인덱스를 생성하는 것은 간단하다. 아래의 커맨드들은 jacksonco_streets table의 지오메트리 컬럼에 인덱스를 생성할 것이다.
CREATE INDEX jacksonco_streets_gix ON jacksonco_streets USING GIST (the_geom);
Note
인덱스를 생성할 때 GIST 절을 이용하는 것은 PostgreSQL가 generic index structure (GIST)인덱스를 사용하게 하는 것이다. 이것은 기본 인덱스 타입이 B-Tree 타입이기 때문에 중요하다. B-Tree 인덱스들은 GIST 인덱스가 하는 것과 같은 lossy (inexact)타입이 아니기 때문이다. 이것은 GIST 인덱스가 지오메트리의 바운딩박스를 인덱싱하는 반면에, B-Tree 반드시 인덱스가 처리할 수 있는 것보다 클 수도 있는 모든 지오메트리를 인덱싱하는 것을 의미한다. 만약 인덱스 생성시에 "ERROR: index row requires 11340 bytes, maximum size is 8191" 이라는 에러가 나오면 USING GIST 절을 쓰는 것을 소흘히 해서 생긴 것이다.
우리가 공간인덱스를 사용할 때 실제 무슨 일이 인덱스가 생성될 때 발생하는지 살펴보자.
왼쪽에 있는 그림의 하나의 폴리곤(polygon)과 세 개의 선(line)이다. 오직 빨간선만이 폴리곤을 가로지르고 있음을 확인할 수 있고, 나머지 두 개의 선은 접하거나 겹치지 않는다. 가운데 있는 그림은 같은 오브젝트들이 바운딩 박스(bounding box )라고도 하는 MBR(minimum bounding rectangle)에 있는 것을 보여준다. 마지막으로 오른쪽의 그림은 바운딩 박스이다.
이 경우에서 우리는 바운딩 박스가 필터가 폴리곤과 라인스트링(linestring)이 빨간선과 파랑선에 교차하는가와 녹색선이 교차(intersection )하지 않는 것을 조회한다는 것을 확인할 수 있다. 바운딩박스 교차 연산자는 &&이고, 이것은 아래 보이는 쿼리의 WHERE 절에 추가 되어졌다.
&& 연산자는 그 자체만으로는 지오메트리들끼리 교차되었는지 보장하지는 못하고, 단지 바운딩 박스가 교차되었다는 것만을 보장할 수 있다. 그런 입장에서 && 연산자는 거의 독립적으로 쓰이지는 않는다. 이러한 이유로 대부분의 관련 함수들이 && 연산자를 쿼리의 일부분으로서 포함할 것이다. ST_DWithin 의 예를 보면 두 개의 && 연산자가 다른 것의 바운딩 박스 확장과 각각의 지오메트리의 바운딩 박스와 어울려 사용된다.
R-Tree 인덱스에 바운딩 박스를 저장하므로써, 박스들은 빠르게 위치하고, 비교되고, 지오메트리가 디스크로부터 읽혀지기 전에 비교되어질 전체 지오메트리의 숫자는 줄어든다.
우리의 인덱스는 이제 생성되어질 것이다. 데이터베이스가 쿼리 계획을 세울 때 사용되어지는 통계를 업데이트 하기 위해서는 우리는 반드시 다음과 같은 커맨드를 실행하여야 한다.
VACUUM ANALYZE jacksonco_streets;
ANALYZE 커맨드는 PostgreSQL이 테이블을 가로지르고 쿼리 수행계획 추정에 사용될 내부 통계의 업데이트를 요청한다. VACUUM 커맨드는 PostgreSQL이 레코드에 대한 업데이트와 삭제에 의해 남겨진 테이블 페이지에 있는 사용하지 않는 공간의 개선을 요청한다. VACUUM ANALZE 커맨드는 위의 두 가지를 모드 수행한다.
여기서는 VACUUM ANALYZE 커맨드를 이용할 것이며, 이것을 GUI를 통해서 하는 방법도 있다.
테이블에서 오른쪽 마우스를 클릭하고 "관리(M)" 옵션을 선택한다. 선택을 하면 아래 화면과 같이 VACUUM, ANALYZE, REINDEX 커맨드 옵션을 볼 수 있다. VACUUM을 선택하고 ANALYZE 옵션에 체크를 하면 우리가 위에서 했던 쿼리와 같은 것을 수행하게 된다. 이 "관리"화면은 데이터베이스, 테이블, 인덱스 레벨에서 실행될 수 있다.
자 이제 쿼리를 다시 실행 시켜 보자.
이제 우리는 속도의 엄청난 향상을 보았다. 많은 관계 연산자를 PostGIS가 내장형 바운딩 박스 오퍼레이션으로 제공하고 있다. 잠시 다른 공간 컬럼들에도 인덱스를 생성하여 보자
CREATE INDEX jacksonco_schools_gix ON jacksonco_schools USING GIST (the_geom);
CREATE INDEX jacksonco_taxlots_gix ON jacksonco_taxlots USING GIST (the_geom);
CREATE INDEX medford_buildings_gix ON medford_buildings USING GIST (the_geom);
CREATE INDEX medford_citylimits_gix ON medford_citylimits USING GIST (the_geom);
CREATE INDEX medford_hydro_gix ON medford_hydro USING GIST (the_geom);
CREATE INDEX medford_parks_gix ON medford_parks USING GIST (the_geom);
CREATE INDEX medford_planzone_gix ON medford_planzone USING GIST (the_geom);
CREATE INDEX medford_stormdrain_gix ON medford_stormdrain USING GIST (the_geom);
CREATE INDEX medford_wards_gix ON medford_wards USING GIST (the_geom);
CREATE INDEX medford_wetlands_gix ON medford_wetlands USING GIST (the_geom);
CREATE INDEX medford_zoning_gix ON medford_zoning USING GIST (the_geom);
CREATE INDEX tracts_gix ON
tracts USING
GIST (the_geom);
Vacuuming
PostgreSQL을 효과적으로 사용하려면 인덱스 생성만으로는 부족하다. VACUUM은 새로운 인덱스가 생성되거나 다수의 UPDATE, INSERT, DELETE가 테이블에 생겼을 때, 반드시 수행되어 져야한다. 효율적인 운영을 위해서 PostgreSQL이 "autovacuum" 옵션을 테이블이 업데이트될 때마다 기능을 수행하기 위해서 자동적으로 수행한다는 것은 매우 중요하다.
Autovacuum은 기본 값으로 실행되게 되어 있으며, 활동 레벨에 의해 결정되어 측정되어진 감지할 수 있는 간격마다 vacuum과 analyze(update statistics) 가 테이블에 실행된다. 이것은 많은 트랜젝션이 발생하는 데이터베이스에 필수인 반면에, 인덱스를 추가한 후나, 데이터의 벌크 로딩이 수행된 후 autovacuum을 기다리는 것은 권장하고 싶지 않다.
데이터베이스의 vacuum과 analyzing은 취향에 따라 따로따로 수행되어질 수 있다. VACUUM 커맨드를 수행하는 것은 데이터베이스 통계를 업데이트 시키지는 않는다. 이와 비슷하게 ANALYZE 커맨드를 수행하는 것도 테이블에서 사용하지 않는 행을 복구하는 것은 아니다. 이 두 커맨드 모두 전체 데이터베이스나, 하나의 테이블, 하나의 컬럼에 수행될 수 있다.
Clustering Data
클러스터링(clustering)은 테이블을 인덱스 기반으로 디스크에 저장하게 하는 PostgreSQL의 특징이다. 아래는 숫자나 텍스트 필드 등의 전형적인 B-Tree 인덱스를 이해시키기 위한 간단한 방법이다.
테이블은 필수적으로 초기의 정렬되지 않은 상태에서 정렬된 상태로 재배열 되어 져야 한다. 이것은 유사한 속성들이 같은 페이지에서 찾게 높은 가능성을 부여하고, 특정 쿼리 타입에 메모리에 읽혀져야만 하는 페이지 수를 줄여주는 역할을 해준다. 인덱스가 선형적인 순서를 가지고 있지 않기 때문에, 이것을 공간데이터로 가시화 시키기는 힘들다. 하지만 효과는 같다. 서로 가까이에 있는 지오메트리는 디스크에서도 서로 가까이 있게 된다.
아래 커맨드는 매우 간단하다.
CLUSTER
jacksonco_streets USING jacksonco_streets_gix;
데이터베이스통계는 테이블 정렬순서에 대한 정보를 가지고 있기 때문에, 클러스터링 후에 테이블을 Analyze하는 것을 매우 권장되는 바이다. Vacuuming은 불필요 하다.
ANALYZE jacksonco_streets;
공간조인(Spatial join)은 공간데이터베이스(spatial database)와 뗄 수 없는 관계이다. 이번 섹션은 관계 연산자(relation operator)와 약간의 일반적인 사용 예제를 서론으로 제공한다.
공간조인은 두 개 혹은 그 이상의 데이터셋을 공간 릴레이션(spatial relationship)과 관련하여 조합하기 위한 연산이다.
(medford_citylimits)Medford city 에 한정된 jacksonco_schools 테이블의 학교 목록을 얻기 위해서는 다음과 같은 쿼리를 사용할 것이다:
이 쿼리는 각각의 학교가 도시 경계 폴리곤 안에 있는 없는지 확인한다. ST_Within 함수는 각각의 학교가 도시 경계 폴리곤 안에 완전하게 있는지 확인하는 꽤 엄격한 정의를 가지고 있다. 이것은 학교가 경계선에 있으면 기술적으로 폴리곤 안에 있지 않는 것을 의미한다. 이것은 폴리곤과 선을 비교할 때 매우 흥미롭게 한다. 선의 끝점이 경계영역의 에 위치하게 되거나, 선의 일부분이 경계영역에 접하게 되는 것은 false 값을 갖게 됨에 충분하다. ST_Within 함수는 바운딩 박스(bounding box) 중첩 연산자(overlap operator: &&)를 포함하고 있음을 명심하여라.
다음으로는 ST_Length 함수를 이용하여 Medford 도시 도로의 총 길이를 계산해 본다. 우리는 ST_Within 연산자를 한번 더 사용할 수도 있지만, 이것은 완벽하게 포함되었는지 판단하는 요청으로 도로의 길이를 더 짧게 계산할 수도 있다. 차라리 ST_Intersects를 사용하여 도로의 길이를 더 길게 계산하여 본다.
이번에는 공간데이터를 다른 데이터들과 함께 사용해 본다. race 테이블은 인구통계치를 tracts 테이블에 있는 인종에 따라 분석해 놓았다. Jackson Country의 각각의 학교마다 인종별 비율을 결정해 보자.
이번에는 릴레이션 연산자의 성능과 유연성을 볼 차례이다.
Note
인구수는 integer로 저장되기 때문에, 우리는 decimal로 계산하기 위해서 floating 포인트로 변환을 하였다. 이것은 CAST white_pop_1race AS DOUBLE PRECSION과 같이 형변환을 하는 것과 같이 많은 방법으로 수행될 수 있다. 나는 위에서 decimal 값(1.0)을 사용하므로써 변환을 하였다.
아래는 릴레이션 연산자와 그에 대한 짧은 설명이다. 각각의 함수들은 참(true) 혹은 거짓(false) 값을반환할 것이다. 나중 섹션에서 이 함수들을 이용하여 더 좋은 사례를 보여줄 것이다. 이 함수들에 대한 완벽한 설명을 보려면 PostGIS 문서를 참조하여라[1].
ST_Contains(A, B)
Returns true if no points in B lie outside of A, and the interiors of A and B share at least one point, otherwise false.
ST_ContainsProperly(A, B)
Returns true if B intersects the interior of A but not the boundary, otherwise false.
ST_Covers(A, B)
Returns true if no point in B is outside of A, otherwise false.
ST_CoveredBy(A, B)
Returns true if no point in A is outside of B, otherwise false.
ST_Crosses(A, B)
Returns true if A and B share some but not all points in common, otherwise false.
ST_Disjoint(A, B)
Returns true if there are no points in common between A and B, otherwise false.
ST_Intersects(A, B)
Returns true if there are any points in common between A and B, otherwise false.
ST_Overlaps(A, B)
Returns true if the geometries intersect, but are not contained and are of the same dimension (i.e. both lines, both points or both polygons), otherwise false.
ST_Touches(A, B)
Returns true if A and B have at least one point in common but their interiors don't overlap, otherwise false.
ST_Within(A, B)
Returns true if A is completely inside B, otherwise false.
윈도우키 + R 키를 눌러 실행창을 실행한 후 커맨드를 입력하면 된다.
Accessibility Wizard – accwiz
Bluetooth Transfer Wizard – fsquirt
Calculator – calc
문자표 Character Map – charmap
c
Check Disk Utility – chkdsk
Clipboard Viewer – clipbrd
Command Prompt – cmd
Component Services – dcomcnfg
Control Panel – control
DDE Shares – ddeshare
Direct X Troubleshooter – dxdiag
Disk Cleanup Utility – cleanmgr
Disk Partition Manager – diskpart
Dr. Watson System Troubleshooting Utility - drwtsn32
Driver Verifier Utility – verifier
Files and Settings Transfer Tool – migwiz
File Signature Verification Tool – sigverif
Firefox – firefox
Fonts Folder – fonts
Free Cell Card Game – freecell
Hearts Card Game – mshearts
Help and Support – helpctr
HyperTerminal – hypertrm
Iexpress Wizard – iexpress
Internet Connection Wizard - icwconn1
Internet Explorer – iexplore
Logs You Out Of Windows - logoff
Malicious Software Removal Tool - mrt
Microsoft Chat – winchat
Microsoft Movie Maker – moviemk
Microsoft Paint – mspaint
Microsoft Syncronization Tool – mobsync
Minesweeper Game – winmine
Netmeeting – conf
Notepad notepad
Object Packager – packager
On Screen Keyboard – osk
Outlook Express – msimn
Paint – pbrush
Performance Monitor – perfmon
Phone Dialer – dialer
Pinball Game – pinball
Printers Folder - printers
Registry Editor – regedit
Remote Access Phonebook - rasphone
Remote Desktop – mstsc
Shuts Down Windows - shutdown
Spider Solitare Card Game – spider
SQL Client Configuration – cliconfg
System Configuration Editor – sysedit
System Configuration Utility – msconfig
System Information - msinfo32
Task Manager – taskmgr
Telnet Client – telnet
Utility Manager – utilman
Windows Address Book – wab
Windows Address Book Import Utility – wabmig
Windows Explorer – explorer
Windows Magnifier – magnify
Windows Media Player – wmplayer
Windows Messenger – msmsgs
Windows System Security Tool – syskey
Windows Update Launches – wupdmgr
Windows Version – winver
Windows XP Tour Wizard – tourstart
Wordpad – write
appwiz.cpl - 프로그램 추가 제거
ncpa.cpl = control netconnections - 네트워크 연결
main.cpl = control mouse - 마우스 옵션
intl.cpl = control international - 국가 및및 언어 옵션
timedate.cpl = control date/time - 날짜/시간날짜/시간
sysdm.cpl = 윈키+Break - 시스템 등록 정보
wscui.cpl - 윈도우즈 보안 센터
nusrmgr.cpl - 사용자 계정 옵션
mmsys.cpl - 사운드 및 오디오 옵션
inetcpl.cpl - 인터넷 옵션
wuaucpl.cpl - 윈도우즈 업데이트 옵션
firewall.cpl - 방화벽 설정 옵션
access.cpl - 내게 필요한 옵션 Accessibility Controls
hdwwiz.cpl - 하드웨어 추가 마법사 Add Hardware Wizard
joy.cpl – 게임 컨트롤러
powercfg.cpl – 전원 옵션 등록 정보
실행창에 커맨드를 실행시키시면 됩니다.
Windows키 + R 키를 누르시면 실행창이 뜨고 그 후에 ""안의 실행어를 입력하시면 됩니다.
인증서 Certificate Manager: "certmgr.msc"
인덱싱 서비스 Indexing Service : "ciadv.msc"
컴퓨터 관리 Computer Management : "compmgmt.msc"
장치 관리자 Device Manager : "devmgmt.msc"
디스크 조각 모음 Disk Defragmenter : "dfrg.msc"
디스크 관리 Disk Management : "diskmgmt.msc"
이벤트 뷰어 Event Viewer : "eventvwr.msc"
공유 폴더 Shared Folders : "fsmgmt.msc"
그룹 정책 Group Policy : "gpedit.msc"
로컬 사용자 및 그룹 Local Users and Groups : "lusrmgr.msc"
Removable Storage : "ntmsmgr.msc"
성능 Performance Monitor : "perfmon.msc"
정책의 결과 집합 Resultant Set of Policy : "rsop.msc"
로컬 보안 설정 Security Policy : "secpol.msc"
서비스 Services : "services.msc"
Windows Management Infrastructure : "wmimgmt.msc"
