Bitmap Index의 원리와 적용: 비트 연산·NULL·DML 동시성

핵심 요약

Bitmap Index는 Key 값마다 여러 Row의 위치를 Bitmap으로 표현합니다.

B-tree Index
  Key Entry → 일반적으로 한 Row의 ROWID

Bitmap Index
  Key 값 + ROWID 범위 + Bitmap
  → 한 Entry가 여러 Row의 포함 여부를 표현

Oracle은 Bitmap을 단순한 전체 Table 길이의 한 줄 Bit Array로만 저장하지 않습니다. 실제 Bitmap Entry는 개념적으로 다음 요소를 가집니다.

Index Key
Low ROWID
High ROWID
해당 ROWID 범위의 Bitmap Piece

같은 Key도 ROWID 범위가 다르면 여러 Entry·Piece로 나뉠 수 있습니다. Oracle은 B-tree 구조의 Leaf Block에 이러한 Bitmap Entry를 저장합니다.

Bitmap Index의 핵심 이점은 여러 조건의 Row 집합을 Table Access 전에 결합하는 것입니다.

COLOR='RED' Bitmap
SIZE IN ('S','M') Bitmap
ACTIVE_YN='Y' Bitmap
        ↓
    OR·AND 연산
        ↓
최종 Bitmap → ROWID 변환 → Table Access

Bitmap Index는 다음 환경에서 특히 효과적일 수 있습니다.

• 대용량 Data Warehouse·분석 Table
• Ad Hoc Query가 여러 Column을 임의 조합
• Query·집계 비중이 높고 동시 DML이 적음
• 조건 결합 후 후보 Row가 크게 감소
• 일괄 적재 후 Index 생성·Rebuild가 가능한 운영

반대로 동시 INSERT·UPDATE·DELETE가 많은 OLTP에서는 한 Index Key Entry가 여러 Row를 가리키므로 Lock 영향 범위가 커질 수 있습니다.

Bitmap 적용 판단
  = Boolean 집합 연산 이득
  + 압축·NULL·Ad Hoc Query 이점
  - 동시 DML·Lock·적재·Rebuild·공간 비용

이 이론의 범위

이 이론은 SQLP의 SQL 고급활용 및 튜닝 → 인덱스 튜닝 → 인덱스 기본 원리·인덱스 설계 범위에서 Bitmap Index의 구조, Bit 연산, NULL, DML 동시성, Partition과 실행계획을 다룹니다. Bitmap Join Index·Star Transformation은 핵심 연결 개념까지만 포함합니다.

학습 목표

이 이론을 학습한 뒤에는 다음을 설명할 수 있어야 합니다.

• B-tree와 Bitmap Index의 ROWID 표현 차이를 설명한다.
• Bitmap Entry의 Key·Low ROWID·High ROWID·Bitmap Piece 구조를 설명한다.
• Bitmap AND·OR·MINUS와 ROWID 변환 순서를 설명한다.
• Bitmap Index가 NULL Key를 저장하는 특성을 설명한다.
• NDV 하나만으로 Bitmap Index를 결정하면 안 되는 이유를 설명한다.
• Data Warehouse와 OLTP에서의 적합성 차이를 설명한다.
• Bitmap Key Entry 잠금이 여러 Row의 동시 DML에 미치는 영향을 설명한다.
• 영구 Bitmap Index와 B-tree ROWID의 일시 Bitmap Conversion을 구분한다.
• Partitioned Table의 Bitmap Index가 Local이어야 하는 제한을 설명한다.
• Bitmap Join Index와 Star Transformation의 역할을 구분한다.
• 실제 Plan·Query 통계·DML Lock을 이용한 적용 검증 절차를 설명한다.

1. Bitmap이 Row 집합을 표현하는 원리

다음 Product Table을 가정합니다.

개념적인 COLOR Bitmap입니다.

