MMO 서버의 게임 로그 형식


12

전체 클러스터 / 샤드에 대한 게임 이벤트 로그 (오류 / 디버그 로그와 달리)는 실제 프로덕션 환경에있는 상용 MMO에 매우 유용하며, 고객 서비스에 대한 중요한 지원과 기록 분석 수단을 제공합니다.

현재 작업중 인 프로젝트는 모든 게임 이벤트 로그를 저장하기 위해 관계형 데이터베이스를 사용하며, 그 방법이 잘 작동하는 동안 로그의 읽기 전용, 시간순 특성으로 인해보다 효율적인 저장 형식이 가능합니다. .

그러나 사용자 지정 이진 로그 형식을 작성하는 방법에 대해 어디에서 배울 지 잘 모르겠습니다. 사용자 정의 로그 형식을 작성하거나 주제에 대한 권장 논문 / 기사를 경험 한 경험이 있습니까?

답변:


7

Stendhal 에서는 게임 이벤트를 대기열에 추가 한 다음 백그라운드에서 비동기 적으로 처리하여 성능 문제를 해결했습니다 .

우리의 경우 이벤트는 레코드 일뿐 아니라 약간의 논리를 갖는 객체 일 수 있습니다. 어떤 경우에는 두 개의 삽입을 수행해야하기 때문입니다. 예를 들어 게임에서 처음으로 항목을 처리 할 때는 항목 이벤트를 기록하기 전에 먼저 항목을 항목 테이블에 삽입해야합니다.

그러나 로그를 작성하는 것은 문제의 한 측면 일뿐입니다.

로그로 어떤 질문에 대답 하시겠습니까?

시간순으로 전체 로그를 읽는 것이 쉽습니다. 한 명의 플레이어를 위해 필터링 할 수도 있습니다.

그러나 다음과 같은 질문이있을 수 있습니다.

  • 안드레가 어제 베스가 집어 든 물건을 바닥에 놓았습니까? 어느 플레이어가 지금 소유하고 있습니까? (앤턴은 물건을 도난 당했다고 불평했다)
  • 평범한 플레이어가 레벨 100에 도달하는 데 시간이 얼마나 걸립니까? 어느 선수가 훨씬 빨랐습니까? 첫 문자 만?
  • 엄청난 양의 게임 머니를 처리하는 플레이어가 있습니까? 어느 선수에게 전달됩니까? 대가로 귀중한 것이 없다면?
  • 약한 플레이어는 합법적으로 죽일 수없는 강한 생물을 죽일 수 있습니까?
  • ...

Stendhal에서는 게임 로그에 관계형 데이터베이스를 사용하는데, 이는 실행 가능한 임시 쿼리를 허용하는 가장 쉬운 방법이기 때문입니다. 사용자 정의 로그 형식을 사용하는 경우 기본적으로 필요할 때 이러한 모든 쿼리를 코딩해야합니다. 그리고 충분한 성능으로이를 수행하는 것은 다소 어려워집니다.

우리의 gameEvents 테이블에는 51,429,139 개의 행 (지난 해)이 있고 15,893,831 개의 항목에 대해 60,360,657 개의 행 (항상)이있는 전용 itemlog 테이블이 있습니다.


데이터베이스를 얼마나 빨리 검색합니까? 로그가있는 비슷한 데이터베이스를 가지고 있으며 3 개월 후에 약 100,000,000 개의 행이 있습니다. 우리는 MySQL을 스토리지로 사용하며 성능이 좋지 않습니다. 플레이어 (20,000 개만) 행의 모든 ​​동작을 나열하는 간단한 쿼리는 종종 60 초 이상이 걸립니다.
Balon

1
인덱스 열에 대한 간단한 쿼리는 즉각적입니다. 복잡한 쿼리는 60 초 정도 걸리지 만 매우 드물다. 테이블을 매우 많이 색인화하고 비동기 적으로 수행하여 삽입에 대한 페널티를 보상했습니다.
Hendrik Brummermann

흠, 내 문제는 결과 세트가 한 명의 플레이어에 대해 3000에서 150000 사이의 레코드로 상당히 크다는 것입니다. 따라서 작은 결과 집합에 대해 매우 빠르게 작동하기 때문에 시간이 오래 걸리는 이유 일 수 있습니다.
Balon

4

효율성이란 무엇입니까? 디스크 크기 나 쿼리 속도에 관계없이 관계형 데이터베이스는 거의 확실하게 독자적인 이진 형식을 능가 할 것이며 훨씬 쉽고 유연하게 사용할 수 있습니다.

관계형 DB에서 사용하는 각 테이블을 사용하면 행당 허용되는 공간의 양을 정확한 바이트로 지정할 수 있습니다. 일반 텍스트를 기록하지 않고 "게임 이벤트 로그 (오류 / 디버그 로그와 반대)" 는 사용자가 필요하지 않거나 최소한 필요하지 않다는 것을 의미합니다. 관계형 데이터베이스는 공간 측면에서 최적에 가깝기 때문에 처음에는 매우 빠릅니다. 또한 관계형 데이터베이스는 매우 빠른 액세스를 위해 인덱스를 만들고 쿼리를 최적화하여 최대한 활용하는 데 매우 편리합니다.

