[게임 통계 서버의 구성 및 설명] 게임 통계 서버 구성 3

게임 통계 서버에서 관계형 데이터베이스(RDBMS)를 사용하는 대신, 도큐먼트 기반 데이터베이스(예: MongoDB)를 사용하는 경우, 유연한 데이터 저장이 가능하며 스키마를 고정하지 않고도 다양한 구조의 데이터를 저장할 수 있다는 장점이 있습니다. 특히 유저 데이터와 게임 이벤트 데이터가 서로 다른 구조를 가질 때 적합합니다.

다음은 도큐먼트 기반 데이터베이스에서 게임 통계 서버의 도큐먼트 구조 테이블 설계 예시 및 설명입니다.

---

도큐먼트 기반 데이터베이스 설계 개요

1. 플레이어 컬렉션 (Players Collection)

   • 각 플레이어에 대한 기본 정보와 게임 통계 데이터를 저장합니다.
   • 플레이어의 레벨, 경험치, 보유 아이템, 매치 결과 등을 하나의 도큐먼트에 포함할 수 있습니다.

2. 매치 컬렉션 (Matches Collection)

   • 각 게임 매치의 기록을 저장하며, 매치에 참여한 플레이어들의 상세 정보와 결과를 함께 기록할 수 있습니다.

3. 아이템 컬렉션 (Items Collection)

   • 유저가 보유하고 있는 아이템 또는 구매한 아이템을 저장합니다.

4. 이벤트 컬렉션 (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) 개념이 없으며, 대신 중첩된 도큐먼트 또는 참조를 통해 관계를 구현할 수 있습니다.

1. 중첩된 도큐먼트:

   • 예를 들어, 플레이어의 recent_matches 필드에 최근 매치 기록을 중첩하여 저장함으로써 매치 정보와 플레이어 정보를 한 곳에 저장할 수 있습니다. 이는 데이터 읽기 시 빠른 조회가 가능하게 해줍니다.

2. 참조:

   • 경우에 따라 데이터를 중복 저장하는 대신, 각 컬렉션에 참조 ID만 저장할 수 있습니다. 예를 들어 player_id를 통해 다른 컬렉션의 도큐먼트에서 필요한 데이터를 조회할 수 있습니다.

---

도큐먼트 데이터베이스의 장점과 단점

장점:

• 유연한 스키마: 스키마가 고정되지 않으므로, 다양한 구조의 데이터를 저장하기 쉽습니다. 유저마다 다른 종류의 데이터를 다룰 때 유용합니다.
• 확장성: 도큐먼트 기반 데이터베이스는 수평적 확장이 용이합니다.
• 중첩된 데이터 구조: 관련 데이터를 하나의 도큐먼트로 저장하여 데이터를 빠르게 조회할 수 있습니다.

단점:

• 중복 데이터: 중첩된 데이터 구조를 사용하다 보면 데이터가 중복 저장될 수 있습니다. 이 경우 데이터 업데이트 시 유지보수가 복잡해질 수 있습니다.
• 복잡한 관계: RDBMS와 달리 명확한 관계 설정이 없기 때문에, 복잡한 조인 작업이 필요한 경우에는 불편할 수 있습니다.

---

결론

도큐먼트 기반 데이터베이스는 유연성과 확장성이 중요한 게임 통계 서버의 데이터 저장 및 분석에 적합한 선택입니다. 특히 유저별로 기록해야 할 데이터가 다르거나, 정해진 스키마가 아닌 다양한 데이터 형태가 필요한 경우 MongoDB와 같은 도큐먼트 DB는 유용합니다.