게임코디 게임코디 연구소 GCGC 프로카데미 교육센터   회원가입 회원등급 실무자 인증 공지사항 RSS
게임프로그래머 만담 커뮤니티 베타게시판 :   지금은 개발중  |             |   무리수 건의함  |  이미지 HDD  |
게임개발자 실시간 만담
   로그인이 안돼요 자동 로그인


새로운 댓글
  안녕 ~ 게임코디 ㅋㅋ
  막아야 하는데 귀찮아...
  답글은 달고 봅니다 ㅋ...
  ㅋㅋㅋㅋㅋㅋ 이러지 ...
  이러지 마십쇼 아직 작...
  아 포인트는 어제 19시...
  두구두구두구두구....
  오!
  누군가 전염병주식회사...
  앗 아앗...
  16200원
  삼성전자우KODEX200KO...
  오오 마토찡의 게임
  되는걸로 알고있습니다...
  코스피 1680찍고 말...
  2019버전이긴 한데, ...
  흠... 과연
  올해만 버티시고5기가/...
  호우 감사함돠
  답변들 감사합니다. dl...
  .....
  비쥬얼이 재미있어보이...
  글로벌 판데믹으로 변...
  해외 직구 배송비 포함...
  ㅎㅎ 그런가요? 감사합...
  아... 사놓을걸...미...
  저도 유투브 보다가 이...
  마감되었습니다. 감사합...
  외부로부터 의도하지 ...
  쩐이 없는거 같어요총...

# 여기는 읽기 전용의 구 '게임코디 1st' 입니다

# 우리는 이제 게임코디 2nd 로 갑니다. https://gamecodi.com

게임 프로그래머의 만담은 새로운 '게임코디 2nd' 에서 진행됩니다.

개발만담 - 개발,업무,우리의 밥벌이와 관련된 만담 게시판.

Loading...
중국의 어떤 서버 개발자의 디비 설계
 * 탈퇴 imays 
작성 : 2015-12-11 14:55:31    |    조회 : 29,819
    11       
  

제가 몇 년 전에 어떤 중국 서버 개발자와 나눈 대화 내용입니다.

----------------------------

중국 개발자: 우리는 가입자 1억명 들어가 있는 게임의 디비에 유저 정보를 바이너리로 시리얼라이즈해서 그냥 쌩으로 때려박는다. 트랜잭션 안 써.

나: 헐? 너 미쳤어?

중국 개발자: 안그러면 디비가 못 버팀. 

나: 그렇게 하면 검색도 어렵고 트랜잭션도...

중국 개발자: 트랜잭션이 뭐하는데 쓰는건지는 아니?

나: 어쩌고 저쩌고

중국 개발자: 그건 피지컬 오류에 대한 롤백이고. 피지컬 오류 발생이 얼마나 나지?

나: 거의 안나지. 

중국 개발자: 게임 서버 만들어봐서 알잖아. 로직은 어디서 다 일어나지?

나: 게임 서버 메모리 안에서지.

중국 개발자: 그래서 피지컬 오류가 거의 안나는거야. 트랜잭션은 로지컬 오류에서 효과적이지. 게임 서버 램 안에서 다 해먹는데 트랜잭션은 득보다 실이 상회한다.

나: ...! (뒷통수 맞는 느낌)

중국 개발자: 계속 이어서 말해주지. 바이너리로 저장하는 이유 말이지... 그것도 성능을 위해서야.

나: 그러면 캐릭터 정보 조금이라도 바뀌면 다 바이너리로 만들어서 저장해야 할텐데?

중국 개발자: 당연하지. 근데 그게 훨씬 빠르다. 너 디비에서 가장 느린게 어딘지 알아?

나: 응. 하드디스크.

중국 개발자: 더 정확하게 짚어서 말하자면, 하드디스크 중에서 헤드가 움직이는 순간이 가장 느려. 

나: ...! (뒷통수 맞는 느낌) 이제야 이해된다. 그렇다면 당연히 캐릭터 정보 전체를 시리얼라이즈해서 매번 통으로 저장하는게 훨씬 빠르겠네. 헤드 움직임이 적을테니까.

중국 개발자: 그렇지. 하나 더 얘기하자면, 바이너리로 저장해서 최대한 압축하는게 좋아. 가능하면 4KB 안에 저장하는게 좋지.

나: 응? 그거는 섹터 하나의 크기 아니야? 그만큼 헤드가 안 움직여도 되고.

중국 개발자: 빙고. 잘 아네.

----------------------------

두줄 요약

트랜잭션은 피할 것.
바이너리에 캐릭터 정보를 압축해서 쌩으로 넣는 것도 효과적.

----------------------------

상기 대화 내용에 대한 저의 생각

