| PostgreSQL 8.3.3문서 | ||||
|---|---|---|---|---|
| Prev | Fast Backward | Chapter 52. 데이터베이스의 물리적인 저장장치 | Fast Forward | Next |
본절에서는TOAST(대형 속성 저장 기술：The Oversized-Attribute Storage Technique)의 개요에 대해 설명합니다.
PostgreSQL는 고정된 페이지 사이즈(통상 8킬로바이트)를 사용해, 다수 페이지에 걸치는 튜플을 허락하지 않습니다. 그 때문에, 대규모 필드값을 직접 저장할 수 없습니다. 이 한계를 극복하기 위해, 대규모 필드값를 압축하거나 다수의 물리적인 행으로 분할하거나 합니다. 이것은 사용자로부터는 발생해, 또, 연구 최종 단계의 코드 전체에는 작은 영향 밖에 주지 않았습니다. 이 기법은TOAST(또는"조각난 빵 이래로 최선의 것")라고 하는 애칭으로 불립니다.
일부의 데이터 타입만이TOAST를 지원합니다.
대규모 필드값을 생성할수 없는 데이터타입에 오버헤드를 지게 할 필요는 없습니다.
TOAST를 지원하기 위해서는, 데이터타입은 변수길이(varlena) 표현을 가지지 않으면 안됩니다.
저장하는 값의 최초의 32 비트 워드에는 바이트 단위의 값의(이 워드 자체를 포함한다) 길이가 포함됩니다.
TOAST는 나머지의 표현에 대해 제한하지 않습니다.
TOAST가능한 데이터타입을 지지하는 C언어 함수는 모두,TOAST화 된 입력치를 주의해 취급하지 않으면 안됩니다
(통상 이것은, 입력에 대해서 무엇인가 작업을 하기 전에PG_DETOAST_DATUM를 호출하는 것으로 행해집니다만,
좀 더 효율적인 방법이 가능한 경우도 있습니다).
TOAST상위 2 비트의 varlena 길이 워드를 사용하기 위해서 가능한 데이터타입의 값의 논리 사이즈는 1기가바이트(230 - 1바이트)까지 됩니다. 양비트가 0의 경우, 값은 보통TOAST화되어 있지 않은 데이터 형식이 됩니다. 이러한 비트들 중 하나의 비트가 설정되었을 경우, 값은 압축된 것이고 사용하기 전에 반드시 압축을 해제하여야 한다는 것을 나타냅니다. 나머지 다른 비트가 설정되었을 경우, 값은 행 밖에 저장되어 있다는 것을 나타냅니다. 나머지 값이 실제로 단지 포인터일 경우 정확한 데이터는 다른 곳에서 찾을수 있습니다. 두 개의 비트가 설정 되어 있을 때는, 행 밖의 데이터 역시 압축되어 있습니다. 각각의 경우 하위 비트 안의 varlena 워드는 압축해제에 의해 추출되거나 행 밖의 데이터를 가져오는 논리적 값의 크기를 나타내는 것이 아니라 데이터의 실제 크기를 나타냅니다.
테이블의 임의의 컬럼이TOAST가능한 경우, 그 테이블은 연관되는TOAST테이블을 가집니다. TOAST테이블의 OID는 테이블의pg_class. reltoastrelid항목에 저장됩니다. 자세한 것은 다음에 설명합니다만, 행 밖의TOAST화 된 값은TOAST테이블내에 보관 유지됩니다.
사용되는 압축 기술은, LZ계의 압축 기술의 하나로 간단하고 상당히 빠릅니다. 자세한 것은src/backend/utils/adt/pg_lzcompress.c를 참조해 주세요.
행 밖의 값은(압축되는 경우는 압축 후에) 최대TOAST_MAX_CHUNK_SIZE바이트의 청크에 분할됩니다 (이 값은 BLCKSZ/4보다 약간 작은 값이거나, 기본값에 의해 2000바이트 정도 입니다.) 각 청크는, 데이터를 가지는 테이블과 제휴하는TOAST테이블내에 개별의 행으로서 저장됩니다. 모든TOAST테이블은chunk_id컬럼chunk_id(특정의TOAST화 된 값을 식별하는 OID), chunk_seq (그 값 안의 청크에 대한 시퀀스 번호),chunk_data(청크의 실제의 데이터) 열을 가집니다. chunk_id와chunk_seq에 대한 일의성 인덱스는 값의 추출을 고속화합니다. 따라서, 행 밖의TOAST화 된 값을 나타내는 포인터 datum에는, 검색처가 되는TOAST테이블의 OID와 지정한 값의 OID를 저장하지 않으면 안됩니다. 간편성을 위해서, 포인터 datum에는 논리 datum 사이즈(기존의 비압축의 데이터 길이)와 실제의 저장 사이즈(압축시에는 다릅니다)도 저장됩니다. varlena 헤더 바이트에 할당하기 위해서TOAST포인터 datum의 총사이즈는, 표현되는 값의 실제 사이즈에 관계없이, 20바이트가 됩니다.
TOAST의 코드는, 테이블내에 저장되는 값이TOAST_TUPLE_THRESHOLD(통상 2킬로바이트)를 넘을 때에게만 실행됩니다. TOAST코드는, 행의 값이 더 이상 얻어지지 않거나, 그 이상의 축소를 할 수 없게 될 때까지, 필드값의 압축이나 행밖으로의 이동을 실시합니다. 업데이트 조작중에는, 통상 변경되지 않는 값은 그대로 남습니다. 행 밖의 값을 가지는 행의 업데이트에서는, 행 밖의 값의 변경이 없으면TOAST하는 것을 요하지 않습니다.
TOAST코드에서는, 이하의TOAST가능한 열을 저장하기 위한 4개의 다른 전략을 인식합니다.
PLAIN는 압축이나 행 밖의 저장을 방지합니다. 게다가 varlena타입에서의 단일 바이트 헤더의 사용을 무효로 합니다. 이것은TOAST화가 불가능한 데이터타입의 컬럼에 대해서만 취할 수 있는 전략입니다.
EXTENDED에서는, 압축과 행 밖의 저장을 허락합니다. 이것은 대부분의TOAST가능의 데이터타입의 기본값입니다. 압축이 먼저 시도되고, 그런데도 행이 너무 크다면 행 밖에 저장합니다.
EXTERNAL는 비압축된 행 밖의 저장을 허락합니다. EXTERNAL를 사용하면,text와bytea 컬럼 전체에 대한 서브스트링 조작이 빨라집니다. 이러한 조작은 비압축의 행외의 값으로부터 필요한 부분을 꺼낼 때에 최적화되기 때문에입니다 (저장 스페이스가 증가하는 단점이 있습니다).
MAIN는 압축을 허락합니다만, 행밖의 저장은 할 수 없습니다 (실제로는 이러한 열에 대해서도 행 밖의 저장은 행해집니다. 그러나, 그 밖에 행을 축소할 방법이 없는 경우의 마지막 수단입니다).
TOAST가능한 데이터타입은 각각, 그 데이터타입의 컬럼용의 기본 전략을 지정합니다. 그러나ALTER TABLE SET STORAGE를 사용해, 어느 테이블 컬럼의 전략을 변경할 수가 있습니다.
이 스키마에는, 페이지를 걸치는 행의 값을 허가하는 것과 같이 직접적 방법에 비해 많은 이점이 있습니다. 통상 쿼리는 비교적 작은 키 값에 대한 비교로 검증되었다는것을 가정하면, 집행자의 일의 대부분은 주요한 행의 항목을 사용하는데 행해지게 됩니다. TOAST화 속성의 대규모 값은, (그것이 완전히 선택되었을때) 결과 집합을 클라이언트에 되돌릴 때에 나타날 뿐입니다. 이 때문에, 주테이블은 행 밖의 저장을 사용하지 않는 경우에 비해 점점 작아져 그 행은 공유 버퍼 캐쉬에 적합하게 됩니다. 정렬 집합도 또한 작아져, 정렬이 완전하게 메모리내에서 행해지는 빈도가 높아집니다. 소규모의 시험 결과입니다만, 전형적인 HTML 페이지와 그 URL를 가지는 테이블에서는,TOAST테이블을 포함해 원래의 데이터 사이즈의 대략 반으로 저장할 수 있어 뿐만 아니라 주테이블에는 전체의 데이터의 대략 10%마셔(URL와 일부의 작은 HTML 페이지)가 저장되었습니다. 비교를 위해서 실행한 모든 HTML 페이지를 7킬로바이트 정도로 줄인TOAST화하지 않는 테이블과 비교해 실행했을시에는 차이가 없었습니다.