블록 범위 인덱스

Block Range Index

블록 범위 인덱스 또는 BRIN은 데이터베이스 인덱싱 기법이다.그것들은 매우[i] 큰 테이블로 성능을 향상시키기 위한 것이다.

BRIN 인덱스는 수평 파티셔닝 또는 샤딩과 유사한 이점을 제공하지만 파티션을 명시적으로 선언할 필요는 없다.[1]

BRIN은 크기가 크고 인덱스 키 값을 쉽게 정렬하고 MinMax 함수로 평가하는 테이블의 인덱스에 적용할 수 있다.[ii]

BRIN은 원래 2013년 2쿼드런트의 알바로 에레라가 '민맥스 지수'[2]로 제안한 바 있다.지금까지의 구현은 데이터베이스 테이블에 대한 내부 구현 및 저장 기법과 밀접하게 연계되어 있다.이것은 그들을 효율적이게 만들지만, 특정한 판매상들로 제한한다.지금까지 PostgreSQL은 Postgre에서 이러한 특정 기능을 갖춘 라이브 제품을 발표한 유일한 벤더임SQL 9.5.[3][4]다른 공급업체들은 Oracle, Netezza [5][6]'구역 맵',[7] Infobright '데이터 팩',[8] MonneDB[9] 및 ORC/Parquet이 포함된 Apache Hive를 포함한 [2]몇 가지 유사한 기능에 대해 설명하였다.[10]

디자인

B-트리 지수 구조
BRIN 지수 구조

BRIN은 대규모 데이터 블록을 "소형" 형태로 "요약"하여 운영하는데, 초기에는 데이터베이스 질의에서 많은 블록을 제외하기 위해 효율적으로 테스트할 수 있다.이러한 테스트는 각 비교에 대해 큰 데이터 블록을 제외한다.BRIN은 큰 블록을 작은 튜플로 표현함으로써 초기에 데이터 볼륨을 줄이고, 많은 블록을 제거함으로써 데이터베이스 노드가 행별로 검토해야 하는 상세 데이터의 양을 실질적으로 줄인다.[11]

대형 데이터베이스의 데이터 저장소는 층을 이루고 청크 처리되며, 테이블 저장소는 '블록'으로 배열된다.각 블록은 각 청크에[iii][13] 약 1MB가 들어 있으며 디스크 기반 스토리지 계층에서 특정 블록을 요청하여 검색된다.BRIN은 이 위에 있는 경량 메모리 내 요약 계층이다. 즉, 인덱스의 각 튜플은 여기에 포함된 데이터의 범위, 즉 최소값과 최대값, 그리고 블록에 관심 열에 대해 Null이 아닌 데이터가 포함된 경우 하나의 블록을 요약한다.[14]

BRIN은 관심가치가 포함된 테이블의 영역을 위치시키는 기존 지표와 달리 "부정지수"[5]로 작용해 관심도가 낮기 때문에 더 이상 처리할 필요가 없는 블록을 보여준다.

일부 간단한 벤치마크에서는 색인화되지 않은 표에 비해 인덱스 스캔을 통해 검색 성능을 5배 향상할 것을 제안한다.[3]B-tree에 비해 유지보수 오버헤드를 피한다.[2]

BRIN은 매우 가볍기 때문에, 그것들은 완전히 메모리에 저장될 수 있기 때문에, 스캔하는 동안 디스크 오버헤드를 피할 수 있다.B-트리도 마찬가지일 수 있다:B-트리에는 테이블의 약 N행마다 트리 노드가 필요하며, 여기서 N은 단일 노드의 용량이기 때문에 인덱스 크기가 크다.BRIN은 각 블록(많은 행의)에 대해 튜플만 요구하므로, 인덱스는 디스크와 메모리의 차이를 만들기에 충분할 정도로 작아진다.'좁은' 테이블의[iv] 경우 B-트리 인덱스 볼륨은 테이블 자체의 볼륨에 접근한다. BRIN은 테이블의 5-15%에 불과하다.[15]

이점

검색 및 인덱스 검색

대형 데이터베이스 색인은 일반적으로 B-트리 알고리즘을 사용한다.BRIN은 항상 B-tree를 대체하는 것은 아니며, 지수를 순차적으로 스캔하는 것이 개선된 것이며, 지수를 주문하는 특정 조건과 검색 대상이 이러한 값들의 좁은 집합이 되는 경우에 특정한 (그리고 잠재적으로 큰) 이점이 있다.일반적인 경우, 무작위 데이터가 있는 경우, B 트리는 여전히 우수할 수 있다.[3]

