PostgreSQL JSONB 인덱싱과 쿼리 성능 최적화

개요

JSONB는 유연한 스키마와 빠른 읽기 성능 덕분에 많은 시스템에서 사용된다. 다만 구조화되지 않은 데이터에 인덱스를 적용하지 않으면 쿼리 성능이 급격히 떨어진다. 이 글에서는 기본 개념부터 인덱스 선택, 쿼리 패턴, 운영 관점의 성능 관리까지 실무에서 바로 적용 가능한 내용을 단계별로 정리한다.

JSONB 기본 개념

JSONB와 JSON 차이

JSONB는 내부적으로 바이너리로 저장되어 검색과 인덱싱이 효율적이다. 반면 JSON은 텍스트 그대로 저장되어 파싱 비용이 발생한다. 따라서 검색 빈도가 높은 필드는 JSONB 사용을 권장한다.

유용한 연산자

-> : JSON 객체에서 JSON 값을 추출
->> : JSON 객체에서 텍스트 값을 추출
@> : 포함(contains) 연산자, 인덱스 활용에 적합
? , ?> , ?& : 키 존재 여부 검사

인덱스 종류와 사용법

GIN 인덱스

일반적으로 JSONB에는 GIN 인덱스가 가장 많이 쓰인다. 전체 문서의 키-값 조합을 색인하므로 포함(@>) 쿼리에서 특히 효과적이다. 기본형(jsonb_ops)과 경량형(jsonb_path_ops)이 있으며, 사용 패턴에 따라 선택한다.

-- 전체 키-값 인덱싱 (유연성 높음)
CREATE INDEX idx_data_gin ON my_table USING gin (data);

-- 경량 인덱스 (jsonb @> 쿼리에 최적)
CREATE INDEX idx_data_jsonb_path_ops ON my_table USING gin (data jsonb_path_ops);

표현식(Functional) 인덱스

특정 키에서 자주 검색하거나 정렬하는 경우 표현식 인덱스가 좋다. 예를 들어 상태(status)를 문자열로 자주 조회하면 해당 값을 추출해 인덱스화한다.

-- data->>'status' 값을 인덱싱
CREATE INDEX idx_data_status ON my_table ((data ->> 'status'));

-- 숫자형 값을 비교할 때는 cast 사용
CREATE INDEX idx_data_amount ON my_table (((data ->> 'amount')::numeric));

BTREE vs GIN 선택 기준

단일 키의 등가 비교나 정렬: BTREE(표현식 인덱스)
문서 포함 여부나 다중 키 검색: GIN
부분 색인(PARTIAL INDEX)으로 조건을 좁히면 인덱스 크기와 유지비용 절감

쿼리 최적화 패턴

인덱스가 활용되는 형태로 쿼리 작성

인덱스가 효과를 내려면 쿼리 표현이 인덱스 친화적이어야 한다. 예를 들어 아래와 같이 @> 연산자를 쓰면 GIN 인덱스를 활용할 수 있다.

SELECT * FROM my_table
WHERE data @> '{"status": "active"}';

반면 JSONB 전체를 함수로 래핑하거나 불필요한 타입 변환을 하면 인덱스를 못 쓰는 경우가 많다.

표현식 인덱스와 인덱스 전용 스캔

((data ->> 'status')) 같은 표현식 인덱스를 만들면 WHERE 절에 동일한 표현식을 사용했을 때 인덱스 전용 스캔(Index-only scan)이 가능하다. 단, 인덱스 전용 스캔은 테이블의 dead tuple이나 TOAST 상태에 따라 제한이 있다.

부분 인덱스 활용

검색 대상이 일부 상태로 좁혀진다면 부분 인덱스를 사용해 인덱스 크기를 줄이고 유지 비용을 낮춘다.

CREATE INDEX idx_active_status ON my_table ((data ->> 'status')) WHERE (data @> '{"status":"active"}');

운영과 모니터링

통계와 실행 계획 확인

EXPLAIN (ANALYZE, BUFFERS)로 실제 쿼리 플랜과 버퍼 사용량을 확인한다. 인덱스가 사용되지 않을 때는 쿼리 표현을 점검하거나 통계를 갱신한다.

EXPLAIN (ANALYZE, BUFFERS)
SELECT * FROM my_table WHERE data @> '{"status": "active"}';

VACUUM, ANALYZE, REINDEX

정기적으로 VACUUM/ANALYZE 실행으로 통계 최신화
대량 업데이트 후에는 REINDEX 고려
maintenance_work_mem를 적절히 조정하면 인덱스 생성 속도가 개선

모니터링 뷰 활용

pg_stat_user_indexes, pg_stat_user_tables로 인덱스 히트율과 스캔 횟수를 모니터링한다. 필요 없는 인덱스는 제거하여 쓰기 성능을 개선한다.

성능 최적화 실전 예시

실제 사례를 통해 자주 발생하는 실수를 피하는 방법을 정리한다.

문제: WHERE data -> 'meta' -> 'flag' = 'true'와 같이 중첩 접근 후 비교하면 인덱스 미사용 가능성 큼
- 해결: 표현식 인덱스 생성 후 동일한 표현식으로 비교
문제: 큰 JSON 문서를 그대로 색인하면 인덱스 크기 증가
- 해결: 자주 검색하는 필드만 별도 칼럼으로 분리하거나 부분 인덱스 사용

예시 쿼리와 인덱스

-- 사용 패턴: 상태와 타입으로 필터링
CREATE INDEX idx_data_status_type ON my_table USING gin (data jsonb_path_ops);

EXPLAIN ANALYZE
SELECT id FROM my_table
WHERE data @> '{"status":"active", "type":"order"}';

-- 특정 필드를 자주 조회한다면
CREATE INDEX idx_data_order_id ON my_table ((data ->> 'order_id'));

요약 및 권장 사항

요약하면 JSONB 성능 최적화는 데이터 모델, 쿼리 패턴, 인덱스 설계를 함께 고려해야 한다. 다음 권장 사항을 적용하면 쿼리 성능을 안정적으로 개선할 수 있다.

자주 검색하는 키는 표현식 인덱스나 별도 칼럼으로 분리
문서 전체 포함 검색에는 GIN(jsonb_path_ops) 활용
부분 인덱스와 정기적 통계 갱신으로 유지 비용 절감
EXPLAIN(ANALYZE)로 실제 플랜을 확인하고 반복 측정
인덱스 과다 생성 방지를 위해 pg_stat_*를 주기적으로 점검

이 글에 제시한 패턴과 예시는 초보자도 적용 가능한 실무 중심의 조언을 엮은 것이다. 시스템 특성에 따라 최적의 조합은 달라지므로, 변경 시에는 항상 테스트와 모니터링을 병행한다.

목차

개요