Qual banco de dados (RDBMS x NoSQL x AMBOS) a ser usado em um jogo para vários jogadores em tempo real?

12

Estou trabalhando em um jogo multiplayer em tempo real que exigirá um banco de dados (para recursos como perfis de jogadores, amigos, desbloqueios, notícias etc.) Este é um jogo para PC padrão (não baseado em navegador) e utilizará um servidor cliente arquitetura. Eu sou novo no uso de bancos de dados e fiz algumas pesquisas nos últimos dias quando me deparei com o acalorado debate: RDBMS vs NoSQL. Atualmente, estou inclinado a usar o NoSQL, mas depois de ler sobre os usos de cada um (RDBMS e NoSQL), sou tentado a usar os dois. Sei que isso pode parecer estranho, mas deixe-me explicar minha situação:

Minha equipe possui um pacote de hospedagem compartilhada que oferece armazenamento e largura de banda ilimitados de mySQL, a única ressalva é que só podemos ter 25 conexões abertas ao mesmo tempo (regra de hospedagem compartilhada). Pretendo usá-lo no meu site (um uso típico, sem dúvida), a fim de publicar atualizações de notícias, oferecer suporte a recursos da comunidade (como comentários, fazer upload de arte de fãs etc.) e similares. Tudo bem e bom - mas! é aqui que as coisas ficam interessantes ... Quero exibir essas mesmas informações que são postadas no meu site, no jogo. Isso significa usar o mySQL no meu site e no meu jogo. Além de posts de notícias e similares, pretendo usá-lo no jogo para coisas como bate-papo e uma lista de servidores. Estou preocupado com essa regra de 25 conexões principalmente.

O que me leva a fazer a pergunta nº 1: isso funcionará e existe uma alternativa melhor?

Agora, além disso, eu li sobre o desempenho do NoSQL e é adequado para jogos em tempo real (eu posso estar errado, passei por uma enorme guerra de chamas RDBMS vs NoSQL para chegar aqui e provavelmente estou queimado). Basicamente, eu gostaria de usar o MongoDB para todos os meus dados de objeto de jogo.

E, novamente, será útil se eu fornecer algum contexto: Encontrei um host (MongoLab) que oferece um pacote MongoDB de 240 MB gratuitamente, que pretendo usar até que seja necessário atualizar. Dado 240 MB, calculei que poderei armazenar aproximadamente 60.000 jogadores (se cada jogador tiver aproximadamente 4KB e ignorarmos outras coisas que possam ser armazenadas). O espaço de armazenamento e ter que pagar por mais no futuro (caso nosso jogo seja bem-sucedido) não é um problema. Atualmente, a única razão pela qual pretendo usar o MongoDB para todos os meus dados de objeto de jogo é a frequência com que esses dados serão acessados ​​(como sempre que um jogador é morto, pega um item, dispara uma arma etc.) também como os documentos sem esquemas diretos (que facilitam o mapeamento de dados do objeto do jogo). Devo notar que, ao mesmo tempo,

Pretendo usar o mesmo MongoDB no meu site, para exibir informações do perfil do jogador (não estou preocupado com a consistência completa, há algum atraso nas atualizações do jogo). O que me leva à minha segunda pergunta, pergunta nº 2: é uma boa idéia ou há algo melhor que devo fazer?

O jogo terá uma experiência inicial semelhante a esta:

  1. Login do cliente (MongoDB)
  2. O cliente está na home page do jogo com salas de bate-papo (MySQL)
  3. Cliente vai para a lista de servidores (MySQL)
  4. O cliente se conecta a um servidor e joga nele

  5. O servidor comunica atualizações para todos os players (MongoDB)

Foi assim que imaginei que funcionaria. Isso parece bom para você ou você tem sugestões sobre como esse plano pode ser melhorado?

Andrew
fonte
9
Ao menos que você forneceu uma abundância de informações , ao contrário de algumas pessoas que não dão suficiente informação.
Cyclops
7
Talvez eu esteja entendendo mal o que você está sugerindo, mas por uma questão de segurança, seu jogo não deve se conectar diretamente ao seu banco de dados, portanto a contagem de conexões não deve importar. Se o seu jogo puder se conectar, também poderá qualquer outra pessoa. Você provavelmente também não deveria estar abrindo uma nova conexão do servidor do jogo ao banco de dados para todos os jogadores que se conectarem.
Matthew Scharley
1
Qual idioma / ferramentas você planeja usar para a programação de back-end?
aaaaaaaaaaaa 23/08
4
Se você escolher um banco de dados hospedado, terá uma viagem de ida e volta do jogo para o servidor e de lá para o servidor do banco de dados. Isso será mais lento do que o jogo para o servidor (que abre uma conexão local com o banco de dados) e anulará o ganho de desempenho assumido pelo uso do NoSQL.
precisa saber é o seguinte
"a equipe possui um pacote compartilhado de hospedagem na web que oferece armazenamento e largura de banda ilimitados do mySQL" ... O que eles dizem e o que você recebe são duas coisas diferentes. Você pode "ter" todo o espaço do mundo, mas se estiver acessando através de um canudo virtual em vez de um tubo de gordura, será inútil.
Ken

Respostas:

11

Minha sugestão é que seu jogo se comunique com um serviço da web que você criou que lida com a consulta ao banco de dados. Nesse ponto, é muito simples tentar diferentes tipos de bancos de dados "alternando" implementações de serviços web (sua interface de serviço web sempre permanece a mesma para que seu jogo não seja interrompido) e decidir qual é o melhor para você.

Também é muito mais seguro não expor seu banco de dados diretamente à Internet.

