Estou construindo um jogo que possui estrutura de micro-serviços usando docker.
A maneira como comecei a construir meus serviços é ter uma instância do mongoDB para cada serviço, portanto, ter o serviço OneToOne para a instância do mongoDB,
Resources ---> resourcesDB (mongoDB instance 1)
Chat ---> chatDB (mongoDB instance 2)
Buildings ---> buildingsDB (mongoDB instance 3)
Battle ---> battleDB (mongoDB instance 4)
...
Isso realmente fazia sentido no início, pois esses serviços, por exemplo, não têm nada em comum e não precisam ter uma conexão com a mesma instância mongo e, quando têm algo em comum (construindo <-> recursos), basta enviar uma chamada ao serviço necessário e que cuida do resto (atualize seu banco de dados).
Mas estou começando a pensar que essa não é a abordagem certa por causa de algumas coisas:
1 - o resourceDB, por exemplo, tem apenas 2 coleções,
Logs ---> logging every resources change (building built, war lost etc.)
Resources ---> 1 document per user holding how much he have.
o que significa que este banco de dados não conterá nenhum dado enorme (o registro será excluído após algum tempo), portanto, definir uma instância apenas para essas 2 coleções parece uma grande eliminação, mesmo que esta instância não tenha seu próprio servidor e compartilhe servidor com o serviço.
2 - manter e fazer backups exigirá algum trabalho extra que não tenho certeza se é necessário no meu caso.
Cada um dos serviços atualizará seu banco de dados com bastante frequência, o recurso está fazendo cálculos a cada segundo para ver quanto cada usuário tem, então atualizará o banco de dados 'users amount'por segundo, além do restante das solicitações, como construir um prédio (reduzir recursos) e outras atualizações, o serviço de bate-papo atualizará o banco de dados a cada mensagem privada ou mensagem de bate-papo, o serviço de batalha atualizará o local e as estatísticas das tropas e mais coisas a cada segundo para cada batalha que está acontecendo.
Estou pensando em arriscar essa estrutura para uma das seguintes:
talvez tenha apenas 1 instância de banco de dados com banco de dados separado, então cada serviço se conectará a um banco de dados separado, mas eu li que ainda será um aborrecimento manter backups dos bancos de dados e dimensionamento.
tenho 1 banco de dados e tenho todas as coleções nele, cada coleção será acessada por um serviço diferente e nunca será acessada por 2, então não tenho nada com que me preocupar com 2 serviços alterando a mesma coleção.
deixe como está e vá com muitas instâncias do mongoDB
algumas perguntas sobre os métodos acima:
o que devo escolher? ter 1 banco de dados parece bom, pois economizará muitos recursos e facilitará minha vida, mas separar os serviços para muitos bancos de dados parece lógico para mim, pois um serviço não precisa ver coleções ou ser capaz de acessar uma coleção que não tem nada a ver com o trabalho dele.
Não tenho certeza de como o mongoDB lida com muitas conexões com a mesma instância ou com o mesmo banco de dados, como você pode ver, ele pode receber muitas chamadas em um segundo, mesmo que eu tenha uma quantidade muito baixa de usuários.
Eu li sobre mongo Sharding, pelo que entendi isso acontece por banco de dados e não no nível da instância, por isso estou pensando na opção 1 banco de dados, pois é bastante útil no meu caso, certo?
É sensato pensar em como dimensionar seu aplicativo no futuro, mas você pode começar com uma implantação mais simples que pode crescer de acordo com seus requisitos.
Minha recomendação seria configurar uma única implantação do MongoDB (idealmente começando com um conjunto de réplicas ou serviço hospedado com alta disponibilidade e redundância de dados):
Uma única implantação do MongoDB pode ter vários bancos de dados; uma implantação do MongoDB por serviço adiciona complexidade administrativa desnecessária.
Para o seu caso de uso, parece razoável ter um banco de dados por serviço e configurar um usuário por serviço para que as ações sejam limitadas à interação direta com o banco de dados esperado.
Um banco de dados por serviço também limita o impacto potencial de ações administrativas (por exemplo, uma construção de índice de primeiro plano) que pode criar contenção no nível do banco de dados.
Posteriormente, você pode dimensionar/ajustar a implantação começando com opções como
directoryPerDB(por exemplo, armazenamento mais rápido para alguns bancos de dados) ou particionar seus dados usando sharding.Esta é uma questão mais sutil, pois depende dos recursos do servidor, bem como do que essas conexões estão fazendo e como/se o seu driver implementa o pool de conexões. Idealmente, eu faria um teste de carga em seu aplicativo real e determinaria como o uso de recursos aumenta com o aumento da atividade do usuário. Se você estiver administrando sua própria implantação do MongoDB, deverá revisar as notas de produção e, em particular, certificar-se de que suas configurações de ulimit foram aumentadas adequadamente para garantir que você não fique sem descritores de arquivo.
Se você estiver preocupado com a facilidade de dimensionamento, considere também uma solução de banco de dados como serviço hospedado (por exemplo, MongoDB Atlas ).
A fragmentação é habilitada inicialmente no nível do banco de dados, mas o particionamento ocorre no nível da coleção com base em uma chave de fragmentação . Você pode ter uma combinação de bancos de dados fragmentados/não fragmentados e coleções fragmentadas/não fragmentadas na mesma implantação do MongoDB.