PostgreSQL

1. Visibility Map(가시성 맵)란? Visibility Map은 트랜잭션에서 데이터에 접근할 때 어떤 데이터가 가시적인지(모든 트랜잭션에서 읽을 수 있는지), 안정적인지 (동결된 튜플인지) 판별하는데 도움을 준다. 데이터 접근 시 불필요한 I/O작업을 줄여주고, 데이터베이스가 어떤 페이지를 직접 접근할 수 있는지를 빠르게 판단함으로써 시스템의 효율적을 올려주는 역할을 한다. 2. Visibility Map(가시성 맵)의 데이터 관리 Visibility Map은 데이터를 주요 데이터와는 별도의 파일(fork)에 _vm 접미사를 붙여 관리한다. 예를 들어 예를 들어 employees 테이블이 있다고 하면 테이블의 Visibility Map은 별도의 포크에 저장된다. 이 포크의 이름은 파일 노드 번호에 _vm 접미사를 붙여 구성되며, 예를 들어 파일 노드번호가 12345인 경우 VM 파일은 12345_vm으로 저장된다. 데이터에는 해당 테이블의 page가 모든 트랜잭션에 보이는지, 동결된 튜플만을 포함하는지 등의 정보를 저장한다. 데이터베이스가 employees 테이블을 조회할 때, 가시성 맵을 먼저 확인한다. 만약 쿼리가 접근하려는 pages가 모든 트랜잭션에게 보이는 상태라고 확인되면, 시스템은 데이터에 더 빠르게 접근한다. 불필요한 버전검사나 락을 안 해도 되기에 성능이 향상된다. ...

1. TOAST (The Oversized-Attribute Storage Technique)란? 데이터베이스의 대용량 속성을 효율적으로 저장하고 관리하기 위한 기법으로, 데이터를 효율적으로 처리하고, 저장공간을 최적화하며 데이터 접근시간을 개선하기 위해 사용된다. PostgreSQL의 각 page영역은 일반적으로 8kb의 고정된 크기로 되어있고 각 tuple이 여러 페이지에 나뉘어 존재할 수 없다. (매우 큰 값을 바로 저장할 수 없다.) 이 한계를 극복하기 위해서, 큰 필드 값은 압축되어 저장되거나 여러 개의 물리적 ROWS로 분할되어 저장된다. 이 과정은 보통 개발자가 별도의 처리로직을 구현할 필요 없이 데이터베이스 백앤드에서 자동으로 이루어진다. 이 기법을 TOAST (The Oversized-Attribute Storage Technique)라고 하며 PostgreSQL에서 큰 데이터 값을 메모리 내에서 효율적으로 처리하는 데에 사용된다. ...

1. Disk 영역 PostgreSQL의 저장 영역은 크게 Heap, Index, Toast 3개로 나뉜다. 각 테이블의 대부분의 데이터를 메인 heap 영역에 저장한고, 테이블 칼럼 중 매우 큰 데이터를 받을 수 있는 칼럼은 TOAST 영역에 별도 저장한다. TOAST 테이블에는 실제 데이터를 저장하고, 본래 테이블에는 해당 데이터를 가리키는 포인터만 남게 된다. TOAST 테이블의 유효한 인덱스는 1개뿐이고, 기준 테이블에는 더 많은 인덱스가 존재할 수 있다. 테이블과 인덱스는 각각의 디스크파일에 저장 되며 각 파일이 1G가 넘으면 별도 파일로 분리된다. ...

