온라인 게임 서버용 형식화 된 데이터 집합 또는 Entity Framework?

Question

내 게임은 턴베이스되었지만 채팅과 같은 실시간 요소가 있으므로 빠른 속도가 필요합니다. 한 대의 서버가 2 천 명의 온라인 플레이어를 이상적으로 지원해야합니다.

나는 데이터 집합이 메모리에 많은 양의 데이터를 저장하는 경향이 있지만, 나는 그것이 매 밀리 세컨드마다 두 번 db 호출을해야하는 것을 피할 필요가 있다고 생각했다. 후드에서 무슨 일이 일어나는지에 대해 많은 통제력을 갖고 있지는 않아서 엔티티 프레임 워크에 기대고 있습니다.

이제는 이들 중 어느 것도 (일반적으로 C#) 어느 누구도 인생에서 가장 훌륭하게 빠른 해결책이 아니라는 것을 알고 있지만 약간의 편의가 필요합니다.

다른 어떤 iffy 종속성 때문에 .Net 4.0을 쉽게 사용할 수 없습니다. 그것들은 고칠 수 있었지만 솔직히 말해서 나는 그것을 알아 내는데 시간을 투자하고 싶지 않습니다. 나는 내 의존성이 잘 작동하는 3.5를 고집한다.

Answer 1

유일한 문제는 당신이 messeging 및 breadcasting을 provied 외부 클라우드 시스템을 사용하여, 그것을위한 솔루션의 다른 종류를 선택할 수 있습니다 채팅 인 경우 ...

체크 아웃이 링크 : http://www.pubnub.com/solutions/how-pubnub-works

전을 기대 어떤 식 으로든 도왔다

Answer 2

나는 데이터베이스 백엔드로 게임을했다.

현자에게하는 말 : 실시간 게임에서 캐시를 업데이트하는 것은 어렵습니다. 플레이어는 항상 상호 작용합니다. 모든 플레이어를 동일한 서버에 유지할지 여부를 고려해야합니다. 그렇다면 캐싱은 간단하지만 성장이 제한됩니다. 그렇지 않은 경우 사람들이 동일한 서버에서 상호 작용할 수있는 방법을 생각하십시오. 예를 들어 채팅 서버는 채팅 문제를 해결합니다. 그러나 지리 정보가있는 경우 전 세계 영역별로 분류하고 싶지 않을 수 있습니다. 그렇지 않으면 그룹을 유지하고 싶을 수도 있고 다른 게임 인스턴스가있는 경우 세그먼트별로 분류 할 수도 있습니다.

다른 문제는 잠금입니다. 플레이어가 다른 플레이어가 업데이트하는 것과 동일한 데이터에 액세스 할 수 있습니다. 거의 확실하게 트랜잭션 격리 수준을 처리해야합니다. 이자형. 읽기 권한이 없으면 잠금 기능이 도움이됩니다. 이를 위해 ADO는 더 많은 제어 기능을 제공합니다.

그러나 EF를 사용하면 훨씬 더 깨끗한 업데이트 코드를 작성할 수 있으며 ID로 업데이트하는 경우 성능이 달라지지 않습니다.

ADO를 통해 읽고 EF를 통해 작성할 수 있습니다. 심지어 ADO를 사용하는 트랜잭션 db 컨텍스트를 작성할 수도 있습니다. 그런 식으로 그들은 똑같이 보이지만 백그라운드에서 다른 일을합니다.

그냥 내 생각, 당신의 솔루션을 이해하는 데 도움이되기를 바랍니다.

Answer 3

두 가지 솔루션 중 하나가 문제에 이상적이라고 생각하지 않습니다. 따라서 젖은 신문이나 우산을 사용하여 벽에 손톱을 넣을지 묻는 질문과 같습니다. 대답에 관계없이 어느 쪽도하지 않아야합니다.

EF에는 많은 제한 사항과 단점이 있으며 약간의 오버 헤드가 있습니다. 3.5에 충실하고 싶다면 (성능이 좋지는 않지만 헤이), 성능 문제를 해결하는 방법을 포함하여 이미 익숙하지 않은 경우에는 권장하지 않습니다.

데이터 세트는 가증 한 것일뿐입니다.모든 VB 프로그래머가 .NET으로 전환하도록 설득하기 위해 Microsoft가 Visual Studio 용 5 분짜리 끌어서 놓기 코딩 데모를 가져올 수 있도록하기 위해 고안된 것이 내 전문 신념입니다. .NET 2.0 성능은 최소한 선형 적으로 확장되기 때문에 모든 것에 비해 매우 느립니다.

정확히 어떤 제품을 사용해야하는지 잘 모르겠지만 서버가 죽는 경우 롤백을 용이하게하기 위해 트랜잭션 로그와 임시 스냅 샷을 저장할 수있는 메모리 관련 관계형 데이터베이스가 있습니다. IIS가 다시 시작됨 등) 확장 성의 비용으로 성능을 제공합니다 (전체 데이터베이스가 메모리에 적합해야 함).

또 다른 옵션은 여러 서버에서 실제로 잘 조정되는 NoSQL 데이터베이스 (예 : MongoDB)를 사용하고 모든 관련 데이터를 단일 문서로 묶을 수 있기 때문에 (테이블을 조인하는 데 필요한 모든 오버 헤드가 없도록) 데이터를 쿼리 할 때).

두 가지 옵션 중 하나가 두 가지 원래 제안 중 어느 것보다 훨씬 적합 할 것입니다.