SQL·테스트 데이터
백만 행을 저장하면 DB는 몇 GB인가요?
사용할 도구
백만 건 예상만으로 디스크를 정할 수는 없습니다. 짧은 ID와 긴 본문 행은 다르고 인덱스·관리 정보도 있습니다. DB 용량 추정은 가정을 명시하며 세밀한 소수는 실측 정확도가 아닙니다.
행당 200byte 가정부터
rows = 1000000
averageRowBytes = 200
indexFactor = 0.3
overheadFactor = 0.15
replicas = 1
base = 200000000 byte
index = 60000000 byte
overhead = 30000000 byte
total = 290000000 byte = 0.29 GB백만 행·200바이트·인덱스 0.3·관리 0.15·복제 1을 입력합니다. 30%는 30이 아니라 0.3입니다. 예시 계수는 공통 상수가 아니므로 구조나 측정 근거로 바꾸세요.
두 계수 모두 기본 200MB에 적용되며 관리 계수를 인덱스 포함 260MB에 곱하지 않습니다. 200×(1+0.3+0.15)이며 계수를 하나씩 0으로 해 기여량을 확인합니다.
글자 수 합계가 행 크기는 아닙니다
100글자가 100바이트는 아니며 DB에는 행·페이지 정보와 가변 길이 저장 방식이 있습니다. 내보낸 JSON 크기/행 수는 JSON 표현 평균이지 저장된 행 평균이 아닐 수 있습니다. 측정 대상을 기록하세요.
짧거나 빈 행만 표본이면 긴 본문을 과소평가하고 최대 길이는 과대평가할 수 있습니다. 200·400·800바이트 범위를 시험하고 원본 기록 대신 집계 가정만 입력하세요.
복제 수 2는 전체 두 사본
두 사본이면 580000000바이트입니다. 주 사본도 포함합니다. baseBytes·indexBytes·overheadBytes는 한 사본, bytes는 전체이므로 차이를 압축이나 오차로 오해하지 마세요.
사본 수는 과거 백업 세대를 모형화하지 않습니다. 백업·로그·임시 공간은 따로 계산하고 평균 행 크기에 포함된 관리 정보를 계수로 중복 가산하지 마세요.
GB와 GiB 때문에 용량이 줄어 보일 때
290000000바이트는 0.29GB, 약 0.2701GiB입니다. 사라진 게 아니라 단위 차이입니다. 요금표·OS·결과 단위를 맞추고 바이트 수와 가정도 남기세요.
증가 원인을 설명하는 추정 만들기
행 수나 평균 크기 두 배면 모델 총량도 두 배지만 인덱스 하나가 항상 30% 추가는 아닙니다. 가정을 하나씩 바꾸며 다음 측정 우선순위를 정하세요.
이 숫자만으로 구매 용량·경보·성능 보장을 정하지 마세요. 갱신·정비 공간·엔진 저장 동작은 단순식 밖입니다. 소수 자릿수보다 실측 근거로 가정을 갱신하는 것이 중요합니다.