Project

General

Profile

Actions

Database » History » Revision 3

« Previous | Revision 3/4 (diff) | Next »
Master Chief, 2020-02-11 08:19


<h1>데이터베이스</h1>

<h2>데이터베이스 설계</h2>

<p><img alt="" src="/attachments/download/128/Game_Database_Diagram.png" /></p>

<h2>게임 데이터</h2>

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

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

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

<h2>서버 데이터</h2>

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

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

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

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

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

<h2>인증 데이터</h2>

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

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

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

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

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

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

<h2>플레이어 데이터</h2>

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

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

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

Updated by Master Chief 5 months ago · 3 revisions