1억명 계정 들어있는 디비를 직접 돌려본 경험이 없어서 저 말이 맞는지는 모르겠지만, 일단은 디비 과부하 상황에서 저런 방법도 고려는 해볼 필요가 있다고는 생각합니다.




 * 탈퇴       
루팡3세

오호~ 유레카~

근데 1억명은 꿈~

2015-12-11
14:58:51

  
힙돌이동남아


와..... 1억명..
2015-12-11
15:02:57

  
닥터이블


검색하지 않을 데이터라면야.. 그나저나 1억명.. 부럽~
2015-12-11
15:29:00

  
.kebi


허허... 그렇겠네요
2015-12-11
15:51:44

  
tinywolf


극한 상황이 최상의 해결법을 찾게 해주는군요.
2015-12-11
16:31:12

  
물치


실제로 퍼블리셔에서는 트랜잭션을 가급적 걸지말라고들 하더라구요.
0.001% 확률로 에러 나는건 운영 이슈로 처리하는게 훨씬 효과적이라고 합니다.
단지 로그들만 충실히 남겨준다면 전부 해결이 가능하다는 얘기를 하더라구요.

그말 듣고 생각해보니 그 적은 확률에 트랜잭션을 매번하는것이 비효율적이라는 생각이 듭니다.

위 글 처럼 바이너리를 때려 박는 구조를 쓸빠엔 MongoDB를 쓰는게 훨씬 좋을 것 같습니다.
MongoDB가 그런식이니깐요.

    1
2015-12-11
16:35:51
  
MNLT


저번에 기회가 있어 한번 대화를 나눴던 내용이네요. 

한가지 정보를 말씀드리면, 제가 있는 회사(중국)의 경우 자체 R&D및 서비스 하고 있는 DB솔루션의 스키마와 서버 프레임워크의 프로토콜이 동일한 포멧 및 기능을 사용합니다. 실제 DB에 때려박는 데이터도 시리얼라이징 된 데이터이고요. (프로토콜 설계하듯 DB스키마 짜서 문서 집어넣으면 테이블이 생성됩니다 / internally automatical sharding & scale-out)

그리고 하나 더... 랭크서버와 같은 폭팔적인 고성능 작업이 필요하지 않는 이상.. 여긴 모든 서버가 멀티쓰레드 사용 안합니다. @_@

2015-12-11
16:54:23

  
노코드


저도 트랜잭션안씁니다.

책에 나와있으니 쓰고야 말겠다는 사람이 아직도 많아서... 매번 설명/설득 하기 힘들어요.

그런데 간혹 필요해지는 경우가 있는데 [안쓰면 기능상 하자가 생길수 있는 경우] 필요할땐 씁니다.


2015-12-11
16:56:36

  
노코드


바이너리로 때려박겠다는 개발자는 한국에서도 몇명 보았는데...

게임 다만들고 오픈 준비하면서 운영이슈들이 들이닥치게 되면 초난감해집니다.

제발 잘 설계된 정식 테이블에 넣어주시길 ㅠㅠ 그냥 테이블에 몇억 넣어두 돼요.

샤딩하면 되자나요 ㅠㅠ


2015-12-11
17:00:50

  
Stiner


좋은 내용이네요. ㅎ
2015-12-11
17:01:52

  
smileeagle


-ㅅ-; 운영이나 데이터분석은 안하나요?
2015-12-11
17:08:27

 * 탈퇴       
imays

ㄴ 하겠죠. 아마 데이터분석을 위한 것을 별도로 저장한다던지, 즉 DW화 하지 않을까요?
2015-12-11
17:09:12

 * 탈퇴       
뿌요뿌요

바이너리를 때려박으라고 존재하는  DB는 아니지 않나요?

그거에 맞는 DB는 따로 있을텐데.....;;;

 1   
2015-12-11
17:15:09
  
smileeagle


ㄴ 몇전전 이야기라서 그분은 OLTP 고려없이 디스크 섹터 이야기를 한듯한데. 
내용상 RDB를 운용하면서 트랜잭션처리를 하지 않는 다는 것으로 보여서요.
위 처럼 구성한다면 카우치베이스가 RDB보다는 더 좋은 솔루션일것 같아요.
(트랜잭션 로그를 통한 텀단위의 장애복구는 어렵겠지만.)
실상 게임서비스에서의 부하는 유저(캐릭터?)데이터로 인한 부하보다는 아이템으로 인한 부하가 더 많은데
아이템은 어찌 처리할지도 궁금하네요 =_= 
2015-12-11
17:16:22

  
smileeagle


그리고 -ㅅ- 트랜잭션을 쓰지 않는다는 것은 ACID를 포기한다는 소리인데..
NO-SQL 만으로 게임 서비스를 하기 애매한 부분들이 가지는 단점을 그대로 가지지 않을지 -ㅅ-;
2015-12-11
17:21:01

  
태풍의그라운드


