MMORPG에서 일반적으로 어떤 종류의 데이터베이스가 사용됩니까? [닫은]


답변:


38

우리는 Ben Z가 실제로 데이터베이스의 원래 저자이기 때문에 내가 할 수있는 것보다 더 나은 이유를 설명 할 수 있기를 바랍니다. 짧은 버전은 관계형 DB가 게임에 매우 유용하지 않다는 것인데, 이는 엄청나게 구조화 된 계층 적 데이터를 효율적으로 저장할 수 없기 때문에 MMO가 일반 작업에 필요한 대부분의 데이터를 구성합니다. 우리는 커스텀 객체 데이터베이스와 분산 트랜잭션 처리 시스템의 일부를 구축하기로 결정했습니다.

당신이 똑같이해야한다면? 아마 처음에는 아니에요. 나는 여전히 SQL을 피하는 것을 옹호하지만 "NoSQL"세계에는 몇 년 전에 존재하지 않았던 더 많은 옵션이 있습니다.

즉, 대부분의 MMO는 SQL (관계형) 데이터베이스에서 실행됩니다. 나는 Eve가 몇 개의 다중 TB RAMSAN 위에 설치된 SQL Server 설치에서 실행된다는 것을 알고 있습니다 (아마도 내 인생에서 그만큼 비용이 들지 않을 것입니다).

편집 : 그가 여기에 게시하지 않아도 되기를 바랍니다. 그러나 이것은 GDC'08에서 데이터베이스에 대해 발표 한 프레젠테이션에 대한 링크와 의견이있는 블로그 항목입니다.


1
+1 대부분의 사람들이 자신의 데이터베이스를 작성했다고 생각합니다. 그러나 NoSQL 세계가 지금 성장하고 있다는 것은 멋진 일입니다.
Jesse Dorsey

5
나중에 무언가를 많이 커스터마이징하더라도 프로토 타입을 만들 수있는 DB가 하나 이상있을 수 있습니다.
coderanger

9
코드 레인저가 맞습니다. MMO에 대한 사용자 지정 데이터베이스를 작성했습니다. 만약 내가 오늘날의 세계에서 다시이 일을한다면, 아마도 4 년 전보다 세상이 더 활동적이라고 언급하기 때문에 기존 기술을 더 자세히 살펴볼 것입니다. 많은 MMO는 실제로 SQL에서 실행되며 일부는 제대로 수행되고 일부는 잘 수행되지 않습니다. 해당 게임의 경우 최대 영역 또는 대륙 동시성이 아닌 최대 샤드 동시성이 낮습니다.
벤 Zeigler

2
"무질서하게 구성된 계층 적 데이터를 효율적으로 저장할 수 없기 때문에 MMO가 정상적인 작업에 필요한 대부분의 데이터를 구성합니다." -이는 게임 프로그래밍보다 응용 프로그램 개발에서 훨씬 더 사실입니다. 불행히도 우리는 우리가 가지고있는 것에 고착하고 있으며 NoSQL 솔루션의 성능 (및 DBA의 가용성)이 현재 RDBMS의 성능과 일치하지 않기 때문에 데이터를 실행할 수있는 형태로 스 머시하고 얼룩지게해야합니다. RDBMS.
BlueRaja-대니 Pflughoeft

1
몇 년 전에는 그랬지만 지금은 필요한 성능 특성을 제공하는 상용 데이터베이스가 많이 있습니다.
coderanger 2016 년

35

이 대답은 더 많은 관찰입니다.

MMORPG에서 일하지 않은 전체 공개. 나는 2009 년에 가장 많이 방문한 10 대 사이트 중 하나에서 일했으며, MMORPG 기술을 만들고 있다고 생각한 게임 엔진 회사에서 일했습니다 (배송 여부는 모르겠습니다).