1. PostreSQL의 물리적 한계치 물론 사용 가능한 disk 용량, 성능 이슈 등 실직적인 제한이 먼저 적용되겠지만, 모든 자원이 충분하다고 가정할 때 물리적인 limit이다. 항목 최대치 데이터베이스 사이즈 무제한 데이터베이스 수량 4,294,950,911 데이터베이스 당 Relations(테이블, 뷰, 인덱스 등의 테이블 객체)수량 1,431,650,303 Relations 사이즈 32TB 테이블 당 ROW 수량 4,294,967,295 pages영역의 크기에 해당하는 ROW 테이블 당 COL 수량 1,600 결과셋의 COL 수량 1,664 COL 사이즈 1GB 테이블 당 인덱스 수량 무제한 인덱스 당 컬럼 32 파티션 키 32 식별자 키 (ex, 테이블, ROW, COL 등의 명칭) 63 bytes function의 매개변수 100 쿼리파라미터 65,535 테이블당 ROW 수량은 4,294,967,295개의 pages 영역에 저장 가능한 ROWS로 제한되어 있는데, 4,294,967,295는 2^32 - 1로 32비트 시스템에서 사용가능한 최대 정수이다. 데이터베이스에서 최대로 관리할 수 있는 pages의 수며, 각 페이지에는 여러 튜플이 저장될 수 있다. 테이블 당 인덱스의 수량은 이론상은 “무제한"이제만, 실제로는 데이터베이스가 관리할 수 있는 최대 Relations (테이블, 뷰, 인덱스 등의 테이블 객체)에 의해 제한된다. 위 표의 인덱스 당 칼럼 수, 파티션 키 수량, 식별자 키, 함수 매개변수 최대 수량은 기본값이며 설정값을 변경하여 증가시킬 수 있다. 테이블 당 최대 칼럼 수는 1600개이지만, 저장되는 튜플이 8192바이트의 힙 페이지에 fit 해야 한다는 조건 때문에 더 줄어들 수 있다. 예를 들어 튜플 헤더를 제외하고, 1600개의 int칼럼 투플 - 6400 bytes로 힙페이지에 정상 저장 가능 (6400 < 8192) 1600의 bigint칼럼 투플 - 12800 bytes로 heap page를 초과 (12800 < 8192) text, varchar, char같이 길이 변경이 가능한 필드의 경우 값이 크면 TOAST 테이블 영역이라 불리는 주 저장공간 외부영역에 값을 저장하고, 본래 테이블에는 해당 데이터를 가리키는 포인터만 남게 된다. 테이블에서 삭제된 칼럼들도 최대 칼럼 개수에 포함된다. 삭제된 칼럼에 대해 새로 생성된 ROW도 내부적으로는 null 표시되지만, 추적을 위해 여전히 공간을 차지하여 최대 개수에 영향을 준다. 2. 결론 운영 단계에서 1억 개 이상의 테이블을 생성하거나 1000개가 넘는 칼럼의 테이블을 생성하는 일은 없을 것이고, 이러한 물리적 제약보다 자원의 한계 (용량 및 성능이슈)를 먼저 만날 것이기에 정확한 수치를 정확히 외울 필요는 없겠지만, 삭제된 칼럼들과 그 이후 생성된 ROW들이 내부적으로는 추적을 위해 해당 컬럼을 NULL로 저장하며, 이 과정에서 사용되는 NULL비트맵이 공간을 차지하기에 최대 카운트에 영향을 준다는 것 운영 시에 유의해야 할 내용이다. ...

1. Index-Only Scans PostgreSQL의 모든 인덱스는 "보조(Secondary)" 인덱스이다. 각 인덱스는 테이블의 메인 데이터 영역(테이블의 heap 영역)과 분리되어서 저장된다. 그렇기 때문에 일반적인 인덱스 스캔에서 각 ROW를 찾기 위해서는, index와 heap 영역 모두에 접근하여 데이터를 탐색해야 한다. 보통 WHERE 절 조건에 부합하는 데이터들은 인덱스 영역 - 서로 가까이 존재하여 정렬된 순서로 빠르게 접근할 수 있다. (인덱스 테이블은 정렬된 상태로 생성) heap 영역 - 특별한 규칙 없이 어디에서든 분포할 수 있기에 heap 영역을 스캔할 때는 무작위로 접근하게 되어 속도가 느리다. 이 퍼포먼스 문제를 해결하기 위해 PostgreSQL은 힙 영역에 대한 접근 없이 인덱스 내에서만 데이터를 조회하는 Index-only 스캔을 지원한다. 기본 개념은 말 그대로 heap 영역의 참조 없이 index 항목에서 바로 값을 반환하는 것으로 매우 효율적으로 보이지만 몇 가지 제한사항이 있다. ...