저희는 운영툴 작업을 외부업체와 같이 진행하는데
유저정보가 한 컬럼에 다 들어가 있다고 생각하면 작업하기 굉장히 번거로울듯 하네요.
성능은 좋아도 협업면에서는 힘들겠군요.^^

2015-12-11
17:21:20

  
뎐삼


동접은 실전이야 **아
라고 제머리속에 요약 되는 이기분은 뭐죠

뭐라 섯불리 말을 못꺼내겠습니다
2015-12-11
17:42:17

  
구라쟁이


요즘 느끼는게 ... DB는 데이타 저장만 하는 곳 같아요. 게임 서버단에서 처리 다 하고 원인 + 결과만 DB에 저장 끝.
운영쪽은 "원인이 이랬는데 결과는 이랬다"만 알려주고 끝.

그리고 ... 계속 게임 쪽은 DB 모델링을 모르는게 사랑 받겠구나 ... 라는 생각이 듭니다 ㅜㅜ
2015-12-11
17:59:11

  
힙돌이동남아


제가 잘 몰라서 그러는데, 살짝 언급된 DB에서 데이터 검색...일경우는요? 트랜잭션이야 그렇다 치더라도..
2015-12-11
18:56:40

  
빵이TM


특정상황에서 성능을 위해서는 괜찮은 방법.
그러나 협업이나 관리차원에서는 좋은지 모르겠습니다.

상황에따라 다르므로 무조건적으로 적용하면 안되겠습니다;;
2015-12-11
19:05:25

  
빵이TM


검색자체는 elastic search같은곳에 별도로 데이터를 퍼올려서 하지 않을까 싶은데요..
2015-12-11
19:06:16

  
MNLT


국내 서비스만 한다면 쉽게 이해하기 힘든 처리 방식이라고 생각할 법도 합니다....
상대적으로 인력도 많이 부족하고, 대한민국 유저 풀로는 사실 다르게 접근해야할 케이스라서요.. (글로벌 서비스하는 분들은 아시겠지만...)

중국의 경우 제가 들었던 어느 스튜디오는 모바일 게임서버 하나 개발하는데 15명씩 붙어서 했다고 합니다.
그리고 여기 R&D 센터의 경우 수십명의 DB/서버프레임워크 개발진이 있어서 우려하는 공용 운영툴 등의 문제도 인력으로(?) 커버해버리네요. (심지어 테스트팀도 잘 꾸려져있습니다.... 버전 패키징 및 유닛테스트 전용팀...)

어지간한 툴은 다 만들어져있고, 개발사나 스튜디오에 제공하다가 모지란것들 있으면 한달내로 뚝딱 만들어줍니다(....)
고로 이건... 뭐랄까 시장에 따른 각기 다른 양상 아닐까요...

근데 RDB에서 샤딩하게 되면 트랜젝션에 대한 고민은 똑같지 않나요? (제가 DBA는 아니라서...)
서버단 트랜젝션이니 뭐니 이런건 성능상의 문제 이슈가 상당하고요... 어짜피 이런 문제들로 고민할꺼라면 전자나 후자나 큰 차이가 없을 것 같기도 하네요...

2015-12-11
19:07:01

  
smileeagle


사실 뭐 장단점을 논하자면.. 끝이 없겠지만.

말씀하신 캐릭터 정보를 저장하는 DB스키마가 제가 이해한 아래 내용이고

| 캐릭터 UID | 직열화 된 캐릭터 정보 바이너리 데이터(레벨, 클래스, 위치정보, 스탯정보, 경험치정보 등등등) |

검색 이슈 및 운영상 캐릭터 정보에 대한 배치 업데이트 이슈가 거의 없다면,
차라리 백업을 위한 스토리지 서버 따로 놓고 디스크를 미러로 구성하고 파일로 저장하는데 낫다는 생각이 들어요. 

괜히 DB에 넣어 구문분석 및 실행계획 절차를 거칠 이유가 없을것 같네요.
2015-12-11
19:25:21

  
Sky_High


모조리 한 컬럼에 때려박는게 아니라 최소한의 entity 구분은 하겠죠?

사실 지표만 별도의 플랫폼에 잘 쌓아준다면 직접 DB에서 데이터 뒤적거리며 추출할 일이
지금까지는 별로 없어서 일견 이해는 갑니다만, 저렇게 바이너리 쌩으로 직렬화해서 때려박았을때
포멧에 오류가 있거나 업데이트로 인해서 변경이 일어났을때는 배치처리를 어떻게 해야할까요?
DB 설계하는 부분은 단순해 지는 느낌인데 운영을 어떤식으로 해나갈지는 저는 감도 안오네요 ㅠㅠ...
2015-12-11
19:53:46

  
ST파파


이게 효과적일 수도 있었던거군요 ㄷㄷㄷ

