게임 통계 서버에서 관계형 데이터베이스(RDBMS)를 사용하는 대신, 도큐먼트 기반 데이터베이스(예: MongoDB)를 사용하는 경우, 유연한 데이터 저장이 가능하며 스키마를 고정하지 않고도 다양한 구조의 데이터를 저장할 수 있다는 장점이 있습니다. 특히 유저 데이터와 게임 이벤트 데이터가 서로 다른 구조를 가질 때 적합합니다.
다음은 도큐먼트 기반 데이터베이스에서 게임 통계 서버의 도큐먼트 구조 테이블 설계 예시 및 설명입니다.
도큐먼트 기반 데이터베이스 설계 개요
플레이어 컬렉션 (Players Collection)
- 각 플레이어에 대한 기본 정보와 게임 통계 데이터를 저장합니다.
- 플레이어의 레벨, 경험치, 보유 아이템, 매치 결과 등을 하나의 도큐먼트에 포함할 수 있습니다.
매치 컬렉션 (Matches Collection)
- 각 게임 매치의 기록을 저장하며, 매치에 참여한 플레이어들의 상세 정보와 결과를 함께 기록할 수 있습니다.
아이템 컬렉션 (Items Collection)
- 유저가 보유하고 있는 아이템 또는 구매한 아이템을 저장합니다.
이벤트 컬렉션 (Events Collection)
- 유저가 발생시킨 다양한 이벤트를 저장하는 구조로, 게임 진행 중 발생하는 이벤트들을 도큐먼트로 기록합니다.
도큐먼트 기반 데이터베이스 설계 예시
1. 플레이어 컬렉션 (Players)
{
"_id": ObjectId("605c72b1e5a1f52c2c9d9b1a"),
"username": "player1",
"level": 15,
"experience": 2500,
"total_games": 100,
"total_wins": 55,
"inventory": [
{ "item_id": "sword123", "item_name": "Legendary Sword", "item_type": "weapon", "acquired_at": "2024-10-10T12:45:00Z" },
{ "item_id": "shield789", "item_name": "Iron Shield", "item_type": "armor", "acquired_at": "2024-10-11T14:20:00Z" }
],
"recent_matches": [
{ "match_id": "match456", "result": "win", "score": 1500, "match_time": "2024-10-22T14:00:00Z" },
{ "match_id": "match789", "result": "lose", "score": 1200, "match_time": "2024-10-21T13:30:00Z" }
]
}
- _id: MongoDB에서 자동 생성되는 플레이어 고유 ID
- username: 플레이어의 이름
- level: 플레이어의 레벨
- experience: 플레이어의 경험치
- total_games: 총 게임 참가 수
- total_wins: 승리한 게임 수
- inventory: 플레이어가 소유한 아이템 목록 (아이템 ID, 이름, 유형, 획득 시간 포함)
- recent_matches: 플레이어가 최근에 참가한 매치 기록 (매치 ID, 결과, 점수, 매치 시간 포함)
2. 매치 컬렉션 (Matches)
{
"_id": "match123",
"match_start": "2024-10-22T14:00:00Z",
"match_end": "2024-10-22T14:30:00Z",
"players": [
{
"player_id": ObjectId("605c72b1e5a1f52c2c9d9b1a"),
"username": "player1",
"result": "win",
"score": 1500
},
{
"player_id": ObjectId("605c72b1e5a1f52c2c9d9b2b"),
"username": "player2",
"result": "lose",
"score": 1200
}
],
"game_mode": "team_deathmatch",
"duration": 1800
}
- _id: 매치의 고유 식별자
- match_start: 매치 시작 시간
- match_end: 매치 종료 시간
- players: 매치에 참여한 플레이어들의 정보 (플레이어 ID, 이름, 결과, 점수 포함)
- game_mode: 게임 모드 (예: 'team_deathmatch', 'battle_royale' 등)
- duration: 매치 진행 시간(초 단위)
3. 아이템 컬렉션 (Items)
{
"_id": "sword123",
"item_name": "Legendary Sword",
"description": "A sword with legendary power",
"player_id": ObjectId("605c72b1e5a1f52c2c9d9b1a"),
"item_type": "weapon",
"attributes": {
"attack_power": 150,
"durability": 100
},
"acquired_at": "2024-10-10T12:45:00Z"
}
- _id: 아이템 고유 식별자
- item_name: 아이템 이름
- description: 아이템 설명
- player_id: 해당 아이템을 보유한 플레이어의 ID (Players 컬렉션 참조)
- item_type: 아이템 유형 (무기, 방어구, 소모품 등)
- attributes: 아이템의 특성 (예: 공격력, 내구성 등)
- acquired_at: 아이템 획득 시간
4. 이벤트 컬렉션 (Events)
{
"_id": "event789",
"player_id": ObjectId("605c72b1e5a1f52c2c9d9b1a"),
"event_type": "level_up",
"event_description": "Player reached level 15",
"event_timestamp": "2024-10-22T15:00:00Z"
}
- _id: 이벤트 고유 식별자
- player_id: 이벤트를 발생시킨 플레이어의 ID
- event_type: 이벤트 유형 (레벨 업, 퀘스트 완료, 보스 처치 등)
- event_description: 이벤트 설명
- event_timestamp: 이벤트 발생 시간
관계와 데이터 모델링
도큐먼트 기반 데이터베이스에서 데이터의 관계는 RDBMS에서처럼 명확한 외래 키(Foreign Key) 개념이 없으며, 대신 중첩된 도큐먼트 또는 참조를 통해 관계를 구현할 수 있습니다.
중첩된 도큐먼트:
- 예를 들어, 플레이어의
recent_matches 필드에 최근 매치 기록을 중첩하여 저장함으로써 매치 정보와 플레이어 정보를 한 곳에 저장할 수 있습니다. 이는 데이터 읽기 시 빠른 조회가 가능하게 해줍니다.
참조:
- 경우에 따라 데이터를 중복 저장하는 대신, 각 컬렉션에 참조 ID만 저장할 수 있습니다. 예를 들어
player_id를 통해 다른 컬렉션의 도큐먼트에서 필요한 데이터를 조회할 수 있습니다.
도큐먼트 데이터베이스의 장점과 단점
장점:
- 유연한 스키마: 스키마가 고정되지 않으므로, 다양한 구조의 데이터를 저장하기 쉽습니다. 유저마다 다른 종류의 데이터를 다룰 때 유용합니다.
- 확장성: 도큐먼트 기반 데이터베이스는 수평적 확장이 용이합니다.
- 중첩된 데이터 구조: 관련 데이터를 하나의 도큐먼트로 저장하여 데이터를 빠르게 조회할 수 있습니다.
단점:
- 중복 데이터: 중첩된 데이터 구조를 사용하다 보면 데이터가 중복 저장될 수 있습니다. 이 경우 데이터 업데이트 시 유지보수가 복잡해질 수 있습니다.
- 복잡한 관계: RDBMS와 달리 명확한 관계 설정이 없기 때문에, 복잡한 조인 작업이 필요한 경우에는 불편할 수 있습니다.
결론
도큐먼트 기반 데이터베이스는 유연성과 확장성이 중요한 게임 통계 서버의 데이터 저장 및 분석에 적합한 선택입니다. 특히 유저별로 기록해야 할 데이터가 다르거나, 정해진 스키마가 아닌 다양한 데이터 형태가 필요한 경우 MongoDB와 같은 도큐먼트 DB는 유용합니다.