디비에 관한 질문....

3권에서 새로 도입된 네트웍 및 멀티플레이어 프로그로그래밍 섹션을 위한 게시판입니다.

Moderator: 류광

Locked
laster40
Posts: 113
Joined: 2005-01-12 05:04
Location: 무소속

디비에 관한 질문....

Post by laster40 »

게임 서버에서 데이터 베이스 처리는 어떻게 하고들 있는지 궁금합니다.


game server <-------> database


보통 중간에 미들웨어를 하나 둔다거나, 아님 위의 그림처럼 직접 연결이 될텐데

저 같은 경운 위의 그림 처럼 직접 연결이 되게 만들고 있습니다.


저렇게 연결되어 있을경우 1:1 이 가장 적합 할까요? ( 하나의 DBMS 에 한해 )

만약에 1:1 보다 더 적합한 구조가 있다면 그것은 어떤것일까요? 또 그 이윤 무었일까요...

DBMS의 속성이나 데이터 베이스 클라이언트 ( ODBC, ADO, 등등 ) 의 특성에 따라 달라지는것인지...


오래전부터 주로 전 game server가 database 에 어떤 작업을 하는 쓰레드별로 커넥션을 하나씩 생성햇었습니다. 이방법은 어떻게들 보시는지요... 쓰레드가 많아 봤자 3~4개 정도 였었고, 동기화가 필요없어서... 이렇게 했었지 않았나 싶습니다. +_+;

여러 적용 사례도 궁금하고, 정확한 원리들이 궁금해 지네요-_-;; 이러면 안대는데-_-;;
jacking
Posts: 1035
Joined: 2002-01-09 09:00

Post by jacking »

game server <-------> database 이 경우는 DB 작업이 빈번하지 않는 경우라면 심플한게 좋다고 생각합니다. 아마 온라인보드 게임쪽은 이렇게 하지 않나 생각합니다.

온라인 보드 게임 특성상 DB 작업의 많지 않고(어느 정도 안정화만 되면 처음 로그인 시에 데이타 가져오고 로그아웃 할 때에 데이터 저장을 하는 식으로 하기도 합니다) DB가 세분화 되어 있는 경우라면 이렇게 하는 것도 좋은 방법 이라고 생각합니다( 아이템 DB, 유저 DB, 게임DB, 프리미엄 유저DB등으로..).

그리고 동기화 문제만 없다면 스레드 사용도 좋다고 생각합니다. 특히나 점점 듀얼 코어로 가고 있으니까(인텔에 의하면2006년 제품의 70%, 2007년 부터는 듀얼코어 이상 제품만 발매(4코어, 8코어 등) 한다고 하더군요) 스레드 상의 문제도 없을거라고 생각합니다.

제가 경험이나 지식이 많지 않았어 정확한 답변은 힘들지만 지금 laster40님 하시고 계신 방법이 문제는 없다고 생각합니다. 특히나 1:1의 장점은 온라인 보드 게임 처럼 게임의 종류가 늘어나는 형식에서는 오히려 관리가 더 편할거라고 생각합니다(DB 관련 작업이 바뀌면 해당 게임 서버만 수정하면 되니까요).
제가 경험한 방식 중 하나가 laster40님과 비슷한 방식이었지만 전혀 문제 없이 서비스 잘 했습니다.
jangdt
Posts: 45
Joined: 2004-10-29 13:38
Location: NCSoft

Re: 디비에 관한 질문....

Post by jangdt »

laster40 wrote:게임 서버에서 데이터 베이스 처리는 어떻게 하고들 있는지 궁금합니다.


game server <-------> database


보통 중간에 미들웨어를 하나 둔다거나, 아님 위의 그림처럼 직접 연결이 될텐데

저 같은 경운 위의 그림 처럼 직접 연결이 되게 만들고 있습니다.


저렇게 연결되어 있을경우 1:1 이 가장 적합 할까요? ( 하나의 DBMS 에 한해 )