첫 MMORPG가 이렇게 개발되었었는데, 아이템 복사, 캐릭터 정보 통채로 복사 등등 수 많은 문제점을 일으켜서
다시는 저렇게 개발하지 않을꺼야 했는데 ㄷㄷㄷ
2015-12-11
19:54:19

  
구라쟁이


운영툴이 예술일것 같은데요.
사용자 정보 / 아이템 지급&회수를 한다면 툴서버에서 DB에 저장된 바이너리 읽어서 파싱 -> 업데이트 -> 다시 직렬화 저장 ... ㅋㅋㅋ

구조 변경되면 점검 걸겠지만... 배치 서버에서 똑같은짓을... ㅋㅋㅋ .... 도전 욕구가 -_-;;
2015-12-11
20:08:25

  
노코드


제발...          

           클릭시 이미지 새창.

클릭시 이미지 새창.


 1   
2015-12-11
20:12:53
  
plenty


상황에 따라 그게 나을 수도 있겠죠. http://eincs.com/2012/06/nosql-is-not-useful/ 오래전 글이지만 이런 걸 보면 페북도 MySQL 을 key-value 의 NoSQL처럼 사용하고 있다고 나오니까요.
2015-12-11
21:09:27

  
노코드


ㄴ NoSQL 처럼 썼다기 보다는, 샤딩을 해서 디비서 조인 못하고 서버에 퍼와서 조인 한다는 내용 같아요.

바이너리로 때려박았다고 해석되기엔 근거가 부족합니다 ㅋ


2015-12-11
21:18:42

  
plenty


바이너리까지의 이야기는 아니고, 일반적이지 않은 방법으로도 쓴다는 의미라서요. ^^
2015-12-11
21:33:14

  
Alucard


요즘 누가 디스크를 쓴다고...
 1   
2015-12-12
00:27:30
  
Alucard


1. 저장만 할거라면 저게 젤 빠릅니다.
2. 요즘 HDD 안 쓰죠...
3. 저래 만들어놨으면 만든 놈이 몽땅 책임 지는겁니다.
4. 그냥 캐시 서버를 만들어도 될거같은데... 굳이 저래야할까... 득보다 실이 많을 것 같은데..
5. 운영이슈 터지면 전체 롤백 뿐... (백업은 하니...?)
6. 저라면 @@@에 @@@@에다 @@ 구성 하겠습니다...
2015-12-12
00:39:43

  
Alucard


5...는 상황에 따라 점검 잡고 바이너리 다 땡겨서 수정 볼 수는 있긴 하것네요... (그렇게 해봤으니..)
그래도 그게 아름다울 것 같진 않...

과거 SQL 2000 쓰던 시절... 느려터진 37, 74GB SCSI로 서비스할 시절에는 바이너리 쓸 수 밖에 없었슴다.
(제 첫 게임이 바이너리로 때려넣었어요. 디스크도 정말 느리고 메모리도 많이 꼽을 수 없었거든요.)

데이터 패치가 잘못 되거나, 이런 저런 운영이슈 터지면... 음 뭐 상상에 맡기겠...
1억의 회원 중 동접이 얼마나 되느냐에 따라 얘기가 다르겠지만...
스토리지랑 RDB 개발하는 사람들이 바보는 아니잖아요. - _-;;;

2015-12-12
00:50:32

  
Alucard


ps. 만든 놈이 세계에서 몇 안 되는 초 천재급에 그가 만든 코드는 0과 같이 절대적인 완벽함을 보장하고, 데이터 패치 등도 절대 실수가 나올 수 없는 프로세스를 가진 조직이라면 좋은 방법이라 생각합니다.
(물론 업무 관련 툴도 전부 만든 놈이 제공해야 함.)
2015-12-12
00:52:22

  
aousee


양날의 검이네요 만약 서버 개발자가 학력이 낮다거나 한다면 무식하다며 독박쓸수도
2015-12-12
06:48:17

 * 탈퇴       
뿌요뿌요

중국넘들중에 그런 넘들이 있는가보다 하면 될거 같습니다

Imays님이 가끔 올리는 중국이야기는 톡특해서 올렷을뿐이라고 생각됩니다.



다만 제가 사장인데   RDB로 저런짓거리하고있었다면   바로 짤랐을거 같네요.


 1   
2015-12-12
08:31:17
 * 탈퇴       
뿌요뿌요

속도좀 올려보겠다고  코드를 어셈블리로 다 바꾸는거와 뭐가 다른지 모르겠어요

 2   
2015-12-12
08:35:55
  
노코드


드립치기전에 찾아봤는데 진짜 있어서 놀라운

http://w.hankyung.com/news/app/newsview.php?aid=2008091045371&sid=01184004&nid=254&ltype=1&q=

고속에서 사이드미러를 접으면 차가 받는 공기저항을 줄여 연비를 높일 수 있다...

내리막길에 기어 중립(N) 두기...