pwny
fonte
Essa é uma ótima idéia, obrigado, eu definitivamente irei. Eu sou novo no uso de bancos de dados, então essas coisas não me ocorreram.
Andrew
2
+1 Fazer o cliente se comunicar diretamente com o DB é uma falha de segurança do calibre goatse.cx.
Nevermind
6

só podemos ter 25 conexões abertas ao mesmo tempo (regra de hospedagem compartilhada).

Isso é mais do que suficiente para o seu jogo. O problema é que, se o seu site usa várias conexões, você pode acabar. Você precisa configurar seu servidor da web para usar apenas um pequeno número deles, deixando o restante para o servidor do jogo. Seu servidor de jogos não precisa realmente de mais de uma conexão, mas pode se beneficiar de ter um punhado.

Agora, além disso, eu li sobre o desempenho do NoSQL e é adequado para jogos em tempo real (eu posso estar errado, passei por uma enorme guerra de chamas RDBMS vs NoSQL para chegar aqui e provavelmente estou queimado). Basicamente, eu gostaria de usar o MongoDB para todos os meus dados de objeto de jogo.

É um argumento um pouco falso, porque nenhum dos sistemas é rápido o suficiente para ser usado como loja principal de um jogo em tempo real - você realmente precisa manter e manipular os valores na memória. Então você só acessa o banco de dados quando é absolutamente necessário, o que pode ser apenas para salvar o personagem inteiro de vez em quando (por exemplo, uma vez por minuto), momento em que as diferenças de velocidade se tornam insignificantes.

O engraçado é que, se você ajustar o MongoDB para a velocidade máxima, poderá chegar a um ponto em que seria rápido o suficiente para executar gravações síncronas em um jogo razoavelmente rápido, mas isso custaria integridade dos dados porque as gravações são armazenadas em buffer. Isso significa que você perde esses dados no caso de uma falha, portanto, havia pouco sentido em executar a gravação, e ainda é mais lento do que se você apenas executasse a edição na memória e a salvasse mais tarde, para obter o pior dos dois mundos. .

Atualmente, a única razão pela qual pretendo usar o MongoDB para todos os meus dados de objetos de jogo é a frequência com que esses dados são acessados ​​(como sempre que um jogador é morto, pega um item, dispara uma arma etc.)

Pergunte a si mesmo por que você precisa gravar no banco de dados quando um jogador dispara uma arma. Por que isso não pode ser tratado na memória no servidor do jogo? Se o seu jogo travar e depois reiniciar, e o jogador descobrir que possui 3 marcadores a mais do que esperava, isso é um problema crítico de negócios?

Também gosto dos documentos diretos, sem esquemas (que facilitam o mapeamento dos dados do objeto do jogo).

Esse é um motivo muito melhor para escolher uma abordagem NOSQL do que a questão do desempenho.

Pretendo usar o mesmo MongoDB no meu site, para exibir informações do perfil do jogador (não estou preocupado com a consistência completa, há algum atraso nas atualizações do jogo).

Isso é bom e sensato. Posteriormente, convém usar uma instância separada, para que as leituras da Web não contestem as leituras e gravações de jogos, mas esse problema é trivial de resolver, em comparação com o problema de se tornar popular o suficiente para que isso seja um problema.

Pessoalmente, eu escolheria um dos dois bancos de dados, com base no qual seria menos trabalhoso para mim, e padronizaria isso - mas não há razão para que você não possa ficar com dois, se quiser.

Kylotan
fonte
Você pode sugerir alguma estrutura para isso? "você realmente precisa manter e manipular os valores na memória." Ouvi falar de redis, mas é apenas uma relação de valor-chave, há algo em que podemos manipular?
user1735921
Não, quando digo "mantenha e manipule valores na memória", estou literalmente dizendo "o jogo roda como um programa normal com os dados armazenados em variáveis", não como algum tipo de camada ou estrutura de banco de dados especial.
Kylotan #
4

Todos os dados em tempo real precisam ser mantidos na memória do aplicativo; qualquer outra coisa seria tola.

Manter os dados de login, estatísticas etc. dos usuários é uma tarefa bastante leve, por isso vou ser ousado e dizer que você pode usar praticamente o que quiser. Embora você possa ter cuidado com o site, coisas como listas de usuários podem prejudicar muito o desempenho do banco de dados se você não criar um sistema de cache adequado.

E, como disse o bummzack, você deve manter tudo na mesma rede. Além disso, cuidado com as coisas gratuitas, 240 MB de armazenamento de banco de dados gratuito parece bom, mas como a máquina provavelmente está dividida entre um grande número de serviços de usuários gratuitos, pode ser bem lento.

aaaaaaaaaaaa
fonte
Concordo, você quer ot manter seus dados do jogo na memória, e assim como você pode manter o login dados na memória, bem como (considerando que eles são muito menores)
MarkR
O motivo para não manter alguns dados na memória (ou permitir que um banco de dados lide com ambos na memória e no disco) é que você deseja que os dados sejam persistentes se o servidor travar. A maneira mais fácil de proteger isso é armazená-lo em um banco de dados.
Aaaaaaaaaaaa 16/10
Você ainda pode usar um banco de dados para persistência - mas ainda assim manter os dados na memória, dessa forma, você terá armazenamento robusto e seguro contra falhas, mas acesso rápido o suficiente para não bloquear o servidor (de outras atividades) se precisar verificar logins etc. .
MarkR
2

Você confia nos seus 60.000 usuários por banco de dados? Caso contrário, você deve anexar a idéia "acesso ao banco de dados a partir do cliente", a menos que o seu nível de conhecimento em segurança do software de banco de dados seja de primeira qualidade e tenha certeza de que pode acomodar quaisquer problemas resultantes.

Andy Finkenstadt
fonte
9
E se você tiver certeza disso, ipso facto, seu nível de conhecimento em segurança de banco de dados não é de primeira.
Jhocking 23/08