MySQL에서 DB engine

http://blog.naver.com/roadkh/40421166

1. MySQL에서 디비엔진을 선택할때의 선택 방법

이건 매우 단순한 거지만 그래도 한번 집고 넘어가주는게 나을거 같다.

알다시피 MySQL은 많은 디비 엔진을 가지고 있다. 보통 다른 DBMS를 사용하는 사람들이 가장 헷갈려 하는 부분이기도 하다(다른 DBMS만 사용하던 사람들은 이 엔진의 개념을 굉장히 생소하게 생각하더라). 간단히 사용가능한 DB 엔진을 얘기해 보면... 음.. 그냥 MySQL 깔린 사람들은 콘솔에서 show engines; 를 처보기 바란다. 나열하려니 귀찮다.

대표적인 엔진들의 선택시 고려사항에 대해서 설명하면 다음과 같다.

[MyISAM]

MyISAM은 MySQL의 가장 대표적인 엔진이다. 잘 모르는 사람들은 MySQL에는 MyISAM만 있는줄도 알더라. 이 엔진은 ISAM이라는 DB에서 발전되어 온 엔진으로 ISAM 자체가 인서트에서 매우 고성능을 발휘하던 DB 였던 만큼 MyISAM도 인서트에서 매우 훌륭한 성능을 발휘한다.

MyISAM 은 단순 인서트와 단순 셀렉트를 빈번하게 사용하는 경우에 주로 사용한다. 여기서 단순 인서트는 트랜잭션이 들어가지 않는 인서트를 말하고 단순 셀렉트는 릴레이션이 복잡하지 않은 그리고 조인이 많이 걸려있지 않은 그런 셀렉트를 말한다. 인서트의 경우는 InnoDB 보다 20% 정도 빠르다는게 일반적인 내용이다(이건 MySQL 에서 발표한거다). 또 한가지 중요한 부분이 대용량 데이터(보통 MySQL에서 말하는 대용량은 100만건 이상이라고 생각한다)가 들어가고 그 데이터에서 단건 쿼리가 아닌 여러 row를 리턴하는 쿼리가 들어가는 경우는 되도록 사용하지 말라는거다. 이유는? MyISAM은 테이블 락이 걸리기 때문이다. 테이블 락이라하면 테이블을 셀렉트할때랑 인서트 할때 테이블 전체를 락을 건다는 거다. 이거 매우 크리티컬 한 결과를 나을 수 있으므로 신중하게 생각해야만 한다. 만약 테이블 락이 전체 데이터를 넣는데 무리를 줄만하다고 판단되면 인서트 성능을 20% 정도 버리더라도 InnoDB를 선택해야 한다. 한가지 더 MyISAM의 특징은 Fulltext Index의 지원이다. 검색엔진을 사용하는 대형 회사에서야 크게 필요가 없지만, 검색엔진까지 도입하기엔 좀 벅찬 중소형 회사에서는 매우 유용하다. 특히 다른 디비에서 지원을 잘 못하는 2byte 문자에 대해서 유니코드 Fulltext를 지원하는 MySQL의 기능은 정말 유용하다. 실제로 사용해 본 결과 인덱스 크기가 좀 크긴 하지만 작동은 잘 된다. 이런 이유로 MyISAM은 보통 게시판 DB로 많이 사용이 된다.

단 MyISAM에서의 또하나의 문제점은 보통의 운영체제에서 4GB 이상의 테이블이 생성되지 않는다는 점이다. 이건 MyISAM의 문제점이 아니라, 보통의 운영체제에서의 문제점이다. 그러나 MyISAM도 한가지 해 줘야 할 부분이 있는데, avg_row_length라는것과 max_rows 라는 넘을 고쳐줘야 한다는 거다. 이건 뒤에 얘기하겠다. 암튼 4GB 가 넘는 다는건 보통 한 Row가 0.5메가 정도 되는 html 코드형 게시판 데이터라고 할 경우 8000 row를 넘지 못한다는게 되니까.. 흠.. 문제가 되기도 하겠다.

[InnoDB]

InnoDB는 일반적으로 트랜잭션이 들어가는 인서트/업데이트와 대용량 셀렉트 쿼리가 들어가는 경우 사용한다. MyISAM과 다르게 InnoDB는 Row 단위 락을 걸기 때문이라고 보면 된다.

단 앞에서도 말했듯이 인서트 성능이 20% 정도 감소된다.  보통 이런 연유로 회원디비, 빌링 등에 MySQL이 사용되면 InnoDB를 많이 사용한다.