와이퍼나 전조등 같은 전기장치를 끄면 제너레이터 가동을 줄여 연료의 2~3% 정도를 줄일 수 있다...

아침엔 기온이 낮아 휘발유 등 연료의 밀도가 높아져 연비가 높아진다는 얘기가 있지만 ...

기름을 적게 채우면 차량 무게가 가벼워져 그만큼 연비가 좋아진다...


2015-12-12
09:48:00

  
제오


근데 'RDBMS를 쓰면서 트랜잭션을 안 건다'는 건 무슨 뜻이죠?
해당 DB의 설정을 바꿔서 트랜잭션 로그 기능을 꺼 놓는다는 얘긴가요?
2015-12-12
10:05:07

  
제오


디스크 헤드 걱정하는 건 좀...
어차피 메모리 버퍼에서 한참 놀다가 디스크에 들어가기 때문에 어플리케이션에서 write하는 순서와 디스크에 실제 write하는 순서와는 관계가 없을 텐데요.
현재 로그인 중인 모든 사용자의 데이터를 한꺼번에 저장하는 거라면 몰라도.

2015-12-12
10:08:08

  
술취한아저씨


중국에서 초대박 게임이 나오면 동접1억일텐데 그런 게임의 서버는

어디 사막에 빌딩이 있고 그 빌딩은 모든층이 서버로 가득찬 상상을 하네요.

2015-12-12
10:40:12

  
뎐삼


@노코드 
클릭시 이미지 새창.
2015-12-12
12:28:06

  
가소니


저도 사용자의 특정 정보(아이템, 파티) json 으로 저장해본적이 있어요. 완전히 통으로 넣을 용기는 없었고요 ㅋㅋ
2015-12-12
15:55:00

  
MNLT


전반적으로 부정적인 시각이 많네요. 이래서 프레임이 무서운가봅니다.
현실적으로 보면 많은 분들의 경험이나 말씀들이 90%에 가까울만큼 맞는 말이지만... (저도 한 2년전까지만해도 그랬고요)

컬럼수의 한계로 인한 문자열 파싱 처리 라던가, 컬럼구조의 수정 이슈라던가 등등의...
RDB의 고유기능만을 사용해서 처리하기 어려워 우회하는 기능들도 상당히 많이 존재할텐데요...
이를 위해 서버단에서 처리를 한다거나 성능의 일정 부분을 포기한다거나 하는 사례들이 많이 있을텐데, 서버단에서 처리하는거면 key-value냐 아니냐의 문제의 논점과는 벗어날꺼같고요.

이때 발생될 수 있는 파싱 비용, 버려지는 더미 컬럼, 데이터 버전처리 문제 등...
충분한 시간과 인력이 있다는 가정하에 개발 코스트는 별 차이 없을것 같긴 합니다.
운영툴의 경우에도 뭐... 쿼리 짜는거나 가져와서 시렬라이징 처리 하는거나... 
백엔드 라이브러리만 잘 처리 되있다면 큰 차이 없을 것 같고요.
(다만 적응의 문제가 있을 수 있겠네요. SQL에 적응되어 있는 상태...)

그냥 결론은 제 생각에 이 부분에 대한 정답은 없다고 보는데, 분위기가 저렇게 쓰면 짤린다, 책임져야한다 등의 무거운 내용들이 있어서, 기술적인 시각이 편향되지 않았으면 하는 바램에서 써봅니다. (충분히 생각해보고 연구해볼만한 가치 아닌가요?) 기술이란 상황에 따라 이렇게도 저렇게도 쓰일 수 있는거라 봅니다.

참고로 전민돌격(한국의 '백발백중')도 바이너리로 때려박습니다.
 3   
2015-12-12
17:27:05
 * 탈퇴       
촘두

DB 문외한인데요.
검색 좀 해보니 바이너리 데이터 타입도 존재하고 http://ra2kstar.tistory.com/82 => BLOB )
저런 걸 필요로 하는 사람도 실제로 꽤 존재하긴 하네요.

암튼 DB를 단지 데이터 저장용으로 쓴다는 건... 재밌네요. ㅋ

2015-12-13
12:44:20

  
뎐삼


전 GAE쓸때 파일시스템 없이 그냥 BLOB으로 때려박는거 정말 적응못하겠던데 ㅋ
2015-12-13
12:47:20

  
뎐삼


http://stackoverflow.com/questions/2693081/does-google-app-engine-allow-creation-of-files-and-folders-on-the-server
 1   
2015-12-13
12:48:49
  
뎐삼


실제로 존재하는걸 떠나서 구글앱엔진에서는 강제합니다 ㅋㅋ
이거 처음에 받아들이기 정말 힘들었어요
2015-12-13
13:01:42

 * 탈퇴       
imays

역시나, 호불호가 갈리는 의견들이 나오네요. 당연하죠. 저도 쉽게 동의하기 어려운 방법, 아니 꼼수니까요.

