Para um novo projeto no qual estou trabalhando agora, eu estava em dúvida sobre qual banco de dados/sistema de armazenamento usar para informações específicas que não mudam com tanta frequência.
Temos, por exemplo, alguns perfis de empresas que terão apenas gravações incidentais quando coisas como o horário de funcionamento mudarem. Por outro lado, eles têm muita capacidade de leitura; a cada carregamento de página, as informações devem ser carregadas. Armazená-lo no sistema de arquivos como documentos simples resulta em muito IO; Usando isso como ponto de partida, eu estava procurando algum tipo de solução na memória.
Normalmente eu armazeno essas informações em um banco de dados Postgres, sem nenhum cache na camada de aplicativo. É claro que eu poderia adicionar uma camada de cache em redis ou memcached para produzir leituras de E/S menores do disco e lidar com atualizações do cache na camada de aplicativo na atualização das informações
Uma outra solução é usar o MongoDB para armazenar os 'documentos'. Mas não sei como o mongodb lida com a leitura/gravação. Por exemplo, a cada recuperação do documento, ele verifica o sistema de arquivos ou exibe o documento do cache/RAM? (Li em algum lugar que o mongodb mantém muita RAM disponível para si)
Alguém pode lançar alguma luz sobre isto?
A resposta como sempre é: depende ;)
Com um pouco de simplificação: Índices e documentos recentemente lidos (e escritos) são mantidos na RAM até que a RAM seja necessária para outra coisa. Portanto, se seus dados são lidos da RAM ou do arquivo, depende muito se a RAM no (s) nó (s) MongoDb é suficiente para manter o índice e pelo menos parte de seus dados (chamados de conjunto de trabalho) na RAM. É seguro dizer que a única coisa que pode substituir ter RAM suficiente em uma instalação do MongoDB é ter mais RAM.
Portanto, a questão é: quanto é RAM suficiente? E a resposta novamente é: depende. No tamanho do seu banco de dados, no número de documentos em suas coleções, no número de índices que você precisa. Não é fácil descobrir os valores corretos e isso depende muito da situação, mas tentarei fornecer algumas regras práticas.
Embora isso pareça um pouco complicado, pode evitar que você desenvolva (e mantenha!) uma camada inteira em seu aplicativo. Isso se resume facilmente ao longo do tempo.
Observação para dimensionamento geral: calcule os tamanhos de índice para o conjunto de dados esperado. Multiplique esse valor por 1,5 pelo menos. Prefiro sugerir a multiplicação por >3. Tome isso como seu tamanho de memória. Na verdade, o fator é determinado pelo seu fator de crescimento e limitado pelo ponto ideal em que seu hardware oferece o melhor retorno possível. Se seus requisitos de RAM estiverem excedendo a RAM do seu ponto ideal de hardware, você deve fragmentar seu cluster imediatamente.