구글, 페이스 북, 트위터 등 거대한 규모를 달성 한 회사를 보면 게임 회사는 아니지만이 분야를 살펴볼만한 가치가 있다고 생각되는 두 가지가 있습니다.

  1. 그들은 싸고 쉽게 갈 수 있었던 것을 잡아서 시작했습니다.
  2. 그들은 궁극적으로 많은 기술을 독자적으로 굴려야했습니다. (때로는 하드웨어)

큰 실수는 값 비싼 턴키 일을 잡아서 마법의 확장을 기대하는 것입니다. 그런 식으로 작동하지 않습니다. 확장의 핵심은 각각의 새로운 도전을 적절히 처리하는 것입니다. 쉽게 출입 할 수있는 유연하고 사용하기 쉬운 솔루션이 필요합니다.

그래서 당신에게 나의 충고는 당신이 처음 시작할 때, 두통이 가장 적은 것 같은 것을 얻는 것입니다.


25

기본적으로 모든 접근 방식이 있으며 데이터베이스의 속성만큼 개발자의 경험을 바탕으로 선택되었다고 생각합니다. 결국 많은 MMO가 표준 관계형 데이터베이스를 사용하고 있습니다. Dark Ages of Camelot 사용 / 사용 (아직 계속 진행되고 있습니까?) MySQL , FreeRealms는 수정 된 Postgresql 등을 사용합니다 .

규모를 따라 가다 보면 Guild Wars가 있습니다. SQL Server를 사용 하지만 단일 BLOB으로 데이터를 저장합니다. 즉, 데이터베이스가 제공하는 몇 가지 이점과 함께 일반적인 이진 형식의 이점을 얻을 수 있습니다. 말할 필요도없이,이 접근 방식의 단점도 볼 수 있지만 플랫 파일 작업에 익숙한 회사의 경우 여전히 단계적으로 향상되었을 것입니다.

그렇다면 아직 초기 단계는 아니지만 다양한 형식화 된 NoSQL 접근 방식을 사용하는 곳이있을 수 있습니다. 팜빌은 사용 membase 그들은 분명히 memcached를 기반으로, 목적을 위해 만든. 이것은 MongoDB, CouchDB 등과 같은 많은 기능을 공유합니다. 이러한 접근 방식을 사용하면 일반적으로 자체 스토리지 형식을 롤링하지만 배포, 캐싱, 중복 등의 이점을 얻을 수 있습니다.

일부는 완전히 자신의 NoSQL에 롤링됩니다 크립 틱은 그들이 비슷한 않았다 뿐만 아니라 그들이 생산에 사용하지 않을 있다고 말했다. ( 편집 : 아래 주석 참조)

그리고 당신은 플랫 텍스트 또는 이진 파일을 사용하는 사람들에게옵니다-Ultima Online, Everquest 등과 같은 오래된 게임은 모두이 길을 갔고 게임 개발 경험이 있지만 데이터베이스 경험이 거의없는 회사에게는 잘 작동합니다. 너무.

또한 용어에 대해 약간의 의미로 자신의 데이터베이스를 작성하는 데 거의 도움이되지 않습니다. 게임에서 항상 자체 메모리를 빌려주지 않는 방식으로 메모리 내 또는 디스크 내에서 관리 해야하는 맞춤형 데이터를 갖게됩니다 일반 소프트웨어에. 데이터를 원할 때마다 SQL 쿼리를 수행 할 수 없으므로 사용하는 백엔드에 관계없이 코드에 많은 정보를 미러링해야합니다.


1
메모리에 보관하는 경우 데이터베이스 내 메모리를 구현해야하거나 영역간에 거래 할 때 품목 복제 / 손실 (예 :)이 발생할 위험이 있습니다. "메모리에 보관하십시오"는 모든 플레이어가 항상 동일한 메모리 공간 내에있는 동안에 만 작동합니다.

1
온라인과 히트 포인트에 대해서는 사실이지만 Cryptic의 DB에서 ACID를 보장하지는 않았지만 퀘스트 이정표 (5/10 늑대 사살) 또는 XP 보상은 플레이어 당 초당 여러 번 발생할 수 있습니다.

