무중단 스키마 변경과 대량 작업

한 번에 하지 않고 NULL 허용으로 추가한 뒤 채우고 제약을 거는 순서로 나눕니다.

한 번에 하면 무엇이 문제인지 보면 이렇습니다. 기본값이 있는 NOT NULL 컬럼을 추가하면 DB 가 모든 행에 그 값을 채워야 하고, 그동안 테이블 전체가 잠깁니다. 1억 행이면 수십 분이고 서비스가 멈춥니다.

3번을 나누는 방법입니다.

흔한 실수: 최신 DB 버전은 기본값 추가가 빠르다는 것만 알고 그대로 실행하는 것. 버전과 조건에 따라 다르고, 조건을 벗어나면 전체를 다시 씁니다. 실행 전에 그 버전의 동작을 확인해야 합니다.

한 건씩 넣지 않고 묶어서 보냅니다. 왕복 횟수가 그대로 시간이 됩니다.

함께 볼 것들입니다.

운영 중과 초기 적재는 판단이 다릅니다. 초기 적재라면 인덱스를 나중에 만들고 최대 속도로 넣습니다. 운영 중이라면 속도를 낮추고 나눠서 넣는 편이 안전합니다.

흔한 실수: 반복문 안에서 커밋을 매번 하는 것. 트랜잭션 시작과 커밋이 100만 번 일어나 그 비용이 삽입보다 커집니다.

DB 작업 자체는 빠르지만, 배포 중에 옛 코드와 새 코드가 함께 돌기 때문입니다.

배포는 순간이 아닙니다. 서버를 하나씩 교체하는 동안 두 버전이 공존하고, 그 사이 옛 버전의 요청이 전부 실패합니다. 되돌리기도 어렵습니다. 이전 버전으로 롤백하면 그것도 옛 이름을 찾습니다.

안전한 순서입니다.

번거롭지만 각 단계에서 두 버전이 함께 동작합니다. 이 원칙은 컬럼 삭제와 타입 변경에도 같이 적용됩니다.

흔한 실수: 배포 시간을 짧게 잡아 문제가 없다고 보는 것. 짧아도 그 사이 요청은 실패하고, 롤백 경로가 막히는 것은 시간과 무관합니다.

목적에 따라 방법이 다릅니다. 전체인지 조건부인지, 운영 중인지가 갈림길입니다.

운영 중에는 네 번째를 씁니다. 1억 건을 한 문장으로 지우면 잠금이 길고 로그가 폭증하며 복제 지연이 커집니다. 1만 건씩 나눠 지우면서 사이에 쉬어야 합니다.

정기적으로 오래된 데이터를 지우는 요구라면 애초에 파티션으로 설계하는 것이 답입니다. 월별 파티션을 두면 지난달 데이터를 지우는 것이 파티션 하나를 떼는 일이 됩니다.

흔한 실수: 조건부 삭제에 TRUNCATE 를 쓰려 하는 것. 조건을 걸 수 없어 전체가 사라집니다.