포스트

카카오 「MySQL Json 데이터 타입의 저장 구조와 성능 비교」 리뷰 — 통째로 넣고 통째로 꺼내면 TEXT, 키로 파고들면 JSON

Tech Blog Review
게시
By August
좋아요 조회 7 분 읽는 시간

원문: MySQL Json 데이터 타입의 저장 구조와 성능 비교 — kakao tech, 2025-09-18

한 줄 요약

MySQL의 JSON 타입은 문자열을 그대로 저장하지 않고 파싱 → 바이너리 직렬화 → 유효성 검사를 거쳐 타입·키 개수·오프셋 테이블이 붙은 구조로 저장하고, 읽을 때는 역직렬화해 문자열로 다시 만든다. TEXT는 받은 그대로 넣고 그대로 꺼낸다. 그래서 {"a":"x","b":"y","c":"z"}가 JSON 타입에서는 35바이트, TEXT에서는 25바이트다. 결론은 단순하다. 저장하고 통째로 읽기만 하면 TEXT가 빠르고, JSON_EXTRACT()처럼 키로 접근하면 오프셋 테이블 덕에 JSON이 훨씬 빠르다.

배경

5.7.8부터 JSON 타입이 있다. 장점은 유효성 보장과 JSON에 최적화된 저장 방식이다. 그런데 JSON 문자열을 TEXT에 넣어도 되니, 둘 중 무엇이 언제 유리한지를 저장 구조부터 따져 본 글이다. 원문은 hexdump로 ibd 파일을 열어 supremum을 찾아 실제 저장 위치를 확인한다.

저장: 직렬화 3단계

JSON 타입에 저장하면 Item::save_str_value_in_field() → Field_json::store()에서 parse(), serialize(), store_binary()가 순서대로 불린다.

  1. JSON 인스턴스 생성. sql_common/json_dom.h의 Json_dom 서브클래스로 만든다. Json_object는 키로 빠르게 찾으려고 std::map, Json_array는 순서 보존을 위해 벡터를 쓴다.
  2. 직렬화. 저장용 바이너리로 변환.
  3. 저장. store_binary()에서 JSON 형식 검사 후 Field_blob::store().

TEXT는 이 과정이 없다. 이 차이가 성능 차이의 주요 요인이다.

바이너리 구조

ibd에 저장된 Json_object는 이렇게 생겼다.

요소크기의미
Type1B문서 유형(SMALL_OBJECT, LARGE_OBJECT 등, json_binary.cc 매크로)
Key Count2B(small) / 4B(large)키 개수
Value Size2B / 4B이 객체의 총 바이트
Key Entry × n4B씩각 키의 오프셋 + 길이
Value Entry × n3B씩각 값의 타입 + 오프셋
Key List가변키 문자열들이 이어서
Value List가변값들이 이어서

키와 값이 key:value로 섞여 있지 않고 키 목록과 값 목록이 분리돼 있으며, 앞에 오프셋 테이블이 있다. 이 구조 덕에 특정 키를 찾을 때 전체를 파싱하지 않고 엔트리를 보고 바로 위치로 갈 수 있다.

크기 비교

예제 {"a":"x","b":"y","c":"z"}(키 3개, 키 문자열 3B, 값 문자열 3B).

  • JSON: 1 + 2 + 2 + 4×3 + 3×3 + 3 + 3 = 35B
  • TEXT: 중괄호 2 + 구분 문자(따옴표·콜론·쉼표) 3×6−1 = 17 + 3 + 3 = 25B

메타 정보 때문에 JSON이 더 크다. 단, 원문의 주석이 중요하다. TEXT는 받은 문자열을 그대로 저장하므로 공백·줄바꿈이 많은 예쁜 JSON을 넣으면 그것까지 다 저장된다. JSON 타입은 불필요한 문자를 제거하고 저장하므로, 그런 입력에서는 오히려 TEXT가 커질 수 있다.

읽기: 역직렬화

JSON 타입은 ibd의 바이너리를 읽어 JSON 객체를 만들고, 그 객체로 문자열을 생성해 클라이언트에 보낸다. TEXT는 변환 없이 보낸다. 즉 JSON 타입은 쓰기와 읽기 양쪽에 변환 비용이 있다.

성능 결론

원문은 여러 시나리오를 돌렸지만 요점만 정리했다.

TEXT가 유리한 경우. JSON을 저장하고 전체를 꺼내는 단순 저장·읽기(SELECT에서 JSON 함수 없이 컬럼 전체를 읽는 것). 직렬화·역직렬화가 없어 빠르다. 유효성 검사는 못 하지만 애플리케이션에서 할 수 있는 영역이다.

JSON이 유리한 경우. JSON 함수로 가공하는 경우, 특히 키로 값을 추출하는 경우. JSON_EXTRACT()를 SELECT에 쓴 QPS 비교에서 큰 차이가 났다(TEXT에도 JSON 함수를 쓸 수는 있지만 매번 파싱해야 한다). 다른 JSON 함수는 결과가 다를 수 있다는 단서가 붙어 있다.

