innodb_file_per_table 이 옵션을 신봉하는 사람들이 있다. 항상 좋은 옵션은 아니니 주의하길 바란다.
일반적으로 innodb 는 table space 를 오라클처럼 지정할 수 있다.
차이는 index 부분과 data 부분이 한 테이블스페이스 안에서 공존하는 것과
서비스 중에 추가 시킬 수 없다는 것이다.
일반적으로 Mysql 로 대용량 서비스를 안해 본 사람은 table space 를 일정량 잡고
auto_extend 로 설정하여 추가로 늘어나는 것은 그 때마다 늘어나게 무책임하게 설정해 놓는다.
한 때 큰회사라 지정되는 회사에 처음왔는데 이렇게 설정해놓고 쓰고 있었다.ㅡㅡ;;
마지막 table space 가 80기가를 넘어서 허덕거리고 있었던거다. 모자라면 계속해서 확장해서 mysql 이 사용하고 있었다.
파일 IO 를 생각해서 분리하는게 원칙이라 이렇게 한파일이 커지면 성능에서도 느려지는것은 당연하다. 개발자라면 알것이다.
이를 보안하기 위해서 나온것이 innodb_file_per_table 이 옵션이다.
이는 테이블마다 테이블스페이스를 따로 잡아서 사용한다.
그래서 한 파일 안에서 데이타를 읽어오기 때문에 빠르다.
하지만 이것 또한 필요할 때마다 확장하면서 증가한다.
좋은 이 옵션의 단점이 무엇일까?
일반적으로 DATABASE 안에 테이블의 데이타가 고루 분포 되어 있고 데이타도 고르게 들어간다면 정말 좋은 성능을 보일것이다.
잘 분할된 IO 로 하지만 일반적으로 그렇게 서비스 되는 곳은 많지가 않다.
예를들어 방명록의 데이타를 가지고 있는 테이블이 전체용량의 10% 를 차지하고 있고 계속 증가한다고 가정하자
그럼 방명록 테이블스페이스는 계속해서 증가하고 대용량이 되었을시 이 테이블 스페이스만 몇십기가가 될 정도로 커질것이다.
10% 의 트래픽이 이파일에 집중된다. 이런 서비스를 가지는 곳은 사용을 피해야 하는 이유이기도 하다.
처음 회사에서 테이블 스페이스를 분리하고 dump 받은 파일을 load 하는데 일주일이 걸릴 정도로(ㅡㅡ); 고생했다.
테이블 스페이스를 5기가씩 30개 이상으로 나눠서 하드웨어적으로 순차적 분리를 통해 성능을 향상시켰다.
모든 옵션이 장점이 있으면 단점이 있다. 자신의 환경에 맞게 쓰는것이 좋다.^^
흠, index 영역과 data 영역이 공존하다니...
MySQL 도 알아야 할 게 많구나.
출처는 "관련 링크" 에...
|
|
|