만약에 1:1 보다 더 적합한 구조가 있다면 그것은 어떤것일까요? 또 그 이윤 무었일까요...

DBMS의 속성이나 데이터 베이스 클라이언트 ( ODBC, ADO, 등등 ) 의 특성에 따라 달라지는것인지...


오래전부터 주로 전 game server가 database 에 어떤 작업을 하는 쓰레드별로 커넥션을 하나씩 생성햇었습니다. 이방법은 어떻게들 보시는지요... 쓰레드가 많아 봤자 3~4개 정도 였었고, 동기화가 필요없어서... 이렇게 했었지 않았나 싶습니다. +_+;

여러 적용 사례도 궁금하고, 정확한 원리들이 궁금해 지네요-_-;; 이러면 안대는데-_-;;
전 보통 미들웨어를 두는 걸 좋아하는데요. 가장 큰 이유는 리스크 분산입니다. 게임서버는 잦은 패치로 인해 지속적인 안정성을 확보하는데 어려움이 많습니다. 그래서 범용 쿼리 서버를 만들어 데이터 검증이나 캐슁 같은 작업을 분리시켜, 한번 안정성을 확보하면 서비스 동안 구조가 바뀌는 일은 없기 때문에 이쪽에 대해서는 잊어버릴수 있어 편합니다.

그 다음으로는 기능 분산인데요. DB 처리는 필연적으로 스레드 수가 많아질 수 밖에 없습니다. 거기다 사용자별로 직렬화 기능을 제공할려면 그에 따르는 스레드가 하나 더 필요하게 되죠. 이쪽 코드를 분리시키면 당연히 게임서버가 더 많은 사용자를 받아들일수 있겠죠~ 자잘한 효과로는 보안 강화 정도가 있구요 ^^
laster40
Posts: 113
Joined: 2005-01-12 05:04
Location: 무소속

Re: 디비에 관한 질문....

Post by laster40 »

전 보통 미들웨어를 두는 걸 좋아하는데요. 가장 큰 이유는 리스크 분산입니다. 게임서버는 잦은 패치로 인해 지속적인 안정성을 확보하는데 어려움이 많습니다. 그래서 범용 쿼리 서버를 만들어 데이터 검증이나 캐슁 같은 작업을 분리시켜, 한번 안정성을 확보하면 서비스 동안 구조가 바뀌는 일은 없기 때문에 이쪽에 대해서는 잊어버릴수 있어 편합니다.

그 다음으로는 기능 분산인데요. DB 처리는 필연적으로 스레드 수가 많아질 수 밖에 없습니다. 거기다 사용자별로 직렬화 기능을 제공할려면 그에 따르는 스레드가 하나 더 필요하게 되죠. 이쪽 코드를 분리시키면 당연히 게임서버가 더 많은 사용자를 받아들일수 있겠죠~ 자잘한 효과로는 보안 강화 정도가 있구요 ^^
답글 감사하구여~

미들웨어를 두신다고 하셨는데 그 미들웨어의 기능은 무었인가요...


그리고 미들웨어와 게임서버 ( 혹은 뭐 다른 컨텐츠 제공 서버 )들의 프로토콜은 어떤형식을 뛰는가요~~?
1.쿼리(스트링으로)를 그냥 미들웨어로 넘기고 게임서버로 그 결과를 받는다?
2.어떤 쿼리 형태가 아닌 특정 요청 형태인가요??? ( 예:로그인 시켜두 되는지 확인해 줄래? )

미들웨어의 기능으로 흔히 데이터의 캐싱...과 뭐 물론 당근 쿼리 실행 등의 역할을 하는거 같던데...
laster40
Posts: 113
Joined: 2005-01-12 05:04
Location: 무소속

ㄳㄳ

Post by laster40 »

jacking wrote:game server <-------> database 이 경우는 DB 작업이 빈번하지 않는 경우라면 심플한게 좋다고 생각합니다. 아마 온라인보드 게임쪽은 이렇게 하지 않나 생각합니다.