참고로, 5년전에 저 대화를 나누었던 사람은, 중국에서 꽤 큰 게임회사의 서버팀장을 맡고 있었습니다. 제가 기억이 확실하다면, 미국 MIT 공과대학 출신입니다. 디비 설계에 대한 지식이 딸려서 저렇게밖에 못한거라고 보기는 어렵습니다. 
 3   
2015-12-13
15:54:55
  
coolspeed


저는 전혀 놀라지 않았는데요. 저도 게임 규묘만
좀 있었으면 이 아키텍쳐 사용했을겁니다. 게임쪽이라 그렇지 대형 웹사이트들에서는 흔할뿐만 아니라 거의 표준동작입니다. 레딧을 예로 달랑 postgresql테이블 두장입니다. 실제로 많은 대형웹사이트들의 메인 디비는 키밸류엔진으로만 사용되는 mysql입니다. 데이터 분석? 하둡마저 가끔만 이용하고 postgresql쓴다더라구요. 일예로,주어들은 텐센트얘기입니다.
 3   
2015-12-13
16:02:19
  
Alucard


적재적소. 딱 그것 뿐.
동접이 몇이 되었든, 회원이 얼마나 되든 주어진 돈과 시간에 적합한 솔루션을 쓰면 됩니다.
2015-12-13
16:30:31

  
Alucard


@배대표님. 스탠포드 칼텍 엠아티 출신들 중에도 바보들 많으니 너무 신뢰하심 이니됨미다... ㅜㅠ
    2
2015-12-13
16:33:05
  
coolspeed


방금은 게임이 아닌쪽 얘기를 했으니까 이젠 다시 게임으로 돌아와볼까요?

넷이즈의 몽환서유는 중국의 MMORPG 인데 누적 유저수가 2.5억이라고 합니다. 이 게임의 데이터 저장 솔루션은 무엇인지 아십니까? 파일입니다. 유저 하나당 파일 하나입니다. 물론 더 많은 기술적 디테일을 보태야 완정한 형태설명이나 완정한 스토리가 되겠지만, 어쨌든 핵심은 이것입니다.

더 기상천외한 솔루션을 얘기해볼까요?
중국의 COC 비슷한 게임인데 역시 넷이즈 당시의 CTO, 몽환서유 메인개발자가 나와서 만든 게임입니다. 이 게임의 데이터 저장 솔루션은 샤딩된 redis입니다. 각 redis인스턴스가 데이터 랜딩(landing, 착륙) 로직을 책임집니다. 데이터 랜딩은 redis자체의 save나 bgsave를 사용하지 않고 해당 노드(기기)에 있는 서비스(프로세스)가 책임집니다. 스토리지 엔진은 unqlite입니다(C언어 버전의 LevelDB라고 보시면 됩니다).

이 개발자의 이름은 Cloud Wu이고 중국에가 제일 유명한 게임 개발자입니다. 중국쪽이랑 혹은 중국 개발자랑 많이 접촉해보신 게임개발자분들은 아마 다 이분을 아실겁니다.

p.s. 이상 내용은 다 인터넷에 공개된 자료에 근거한겁니다. 링크들은 첨부하지 않겠습니다. 정말 증명하거나 부증하고싶으신 분들은 분명 다 출처를 스스로 찾을 수 있으실겁니다.
2015-12-13
17:28:33

 * 탈퇴       
imays

ㄴ 헐, 실제로 단순 파일에 서비스를 하는 업체가 있었군요. 
어차피 검색 못할거면, 그냥 유저별로 파일에 저장하는게 훨씬 속도가 빠를거라고 짐작하고 있었는데요[1], 진짜로 그렇게 하기도 하는군요!

Cloud Wu의 영향 때문인지 제가 중국에서 만난 서버개발자들은 Lua를 많이 쓰더라구요. C++은 크래시 때문에 위험해서 안쓴다고 합니다.

---------

[1] 성능 테스트 결과 DB 테이블에 저장하는 것보다 파일 기록 속도가 약 10~100배 정도 빠릅니다.
2015-12-13
18:01:17

  
노코드


클릭시 이미지 새창.


이런 느낌입니다.... 정원보다 10배 태우고도 굴러가긴 하겠죠....


2015-12-13
19:19:09

  
뎐삼


ㄴ 가끔 사람하나 떨어져도 운영이슈로 커버하구요? ㄷㄷ
 1   
2015-12-13
22:51:42
  
noname


ㄴㄴ관리자도 저정도 기세로 붙어 있을테니 문제X일려나요 ㄷㄷ
2015-12-13
23:06:09

  
큐피리도


저도 비슷한 생각으로 BLOB로만 사용할거면 파일로 사용하는 게 편하지 않나 생각되네요.


