콘텐츠로 이동

2024 10 07

2024-10-07

MySQL column 제한

참고: https://dev.mysql.com/doc/mysql-reslimits-excerpt/8.0/en/column-count-limit.html 참고: https://stackoverflow.com/questions/15410604/maximum-number-of-columns-in-mysql-table 참고: https://www.percona.com/blog/understanding-the-maximum-number-of-columns-in-a-mysql-table/

  • 개요
    • 최대 4,096개의 열을 가질 수 있으나, 실제로는 여러 요인으로 인해 이보다 적은 수의 열만 사용 가능
  • 제약
    1. 최대 행 크기 : Row 하나에 최대 크기는 65,535 byte
    2. 저장 요구사항 : 데이터 유형에 따라 저장 방식이 다르기에, 최대 행 크기에 영향을 주게 됨
    3. 스토리지 엔진의 제한 사항 : InnoDB는 테이블당 1,017개의 열로 제한
    4. 문자 집합 : 문자 집합은 저장 요구사항에 영향 미침
    5. Virtual Key : 가상 키가 있어서 실제로 더 적게 쓸 수 밖에 없을 수도
  • 유스케이스
    1. InnoDB : 1,017 컬럼들
    2. 여러가지 요인에 따라 191~2829 개 사이이며.. 59개에서 뻑이난 사람도 있음
  • Tips
    • 열수가 많으면 유지보수, 성능 저하로 이어질 수 있음! => 그럴땐 정규화 고려하기

DB 성능 개선을 위한 테이블 분할

참고: https://khdscor.tistory.com/56 참고: https://khdscor.tistory.com/46

  • 개요
    • Target: 대용량이면서 성능 이슈가 있는 테이블
    • 수직 분할/수평 분할로 나눌 수 있음
      • 수직 분할 : 컬럼을 기준으로 테이블을 분리하는 것
      • 수평 분할 : 로우를 기준으로 테이블을 분리하는 것
    • 테이블의 컬럼 수가 많을 수록 I/O 부하 up
  • I/O 성능 개선을 위한 수직분할
    • 한 테이블에 컬럼이 매우 많다면 -> 한 Row가 매우 김 -> 데이터 저장 시, 디스크의 여러 블록에 데이터가 저장됨 -> I/O 성능 저하
      • Row 체인 : 길이가 너무 커서 하나의 블록에 저장되지 못하고, 다수의 블록에 나누어져 저장
      • Row 이주 : 수정된 데이터를 해당 데이터 블록에 저장하지 못하고 다른 블록의 빈 공간에 저장
    • 이런 방식이라면 많은 I/O 발생됨으로 성능 저하되기에, 수많은 컬럼 다 필요없다면 자주되는 친구들만 찢는 것도 방법
  • 클러스터링 팩터
    • 인덱스의 순서와 찾고자 하는 테이블의 로우들이 비슷하게 모여 있는 것
      • 클러스터링 팩터가 좋을수록 성능이 좋음 (적은 블록을 액세스 하게 됨)
    • 인덱스를 따라 테이블 로우 찾는 것 = 랜덤 액세스
    • 랜덤 액세스 줄이는 방식 소개
      1. 테이블 재생성
        • 로우가 너무 길어지면, 부족한 공간을 다른 블록으로 메울 수 밖에 없음. => 이는 ROWID의 변경을 의미
        • ROWID를 냅두고, 그 안에 그냥 신규 주소를 넣는 방식으로 이주를 함. 이를 로우의 이주라 불림.
        • Chain은 이와 같이 로우의 길이가 한 블록을 넘는다면 필요 공간만큼 연결해서 저장하는데 이를 체인 이라고 함.
        • 테이블 재생성하면, 응집도 높아지고 체인 줄어들면서 저장률 높아짐
      2. 인덱스 일체형 테이블 (Index-Organized Table)
        • 인덱스와 테이블이 일체형으로 되어 있다 == 인덱스와 다른 일반 칼럼들이 모두 같은 위치에 저장.
          • 인덱스만 접근하면 테이블 접근할 필요 X
      3. 클러스터링
        • 인덱스처럼 저장 공간을 가진 하나의 오브젝트
        • 클러스터는 다만, 테이블의 상위 개념
        • 클러스터 인덱스 키로 어떤 클러스터 들어가면 여러 로우들을 한번에 스캔하기에 효율적 접근 가능
        • MySQL => 클러스터형 인덱스, PK 기준 클러스터 키 칼럼으로 정하고 클러스터링. (테이블당 하나씩 생성 가능)
          • 넓은 범위의 처리에 도움 + 조인 효율성 높여줌
  • 처리 성능 개선을 위한 수평분할
    • 파티셔닝을 도입할 수 있음! (우리도 로그는 date range 별로 파티셔닝)
    • range partitioning
    • list partitioning
    • hash partitioning