온라인 보드 게임 특성상 DB 작업의 많지 않고(어느 정도 안정화만 되면 처음 로그인 시에 데이타 가져오고 로그아웃 할 때에 데이터 저장을 하는 식으로 하기도 합니다) DB가 세분화 되어 있는 경우라면 이렇게 하는 것도 좋은 방법 이라고 생각합니다( 아이템 DB, 유저 DB, 게임DB, 프리미엄 유저DB등으로..).

그리고 동기화 문제만 없다면 스레드 사용도 좋다고 생각합니다. 특히나 점점 듀얼 코어로 가고 있으니까(인텔에 의하면2006년 제품의 70%, 2007년 부터는 듀얼코어 이상 제품만 발매(4코어, 8코어 등) 한다고 하더군요) 스레드 상의 문제도 없을거라고 생각합니다.

제가 경험이나 지식이 많지 않았어 정확한 답변은 힘들지만 지금 laster40님 하시고 계신 방법이 문제는 없다고 생각합니다. 특히나 1:1의 장점은 온라인 보드 게임 처럼 게임의 종류가 늘어나는 형식에서는 오히려 관리가 더 편할거라고 생각합니다(DB 관련 작업이 바뀌면 해당 게임 서버만 수정하면 되니까요).
제가 경험한 방식 중 하나가 laster40님과 비슷한 방식이었지만 전혀 문제 없이 서비스 잘 했습니다.
안녕하세요~ 답글 ㄳㄳ

보드 게임쪽만 언급을 해주셔서^^;;

mmorpg에서는 조금 그런가요? ^^a

쿼리를 날릴때 물론 게임을 처리 중인 쿼리를 날리는 쓰레드가 빠지긴 합니당^^;

mmorpg개발시 보통 미들웨어를 제작하는게 일반적인가요? -_-;; 제가 봣던( 한 회사만 다녀서;; ) 곳에서는 항상 그냥....;

하나의 디비에 여러개의 커넥션을 연결해서 처리하는것과 하나의 디비에 하나의 커넥션을 연결해서 처리하는것을 비교하면 어떤것이 나은지가 우선 궁금한데... 테스트는 비슷비슷한 결과가 나오긴 하지만 이건 어디까지나 테스트이기 때문에 파악이 잘되질 않네요....^^ 혹시 이것에 대해서 자세히 아시면 답글좀 부탁드립니다.
jacking
Posts: 1035
Joined: 2002-01-09 09:00

저도 별로 아는게 없네요...-_-;;;

Post by jacking »

저도 경험이 많지 않았어... -_-;;

MMO는 제가 알기로는 거의 대다수가 미들웨어를 두는 걸로 압니다.
(제가 있는 팀도 그렇고요)

MMO는 워낙 다양하게 DB 작업을 하니 미들웨어를 두는게 좋다고 생각합니다.
그리고 그 미들웨어는 하나의 MMO를 전담할 테니 오히려 한쪽에서만 관리하는게
더 좋기도 하고요(그에 반해 보드게임은 여러 게임을 서비스 하니 미들웨어를
두면 해당 게임 개발자는 미들웨어 담당자를 통해야 되니 오히려 귀찮아 질듯
합니다).

하나의 DB에 하나의 커넥션이 좋으리라 생각합니다. 그리고 일반 DBA가 보면
별 의미 없이 연결하고 있는 것 별로 안 좋아 하더군요..리소스를 잡아 먹으니
다만 DB를 나눌 수 있다면 DB를 나눈 후 각각 커넥션 하면 좋을 듯 합니다.
(MMO는 최소한 공용DB와 게임DB로는 나눌 수 있고, 저의 경우는 로그 통계 DB도
사용 합니다)