Row 위치       1 2 3 4 5 6
COLOR=RED      1 0 1 0 0 1
COLOR=BLUE     0 1 0 0 0 0
COLOR=GREEN    0 0 0 1 0 0
COLOR=NULL     0 0 0 0 1 0

Bit가 1이면 해당 ROWID 위치의 Row가 Key 값을 가진다는 뜻입니다.

실제 저장은 다음과 같이 범위별 Piece로 나뉠 수 있습니다.

RED, Low ROWID=A, High ROWID=H, Bitmap=10100100...
RED, Low ROWID=I, High ROWID=P, Bitmap=00110010...

같은 Key가 여러 Entry에 반복될 수 있는 이유는 각 Entry가 담당하는 ROWID 범위가 다르기 때문입니다.

2. B-tree와 Bitmap 비교

Bitmap은 단순히 “값 종류가 적은 B-tree”가 아니라 Row 집합을 Boolean 연산하기 위한 별도 Index 구조입니다.

3. Bitmap Entry의 실제 구성

Oracle Bitmap Index는 내부적으로 B-tree를 사용해 Key와 Bitmap Piece를 저장합니다.

Bitmap Entry의 개념적 구성입니다.

1. Index Key
2. Low ROWID
3. High ROWID
4. 해당 ROWID 범위의 Bitmap

예를 들어 같은 JOB_TITLE='Stock Clerk' Key도 ROWID 범위가 다르면 여러 Entry로 저장됩니다.

Stock Clerk, ROWID A~C, 1001001100
Stock Clerk, ROWID D~T, 0101001001
Stock Clerk, ROWID U~Z, 100001

따라서 “한 Key에 항상 하나의 거대한 Bitmap Entry만 존재한다”는 설명은 부정확합니다.

4. Boolean 연산으로 후보 결합

Query입니다.

SELECT product_id,
       product_name
FROM   product
WHERE  color_code = 'RED'
AND    size_code IN ('S','M')
AND    active_yn = 'Y';

개념적 처리입니다.

SIZE='S' Bitmap ─┐
                  ├─ BITMAP OR ─┐
SIZE='M' Bitmap ─┘              │
                                 ├─ BITMAP AND ─┐
COLOR='RED' Bitmap ──────────────┘              │
                                                ├─ BITMAP AND
ACTIVE_YN='Y' Bitmap ───────────────────────────┘
                                                ↓
                               BITMAP CONVERSION TO ROWIDS
                                                ↓
                                       TABLE ACCESS

예시입니다.

RED       1 0 1 0 0 1
S OR M    1 1 1 1 0 0
ACTIVE Y  1 1 0 1 0 1
--------------------------------
AND 결과  1 0 0 0 0 0

Table Access 전에 후보를 한 Row로 줄일 수 있습니다.

4.1 대표 연산

• BITMAP AND: 모든 조건을 만족하는 Bit만 유지
• BITMAP OR: 조건 중 하나를 만족하는 Bit 유지
• BITMAP MINUS: 한 Bitmap 집합에서 다른 집합을 제거
• BITMAP MERGE: 여러 Bitmap 결과를 병합
• BITMAP CONVERSION TO ROWIDS: 최종 Bitmap을 Table ROWID로 변환
• BITMAP CONVERSION FROM ROWIDS: B-tree 등의 ROWID 집합을 실행 중 Bitmap으로 변환

5. 실행계획 해석

영구 Bitmap Index를 직접 사용할 때 다음 Operation이 나타날 수 있습니다.

BITMAP INDEX SINGLE VALUE
BITMAP INDEX RANGE SCAN
BITMAP AND
BITMAP OR
BITMAP MINUS
BITMAP CONVERSION TO ROWIDS
TABLE ACCESS BY INDEX ROWID

예시입니다.

TABLE ACCESS BY INDEX ROWID PRODUCT
  BITMAP CONVERSION TO ROWIDS
    BITMAP AND
      BITMAP INDEX SINGLE VALUE PRODUCT_COLOR_BIX
      BITMAP OR
        BITMAP INDEX SINGLE VALUE PRODUCT_SIZE_BIX
        BITMAP INDEX SINGLE VALUE PRODUCT_SIZE_BIX

