서버에서 데이터 베이스 이용시 유의 사항

서버 개발시에 DBMS의 지원을 받지 않는 것은 불가능에 가깝습니다. 

특히나 트랜잭션을 C/C++ 레벨에서 구현하기란 보통 어려운게 아닙니다. DBMS에서는 시스템 단에서 지원해주기 때문에 손쉽게 트랜잭션을 사용 할 수 있죠. 데이터를 저장하고 불러 오는 것 역시 파일 시스템보다 DBMS가 훨씬 더 효율이 좋죠.

물론 그것도 잘 만들고, 잘 사용하고, 잘 관리했을때 이야기지만 말이죠.

다음은 게임 서버에서 DBMS를 이용할 때의 유의 사항입니다.

1. 반드시 측정하라.

쿼리 프로파일러 등을 통해서 DB 부하를 측정하라. 

원하는 목표치를 수립하고, 그 목표치에 달성 할 수 있게끔 노력하라.

목표치가 너무 높거나 낮을 수도 있지만, 목표치가 없이 무작정 빠르게보다 동기부여도 되고, 성취감도 생기기 때문에 반드시 목표치를 두자.

2. 미리 테스트하라.
반드시 테스트 하라. 그리고 미리 테스트하라.

개발 과정에서 데이터를 임의로 생성하고, 측정하라.

테스트할 데이터가, 실제 유저들이 쌓을 데이터와 비슷하다면 금상 첨화다.

하지만 그렇지 않다하더라도 선행 테스트는 반드시 필요하다.

3. 쿼리 호출 횟수를 줄이는 것도 좋은 튜닝 방법이다.

물론 쿼리 자체가 느리다면, 쿼리 호출 횟수가 작아도 문제가 생길 수 있다.

하지만, 쿼리가 아무리 빠르더라도 쿼리 호출 횟수 자체가 많다면 그것이 부하가 될 수도 있다.

4. 같은 동작이 겹치는 상황을 줄여라.

같은 테이블에 동시에 접근하는 것은, 쿼리 수행시간 증가의 요인중 하나다.

단일 큐처리, 테이블 분산 등을 통해서 최대한 병렬 작업의 효율을 높이도록 하자.

5. 커넥션이 많다고 좋은게 아니다.

4번 항목과 연관성이 있는 내용으로, 커넥션이 많다고 능사가 아니다.

같은 테이블에 접근하는 SP가 여러개 커넥션에서 몰리면 블러킹으로 효율이 저하될 가능성도 높아진다.

진정한 병렬수행이 될 수 있도록 설계하고, 사용하라.

잘 사용하는 것은 잘 만든 것 만큼이나 중요한 것이다.

6. 적은량의 데이터만으로 테스트 하지 말아라.

2번 항목에서 언급했듯이, 테스트할 데이터가 실제 유저들이 쌓을 데이터와 비슷하면 비슷할수록 실제 서비스와 유사한 측정과 개선이 가능해진다.

실제 유저들이 쌓을 데이터가 아닌, 개발자와 QA 데이터 몇개만으로 테스트 하지 말아라. 그렇게하면 논리적 구현의 테스트는 될 지언정 효율에 대한 테스트는 불가능하다.

7. 트랜잭션을 적극 활용하라.

4,5번 항목과 조금 엇갈리는 내용이지만, 효율보다 예외처리가 더 중요하다.

트랜잭션을 잡아야 하는 동작이 있다면 반드시 트랜잭션을 잡아라. 효율을 위해 번거로운 예외처리를 서버에서 처리하게 된다면, 그로 인해 손해 보는 것 (예외 상황을 처리하는 개발 과정, 예외 상황 처리를 테스트 하는 과정, 예외 상황을 정상 처리로 수행 가능하게끔 만들기 위한 노력, 만약에 예외 처리에 실패했을 경우에 겪는 피해)들이 너무 크다.

트랜잭션을 잡게 되면 그만큼 효율은 떨어지지만, 논리적 오류로써 겪게 되는 문제들에서 해소 될 수 있다.

좋은 개발자는 단순히 속도만 생각해서 되는 것이 아니다. 무엇이 더 효율적인지 생각하라.