그리고 미들웨어를 사용하더라도 캐싱 기능은 별로 사용 안하는 걸로 압니다.
몇년전에는 사용한걸로 아는데 근래에 물어보니 거의 사용하지 않더군요.
제가 생각해봐도 캐싱 기능 잘못 사용하면 DB의 데이타 값이 잘 못될 여지가
있을 것 같아서 성능 좀 높일려고 하다가 큰일 당하겠더군요 그래서 캐싱 부분은
포기 했습니다. 그리고 어느분 말처럼 이런 작업 하는 것보다 DB 튜닝을
잘하는 쪽이 훨씬 좋습니다. 저도 근래 DB 동영상 강좌를 보고 있는데 제가
스킬이 낮아서 다는 이해를 못하지만 DB의 심오함과 실수에 의해 어떤일이
벌어지는지 알게 되어서 두렵더군요. DB쪽 성능을 올리고 싶으시면 DB 튜닝(설계)을
잘하는게 최고 입니다.
현재까지의 DB의 대한 저의 생각은 DBA에 있는 회사를 가던가, DB를 좋아하고
잘 아는 사람과 일을 하던가..정 안되면 제가 열심히 공부 해야 된다는 거더군요..
가능하면 전 1번이 되었으면 좋겠습니다.^^;;;
jangdt
Posts: 45
Joined: 2004-10-29 13:38
Location: NCSoft

Re: 디비에 관한 질문....

Post by jangdt »

laster40 wrote:
전 보통 미들웨어를 두는 걸 좋아하는데요. 가장 큰 이유는 리스크 분산입니다. 게임서버는 잦은 패치로 인해 지속적인 안정성을 확보하는데 어려움이 많습니다. 그래서 범용 쿼리 서버를 만들어 데이터 검증이나 캐슁 같은 작업을 분리시켜, 한번 안정성을 확보하면 서비스 동안 구조가 바뀌는 일은 없기 때문에 이쪽에 대해서는 잊어버릴수 있어 편합니다.

그 다음으로는 기능 분산인데요. DB 처리는 필연적으로 스레드 수가 많아질 수 밖에 없습니다. 거기다 사용자별로 직렬화 기능을 제공할려면 그에 따르는 스레드가 하나 더 필요하게 되죠. 이쪽 코드를 분리시키면 당연히 게임서버가 더 많은 사용자를 받아들일수 있겠죠~ 자잘한 효과로는 보안 강화 정도가 있구요 ^^
답글 감사하구여~

미들웨어를 두신다고 하셨는데 그 미들웨어의 기능은 무었인가요...


그리고 미들웨어와 게임서버 ( 혹은 뭐 다른 컨텐츠 제공 서버 )들의 프로토콜은 어떤형식을 뛰는가요~~?
1.쿼리(스트링으로)를 그냥 미들웨어로 넘기고 게임서버로 그 결과를 받는다?
2.어떤 쿼리 형태가 아닌 특정 요청 형태인가요??? ( 예:로그인 시켜두 되는지 확인해 줄래? )

미들웨어의 기능으로 흔히 데이터의 캐싱...과 뭐 물론 당근 쿼리 실행 등의 역할을 하는거 같던데...
미들웨어의 기능은 부여하기 나름이구요..
프로토콜 또한.. 스트링 기반 혹은 바이너리 기반 모두 가능합니다.
다만.. 경험에 의하면 바이너리 기반이 훨씩 좋았구요.
스레드당 각각 DB랑 컨넥션을 유지하는 형태를 기반으로 하구요.. 상위에 Assign 스레드를 두어 유저당 직렬화 처리를 해줘도 되고 안해줘도 됩니다. (필요에 따라.. ) 커넥션은 저는 최고 40개까지 사용해봤습니다.
즉, 스레드가 40개죠.. 스레드수는 초당 예상 쿼리수를 잘 계산하여 테스트에 의해 정하시면 되구요. 스레드가 너무 적으면.. 동시 실행 쿼리수가 적기 때문에 DB가 놀게됩니다. 반대로 너무 많으면 DB에 부하가 걸리지요. 제 경험으로는 쿼리서버보다 DB가 한계에 먼저 부딧쳤습니다. 실제 일은 DB에서 하니 당연한 얘기지만.. ㅎㅎ
캐싱은 게임에 따라서.. 할수도 안할수도 있습니다. 다만, MMO같은 경우 잦은 중간 업데이트 혹은 실시간 으로 정보를 저장할려면.. DB에 부담이 되니 캐싱을 해주면 좋죠.
soryu
Posts: 204
Joined: 2003-12-12 22:59

