>  기사  >  시스템 튜토리얼  >  PostgreSQL의 발견 여정

PostgreSQL의 발견 여정

王林
王林앞으로
2024-01-17 08:15:151171검색

PostgreSQL의 발견 여정

Postgres에는 여러 가지 인덱스 유형이 있으며 새 버전마다 새로운 인덱스 유형이 추가되는 것 같습니다. 각 인덱스 유형은 유용하지만 사용할 유형은 (1) 데이터 유형, 경우에 따라 (2) 테이블의 기본 데이터 및 (3) 수행되는 조회 유형에 따라 달라집니다. 다음 내용에서는 Postgres에서 사용할 수 있는 인덱스 유형과 어떤 인덱스 유형을 사용해야 하는지 소개합니다. 시작하기 전에 안내할 인덱스 유형 목록은 다음과 같습니다.

B-트리
일반화 역지수(GIN)
일반화된 역해석 트리(GiST)
공간 분할 GiST(SP-GiST)
블록 범위 지수(BRIN)
해시
이제 인덱싱을 시작해 보겠습니다.

Postgres에서는 B-Tree 인덱스가 가장 일반적으로 사용되는 인덱스입니다

컴퓨터공학 학위가 있다면 B-Tree 인덱싱을 가장 먼저 배울 수 있습니다. B-트리 인덱스는 항상 균형을 유지하는 트리를 만듭니다. 인덱스를 기반으로 무언가를 찾을 때 트리를 탐색하여 키를 찾고 찾고 있는 데이터를 반환합니다. 인덱스를 사용하면 수천 개의 레코드를 순차적으로 스캔하는 것과 달리 몇 페이지(몇 개의 레코드만 반환하는 경우)만 읽으면 되므로 순차 스캔보다 훨씬 빠릅니다.

표준 CREATE INDEX 문을 실행하면 B-트리 인덱스가 생성됩니다. B-트리 인덱스는 텍스트, 숫자, 타임스탬프 등 대부분의 데이터 유형에 유용합니다. 데이터베이스에서 인덱스를 처음 사용하고 데이터베이스에서 Postgres의 고급 기능을 너무 많이 사용하지 않는 경우 표준 B-Tree 인덱스를 사용하는 것이 아마도 최선의 선택일 것입니다.

다중 값 열의 GIN 인덱스

일반적으로 GIN이라고 불리는 Generalized Inverted Index는 단일 열에 여러 값이 포함된 데이터 유형에 가장 적합합니다.

Postgres 문서에 따르면:

"GIN은 색인화되는 항목이 복합 값이고 색인에 의해 처리되는 쿼리가 복합 항목에서 발생하는 값을 검색해야 하는 상황을 처리하도록 설계되었습니다. 예를 들어 이 항목은 문서일 수 있고 쿼리는 문서에 포함된 특정 문자를 검색할 수 있습니다.”

이 범위에 포함된 가장 일반적인 데이터 유형은 다음과 같습니다.

h스토어
배열
범위
JSONB
GIN 인덱스의 가장 만족스러운 점 중 하나는 복합 값에 저장된 데이터를 이해하는 능력입니다. 그러나 GIN 인덱스에는 추가되는 각 개별 유형의 데이터 구조에 대한 특정 지식이 필요하므로 모든 데이터 유형이 GIN 인덱스에서 지원되는 것은 아닙니다.

겹치는 값이 있는 행에 대한 GiST 인덱스

GiST(Generalized Inverted Seach Tree) 인덱스는 데이터가 동일한 열에 있는 다른 데이터 행과 겹칠 때 가장 적합합니다. GiST 인덱스를 가장 잘 활용하는 방법은 기하학 데이터 유형을 선언하고 두 개의 다각형에 몇 개의 점이 포함되어 있는지 알고 싶은 경우입니다. 어떤 경우에는 특정 점이 상자에 포함될 수 있지만 동시에 다른 점은 다각형에만 존재할 수 있습니다. GiST를 사용하여 색인화되는 일반적인 데이터 유형은 다음과 같습니다.

기하학 유형
전체 텍스트 검색이 필요한 텍스트 유형
GiST 인덱스 크기에는 고정된 제한이 많이 있습니다. 그렇지 않으면 GiST 인덱스가 극도로 커질 수 있습니다. 그 대가로 GiST 인덱스는 손실이 있습니다(부정확).

공식 문서에 따르면:

"GiST 인덱스는 손실이 있습니다. 즉, 인덱스가 잘못된 일치를 생성할 수 있으므로 잘못된 일치를 제거하기 위해 실제 테이블 행을 확인해야 합니다. (PostgreSQL은 필요할 때 자동으로 이 작업을 수행합니다.)"

이것은 잘못된 결과를 얻게 된다는 의미가 아니라 Postgres가 데이터를 반환하기 전에 이러한 가짜 결과를 필터링하기 위해 약간의 추가 작업을 수행한다는 의미입니다.

특별 팁: GIN 및 GiST 인덱스는 종종 동일한 데이터 유형에 사용될 수 있습니다. 일반적으로 성능은 좋지만 디스크 공간을 많이 차지하며 그 반대의 경우도 마찬가지입니다. GIN과 GiST의 경우 모든 상황에 적용할 수 있는 일률적인 솔루션은 없지만 위의 규칙은 가장 일반적인 상황에 적용되어야 합니다.

