서버 개발시에 DBMS를 사용하지 않는 것은 불가능에 가깝습니다.
특히나 트랜잭션을 C/C++ 레벨에서 구현하기란 보통 어려운게 아닙니다. DBMS에서는 시스템 단에서 지원해주기 때문에 손쉽게 트랜잭션을 사용 할 수 있죠. 데이터를 저장하고 불러 오는 것 역시 파일 시스템보다 DBMS가 훨씬 더 효율이 좋죠.
물론 그것도 잘 만들고, 잘 사용하고, 잘 관리했을때 이야기지만 말이죠.
다음은 게임 서버에서 DBMS를 이용할 때의 유의 사항입니다.
- 반드시 측정하라.
- 쿼리 프로파일러 등을 통해서 DB 부하를 측정하라.
- 원하는 목표치를 수립하고, 그 목표치에 달성 할 수 있게끔 노력하라.
- 목표치가 너무 높거나 낮을 수도 있지만, 목표치가 없이 무작정 빠르게보다 동기부여도 되고, 성취감도 생기기 때문에 반드시 목표치를 두자.
- 미리 테스트하라.
- 반드시 테스트 하라. 그리고 미리 테스트하라.
- 개발 과정에서 데이터를 임의로 생성하고, 측정하라.
- 테스트할 데이터가, 실제 유저들이 쌓을 데이터와 비슷하다면 금상 첨화다.
- 하지만 그렇지 않다하더라도 선행 테스트는 반드시 필요하다.
- 쿼리 호출 횟수를 줄이는 것도 좋은 튜닝 방법이다.
- 물론 쿼리 자체가 느리다면, 쿼리 호출 횟수가 작아도 문제가 생길 수 있다.
- 하지만, 쿼리가 아무리 빠르더라도 쿼리 호출 횟수 자체가 많다면 그것이 부하가 될 수도 있다.
- 같은 동작이 겹치는 상황을 줄여라.
- 같은 테이블에 동시에 접근하는 것은, 쿼리 수행시간 증가의 요인중 하나다.
- 단일 큐처리, 테이블 분산 등을 통해서 최대한 병렬 작업의 효율을 높이도록 하자.
- 커넥션이 많다고 좋은게 아니다.
- 4번 항목과 연관성이 있는 내용으로, 커넥션이 많다고 능사가 아니다.
- 같은 테이블에 접근하는 SP가 여러개 커넥션에서 몰리면 블러킹으로 효율이 저하될 가능성도 높아진다.
- 진정한 병렬수행이 될 수 있도록 설계하고, 사용하라.
- 잘 사용하는 것은 잘 만든 것 만큼이나 중요한 것이다.
- 적은량의 데이터만으로 테스트 하지 말아라.
- 2번 항목에서 언급했듯이, 테스트할 데이터가 실제 유저들이 쌓을 데이터와 비슷하면 비슷할수록 실제 서비스와 유사한 측정과 개선이 가능해진다.
- 실제 유저들이 쌓을 데이터가 아닌, 개발자와 QA 데이터 몇개만으로 테스트 하지 말아라. 그렇게하면 논리적 구현의 테스트는 될 지언정 효율에 대한 테스트는 불가능하다.
- 트랜잭션을 적극 활용하라.
- 4,5번 항목과 조금 엇갈리는 내용이지만, 효율보다 예외처리가 더 중요하다.
- 트랜잭션을 잡아야 하는 동작이 있다면 반드시 트랜잭션을 잡아라. 효율을 위해 번거로운 예외처리를 서버에서 처리하게 된다면, 그로 인해 손해 보는 것 (예외 상황을 처리하는 개발 과정, 예외 상황 처리를 테스트 하는 과정, 예외 상황을 정상 처리로 수행 가능하게끔 만들기 위한 노력, 만약에 예외 처리에 실패했을 경우에 겪는 피해)들이 너무 크다.
- 트랜잭션을 잡게 되면 그만큼 효율은 떨어지지만, 논리적 오류로써 겪게 되는 문제들에서 해소 될 수 있다.