Post by soryu »

꼭 미들웨어를 두지 않아도 됩니다-_-/

게임 - DB 를 다이렉트로 연결하는데다가,

스레드로 DB를 빼지 않고 직접 쿼리를 날리고 Block 상태에 들어간다 할지라도..

왠만큼 이상의 동접은 버텨줍니다;;

거기다가 서버 컴텨를 고사양으로 셋팅해준다면, 상상 이상의 동접을 가뿐히 받아냅니다.

미들웨어로 DB를 두어서 생기는 각종 문제에 대한 대처에 드는 비용을 생각해본다면, 나쁘지 않은 선택인거 같습니다.
zupet
Posts: 2764
Joined: 2003-05-13 03:34
Location: NCSOFT LE팀

Post by zupet »

soryu wrote:꼭 미들웨어를 두지 않아도 됩니다-_-/

게임 - DB 를 다이렉트로 연결하는데다가,

스레드로 DB를 빼지 않고 직접 쿼리를 날리고 Block 상태에 들어간다 할지라도..

왠만큼 이상의 동접은 버텨줍니다;;

거기다가 서버 컴텨를 고사양으로 셋팅해준다면, 상상 이상의 동접을 가뿐히 받아냅니다.

미들웨어로 DB를 두어서 생기는 각종 문제에 대한 대처에 드는 비용을 생각해본다면, 나쁘지 않은 선택인거 같습니다.
soryu 님의 의견에 상당부분 동감하지만 그래도 H/W를 활용한다는 측면에서 동기화 DB 접근은 줄여 나가지 않으면 안된다고 생각합니다. 대부분 DB의 반응이 무척 빠르지만 그래도 네트워크를 거쳐서 결과가 돌아오게 되고 그동안 메인 쓰레드가 쉬어야 하는 것은 사실이니까요. 위와 같이 얘기한 게임중에 성공적인 게임도 경험이 있지만 그래도 DB의 부하에 따른 게임 서버의 랙이나 문제점등을 끝까지 사라지지 않았고 끝내 초 고가 장비로 떡칠을 해서 겨우 어느정도 구색만 맞추었습니다. 가격은 10배도 넘게 들었지만 실제 효율은 두배도 채 못되었던 걸로 기억하고 있습니다.

'그 짧은 시간' 이라 말하시는 분이 계실지도 모르지만 저는 아직도 M$ 에서 테스트하는 MS-SQL의 트랜젝션 숫자와 실제 게임 서버들이 처리하는 트랜젝션 숫자의 차이값이 왜 수백 수천배씩 차이가 나야하는지 아직 이해하지 못하고 있습니다. 제가 클라이언트라서 그런지 몰라도 3D 카드에선 어느정도 합리적인 수치들이 나오는데 반해서 DB 에선 왜 그런 합리적결과나 벤치에 근접한 모양들을 내지 못하는지 궁금합니다.

p.s.역시 직접 DB를 해봐야하는데.. 다음 프로젝트는 서버 닦까리 부터 시켜달랠까?
mesya
Posts: 268
Joined: 2005-02-28 20:08

Post by mesya »

디비처리는 스레드로 빼야된다에 한표입니다.
디비처리에 동접대비 걸리는 시간을 적당히 뽑아보시면..
디비스레드를 몇개 돌렸을때 최적인지도 뽑을 수 있겠죠..
(디비스레드 1개당 커넥션 1개겠지요)