해석 순서입니다.

1. 각 Key의 Bitmap Piece를 읽습니다.
2. OR·AND로 후보 집합을 결합합니다.
3. 최종 Bitmap을 ROWID로 변환합니다.
4. 필요한 Table Column을 읽습니다.

5.1 최종 Table Access 주의

Bitmap 연산 자체가 작아도 최종 후보가 Table의 큰 비율이면 Table Access가 병목일 수 있습니다.

Bitmap 결합 전 후보  10,000,000
Bitmap 결합 후 후보   6,000,000
최종 결과             6,000,000

이 상황에서는 Full Scan·Parallel Scan이 더 유리할 수 있습니다.

6. NULL 저장 특성

Bitmap Index는 B-tree와 달리 NULL Key를 포함할 수 있습니다.

CREATE BITMAP INDEX customer_marital_bix
ON customer(marital_status);

SELECT COUNT(*)
FROM   customer
WHERE  marital_status IS NULL;

NULL Bitmap을 이용할 수 있습니다.

또한 Bitmap Index는 NULL Row까지 포함하므로 다음 Query에서 전체 Row를 표현할 수 있습니다.

SELECT COUNT(*)
FROM   customer;

단, Optimizer가 실제 Bitmap Index를 선택할지는 비용과 다른 후보에 따라 달라집니다.

6.1 적용 판단

NULL 조회 하나만 필요하다고 고동시성 OLTP Table에 Bitmap Index를 추가하지 않습니다.

대안을 함께 검토합니다.

• NOT NULL 후행 Column을 포함한 복합 B-tree
• Function-Based Index
• Virtual Column
• 별도 Summary·Materialized View
• Full Scan·Partition Pruning

7. NDV만으로 결정하지 않는다

Bitmap Index의 압축 이점은 NDV / Table Row 수 비율이 낮을수록 커지기 쉽습니다. 그러나 “NDV가 2이면 Bitmap, NDV가 높으면 B-tree”라는 절대 규칙은 아닙니다.

Oracle Data Warehousing Guide는 다음과 같은 후보 기준을 제시합니다.

한 Distinct Value당 Row 수가 많음
Indexed Column이 WHERE 조건에 사용됨
또는 Fact Table의 Dimension Foreign Key

예를 들어 수십억 Row Table에서 100만 NDV라도 값당 Row가 100개 이상이고 여러 조건과 결합된다면 Bitmap 후보가 될 수 있습니다.

7.1 유리한 조건

• Table이 매우 큼
• 한 값당 많은 Row가 존재
• 여러 Column을 Ad Hoc하게 AND·OR
• 읽기·집계가 많고 DML이 적음
• Bitmap 결합 후 후보가 크게 감소
• Partition별 Load·Rebuild 운영 가능

7.2 불리한 조건

• 고동시성 OLTP DML
• 단건 PK·Unique 검색 중심
• Bitmap 결합 후에도 대부분의 Row가 남음
• 실시간 Row-by-Row Load
• 같은 Key의 변경이 집중됨
• Rebuild Window와 공간이 부족함

8. DML 잠금과 동시성

Oracle Bitmap Index에서 한 Row의 Indexed Column을 변경하면 Database는 해당 Row의 Bit 하나만 독립적으로 잠그는 것이 아니라 관련 Bitmap Key Entry에 대한 배타적 접근을 요구합니다.

예를 들어 한 직원의 Job을 Shipping Clerk에서 Stock Clerk로 변경하면 다음 Entry가 영향을 받습니다.

Old Key Entry: Shipping Clerk
New Key Entry: Stock Clerk

각 Entry가 가리키는 Row들은 Commit까지 잠금 영향 범위에 포함될 수 있습니다.