예전에 머드게임들도 이런식의 파일 방식으로 많이 운영됐었는데

메모리 형태로 한 번에 밀어넣다보니 데이터 구조체를 중간에 변경하기가 힘들어

예약된 char 버퍼를 하나 크게 만든 후 padding bytes 계산해서 필요할 때마다 잘라 사용하니

데이터 필드 변경 이슈로부터도 크게 문제가 없었습니다.


하지만 I/O 속도가 서버에 바로 영향을 미쳐버리는 단점이 있기 때문에

요즘 같이 접속자가 많은 시대에는 별도의 캐시 서버를 만들어야 할 수도 있겠네요.


물론 필드 검색(이것은 BLOB인 이상 DB 형태로도 힘들죠)과 백업은 별도 툴을 만들어 사용해야 겠지만

키 검색은 폴더를 잘 나누는 방식으로 해결하면 되고 (파일 시스템에 따라 최대 개수를 고려하여)

위험 요소는 RAID 깨지는 것을 고려한다면 데이터베이스가 통째로 깨지는 것 보다

일부 파일들이 소실되는 게 오히려 더 빠른 복구가 가능하다는 장점이 있지 않을까 생각됩니다.


물론 위 모든 전제는 BLOB 형태로 통째로 밀어 넣는다는 전제입니다. :)

 1   
2015-12-14
01:32:46
  
coolspeed


참고로 중국은 대중교통이 엉망인데, 기차하나는 알아줘야하거든요 ㅎㅎㅎ
https://namu.wiki/w/%EC%A4%91%EA%B5%AD%EC%B2%A0%EB%A1%9C%EA%B3%A0%EC%86%8D

2015-12-14
02:51:32

  
김시


이런 글이 너무 좋습니다.
잘 배우고 갑니다!
2015-12-14
03:44:52

  
makga


바이너리는..수정이 극악..입니다 ㅠㅠㅠ..
관련 툴이나 부가 작업이 가능하게 서포팅이 되어야함...
2015-12-14
08:55:31

  
zepinos


이럴바엔 그냥 IMDG 를 쓰고 백업으로 RDBMS 등을 연동하는게 낫겠네요.

그리고 위에서 잠깐 언급된 BLOB 같은 바이너리 DB 저장 타입은 매우 느립니다. 그래서 실제로는 File System 에 저장하고 경로만 varchar 로 저장하는 형태로 쓰지, BLOB 에 바이너리를 넣어두고 쓰는 경우는 없다고 봐도 무방합니다.
2015-12-14
10:31:56

  
zepinos


아...IMDB 이야기 나와서...좀 더 하자면, IMDG 는 말 그대로 메모리에 저장하는 형태이기 때문에 속도가 당연히 빠르고 Data Grid 라는 말 답게 Cluster, Sharding 을 지원하는 놈들이 대부분이며, DBMS 나 NoSQL 와는 달리 Game Server Logic 이 있는 곳에 통합되어 있기 때문에 서버의 대수가 늘어나는 문제도 줄어드는 장점이 있죠. 이 말은 DB 가 있는 서버와 네트워크 통신을 해야하는 문제가 줄어든다(물론 IMDG 들끼리의 통신은 여전하지만)는 장점이 있습니다.

돈만 있으면 코히어런스(Oracle Coherence) 같은 놈의 도입을 추천해봅니다.
2015-12-14
10:36:14

  
coolspeed


그럴바에는 redis에 던지고 말죠. 실제로 요즘 이렇게들 한다고 합니다. 위에서도 소개해드렸듯이.
 1  3
2015-12-14
11:32:34
  
smileeagle


ㄴ 공감합니다. 위 제약사항을 허용하면 그게 베스트겠네요.
2015-12-14
11:45:28

  
MNLT


** 작성자(또는 관리자)에 의해 삭제된 댓글입니다 **
2015-12-15
03:29:29

  
sophnim


제가 만들고 있는 게임이 메인 저장소로 redis를 씁니다. 복수개의 redis 인스턴스들을 Twemproxy로 샤딩하고 있습니다. 모바일의 경우 한번 게임 해보고 안돌아오는 유져가 상당한데 이런 유져의 데이터는 Redis로부터 백업용도의 MariaDB로 이전시키는 구조입니다(물론 이 유져가 오랜만에 돌아오는 순간 다시 Redis로 이동시킵니다).

주 저장소를 Redis를 쓰는 바람에 일체의 관계형 연산이 불가능하므로 통계자료의 추출이 힘든건 사실입니다만 이런 유져 데이터의 분석은 스플렁크나 기타 텍스트 로그 파일기반 빅데이터 분석 솔루션을 사용하는 방향으로 개발하고 있습니다.

 1  1
2015-12-20
12:38:01
  
zepinos


Redis 는 용량 압박이...

그래서 Redis + MongoDB 조합도 많이 쓰시죠.