동기화처리만 조금 신경쓰면 될텐데...
작업할때 편하기는 그냥 메인프로세스에서 처리하는게 편하겠지만..
이왕이면 빼세요 스레드로...

메인프로세스에서 처리하게 되면, 디비처리를 하는동안
서버는 멈춰있는건데.. 디비처리렉=서버렉 이 되겠네요..

개인적으로 중간에 미들웨어까지 둘 필요도 없다고 생각하구요.
(제가 캐주얼게임을 만들다보니 그럴수도.. 있겠네요)
이지노리, 김현중
seeper
Posts: 1483
Joined: 2003-06-06 23:19
Contact:

Post by seeper »

zupet wrote:'그 짧은 시간' 이라 말하시는 분이 계실지도 모르지만 저는 아직도 M$ 에서 테스트하는 MS-SQL의 트랜젝션 숫자와 실제 게임 서버들이 처리하는 트랜젝션 숫자의 차이값이 왜 수백 수천배씩 차이가 나야하는지 아직 이해하지 못하고 있습니다.
어떤 자료인지는 모르겠지만... 추측하자면...
3D 카드의 경우는 대부분 용도가 비슷하지만...
DB의 용도마다 튜닝 방법이 완전히 달라지기 때문 아닐까요?
아마도 게임 DB에 기초한 값이 아니라는 생각이드네요...
seeper0 (a) gmail.com [email주소 무단수집거부]
jacking
Posts: 1035
Joined: 2002-01-09 09:00

Post by jacking »

DB가 구성 및 쿼리 내용에 따라 성능에 많은 영향을 주는 걸로 압니다.

