웹에서 발생하는 여러 로그들을 디비에 삽입하여 활용하려고합니다.
문제는 피크타임에 초당 수십회이상의 inser쿼리가 들어온다는 점과(일평균 100만로우),
많게는 수개월간 누적된 로그를 확인하기 위하여 아주 무거운 select 쿼리가 발생한다는 점입니다.
그래서 여러모로 innodb보다는 myisam으로 가려고 하구요, 인서트전용DB와 셀렉트 전용디비로 분리하려 합니다.
셀렉트 전용디비는 인서트전용디비를 리플리케이션해오구요..
사실 로그수집/분석용 서버라 서비스에 1차적인 영향을 미치는 서버는 아니라 그 안정성에 대한 요구는 많이 떨어지는편입니다.
이런 구성이 괜찮을까요?
MySQL은 데이타가 방대해지면 튜닝을 제대로 안하면 엄청 느린다는 말을 들었습니다. MS-SQL도 마찬가지지만 아무래도 나중에 문제가 커질듯 싶습니다.
실시간으로 DB를 분석해야 하는 것이 아니라면 App단에서 지연 Writing을 통해서 File로 쌓아두셨다가
일정 시점마다 Bulk Insert 하시는 게 좋을 것 같습니다.
지연 Writing은 임계치에 다다랐을 때 File에 기록하시거나 주기적으로 Schedule을 실행하셔서 File로
기록하시는 게 좋을 것 같구요.
MySQL용 Bulk Insert File 규격에 맞춰서 저장하시면 수백만 로우를 입력하시는 데 몇십초도 안걸릴 것이라고
사료됩니다.
분석용 서버는 서버의 종류나 성능을 떠나서 Index 생성이 안되어있거나 Optimized 된 Query가 아니기
때문에 느릴 것이라고 사료됩니다.
아시다시피 Index 생성된 Table에 Insert를 하신다면 내부적으로 증분 Index 및 여유 공간을 확보하기 위한
작업을 하기 때문에 Insert Query의 성능이 낮아진다는 문제가 있습니다. (이 문제는 분석용 서버를 따로 두고
거기에 리플리케이션을 하든 간에 동일하게 적용되는 부분입니다)
다만 App 단에서 지연 Write로 성능상의 문제는 제거했고 주기적으로 Bulk Insert를 돌릴 것이기 때문에
결론적으로 Insert하는 데 몇십초가 더 걸려도 큰 문제는 없지 않을까 사료됩니다.
제가 말씀 드린 방법은 App 단도 수정을 해야 하는 Case이고 분석 전용 서버를 따로 둔다고 하여도 여전히
궁극적인 문제 해결을 위해 Index와 Query를 Optimizing 해야 하고 두 서버간의 사양차이가 없다면
크게 개선되지는 않을 것이라고 생각됩니다.