마무리는 “완벽한 정답은 없지만 원리를 알면 최선의 선택은 할 수 있다”이다.

읽고 남는 질문

  • QPS 그래프의 수치가 본문에 없다. TEXT 대비 몇 배인지, 문서 크기(키 수백 개짜리)에서 차이가 어떻게 커지는지가 있으면 선택 기준이 더 명확하다.
  • WHERE 절에서 JSON 키를 조건으로 쓰는 경우(생성 컬럼 + 인덱스, 8.0의 multi-valued index)는 다루지 않았다. 실무에서 JSON 타입을 택하는 가장 큰 이유가 그것이라 아쉽다.
  • 부분 업데이트(JSON_SET으로 일부만 바꿀 때 8.0의 partial update와 binlog binlog_row_value_options=PARTIAL_JSON)는 JSON 타입만의 큰 장점인데 언급이 없다. 쓰기 성능 비교에 이 요소가 들어가면 결론이 달라질 수 있다.

한 줄로 가져가기

JSON 타입의 비용은 “저장할 때 한 번 파싱해 오프셋 테이블을 만드는 것”이고, 그 비용은 키로 접근할 때만 돌아온다. 통째로만 다룬다면 그 비용을 낼 이유가 없다.

시리즈

빅테크 기술 블로그 리뷰

31편 중 18편