1
서버가 다운되면 퀘스트 진행률을 잃는 사용자를 잘 다루는 경우 트랜잭션 의미 체계가 필요하지 않습니다. XP 보상의 경우, 레벨을 잃는 것을 의미 할 수 있으며, 게임이 충돌하고 레벨을 잃을 때 다음 단계는 일반적으로 게임을 중지하는 것입니다.

6
XP는 매우 많은 거래가 필요합니다. 처음에 CrypticDB를 생성하게 한 특정 악용 중 하나 (내가 믿어 라)는 한 번에 여러 서버에서 XP 이득을 얻었고 사용자가 인터럽트 할 수없는 동기화에 실패했습니다. 캐릭터의 진행에 중요한 것은 실제로 거래되어야하며, 그렇지 않으면 플레이어는 악용 할 수있는 방법을 찾을 것입니다.
벤 Zeigler

1
@ expiredninja : 그것은 매우 열린 질문입니다. 그러나 'flatfile'은 "임의의 디스크 직렬화"를 의미합니다. 예를 들어 게임 개발자는 종종 각 필드를 fprintf로 작성합니다.
Kylotan

10

불타는 바다의 해적에서 우리는 MySQL로 시작했습니다 (솔직히 Postgres를 선호했을 것입니다). 솔직히, 나는 아마 그 길을 앞으로 다시 가지 않을 것입니다. 대부분의 PotBS 데이터는 어쨌든 유지되기 전에 미리 직렬화되므로 DB에 포함 된 대부분의 데이터는 자란 키 / 값 저장소에 지나지 않습니다. 또한 지속성 계층에서 성능을 향상시키고 데이터가 메모리에 캐시되는 방식을 더 잘 제어하기 위해 데이터베이스 앞에 앉아있는 캐싱 서버를 작성했습니다.

Kylotan은 아주 그렇습니다. 당신은 어떤 수준으로 자신을 굴리지 않을 것입니다. SQL 관계형 데이터베이스 서버는 게임이 데이터를 사용하는 방식으로 설계되지 않았습니다. 관계형 DB 서버가 최후의 데이터베이스라고 가정하는 대신 도구를 선택하기 전에 우리가 찾고있는 이점에 대해 더 많이 생각해야했습니다.

다음 번에는 BerkleyDB 또는 다른 NoSQL 스타일 DB와 같은 것들에 대해 더 자세히 살펴볼 것입니다.


10

주목해야 할 또 다른 사항은 (상대적으로) 정적 데이터 세트가있는 경우 데이터베이스에 저장하지 마십시오! 철자 정의, 아이템 정의, 맵 등을 데이터베이스에 저장해야 할 이유는 없습니다. 이름을 제외하고는 거의 쿼리하지 않습니다. 많은 사람들이 지속적인 플레이어 데이터와 함께 이러한 것들을 저장하는 게임 개발에 뛰어 들었고 완전히 다른 종류의 것입니다.

이를 위해서는 파일 시스템과 같은 데이터 저장소가 필요합니다. 개발 외부에서는 ACID가 필요하지 않으며 CRUD가 필요 없으며 이러한 종류의 데이터에 대한 데이터베이스가 필요하지 않습니다. 개발 과정에는 데이터베이스가 필요하지만 VCS도 필요하며 VCS를 선택하면 데이터베이스를 선택할 수 있습니다.

(플레이어가 커스텀 스펠이나 아이템 또는 퀘스트를 만들 수있는 게임을하고 있다면, 그 데이터는 플레이어 데이터와 같은 종류이므로 데이터베이스가 다시 필요합니다.)


5

MMORPG는 집중적 인 응용 프로그램이며 큰 사업입니다. 게임 개발을 시작하는 경우 더 작은 작업을 수행하는 것이 좋습니다.

