1. insert시 latency 줄이기....
이건, 사실 latency가 있을만한 이슈가 아닙니다. 인서트는 그냥 Disk write time만큼만 걸릴뿐입니다. 단, 쓸데없는 인덱스(clustered index종류면 더 심하고)가 많이 걸려있다면, 인덱스 갱신 시간이 조금 더 걸릴뿐입니다. 인서트를 날렸는데 시간이 오래걸린다면, 스토리지보다는, DB 구조를 의심해주세요
2. update시 latency
요건, 인서트 보단 아주 쵸큼 더 민감합니다. 우선, DISK 어디에 원래놈이 있는지 찾아서, 거기다가 써주거나, 그것보다 넘어가는게 있으면 row chaining이 발생하믄서 쭈루룩 늘어질 수 밖에 없겠지요.
하지만, 이것도 스토리지와는 상관이 별루 없습니다. 실제로 쓰는 작업은 얼마 안되니까요(뭐.. 한번에 1만건이상을 업데이트하진 않는다면요... ㄷㄷㄷ)
정확하게 where조건으로 범위를 최대한 줄인뒤에 최적조건으로 원하는 레코드를 선택해서 수정할 수 있게 해주는게 기본이고, 확정적인 필드는 varchar가 아닌 char형을 사용해주면 update시의 오버헤드를 줄일 수 있습니다.
이상, 결론적으로 스토리지를 변경한다고 해서, 원하시는 인서트, 업데이트의 수행성능이 대폭 향상되지는 않습니다.
넵. 자세한 설명감사합니다. SSD 로 실제테스트 해보니 오히려 더느린결과가 나왔습니다.^^ 하드웨어 보다는 메인프레임의 플렛폼이 더많은 영향을 주는 것 같습니다. 동일 조건하세여 OPEN 및 INSERT , UPDATE , DBF->SQL UPLOAD 시 한 15~20 % 정도 시간이 더 걸리는 값이 나왔습니다.
OS : CentOS 5.3 ( 64Bit)
PS : SATA vs S.D.D ( MySql ver 5.1.32 )
