1. InnoDB - Transaction, Foreign Key, UNION 문법 지원한다.
- 동시에 읽고 쓰기가 많은 경우에 좋다. (초당 400~500 query)
- 안정성 측면에서 MyIsam보다 조금 더 우수하다.
- Update시 행단위 lock (row level locking)
: select 에서 읽을 수 있도록 non-lock 가능
- Record 수가 많고, 동시 사용자 수가 많은 경우 InnoDB의 성능이 어느정도 양호하다. - Foreign Key나 Transaction 등이 필요한 상황에서는 InnoDB를 선호한다.
- 제공하는 기능이 다양한 반면, 프로세스 자체는 MyIsam에 비해 무겁다.
- 테이블과 인덱스를 Tablespace에 저장한다.
- 데이터와 인덱스를 캐시하기 위한 자체적인 buffer pool로 주 메모리를 사용한다.
- Dump를 이용하여 백업한다.
2. MyIsam
- 인덱스 데이터를 위한 키 캐시가 존재한다.
- Varchar, Char 데이터 형은 64K까지 사용할 수 있다.
- BLOB, TEXT 데이터형도 인덱스 지정이 가능하다.
- Transaction을 지원하지 않는다. (Insert, update, delete 작업시 부가작업을 하지 않는다.)
- 일반적으로 insert, update할때 빠른 속도를 보장한다.
- 초당 100 query 정도에 적합하다. (일반 게시판 수준)
- Update 시 table Lock (Table level locking)한다.
- Record 수가 많을 시 Alter 에서 MyIsam 속도가 양호하다.
- 테이블과 인덱스를 각각 분리된 파일로 관리한다. (*.MYI : 인덱스, *.MYD : 데이터)
- 테이블 단위의 백업이 가능하다.
출처
http://dev.kthcorp.com/2011/06/17/why-we-need-to-use-innodb-on-mysql-vs-myisam-comparison/
Overview
MySQL에서는 MyISAM, InnoDB, Archive 등과 같은 훌륭한 엔진을 제공합니다. 목적에 맞게 적절(?)하게 사용을 한다면, 기타 고 비용 상용 DBMS 부럽지 않게 DB를 구성할 수 있습니다. 물론 적절이라는 말이 세상에서 가장 난해한 단어겠지만요.^^
사실 OLTP 성 서비스에는 대부분 innodb위주로 설정을 해왔기에, 특별하게 MyISAM 영역에 대해서는 신경을 쓰지 않았습니다. 단순하게 해당 스토리지 엔진의 특성만 기억하고 있었지, OLTP 성격의 서비스에 굳이 투입하고 싶지도 않았고요. 하지만 얼마전 공간 인덱스(R-Tree)에 관한 요구사항이 발생하여 어쩔 수 없이 MyISAM 위주로 구성을 한 Case가 있습니다. 그래서 MyISAM 스토리지 엔진에 관한 간단한 BMT를 진행하였고, 결과에 관해서 공유드리고자 합니다.
Feature
MyISAM과 InnoDB를 간단하게 비교한 표입니다. Geospatial 기능과 Full-text Search 기능을 제외하고 눈여겨 보셔야 할 부분은 트랜잭션, Locking Level, Data caches 등 세가지 입니다. 이 세가지 특성으로 인하여 특수한 경우(spatial, full-text search)등을 제외한 경우 InnoDB를 선택해야만 하는 이유가 나옵니다.
아직 InnoDB에서는 Compressed 기능 적용 시 테이블 사이즈 변화는 검토해볼 사항이겠군요. Barracuda format을 적용하여 Compressed 적용 시 성능 및 데이터 사이즈 변화에 관한 내용은 조만간 비교해서 공유드리겠습니다.^^
MyISAM Benchmark
< 시스템>
- CPU
4-core : Intel(R) Xeon(R) CPU E5405 @ 2.00GHz
8-core : Intel(R) Xeon(R) CPU L5520 @ 2.27GHz - Memory : 8G
- DISK :
Raid-1 for OS
Raid-1 for DATA (I/O성능은 좋지 못하다고 보면 됨) - MySQL verstion : mysql Ver 14.14 Distrib 5.1.57
<Benchmark>
- Sysbench-0.4.12 tool사용
- MyISAM 1000만 건 데이터 생성 후 Read-only/Complex Test 수행
- 4-core/8-core/key_cache_block_size 변경 후 테스트
<Query Cache on/off READ TEST result>사용 유무에 따라서 2배 성능 차이가 발생합니다.
두 경우 모두 5개 Thread이상에서는 더이상 성능 향상이 발생하지 않습니다.
두 경우 모두 5개 Thread이상에서는 더이상 성능 향상이 발생하지 않습니다.
<Key Block Size 변경 READ TEST result>key_cache_block_size를 OS와 동일하게 구성한 결과 15% 성능 향상되었습니다.
두 경우 모두 5개 Thread이상에서는 더이상 성능 향상이 발생하지 않습니다.
두 경우 모두 5개 Thread이상에서는 더이상 성능 향상이 발생하지 않습니다.
<CPU core 개수 변화에 따른 READ TEST result>8-core가 2배 정도 성능이 좋게 나오나, 장비가 다르므로 큰 의미는 없습니다.
다만 4-core는 5-Thread에서, 8-core는 10-thread 이상에서는 성능에 변동이 없는 것을 확인할 수 있네요.
다만 4-core는 5-Thread에서, 8-core는 10-thread 이상에서는 성능에 변동이 없는 것을 확인할 수 있네요.
<Key Block Size 변경에 따른 READ/WRITE TEST result>key_cache_block_size를 OS와 동일하게 구성한 결과 15% 성능 향상되었습니다.
5개 Thread이상에서는 더이상 성능 향상이 없습니다.
5개 Thread이상에서는 더이상 성능 향상이 없습니다.
<CPU core 개수 변화에 따른 READ/WRITE TEST result>8-core가 성능이 훨씬 좋은 것으로 나오나, 장비가 다르므로 큰 의미는 없습니다.
4-core, 8-core 모두 5-thread 이상에서 성능상 큰 변동은 없군요.
4-core, 8-core 모두 5-thread 이상에서 성능상 큰 변동은 없군요.
다음은 MySQL에서 최근 발표한 MyISAM vs InnoDB 성능 테스트 BMT결과입니다. MySQL 5.5 Version부터 innodb를 default-storage-engine으로 적용하면서 비교 분석한 자료네요. 이 자료를 보면 왜 OLTP환경에서는 InnoDB 를 채택하는 것이 좋은지를 아주 명확하게 알려줍니다. Core가 많을 수록 InnoDB성능은 비례하게 올라가는 반면, MyISAM은 그대로 유지합니다.
Conclusion
일정 동시 요청 건 수(5~10 Thread) 이상으로는 더이상 성능 향상이 없는 것을 확인할 수 있습니다. 이는 MyISAM이 Table-level Lock으로 데이터 DML을 처리하고, Data를 직접 DISK에서 읽어오는 것에서 발생하는 한계점이라고 판단이 듭니다.
따로 내용을 정리하지는 않았었지만, Key Cache 사이즈 변화에 따른 성능 변화도 테스트해 보았습니다. 그 결과 인덱스 총 사이즈보다 Key Cache 사이즈가 크게 설정되어 있으면 성능상 변화는 거의 없었습니다. 인덱스 또한 MyISAM은 인덱스 압축 기법을 통하여 사이즈를 최소화하기 때문에 굳이 Key Cache사이즈를 4G 이상으로 할당하는 것은 큰 의미가 없겠습니다.
결국 MyISAM을 사용 시 고비용의 고스펙 장비는 필요없다는 결과가 나왔습니다. CPU/Memory 부분보다는 오히려 DISK 성능을 향상시키는 것이 성능상 큰 효과를 거둘 수 있겠습니다. (Random I/O가 좋은 SSD라면 상당한 효과를 거두겠습니다.) 메모리는 OS Cache를 고려하여 6G~8G, CPU는 최대 8-core까지만 사용하는 것이 낫다고 생각합니다. 그리고 key cache block size는 OS 사이즈를 확인 후 동일하게 유지하는 것을 권고드립니다.