그것은 당신의 설정에서 두 가지 짜기 최고 성능이 필요하다고 말했습니다. 분명히 서버 팜 / 하이브가 필요합니다. 네트워크 통신은 상대적으로 비싸고 (대부분의 MMORPG는 실시간이므로) 중앙 데이터베이스를 각 게임 서버에 복제 할 수 있습니다 (선택한 데이터베이스의 실시간 지연 시간이 짧은 복제와 동일 함).

각 서버가 WoW와 같은 게임 세계의 특정 세그먼트를 제공하는 경우 분산 파티션 뷰 와 같은 것 . DPV를 사용하면 다른 서버에서 데이터베이스 행을 세그먼트화할 수 있습니다. 각 서버의 열 제약 조건에 따라 MSSQL과 Oracle은 모두 WHERE 또는 ON 절에 포함 된 데이터가 포함 된 서버와 만 통신하기에 충분합니다. 오픈 소스 제품 중 하나에 DPV가 있는지 확실하지 않습니다.

이 모든 결과는 어떤 DB를 사용하든 상관없이 MSSQL, Oracle, MySQL, PostgreSQL과 같은 좋은 이름의 데이터베이스를 사용 하는 것입니다. ANSI SQL로 데이터베이스를 작성하고 어떤 시스템이 가장 잘 작동하는지 확인하십시오. 이것이 유일한 방법입니다.

NoSQL 경로는 높은 동시성을 위해 설계되었으므로 좋은 아이디어 일 수 있습니다. Pranny의 제안은 트릭을 할 수 있습니다.


5

MongoDB (NoSQL)를 사용했는데 TCP를 통해 액세스 할 수있는 매우 빠른 문서 저장소입니다. 시도 해봐! 그것은 굉장!

자신의 DB를 작성하는 것은 어려운 작업입니다. 먼저 이미 존재하는 것을 탐색하고 특정 기준과 일치하는 것을 찾을 수 없으면 직접 빌드하십시오. 아, 그리고 오픈 소스를 잊지 마십시오. :)


0

어떤 종류의 데이터를 어떤 형식으로 저장해야하는지에 따라 크게 달라집니다.

저는 대부분의 사람들이 SQL Server, MySQL, PostgreSQL 등 플레이어 정보와 같은 "동적"데이터를 위해 "표준"SQL 데이터베이스를 사용한다고 생각합니다.

그러나 "내부"데이터 (세계의 상태, 내용, ....)는 어떤 형식으로도 저장할 수 있으며 대부분의 회사는 특정 요구에 맞게 해당 부분에 대해 최소한 부분적으로 사용자 지정 데이터베이스 시스템을 작성한다고 생각합니다. .


0

글쎄, 그것은 실제로 응용 프로그램에 달려 있습니다. 우리는 소셜 RPG를 개발하는 곳에서 일하고 Google App Engine을 백엔드로 사용합니다.


0

이 질문은 다소 오래되었지만 그것을 처리하는 방법에 대한 나의 아이디어는 오늘날처럼 요청 된만큼 유효합니다.

관계형 데이터베이스를 사용하는 경우이 아이디어가 도움이되도록로드를 줄여야합니다.

모든 공개 정보를 각 클라이언트 시스템 및 서버 DB의 로컬 DB에 저장하십시오.

클라이언트 데이터베이스에 항목이있는 모든 테이블을 저장하십시오. 해당 무기 위에 통계를 표시 할 때 클라이언트가 서버를 찾는 대신 로컬 데이터베이스에서 통계를 확인합니다. 서버에는 계산할 때 통계를 가져 오기위한 자체 데이터베이스가 있으며 클라이언트에 남아있는 피해와 상태를 전달합니다.

이 아이디어의 최악의 사례는 모든 고객이 클라이언트 데이터베이스에 들어가면 모든 무기에 대한 통계를 볼 수 있다는 것입니다. 값을 변경하더라도 원인은 중요하지 않지만 서버의 데이터베이스 값은 게임에서 계산하는 것입니다.


1
그런 정보를 모두 로컬에 저장하면 데이터베이스에있을 필요는 없습니다.
Josh
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.