수십억 행 실측으로 검증한 DB 엔진 비교
운영 DB를 읽기 전용으로 실측하고, 저장 구조와 전환 비용을 기준으로 엔진 후보를 비교했습니다.
작업 요약
4개 인스턴스 실측 · 검토·리뷰 완료 · 엔진 채택 결정 대기
운영 스키마를 실측한 뒤 엔진을 비교했습니다
엔진 비교는 문서 인용 대신 운영 중인 우리 스키마 실측에서 시작했습니다. 4개 인스턴스를 read-only로 실측해 보니 파티셔닝은 한 건도 없었고, 어떤 테이블은 인덱스가 데이터보다 컸습니다. 이 실측값을 기준으로 대안을 비교했습니다.
라이선스 정책이 어디까지 요구하는지에 따라 전환 비용이 작은 MariaDB와 저장 구조를 바꾸는 PostgreSQL 중 선택이 달라지므로, 항목별 비용을 문서에 정리하고 회의에서 결정하도록 했습니다.
배경
고객사의 MySQL 라이선스 정책 문의를 계기로 엔진 대안 검토가 필요해졌습니다. 현재 DB 구조도 함께 검토해야 했습니다. 수십억 행 단일 테이블이 파티셔닝 없이 돌고 있었고, 일부 테이블은 인덱스가 데이터보다 큰 상태였습니다.
- 4개 인스턴스(수집·배포 2계열·운영) 전 테이블 파티셔닝 0건(
information_schema.PARTITIONS실측) - 최대 테이블 66.7억 행 · 914GB, 다른 대형 테이블은 34억 행에서 인덱스 701GB > 데이터 178GB
- 인덱스 비대의 근본 원인: InnoDB 보조 인덱스가 넓은 복합 PK(4컬럼 문자열)를 통째로 포함하는 구조
접근
- 실측
4개 인스턴스의 파티션·용량·PK 구조를 읽기 전용으로 조사
- 원인 규명
인덱스가 데이터보다 큰 원인을 복합 PK 구조에서 확인
- 3개 엔진 비교
파티셔닝 FK·자동화·purge·인덱스 구조 항목별 비교
- 방안 정리
라이선스 수준별 전환 경로와 비용을 문서화
비교는 우리 스키마에 대입해서만 했습니다. 예를 들어 최대 테이블은 PK와 유니크 키에 공통 컬럼이 없어 어떤 엔진을 골라도 파티셔닝 전에 키 재설계가 선행돼야 한다는 것, MySQL·MariaDB는 파티션 테이블에 FK를 걸 수 없고 PostgreSQL은 FK 유지·pg_partman 자동화·BRIN·무중단 purge가 가능하다는 것을 항목별로 정리했습니다.
PostgreSQL의 비용도 같은 문서에 남겼습니다. VACUUM 운영 부담, 힙 구조의 포인트 조회 특성, 코드 전환 약 2~3주(FULLTEXT 8곳·뷰 58개 재작성)와 3TB 데이터 이관이 그것입니다. 라이선스 대응만 보면 MariaDB가 최소비용이라는 점도 명시했습니다.
결과
실측과 엔진 비교에 대한 검토·리뷰를 마쳤습니다. 현재는 의사결정권자의 답변을 기다리고 있으며, 엔진 채택이나 데이터 이관은 진행하지 않았습니다.
역할
데이터 엔지니어로서 실측 설계와 수행, 원인 분석, 3개 엔진 비교 문서 작성을 직접 진행했습니다. 운영 DB를 다루므로 실측은 read-only로 한정했고, 엔진 채택 결정은 라이선스 정책 확인 후 회의로 확정하도록 문서에 명시했습니다.
라이선스 대응 로드맵과 함께 검토·리뷰를 마쳤으며, 엔진 채택 결정은 대기 중입니다.