제가 보고 있는 강좌를 보니 한 예로 예전의 KT의 이야기 인데 이곳에서 튜닝 해주로 가기전까지는 매달 전 사원 월급 계산 결과 내는데 18시간을 걸렸는데 강사가 가서 튜닝을 하고 직원 한명을 교육 시켰는데( 이분은 DB는 집합이라고 생각하기 때문에 경력직 보다 수학과 출신의 신입을(쿼리를 처음 사용해보는) 데리고 같이 일하면서 가르쳤는데 한달 후에 18시간 걸리는 작업을 단 10분만에 끝냈다고 하더군요.
이 강의를 보면 이런 예가 여러 나오는데 이걸 보면 DB가 상당히 두려워집니다..-_-;;;
jangdt
Posts: 45
Joined: 2004-10-29 13:38
Location: NCSoft

Post by jangdt »

미들웨어로 빼면 더 관리하기 힘들거라고 생각하시는 분들이 많은거 같은데요.
제너널한 쿼리서버 제대로 만들어놓으면 훨씬 편하다고 생각합니다. 여러 프로젝트에 사용 가능하게도 만들수 있구요. 뭐.. 프로시저 실행딴에서 단순 작업량이 조금 많아지는거야 어쩔수없지만.. 프로젝트 하나 할거 아니라면 오히려 미들웨어로 빼는게 더 좋습니다.

그리고 여담이지만~ DB는 DB를 전문적으로 하시는 분들에게 맡겨야 한다고 생각합니다. 서버 플머가 DB한거 치고 제대로 된거 아직 못봤네요.. 다들 통DB.. DB설계나 튜닝 말고도 기획서를 보고 DBA 관점에서 데이터도 뽑아주고요.. 모니터링 툴도 만들어주고.. 좋은점이 많습니다.
zupet
Posts: 2764
Joined: 2003-05-13 03:34
Location: NCSOFT LE팀

Post by zupet »

jangdt wrote:미들웨어로 빼면 더 관리하기 힘들거라고 생각하시는 분들이 많은거 같은데요.
제너널한 쿼리서버 제대로 만들어놓으면 훨씬 편하다고 생각합니다. 여러 프로젝트에 사용 가능하게도 만들수 있구요. 뭐.. 프로시저 실행딴에서 단순 작업량이 조금 많아지는거야 어쩔수없지만.. 프로젝트 하나 할거 아니라면 오히려 미들웨어로 빼는게 더 좋습니다.

그리고 여담이지만~ DB는 DB를 전문적으로 하시는 분들에게 맡겨야 한다고 생각합니다. 서버 플머가 DB한거 치고 제대로 된거 아직 못봤네요.. 다들 통DB.. DB설계나 튜닝 말고도 기획서를 보고 DBA 관점에서 데이터도 뽑아주고요.. 모니터링 툴도 만들어주고.. 좋은점이 많습니다.
DB 하시는 분들께 죄송하지만 이쪽 업계에서 자칭 DBA라고 하면서 DB 관리 하시는 분중에 H/W 적인 특성을 제대로 이해하면서 DB 하시는 경우를 한분도 못뵈었습니다. DB 튜닝은 도리어 H/W 매니아 SE 라던지 프로그래머쪽이 훨씬 잘하곤 하고 DBA 라는 분들은 적당히 인덱스 잡고 몇가지 손보면서 '구조가 썩었어(좀 부드럽게 말해서)' 라고 중얼거리는게 대부분이었던 걸로 기억하는군요.

일단 저렴한 DBA 의 경우 교육 수준도 수준이고 대부분 MCSE 따듯이 몇몇 자격증을 딴 상태에서 큰 경험없이 취업하는 경우도 많으니까요. 제대로 튜닝을 할 수 있는 사람은 가볍게 억대로 넘어간다지만 2000 ~ 3000 만원대 연봉에 뽑아서 원하는 결과를 내기는 정말 힘든 것 같습니다. 큰 회사에는 제대로된 DBA가 한두명은 있을법 하긴 한데 아직까진 직접 만나보지 못했네요.

p.s.DB튜닝 제대로 들어가면 디스크 I/O 블럭 전송 경계까지 신경써서 테이블 만든다던데 -_-a

p.s.2.물론 쿼리도 못만집니다. 프로그래머가 다 만들어 놓은걸 맘대로 뜯어 고치는 것도 한계가 너무 크니까요. -_-a
seeper
Posts: 1483
Joined: 2003-06-06 23:19
Contact:

Post by seeper »

정말 큰회사가 아니라면 게임회사에 전문 DBA를 두는것은 인력구성에서 낭비라는 생각이드네요..
(사실 큰회사도 낭비라고 생각합니다만... ^^)

지적하신대로 제대로된 튜닝하려면 논리적인것 뿐만이라 물리적인것 까지 제대로 이해해야합니다.
대부분의 경우 논리적인것만 약간 이해할 뿐이죠.

제대로 안다면 억대 연봉이 나올수 밖에 없습니다.
그런데 게임회사에서 연봉주는건 기술순이 아니라 흥행순이기 때문에 더욱 힘들죠...
아니 게임회사 뿐만 아니라 고용하기 힘들기 때문에 이런 분들은 컨설팅 같은 쪽에 있습니다.

결국 게임에서 DB최고 책임자는 DB컨설팅하는 사람과 책임지고 커뮤니티 가능한 사람 정도가 적당한것 같습니다.

컨설팅 가능한 사람은 문제있을때 불러서 체크하는것이면 충분하다고 생각합니다.
길게 잡아 한달 비용정도만 들이면 아주 좋은 효과를 볼 수 있으니까요.

ps...
몇년전만 해도 하드웨어가 비쌌기 때문에 제대로된 DBA의 몸값이 무지 비쌌습니다.
게임쪽으로 온 이후에 그 쪽 상황은 잘 모르겠네요...
그러나 하드웨어의 가격 인하 때문에 제대로된 DBA의 필요성이 줄어드는 듯한 기분입니다.
(게임쪽에 있기 때문에 그렇게 느껴지는건지 모르겠지만요.. )
seeper0 (a) gmail.com [email주소 무단수집거부]
Locked