서로 다른 Table Row
  + 같은 Bitmap Key·ROWID Range
  → 동일 Bitmap Entry·Piece 변경 경쟁 가능
  → TX Lock Wait 확대

이 때문에 Bitmap Index는 많은 동시 Transaction이 Indexed Column을 수정하는 OLTP에 일반적으로 부적합합니다.

8.1 관찰 지표

• enq: TX - row lock contention
• DML Elapsed·P95·P99
• Blocked Session·Final Blocker
• Commit 전 Lock 유지시간
• Batch Load 처리량
• Indexed Key별 Update 집중도
• Index Segment·Partition 범위

9. Data Warehouse 적재 전략

읽기 중심 DW에서는 다음 운영이 효과적일 수 있습니다.

1. Stage 또는 신규 Partition에 대량 적재
2. Data Validation·Transformation
3. Bitmap Index 생성·Rebuild
4. Partition Exchange·활성화
5. Query 기간에는 읽기 중심 운영

Oracle 문서도 Bitmap Index는 Row별 유지보다 파괴 후 재생성이 더 쉬운 경우가 많다고 안내합니다.

확인합니다.

• Load Window
• Local Bitmap Index Rebuild 시간
• NOLOGGING·Recovery 정책
• Partition Exchange
• Query 가용성
• Segment 공간
• 통계 수집
• 장애 시 Rollback

10. Partitioned Table의 제한

Partitioned Table에는 Bitmap Index를 생성할 수 있지만 반드시 Local Index여야 합니다.

Partitioned Table
  → Local Bitmap Index 가능
  → Global Bitmap Index 불가

Global Bitmap Index는 Nonpartitioned Table에서만 지원됩니다.

Local Bitmap의 이점입니다.

• Table Partition과 Index Partition의 1:1 대응
• Partition Load·Drop·Exchange 후 해당 Local Partition 중심 관리
• Partition Pruning과 결합 가능
• 전체 Index 대신 일부 Partition Rebuild 가능

11. 영구 Bitmap과 일시 Bitmap Conversion

Plan에 BITMAP Operation이 있다고 실제 Bitmap Index Object가 반드시 존재하는 것은 아닙니다.

11.1 영구 Bitmap Index

BITMAP INDEX SINGLE VALUE PRODUCT_COLOR_BIX

Data Dictionary에서 확인합니다.

SELECT index_name,
       index_type,
       partitioned,
       visibility
FROM   user_indexes
WHERE  table_name = 'PRODUCT';

INDEX_TYPE='BITMAP'인지 확인합니다.

11.2 B-tree ROWID의 일시 Bitmap 변환

BITMAP CONVERSION TO ROWIDS
  BITMAP AND
    BITMAP CONVERSION FROM ROWIDS
      INDEX RANGE SCAN PRODUCT_COLOR_IX
    BITMAP CONVERSION FROM ROWIDS
      INDEX RANGE SCAN PRODUCT_SIZE_IX

저장 Object는 B-tree이지만 실행 중 ROWID 집합을 Bitmap으로 바꾸어 결합합니다.

11.3 판단 원칙

영구 Bitmap 여부
  = Plan Operation
  + Object Name
  + USER_INDEXES.INDEX_TYPE
  + 실제 DDL

12. B-tree Bitmap Conversion의 Trade-off

장점입니다.

• 기존 단일 B-tree Index 재사용
• 여러 조건 조합에 유연
• Table Access 전에 ROWID 집합 결합
• 영구 Bitmap DML 잠금 위험을 추가하지 않음

비용입니다.

• 각 B-tree Range Scan
• ROWID → Bitmap → ROWID 변환
• CPU·Memory 사용
• 후보가 많을 때 큰 Bitmap
• 핵심 SQL에서는 복합 B-tree보다 비효율 가능

Plan에 일시 Bitmap 변환이 보임
  ≠ 영구 Bitmap Index가 정답

B-tree 복합 Index·Full Scan·영구 Bitmap을 같은 Workload에서 비교합니다.