Oracle Exadata의 Smart Scanning과 공유되는 BRIN 기법의 특별한 이점은 빅 데이터나 데이터 웨어하우징 애플리케이션과 함께 이러한 유형의 지수를 사용하는 것인데,[6] 여기서 표의 거의 대부분이 관심 범위와 무관하다고 알려져 있다.BRIN은 관심 있는 데이터를 포함할 수 있는 블록만 검색하고 범위를 명백히 벗어나거나 이 열에 대한 데이터가 포함되지 않은 블록만 검색하여 테이블을 쿼리할 수 있도록 한다.

삽입하다

대형 테이블의 처리에 관한 규칙적인 문제는 검색에는 지수를 사용해야 하지만, 이 지수를 유지하면 새로운 기록의 추가를 늦춘다는 것이다.일반적인 관행은 추가사항을 함께 그룹화하여 하나의 대량 트랜잭션으로 추가하거나, 색인을 삭제하거나, 새 레코드 배치를 추가한 후 색인을 다시 생성하는 것이었습니다.이 두 가지 모두 동시 읽기/쓰기 작업에 지장을 주며, 일부 연속 운영 기업에서는 불가능할 수 있다.[16]

브린(BRIN)으로 B-트리 대비 지수 유지에 따른 둔화폭이 크게 줄어든다.[17]Wong은 B-tree가 색인화되지 않은 10GB 테이블의 추가 속도를 85%까지 늦췄지만 비교 가능한 BRIN의 오버헤드는 11%[1]에 불과했다.

인덱스 생성

BRIN은 B-트리 수평 파티셔닝이 필요한 매우 큰 데이터에 대해 생성될 수 있다.[14]

BRIN을 생성하는 것도 B-트리보다 80% 더 빠르다.[1]이것은 코드 변경을 요구하지 않고 드롭 애드-리인덱스 접근방식을 사용하는 기존 데이터베이스 애플리케이션을 리팩터링하는 데 유용한 개선이 될 것이다.

실행

테이블 순서에 대한 의존성

단일 테이블의 서로 다른 열에 대해 복수의 BRIN을 정의할 수 있다.그러나 제약이 있다.

BRIN은 핵심 가치의 순서가 스토리지 계층의 블록 구성을 따르는 경우에만 효율적이다.[13][15]가장 간단한 경우, 이것은 키의 순서와 일치하기 위해 종종 그 안에 있는 행의 생성 순서인 표의 물리적 순서가 필요할 수 있다.이 키가 생성 날짜인 경우, 이는 사소한 요구 사항일 수 있다.[14]: 9

데이터가 실제로 무작위이거나 '핫' 데이터베이스에 핵심 값이 많이 뒤틀린 경우 BRIN의 기초가 되는 가정이 무너질 수 있다.모든 블록에는 "관심 항목"이 포함되어 있으므로 BRIN 범위 필터에 의해 초기에 제외될 수 있는 것은 거의 없다.

대부분의 경우 BRIN은 테이블당 하나의 인덱스로 제한된다.복수의 BRIN을 정의할 수 있지만, 하나만 적절한 순서를 가질 가능성이 있다.두 개(또는 그 이상) 인덱스의 순서 동작이 유사한 경우, 동일한 표에 여러 BRIN을 정의할 수 있고 유용할 수 있다.분명한 예로는 작성 날짜와 record_id 컬럼 둘 다 기록 작성 순서와 함께 단조롭게 증가하는 것이다.다른 경우에는 키 값이 단조적이지 않을 수 있지만, 레코드의 물리적 순서 내에 여전히 강한 그룹이 존재한다면 BRIN이 효과적이다.

Exadata 스토리지 인덱스

BRIN은 Oracle Exadata "Storage Indexes"[2][5][18]와 비슷한 점이 있다.Exadata는 아키텍처 스택에서 '스토리지 계층'이라는 강력한 개념을 가지고 있다.테이블 데이터는 저장소 서버의 블록 또는 '저장 셀'로 저장된다.이러한 스토리지 셀은 스토리지 서버에 불투명하며 식별자에 의해 요청 시 데이터베이스 엔진으로 반환된다.이전에는 데이터베이스 노드가 모든 저장 셀을 검색하기 위해 모든 저장 셀을 요청해야 했다.[6]

스토리지 인덱스는 이 계층에서 데이터 정리(더 이상 관심이 없는 섹션을 효율적으로 표시)를 제공한다.[13][v][19]저장 지수는 저장 서버의 메모리에 로드되므로, 셀 요청이 발행될 때 검색 값으로 지정될 수 있다.이러한 셀을 스토리지 인덱스와 비교한 후 관련 셀만 데이터베이스 노드로 반환하면 된다.

스토리지 인덱스의 성능 이점은 인덱싱된 열에 많은 null이 포함되어 있을 때 가장 뚜렷하게 나타난다.희박한 데이터를 검색하면 엄청난 성능 이점을 얻을 수 있다.[20]