보통은 4GB 를 넘겨야 하는 데이터일 경우에는 InnoDB를 사용하는게 일반적이다. 그러나 InnoDB도 2GB 씩 끊어서 테이블 스페이스를 잡는 것이 일반적으로 퍼포먼스가 좋다고 한다.(ITBridge 컨설팅 중)

[Memory]

Memory DB는 보통 Heap 테이블이라고 알고 있는 디비 엔진이다. 매우 빠른 인서트와 셀렉트 성능을 보인다는건 뭐 말안해도 당연할거 같아서... Heap 테이블이라고 알고 있지만 이것도 하나의 엔진으로 통하고 있다. 이 DB 역시 한계는 있는데, blob이나 text 형식의 데이터 타입을 사용할 수는 없다. 또 하나 뭐 다 아는 내용이겠지만.. 서버가 죽으면 데이터는 모두 사라진다. MySQL에서 발표한 바에 의하면 대용량 인서트시에 MyISAM보다는 33%는 InnoDB보다는 50% 정도 빠르다고 한다. 보통은 중요하지 않은 대용량 로그 데이터를 Memory에 넣은 다음에 배치로 가공하여 다른 DB로 옮기는 경우와 인증 데이터와 같이 잠시 사용하는 경우(Session 데이터에 사용하기도 한다)에 사용을 결정하곤 한다. 하지만 일반적으로 많이 쓰지는 않는다.

[FEDERATED]

Federated  엔진은 굉장히 생소한 엔진이다. 그도 그럴것이 MySQL에서도 5.0.3 버전 이후부터 지원을 하기 시작한 엔진이다. 물론 내가 사용할 당시에는 굉장히 불안정한 버전이었지만...

어쨌건 이 엔진은 불안정해도 굉장히 매력적인 엔진이다. 이 엔진은 다른 머신(메뉴얼에서는 동일 머신도 지원한다고 하는데 실제 해보니 안됐었다.)에 있는 디비의 특정 테이블을 마치 로컬에 있는 테이블인양 쓸 수 있게 한다는 그런 엔진인 것이었다. (갑자기 말투가 왜이러냐..)

즉, 회원 디비를 별도로 구성해서 가져가는 경우 아이디랑 주요 정보가 있는 테이블을 조인해서 회원의 번호만 있으면 아이디를 가져오게 한다던가 이런 경우에 구성하는 테이블인거다. 그냥 federated로 선언된(약간 create 문이 다르다) 테이블을 생성만 해 놓으면 쓸수 있게 한다는 거다. 굉장히 매력적이지 않나.. 그러나 이 엔진은 내가 사용하던 시절만 해도 약간 문제가 있었다. 지금도 그런지는 안해봐서 모르겠다. 그래도 정리해 볼테니 혹시 사용해 볼일이 있으면 꼭 체크하고 사용하기 바란다.

우선은 당연하겠지만, 네트워크 속도에 큰 영향을 받는다는 거다. 보통은 디비끼리는 사설망이라서 그렇게 문제가 되지 않았지만, 그래도 가끔 네트워크 트래픽 증가가 있을 경우 결과에 영향을 미친다는 문제가 발생했다.

다음, 셀렉트 시에는 유용하지만 인서트/업데이트에서는 문제가 생긴다는거다. 뭐 MySQL 측에서도 셀렉트시 조인의 용도로 사용할 것을 권장한다. 인서트/업데이트(또는 그 중 하나)가 지원이 되긴 하는데 데이터에 대한 보장은 절대 안된다.

마지막으로 사용이 빈번하지 않은 경우 일정 시간이 지나면 한글 데이터의 경우는 깨진다는거다. 그 당시 UTF-8 포맷을 사용했던 것으로 기억하는데, 이게 일정 시간이 지나버리면 깨져서 나온다는 거다. 아무리 charset을 조정하면서 해결해 보려고 했지만 모두 실패했다. 그때는 federated 테이블을 날리고 새로 생성해야만 정상으로 돌아왔었다.

이제 생긴지 얼마 안된 엔진이라 앞으로 어떤 방식으로 발전하게 될지 매우 기대가 되는 엔진이다. MySQL의 앞으로의 계획에 보면 MySQL 테이블 뿐 아니라 MSSQL, Oracle 등의 다른 디비에 있는 테이블로 Federated 테이블을 이용해서 끌어올 수 있게 만든다고 하던데... 정말 된다면 참 좋겠다.