1) Em termos de durabilidade, você pode dizer ao driver java do MongoDB (que o Morphia está usando), qual estratégia usar, veja https://github.com/mongodb/mongo-java-driver/blob/master/src/main/com/ mongodb/WriteConcern.java#L53 . É simplesmente uma troca entre velocidade:NONE (nem mesmo problemas de conectividade causarão um erro) até FSYNC_SAFE (os dados são definitivamente gravados em disco). Para detalhes internos, confira http://www.kchodorow.com/blog/2012/10/04/how-mongodbs-journaling-works/

2) Todos os seus dados são mapeados para a memória (é por isso que a edição de 32 bits tem um limite de tamanho de 2 GB), porém ele só é carregado de fato, quando necessário. O MongoDB deixa isso para o sistema operacional usando mmap. Portanto, enquanto houver mais RAM disponível, o MongoDB carregará todos os dados necessários na RAM para tornar as consultas muito rápidas. Se não houver mais memória disponível, cabe ao sistema operacional trocar as coisas antigas. Isso tem o bom efeito de que seus dados serão mantidos na memória mesmo se você reiniciar o processo do MongoDB; somente se você reiniciar o próprio servidor, os dados devem ser recuperados do disco novamente. Acho que a desvantagem é que o processo de banco de dados pode ter uma compreensão um pouco melhor do que deve ser trocado primeiro em comparação com o sistema operacional. Não estou usando o MongoDB no Windows e não vi essa mensagem no Mac ou Linux (ainda ), mas o sistema operacional deve lidar com isso para você (e trocar automaticamente as informações conforme necessário). Você já tentou configurar o driver para JOURNAL_SAFE (deve ser um bom compromisso entre segurança de dados e velocidade)? Nessa configuração, nenhum dado deve ser perdido, mesmo que o processo do MongoDB seja interrompido.

3) Em geral, o MongoDB é construído para usar o máximo de memória disponível, mas você pode restringi-lo com http://captaincodeman.com/2011/02/27/limit-mongodb-memory-use-windows/ - que não testei, pois estamos usando servidores Linux (virtuais).