13. Star Transformation과 Bitmap

Star Schema에서 Fact Table은 Dimension Foreign Key를 가집니다.

SALES Fact
  time_id
  customer_id
  product_id
  channel_id

각 Dimension 조건으로 Fact Foreign Key Bitmap을 찾고, Bitmap을 AND·OR하여 Fact 후보를 줄일 수 있습니다.

Dimension Subquery Key
  → BITMAP INDEX RANGE SCAN
  → BITMAP MERGE
  → BITMAP AND
  → TO ROWIDS
  → Fact Table Access

Star Transformation은 Bitmap 조합으로 Fact Full Scan을 피할 수 있지만, Optimizer는 변환 Plan의 비용이 대안보다 낮을 때 선택합니다.

14. Bitmap Join Index

Bitmap Join Index는 두 개 이상의 Table Join 결과를 미리 Bitmap Index로 저장합니다.

예시 개념입니다.

Fact Table: SALES
Dimension: CUSTOMERS

Bitmap Join Index Key
  → CUSTOMERS.GENDER

Bitmap의 ROWID
  → SALES Row

장점입니다.

• Query 시 Join과 후보 축소를 미리 수행
• Dimension의 저·중 NDV 속성을 Fact Row에 연결
• Materialized Join View보다 ROWID 압축 측면에서 작을 수 있음

주의합니다.

• Join은 Data Warehouse의 PK·FK Equijoin 구조에 적합해야 함
• Dimension Key·Unique Constraint 요구
• DML·Parallel DML 제한
• Temporary Table 불가
• 운영 복잡성·Rebuild·Partition 관리

Bitmap Join Index 상세 DDL 제한은 별도 고급 범위로 관리합니다.

15. Query와 DML을 함께 검증한다

Query입니다.

SELECT /*+ GATHER_PLAN_STATISTICS */
       product_id,
       product_name
FROM   product
WHERE  color_code = 'RED'
AND    size_code IN ('S','M')
AND    active_yn = 'Y';

SELECT *
FROM TABLE(
  DBMS_XPLAN.DISPLAY_CURSOR(
    :sql_id,
    :child_no,
    'ALLSTATS LAST +PREDICATE +ALIAS +NOTE'
  )
);

15.1 Query 검증

• Bitmap Source가 영구 Bitmap인지 일시 Conversion인지
• 각 Bitmap Scan의 Starts·A-Rows·Buffers·Reads
• AND·OR 전후 후보 감소
• TO ROWIDS 후 후보 수
• Table Buffers·Reads
• CPU·PGA·Elapsed
• COUNT만 필요한지 Table Column 조회가 필요한지
• B-tree·Full Scan 대안

15.2 DML 검증

• 동시 UPDATE Session 수
• 같은 Bitmap Key·Piece에 대한 변경 집중
• TX Lock Wait
• DML P95·P99
• Commit 주기
• Batch Load Rows/sec
• Redo·Undo
• Local Partition Rebuild 시간

Query만 빨라지고 DML이 장애 수준으로 악화되면 적용하지 않습니다.

16. 선택 프레임

17. 적용 절차

1. Query·DML 비율과 Peak 동시성을 확인한다.
2. Table Row 수·NDV·NULL·값당 Row·편중을 확인한다.
3. 실제 조건 AND·OR·IN 조합을 수집한다.
4. Bitmap 결합 전후 후보 감소를 추정한다.
5. B-tree 복합 Index·일시 Bitmap Conversion·Full Scan과 비교한다.
6. Partitioned Table이면 Local Bitmap 제한을 확인한다.
7. Query Runtime·Table Access·CPU·Memory를 측정한다.
8. 동시 DML·Batch Load의 Lock·Redo·TPS를 측정한다.
9. 생성·Rebuild·통계·Recovery·Rollback 절차를 준비한다.
10. 읽기 이득이 동시성·운영 비용보다 클 때 적용한다.

자주 혼동하는 판단