서비스 오픈을 준비중인데요
사용자 폭주로 MSSQL 서버 한대로 힘들때 만약 3대를 돌린다면..
MSSQL 는 sharding을 자체로 지원하지 않는 걸로 아는데
어떠한 확장 방법이 있을까요?
예를 들자면 , 테이블 단위로 쪼개서 3대에 나눠서 저장한다든가
나눠서 저장하게 되면 트랜잭션 관리가 안될거 같고.
수평적 분할을 하자니
예를들어 짝수 회원정보는 A서버에, 홀수는 B서버 에 저장한다고 해도
A서버와 B서버간에 공유하는 정보는 어떻게 할것인지
좀 막막하네요
Comment 5
-
쓸만한게없네(윤선식)
2013.05.15 14:21
-
진윤호
2013.05.15 15:41
쓸만한게 없네 님의 말씀을 최우선으로 생각하시고 분할해야겠다고 생각하신다면 링크드 서버를 이용한 방식도 하나의 방식이겠네요
-
zza
2013.05.15 16:39
쓸만한게없네//답변감사합니다. 네 물론 튜닝이 최우선이겠지요. 그렇지만 튜닝을 뛰어넘는 경우를 고려해야 하는 상황이라 질문을 드렸습니다.
진윤호 // 답변 감사합니다. 링크드 서버로 날리는 쿼리가 트랜잭션 구문에 포함되어 있다면 만약 에러 발생 시 모두 롤백이 되는지 궁금하네요. 그리고 매 요청 마다 링크드 서버로 CRUD 를 하게 되면 , 쿼리를 콜 한 서버의 부하는 단독으로 처리 했을때와 비교해서 어느정도 차이가 나는지 궁금하네요.
-
진윤호
2013.05.15 17:48
트렌젝션을 전체 롤백하려면 원격 트렌젝션 속성을 TRUE로 바꺼주셔야 하구요
네트워크 부하는 있겠지만 처리는 서로 다른 서버에서 하기 때문에 물리적으로 IO가 분리되어 있으므로 IO 부하는 없을꺼구요
병목은 얼마나 자주 그 프로시저를 호출하느냐에 따라 다를꺼라서 답해 드리기가;;;
-
zza
2013.05.15 18:44
진윤호 // 답변 감사드립니다. 덕분에 도움 많이 됐습니다.
분할을 생각하기 이전에...
서비스 진행하면서..
기본적으로 성능모니터링과 Trace , 또는 확장이벤트 등을 이용해서 성능을 측정하고.
어느 곳에 부하가 생기는 지 보고 튜닝을 먼저 진행하는 것이 좋지 않을까 싶네요.
측정된 수치를 보고 CPU를 늘리거나, 메모리를 늘리거나, 디스크를 늘리는 등이 필요한 지 보고,
경우에 따라 쿼리 튜닝을 진행하면 어느 정도 해소할 수 있을 듯 합니다만.