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

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?

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.

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.

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.

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.