Project

General

Profile

Actions

데이터베이스

데이터베이스 설계

게임 데이터

Message , Tip , UI , Vendor , Weapon 등의 테이블은 Client 만 참조하는 정보이며 Effect , Item , Upgrade , Manufacture , Stage , Reward , Npc , Quest , Channel 등의 테이블은 Client , Server 모두 참조합니다.

아이템 상점 시스템을 개발할 경우 Vendor 는 진열 정보에 대한 테이블을 의미합니다. 이 정보는 Client 표시용으로만 참조가 되며 Server 기능 구현에는 조금도 필요없습니다. Server 는 가격 확인 정보들만 참조하면 되며 이를위해 Item 테이블 정보만 필요합니다.

제법 많은 시스템에 대한 관계형 테이블 구조입니다. 내용이 많이 길어질것 같아 여기서 이만 줄일께요.

서버 데이터

Activator , Configuration , UserCount 등의 테이블은 Server 에서만 관리하는 정보입니다.

플레이어의 계정 인증세션 등을 전체 서버에서 참조하기 위해 Activator 테이블을 사용합니다.

만약 Session Server 제작을 계획중이라면 해당 테이블을 사용하지 않아도 괜찮습니다.

웹 스크립트 운영도구를 개발할 경우 Configuration 테이블을 활용하여 최대 동시접속 제한수 등을 손쉽게 설정할수 있게됩니다. 서버는 Restart 되거나 Reload 될때 설정값을 참조하여 적용합니다.

다음으로 UserCount 테이블은 각 서버 및 채널의 동시접속 수를 갱신합니다. 만약 운영도구에서 실시간 동시접속수를 보여줘야 한다면 로그 수집시간을 기다리는 것이 어렵습니다. 이런경우 활용이 가능합니다.

인증 데이터

Account , Db 등의 테이블은 Server 에서만 관리하는 정보입니다.

사용자 계정에 대한 정보 보관을 위해 Account 테이블을 사용합니다. Id , Password , Coin , Cash , Db 필드 정도로 구성될수 있으며 Db 필드는 Db 테이블의 인덱스 번호를 나타냅니다.

서버에서 연결할 데이터베이스 연결 정보는 Db 테이블에 입력합니다.

서버 Startup 을 하게되면 Db 연결 정보들을 모두 읽어와 데이터베이스 접속을 시도합니다. 한번 연결된 컨넥션들은 서버 Shutdown 상황까지 지속되며 상당량의 데이터베이스 부하를 줄여줍니다. 웹서버 처럼 Session 단위 Db 접속을 하지 않습니다.

이제 사용자 계정을 등록할때 마다 Db 인덱스 번호를 부여하세요. Round Robin Scheduling 또는 Min Count 검사 등으로 Player Data 1 , Player Data 2 로의 분산 구현이 가능합니다.

대규모 접속이 발생 하더라도 분산 설계만 잘하면 안전합니다. 명심하세요. 데이터베이스 분산이 가장 중요합니다.

플레이어 데이터

Character , Inventory , Warehouse , Quest , Stage , Friend , Post 등의 테이블은 Server 에서만 관리하는 정보입니다.

데이터베이스 부하를 줄이기 위해 클아이언트 로그인시 모든 데이터를 로딩합니다. 이후 메모리 데이터로만 관리를 하며 로그아웃시 데이터베이스로 저장합니다.

우편물 발송, 캐시 아이템 구입같이 발생 빈도가 적은 기능들은 즉시 데이터베이스에 저장하세요. 특히 캐시 아이템 구입같은 경우 즉시 저장하는 것이 안전합니다.

Updated by Master Chief 12 days ago · 3 revisions