그래서 나는 당신이 가진 것을 고수하는 것이 좋습니다.


답변 주셔서 감사합니다 (아래 답변을 제출 한 다른 사람들에게 감사드립니다)! 내가 생각할수록 RDBMS 가이 특정 유형의 로깅에 적합한 것으로 보입니다. 기본적인 종류의 검색에 대해 잘 색인 된 사용자 정의 로그 형식을 설계하는 것은 그리 어렵지 않지만 CSR 및 게임 분석에서 자주 사용되는 복잡한 쿼리의 경우 더 일반적인 접근 방식이 필요합니다. 기존 제품은 대부분의 경우 성능이 뛰어납니다.
Charles Ellis

커스텀 이벤트 로그 설정은 FPS 데모 레코딩의 연대순으로 재생하는 데 편리하지만 해결해야 할 문제가 매우 다릅니다. 대규모 멀티 플레이어 클라이언트-서버 게임을위한 데모 레코딩과 비슷한 것을 개발 한 경험이 있습니까?
Charles Ellis

서버 측 로직 처리 모델에 따라 서버에 도착한 시간이 각인 된 모든 입력을 재생할 수 있습니다. 모든 단일 입력을 재생하고 다른 요소 (예 : 랜덤 시드, 지연 시간에 따라 변경되는 것과 같은 암시 적 입력 등)를 모델링해야하기 때문에 문제가 재생되는 경향이 있습니다. 그러나 여기에 모든 규모에 맞는 시스템은 없습니다. 서버 작동 방식에 따라 다릅니다.
Kylotan

3

사용자 정의 형식으로 몇 바이트를 저장하거나 텍스트를 압축하면 저장 공간이 저렴하므로 더 이상 최적화 할 가치가 없습니다. 더 중요한 것은 I / O 버퍼링 및 쿼리와 같은 것들을 다루는 것인데, 둘 다 상용 SQL 서버가 아마 잘 할 것입니다. 그것이 그 전선에서 당신을 위해 일하고 있다면, 나는 그것을 실행할 것입니다. 우리는 우리 자신의 버퍼링 로그 서버를 작성했습니다.이 파일은 사용자 지정 파일에 쓰고 별도의 파서 프로그램을 사용하여 쿼리를 위해 데이터베이스로 읽습니다. 권장하지 않습니다.


0

요즘의 관계형 데이터베이스는 비효율적이지만 노크하는 로그 유형을 저장할 때 게임이나 사용자가 지속적으로 액세스하지 않기 때문에 효율성이 필요하지 않습니다. 팀만 필요합니다. 데이터를 읽습니다.

따라서 "효율성"은 그다지 중요하지 않습니다. 더 중요한 것은 사용자가 게임에서 무엇을하고 있는지에 대한 이야기를 쉽게 전달할 수있는 방식으로 데이터를 주문하는 것입니다. 개발자는 일반적으로이 데이터를 소비하고 분석가가 읽을 수있는 인터페이스에 데이터를 표시해야하며 분석가는 때때로 데이터를 쿼리하여 사용자 행동에 대해 깊이 파고 들어야합니다. 예를 들어, 플레이어가 업데이트 전에 특정 품목을 구매하고 있지만 업데이트 후에 구매를 중단 한 경우 분석가는 구매와 관련된 동작에 대해 특정 숫자를 노출시켜 사용자가 더 이상 구매하지 않는 이유를 판단하는 특정 쿼리를 작성하면 도움이됩니다. 제대로 작동하는 표준 쿼리 언어가 문서화되어있는 것이 가장 좋습니다. 이러한 검색어를 맞춤 이진 형식으로 만들어야하는 경우 작업이 훨씬 더 어려워집니다.

일반적으로 게임 이벤트는 다음과 같습니다 (특히 DeltaDNA 형식).

{
 "eventName":"specific event code – eg. gameStarted",
 "userID":"ABCD1-4321a879b185fcb9c6ca27abc5387e914",
 "sessionID":"4879bf37-8566-46ce-9f3b-bd18d6ac614e",
 "eventTimestamp":"yyyy-mm-dd hh:mm:ss.SSS",
 "eventParams":
  {
   "platform":"WEB",
   "param1":"stringParam",
   "param2":true,
   "param3":1234,
   "param4":["a","b","c"]
  },
}

이벤트에는 일반적으로 이벤트 이름, 사용자 ID, 세션 ID, 타임 스탬프 및 해당 이벤트 주변에 기록하는 데 유용한 데이터를 기록 할 수있는 매개 변수가 포함됩니다. 그리고 내 경험상 관계형 데이터베이스 형식이 그러한 구조를 기록하는 데 가장 좋습니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.