DB 관리 설계

1.    모든 작업은 스크립트로 한다.
(데이터베이스의 모든 객체 생성 스크립트 정도가 아닌 이상은 전부 SQL로 한다.)

2.    해외 서비스 시작 시 항상 최신 업데이트를 기준으로 한다.

-      혹시나 하는 마음에… 대표적인 ‘최신이잖아!’라고 해외 담당이나 거래처가 낚시하는 예를 들자면, 한국 서비스는 2014년 2월에 업데이트했는데, A 국가에 1월 업데이트로 프로토타입 테스트(사내 테스트나 FGT 등. 계약 이후 커뮤니케이션 과정에 논의된 버전)를 수행. 실 서비스도 이 버전으로 하겠다고 우기면, 과감하게 때려 처라. *PM이나 대표한테 배째라, ‘너님이 패치 만드시던가~’ 라고 강하게 나가도 된다.

3.    쓸데없는 고집, 취향을 고집하지(우기지) 마라.

-      예를 들면, ‘테이블의 컬럼 추가는 무조건 보기 예쁘게 나열되어야 한다.’라는 생각 따윈 X나 줘버리… 제발 컬럼 순서(Ordinal Position)에 목숨 걸지 말 것. 그런 건 SELECT 할 때 Select List에서나 챙겨라. (제발)

-      데이터 표기 방식에 있어 정말 막대한, 서비스에 영향이 클 정도의 ‘최적화 수준’이 아니라면 생산성 향상에 신경 써라. 그작 저작 적당히 설계된 별다른 성능 이슈 없는 OLTP 게임 서비스 따위가 CPU 10% 넘기는 것은 쉬운 일이 아니다. 차라리 그 시간에 서비스를 어떻게 완성할지, 컨텐츠의 완성도를 어떻게 높일 수 있을지,어떻게 하면 관리 효율을 높일 수 있는지를 고민해라.
(예를 들면 DATETIME 형식의 CONVERT Style에 따른 성능 향상 등에 목숨 걸거나 고집하지 말 것! 제발!!!! 결과가 20140101로 나오던 ‘2014-01-01 00:00:00.000’으로 나오던, 이 둘의 성능 차이가 하늘과 땅이라 한다면 이해 하겠다! 놀고 노는 CPU에게 일거리 좀 주면 어디 덧나나?!)

4.    버전 관리 (SVN 이던, git 이던) 할거면 하고 말려면 시도하지도 마라.

-      SVN 같은 버전 관리 솔루션 없이도 패치 스크립트를 잘 관리할 수 있다. 이런 솔루션이 만능 해결사도 아닌, 그저 추노질을 도와주는 도구 이다. 추노질 하는 게 중요한 것이 아닌, 사람의 실수를 줄이는 것이 관건이다.
이건 ‘프로세스’로 해결해야 하는 일이다!
SQL을 Revert 하거나 이미 적용한 스키마 변경사항을 롤백하는 것보단 백섭이 빠르니 애초 ‘버전 관리’란 개념 자체가 무의미하다.
물론 ‘스크립트를 잘못 저장하는 실수’ 등을 SVN으로 편하게 되돌릴 수는 있으니 ‘할 필요 없대~’라고 해석하면 곤란하다. (필자도 추노질&저장 실수 롤백에 애용한다.)

5.    성능? 자신이 편해서? 글쎄… 유지보수가 최우선이다.

-      이 부분은 호불 호가 가리는 부분인데, OLTP DBA & Developer의 입장에서 지극히 개인적인 사상이 깊이 관여된 것을 미리 알린다.

-      어떤 일이던 본인이 회사 문 닫을 때까지 책임지겠단 생각으로 만들면 절대 안 된다.
당장 본인 책상이 빠지더라도 서비스를 유지할 수 있어야 하고 그러자면 유지보수와 관련된 부분은 최적화가 필요하다.
그러나 각종 Feature를 학습하여 깨달음을 얻고 DBMS의 SELECT, INSERT, UPDATE, DELETE 외에 다른 멋진 기능을 사용해 서비스를 구성하였다면?
예를 들면, SSIS라는 멋진 자동화 시스템 (과거 SQL Server DTS라 불렸던 그것.)을 사용하여 각종 배치 작업을 효율적으로 만들었다 치자.
 (필자는 대체 게임에 이걸 쓸 일이 왜 있느냐 물어보고 싶다.)
이후 신입 or 경력직으로 OLTP 담당자가 배치되었으나 이와 관련된 지식이 없다면?
SSIS라는 방대한 서비스에 대한 지식을 숙지하는 데 걸리는 시간과 시행착오를 겪는 동안 서비스는 어떻게 될까?

게다가 SQL Server 2000->2005로 업그레이드되면서 수많은 스텝의 DTS 패키지가 100% 마이그레이션 되지 않는 문제도 겪어봤다. 
(대략 160~170개 정도 되는 스텝으로 기억한다.)
필자의 밥벌이 기술 중 하나인 SQL Server로 말을 들자면, ‘SQL Server는 SELECT, INSERT, UPDATE, DELETE 말고는 해선 안 된다.’ 이다.
그냥 그런 빈번하게 발생하는 배치 작업은 쿼리(Stored Procedure 포함.) + SQL Agent 스케줄로 처리하길 강력히 권장한다.
물론 본인이 OLTP가 아닌 DW 담당이라면 SSIS를 쓰는 것이 좋을 때도 많겠지만, PASS.
(이 글은 게임 서비스 DB에 대한 이야기이니… 100% OLTP DBA 입장이다.)

-      물론 이 부분은 위에 언급한 “쓸데없는 고집, 취향을 고집하지(우기지) 마라”라는 말을 해놓고 무슨 소리냐?! 라고 할 수도 있다. 그런데 그냥 쿼리로 할 수 있는 일은 쿼리로 하는 것이 필자의 경험상 최고였다. 하루 1TB씩 쌓이는 게임 로그도 SQL로 잘만 퍼다 날랐으니까. 어떤 일이든 ROI와 TCO를 기반으로 생각해보기 바란다.
“이게 얼마짜리 일인데?”

출처 : http://lab.gamecodi.com/board/zboard.php?id=GAMECODILAB_Lecture_series&no=59&z=0