개발

Postgre 개발SQL은 액슬 프로젝트의 일부로 수행됨(초대형 유럽 데이터베이스를 위한 고급 분석)[21]이 작업은 유럽연합의 제7차 프레임워크 프로그램(FP7/2007-2013)에 의해 부분적으로 자금을 지원받았다.[22]

PostgreSQl

Postgre에 대한 구현SQL은 2013년에 처음으로 명백해졌다.[2]BRIN은 Postgre 9.5 릴리즈에 등장했다.2016년 초의 SQL.[15][23]

참고 항목

메모들

  1. ^ 여기서 'Large'는 필드 크기나 전체 크기가 아닌 테이블의 행 수를 가리킨다.
  2. ^ 다수의 데이터 항목을 효율적으로 평가하고 최소값과 최대값을 반환하는 함수."최소"와 "최대"의 개념은 광범위하며, 분류 가능한 모든 데이터 유형 또는 이들의 조합에 적용될 수 있다.
  3. ^ PostgreSQL은 기본 BRIN 청크 크기가 128×8k 페이지 또는 1MB이다.[3] Oracle은 이러한 '저장소 영역'을 말하며 기본 크기는 1MB이다.[12]
  4. ^ 테이블 열은 인덱싱된 열보다 겨우 넓다.
  5. ^ Foote는[13] 색인을 "Null이 존재하는지 여부를 나타내는 깃발"을 들고 있는 것으로 설명한다.이것은 아마도 오자일 것이다:Oracle은 이들을 "확실히 값을 포함하지 않을 영역을 식별한다"[5]는 "부정 지수"라고 기술하고 있다. 이 경우 깃발은 "Null만 존재한다" 또는 "Null이 아닌 모든 것이 존재한다"를 나타내는 것으로 더 명확하게 기술될 것이다.

참조

  1. ^ a b c Mark Wong (October 10, 2014). "Loading Tables and Creating B-tree and Block Range Indexes". AXLE project.
  2. ^ a b c d e Alvaro Herrera (2013-06-14). "Minmax indexes". Pg Hackers.
  3. ^ a b c d "What's new in PostgreSQL 9.5". PostgreSQL.
  4. ^ "Chapter 62. BRIN Indexes". PostgreSQL 9.5.0 Documentation. 2016.
  5. ^ a b c d Arup Nanda (May–June 2011). "Smart Scans Meet Storage Indexes". Oracle Magazine. Oracle.
  6. ^ a b c "Understanding Storage Indexes in Oracle Exadata".
  7. ^ "With Netezza Always Use Integer Join Keys For Good Compression, Zone Maps, And Joins". Netezza. 2010.
  8. ^ "Data packs". Infobright. Archived from the original on 2009-06-27.
  9. ^ "Cooperative Scans: Dynamic Bandwidth Sharing in a DBMS". MonetDB. 2007. CiteSeerX 10.1.1.108.2662. {{cite journal}}:Cite 저널은 필요로 한다. journal=(도움말)
  10. ^ "Hive Optimizations with Indexes, Bloom-Filters and Statistics". Jörn Franke. 2015.
  11. ^ Herrera, Alvaro (7 November 2014). "commitdiff - BRIN: Block Range Indexes". git.postgresql.org. Retrieved 2017-10-03.
  12. ^ "When is Exadata's storage indexes used?". OakTable.net.
  13. ^ a b c d Richard Foote (4 October 2012). "Exadata Storage Indexes – Part I".
  14. ^ a b c Mark Wong (10 March 2015). "PostgreSQL Performance Presentation" (PDF). pp. 7–10.
  15. ^ a b c "Block Range (BRIN) Indexes in PostgreSQL 9.5". Python Sweetness. May 22, 2015.
  16. ^ Petr Jelinek (28 November 2014). "Progress on online upgrade". AXLE project.
  17. ^ Mark Wong (10 October 2014). "Index Overhead on a Growing Table".
  18. ^ "Oracle Sun Database Machine Application Best Practices for Data Warehousing". Oracle. 1094934.1. {{cite web}}:누락 또는 비어 있음 url=(도움말)
  19. ^ Marc Fielding (July 20, 2010). "Exadata's Best Kept Secret: Storage Indexes".
  20. ^ Kerry Osborne (August 10, 2010). "Oracle Exadata – Storage Indexes".
  21. ^ "AXLE project (Advanced Analytics for Extremely Large European Databases)". 2014.
  22. ^ "European Union's Seventh Framework Programme (FP7/2007-2013) under grant agreement n° 318633". {{cite web}}:누락 또는 비어 있음 url=(도움말)
  23. ^ Alvaro Herrera (2014-11-07). "BRIN: Block Range Indexes". PostgreSQL. Retrieved 2016-01-14.