이전 시리즈 글 야놀자 「RESTful API validation 자동화 하기」 리뷰 — 인터페이스 하나에서 검증·문서·타입을 뽑는 이유, 그리고 자동화가 없으면 누락이 필연이라는 문장 다음 시리즈 글 LINE 「도메인에 의존하지 않는 채팅 플랫폼은 어떻게 만들었을까?」 리뷰 — 사용자를 모르는 채팅 플랫폼, 웹으로 만든 클라이언트, SOFT STOP으로 갈아 끼우는 챗봇 시나리오
  1. 1 카카오 「실시간 메시징 시스템 개발기」(3편) 리뷰 — Redis에 몰린 부하를 서버로 옮기고, 그 서버를 pprof로 세 번 깎은 이야기
  2. 2 카카오 「추가배포 없이 API의 case 통일시키기」 리뷰 — 받는 쪽이 자기 케이스에 맞춰 알아서 읽게 하면 배포 순서가 사라진다
  3. 3 카카오 「MySQL DATETIME, TIMESTAMP 데이터 타입에 대한 분석」 리뷰 — 바이트 단위 저장 구조부터 아직 안 고쳐진 Y2K38까지
  4. 4 네이버 D2 「6개월 만에 연간 수십조를 처리하는 DB CDC 복제 도구 무중단/무장애 교체하기」 리뷰 — 복제·검증·복구를 셋으로 나누고, 옛 도구와 새 도구를 서로 모르게 같이 돌린 전환
  5. 5 카카오 「MySQL ALTER DDL 수행 방식에 대한 이해」 리뷰 — Copy·In-Place·Instant는 '무엇을 복사하느냐'보다 '언제 Exclusive 메타 락을 잡느냐'로 구분된다
  6. 6 카카오 「MySQL Orchestrator 기반의 새로운 HA 표준 개발기」 리뷰 — 10년 멈춘 Perl 도구를 떠나 Raft 클러스터로, 그리고 slave_net_timeout 한 줄
  7. 7 카카오 「MySQL Ver. 8.0 New Feature: Instant DDL Algorithm에 대한 이해」 리뷰 — 컬럼을 0.01초에 추가하는 대가는 '읽을 때마다 버전을 대조하는 것'이다
  8. 8 네이버 D2 「CDC 복제 이후 오라클이 느려졌다? child cursor 폭증이 만든 예상치 못한 문제」 리뷰 — 같은 SQL인데 바인딩 타입이 다르면 Oracle은 다른 쿼리로 본다
  9. 9 카카오 「MySQL InnoDB Log에 대한 이해 - (1)」 리뷰 — 트랜잭션 하나가 어떻게 MTR 여러 개로 쪼개져 Redo Log Buffer에 들어가는가
  10. 10 카카오 「PostgreSQL to ES: Kafka Connect CDC 파이프라인」 1·2편 리뷰 — 변경이 없어서 디스크가 차고, LSN이 사라져서 스냅샷을 다시 짜야 했던 CDC의 실제 운영 비용
  11. 11 LINE 「기획서 없이 내재화하기: 검증 로직으로 동일함을 증명하다」 리뷰 — 블랙박스는 입력과 출력만 정의하면 통계로 같음을 증명할 수 있다
  12. 12 뱅크샐러드 「게임을 만들 때 데이터 정합성을 유지하는 법 (feat. 낙관적 락)」 리뷰 — 같은 WHERE version 조건인데, 충돌한 요청을 어떻게 하는가에서 갈리는 두 설계
  13. 13 우아한형제들 「Spring Batch와 Querydsl」 리뷰 — offset을 버린 Reader가 21분을 4분으로 만든 이유, 그리고 그 Reader가 답하지 않는 두 가지
  14. 14 네이버 D2 「테스트는 어떻게 좋은 코드를 만드는가(feat. 험블 객체 패턴)」 리뷰 — 목이 많아지는 것은 테스트의 문제가 아니라 설계의 신호
  15. 15 당근 「QR을 찍으면 무슨 일이 벌어질까? 당근페이 현장 결제의 모든 것」 리뷰 — 카드망을 빌려 7주 만에 낸 결제와, 그 글이 다루지 않은 승인 응답이 사라지는 순간
  16. 16 네이버 D2 「스마트스토어센터 Oracle에서 MySQL로의 무중단 전환기」 리뷰 — 두 DB에 동시에 쓰되 한쪽 실패는 무시하고, 읽기 트래픽을 복제해 성능을 재고, 6개월간 불일치를 0으로 만든 과정
  17. 17 야놀자 「RESTful API validation 자동화 하기」 리뷰 — 인터페이스 하나에서 검증·문서·타입을 뽑는 이유, 그리고 자동화가 없으면 누락이 필연이라는 문장
  18. 18 카카오 「MySQL Json 데이터 타입의 저장 구조와 성능 비교」 리뷰 — 통째로 넣고 통째로 꺼내면 TEXT, 키로 파고들면 JSON
  19. 19 LINE 「도메인에 의존하지 않는 채팅 플랫폼은 어떻게 만들었을까?」 리뷰 — 사용자를 모르는 채팅 플랫폼, 웹으로 만든 클라이언트, SOFT STOP으로 갈아 끼우는 챗봇 시나리오
  20. 20 카카오페이 「MSA 환경에서 네트워크 예외를 잘 다루는 방법」 리뷰 — Unknown을 타입으로 만든 글과, Unknown을 상태로 저장한 프로젝트가 갈리는 지점
  21. 21 카카오 「메시징 서버의 스트레스 테스트 노하우와 AI가 덜어 준 부분」 리뷰 — 지표를 네 층으로 내려가 읽는 법, 그리고 LLM에게 맡긴 것과 맡기지 못한 것
  22. 22 네이버 D2 「일 3,000만 건의 네이버페이 주문 메시지를 처리하는 Kafka 시스템의 무중단 전환 사례」 리뷰 — 두 벌로 발행해 대조한 검증기와, 발행 제어 키를 파티션 키와 같게 둔 이유
  23. 23 카카오 「잃어버린 리포트를 찾아서: 카카오 메시징 시스템의 경쟁 조건 문제와 안티 패턴 제거 과정」 리뷰 — 벤더가 8ms 만에 리포트를 보냈고, 우리는 101ms짜리 트랜잭션 안에 있었다
  24. 24 컬리 「컬리의 입고 시스템이 외부 인입 데이터를 안전하게 동기화하는 방법」 리뷰 — 145회 재시도가 맞는 도메인과 재시도를 금지한 도메인, 그리고 발행부와 수신부가 각자 책임지는 구조
  25. 25 네이버 D2 「@RequestCache: HTTP 요청 범위 캐싱을 위한 커스텀 애너테이션 개발기」 리뷰 — 캐시의 수명을 '요청 하나'로 맞추면 TTL 고민이 사라진다, 그리고 @RequestScope가 안 되는 이유
  26. 26 무신사 「Kafka와 Strimzi를 이용하여 6개의 도메인을 하나의 도메인으로 합쳐보았습니다」 리뷰 — 배치 없이 CDC와 Kafka Streams로 옮긴 결정, 그리고 통합 모델이 원본과 같다는 것을 누가 확인하는가
  27. 27 쿠팡 「대용량 트래픽 처리를 위한 쿠팡의 백엔드 전략」 리뷰 — 캐시 두 겹과 '분 단위 99.99% 동일'이라는 문장, 그리고 그 0.01%를 누가 어떻게 세는가
  28. 28 LINE 「LINE에서 Kafka를 사용하는 방법 - 1편」 리뷰 — 초당 4GB 클러스터가 바이트가 아니라 요청 수를 제한하는 이유, 그리고 2,000틱짜리 파이프라인에서 같은 것을 본 기록
  29. 29 카카오 「MySQL 인증 플러그인 caching_sha2_password에 대한 이해」 리뷰 — 비밀번호 해시가 바뀌는 것보다 '평문이 서버까지 가야 한다'는 점이 전환의 진짜 비용
  30. 30 LINE 「초당 100만 건, LINE 앱에 Apache Kafka 종단 간 암호화 적용기」 리뷰 — 인터셉터와 시리얼라이저만으로 브로커에 평문을 남기지 않는 법
  31. 31 카카오뱅크 「하루 N억 건의 알림 시스템 구축기 (1)」 리뷰 — P99의 80%가 대기였다는 진단, Age 기반 Work-Stealing, 그리고 큐를 나누는 순간 순서를 잃는 문제
TechBlog, Kakao
Tech Blog Review Kakao MySQL JSON InnoDB Storage Format Performance Database
이 기사는 저작권자의 CC BY 4.0 라이센스를 따릅니다.

댓글

아직 댓글이 없습니다