더 큰 데이터를 위한 SP-GiST 인덱스

SP-GiST(공간 분할 GiST) 인덱스는 Purdue Research의 공간 분할 트리를 채택했습니다. SP-GiST 인덱스는 데이터에 자연적인 클러스터링 요소가 있고 균형 트리가 아닌 경우에 자주 사용됩니다. 전화번호가 좋은 예입니다(적어도 미국 전화번호는 그렇습니다). 형식은 다음과 같습니다:

3자리 지역번호
3자리 프리픽스 번호(구 전화 교환기 관련)
4자리 줄번호
이는 첫 번째 세트의 처음 세 자리 숫자에 자연적인 클러스터링 요소가 있고 그 다음 세 자리 숫자의 두 번째 세트가 이어지며 숫자가 균등하게 분포된다는 것을 의미합니다. 그러나 전화번호의 일부 지역번호에서는 다른 지역보다 포화 상태가 더 높습니다. 그 결과 매우 불균형한 트리가 될 수 있습니다. 자연적인 집계 요소가 사전에 있고 데이터가 균등하게 분산되지 않기 때문에 전화번호와 같은 데이터는 SP-GiST에 좋은 사례가 될 수 있습니다.

더 큰 데이터를 위한 BRIN 인덱스

BRIN(블록 범위 인덱스)은 SP-GiST와 같은 일부 상황에 중점을 두고 데이터에 자연스러운 순서가 있고 데이터 크기가 큰 경우에 가장 잘 사용됩니다. 연대순으로 10억 개의 레코드가 있는 경우 BRIN이 유용할 수 있습니다. 여러 우편번호와 같이 자연적으로 그룹화되는 대규모 데이터 세트를 쿼리하는 경우 BRIN은 유사한 우편번호가 디스크의 가까운 위치에 저장되어 있는지 확인하는 데 도움이 될 수 있습니다.

날짜나 우편번호별로 정렬된 매우 큰 데이터베이스가 있는 경우 BRIN 인덱스를 사용하면 일부 불필요한 데이터를 매우 빠르게 건너뛰거나 제외할 수 있습니다. 또한 BRIN 인덱스는 전체 데이터 크기에 비해 상대적으로 작으므로 데이터 세트가 클 경우 BRIN 인덱스가 더 나은 성능을 발휘할 수 있습니다.

해시 인덱스, 마침내 더 이상 충돌을 두려워하지 않습니다

해시 인덱스는 수년 동안 Postgres에 사용되어 왔지만 Postgres 10이 출시될 때까지 해시 인덱스 사용에 대한 큰 주의 사항이 있었습니다. 이는 WAL 로그가 아니었습니다. 즉, 서버가 충돌하고 대기로 장애 조치할 수 없거나 예를 들어 wal-g를 사용하여 아카이브에서 복원할 수 없으면 다시 빌드할 때까지 해당 인덱스를 잃게 됩니다. Postgres 10이 출시되면서 이제 WAL에 기록되므로 다시 사용하는 것을 고려할 수 있지만 실제 질문은

입니다.

해시 인덱스는 때때로 B-Tree 인덱스보다 빠른 조회를 제공하고 생성 속도도 빠릅니다. 가장 큰 문제는 "동등" 비교 작업에만 제한되어 있으므로 정확히 일치하는 조회에만 사용할 수 있다는 것입니다. 이로 인해 해시 인덱스는 일반적으로 사용되는 B-Tree 인덱스보다 유연성이 훨씬 떨어지므로 이를 대체물로 생각해서는 안 되며 특별한 경우를 위한 인덱스로 생각해야 합니다.

어떤 것을 사용해야 하나요?

방금 많이 소개했는데 조금 겁이 나시면 정상입니다. 이전에 이것을 알고 있다면 CREATE INDEX는 항상 B-Tree를 사용하여 인덱스를 생성하며 좋은 소식은 Postgres 성능이 대부분의 데이터베이스에 대해 좋거나 매우 좋다는 것입니다. :) 더 많은 Postgres 기능 사용을 고려하고 있다면 다른 Postgres 인덱스 유형을 사용할 때의 치트 목록은 다음과 같습니다.

B-트리 - 대부분의 데이터 유형 및 쿼리에 적합
GIN - JSONB/hstore/배열용
GiST - 전체 텍스트 검색 및 기하학적 데이터 유형용
SP-GiST - 자연적인 집계 인자가 있지만 분포가 고르지 않은 대규모 데이터 세트에 적합합니다
BRIN - 순차적인 대규모 데이터 세트에 적합
해시 - 동등 연산에 적합하지만 일반적으로 B-Tree 인덱스만 있으면 됩니다.
이 기사에 대해 질문이나 피드백이 있으면 언제든지 Slack 채널에 참여해 주세요.

위 내용은 PostgreSQL의 발견 여정의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!

성명:
이 기사는 linuxprobe.com에서 복제됩니다. 침해가 있는 경우 admin@php.cn으로 문의하시기 바랍니다. 삭제