차라리...병이 도져서 Couchbase 같은걸 고민하게 되고...그런거죠.
 1  1
2015-12-21
10:02:01
  
LOC


** 작성자(또는 관리자)에 의해 삭제된 댓글입니다 **
2015-12-22
13:50:17

  
뎐삼


조회수순 주행중
    1
2019-09-06
19:06:14


목록보기  |  
SORT :: |  번호순  |  최근댓글  | HIT
notice
■■ 개발만담 게시판 안내 ■■  [7]
   게임코디 11/07/04 4660
4943
게임 주제의 KBS 다큐 두 편  [1]   
  술취한아저씨
20/03/15 3204
4942
visual studio 2017 이거 옵션 뭘 바꿔야 할까요?  [7]   
  아쥬
20/03/08 2870
4941
리포지드... 보고 있나? 이것이 [ 리메이크 ] 다!  [2]   
  노코드
20/03/08 3573
4940
VSCode C# Update 주의  [3]   
  시니컬춥스
20/03/06 3400
4939
NDC 20 행사 잠정연기 ㅜㅜ  [2]   
  게임코디
20/03/05 2596
4938
블소 프론티어  [7]   
  뎐삼
20/03/05 2522
4937
std말고 간단한(?) 컨테이너들 모은 라이브러리 (오픈소스) 혹시 없을까요...  [9]   
  아쥬
20/03/02 3041
4936
게임 개발자 학습 로드맵 (GitHub 펌)  [1]   
  장찌루
20/02/28 3780
4935
두 유 노우 재택근무 프로그래머 ?  [5]   
  노코드
20/02/25 2564
4934
재택근무 시행 게임사  [16]   
  뎐삼
20/02/25 2715
4933
프로그래머 실무 면접에 관한 동영상 링크 투척해요~~  [6]   
  ProgC
20/02/25 2894
4932
중견회사들은 신작게임 안 만드나요?  [8]   
  imays
20/02/24 3403
4931
근본없는 블렌더 -5편- retopo     
  뎐삼
20/02/24 1002
4930
근본없는 블렌더 -4편- 채색     
  뎐삼
20/02/24 2228
4929
근본없는 블렌더 -3편- 버텍스 직접 편집  [1]   
  뎐삼
20/02/22 1751
4928
근본없는 블렌더 -2편- 스컬프팅     
  뎐삼
20/02/22 1398
4927
근본없는 블렌더 -1편- 설치 및 기본조작  [2]   
  뎐삼
20/02/21 1957
4926
비쥬얼스튜디오에 build clean 할 때...     
  아쥬
20/02/21 594
4925
안드로이드에서 네이티브 코드로 IPC사용시 대량의 데이터 처리  [6]   
  아쥬
20/02/20 1100
4924
2020 NDC 발표자를 모집합니다  [4]   
  게임코디
20/02/18 1749
4923
언리얼 빌드후, 안드로이드에서 크래시 확인하는 좋은 방법이 있을까요?  [4]   
  아쥬
20/02/13 1403
4922
쌩초보주의)) 유니티 모바일과 컴퓨터 개발이 차이가 있나요?  [2]   
  김김김민
20/02/13 1607
4921
개발 소스의 해킹보안에 대해 질문드립니다.  [10]   
  군림주먹
20/02/12 2962
4920
APK 앱서명의 보안성에 대해 궁금합니다.  [1]   
  kachuuu
20/02/11 822
4919
게임서버프로그래밍 교과서에 첨부된 코드에 대한 주의사항  [4]   
  imays
20/02/11 1588
4918
C++표준을 따르면서 buffer에 쓰고 읽는법. 제대로 알고 계신가요?  [7]   
  retro
20/02/10 2544
4917
Creator's star  [3]   
  데미데루스
20/02/09 939
4916
리눅스 epoll 에서 epolloneshot, epollexclusive 플래그...  [10]   
  retro
20/02/09 1990
4915
언리얼에서 안드로이드 빌드할 때, 플러그인 낑가 넣으면...  [1]   
  아쥬
20/02/09 861
4914
프라우드넷  [8]   
  발코더6
20/02/07 1716
4913
이세계 카페에서 바리스타가 되는 게임! Coffee Talk     
  술취한아저씨
20/02/02 1408
4912
개발자 번아웃 대처방법의 모든 것  [4]   
  노코드
20/01/29 2876
4911
앱스토어 검색어에 검색이 안됩니다.  [1]   
  닥터이블
20/01/26 846
4910
Vulkan과 메탈  [4]   
  그래픽스어린이
20/01/23 3262


목록보기  |   다음페이지  |   1 [2][3][4][5][6][7][8][9][10]..[142] [다음 10개]



게임코디 GAMECODI , 게임 프로그래머 만담 커뮤니티

게임코디 소개     |      크라우드펀딩 후원자     |      관리실 연락처     |