1) По отношение на издръжливостта, можете да кажете на драйвера на MongoDB Java (който Morphia използва), коя стратегия да използвате, вижте https://github.com/mongodb/mongo-java-driver/blob/master/src/main/com/ mongodb/WriteConcern.java#L53
. Това е просто компромис между скорост:NONE (дори проблемите със свързването няма да причинят грешка) до FSYNC_SAFE (данните определено се записват на диск). За вътрешни подробности вижте http://www.kchodorow.com/blog/2012/10/04/how-mongodbs-journaling-works/
2) Всичките ви данни се картографират в паметта (ето защо 32-битовото издание има ограничение на размера от 2 GB), но те се зареждат действително само когато е необходимо. MongoDB оставя това на операционната система, като използва mmap. Така че, докато има повече налична RAM, MongoDB с радост ще зареди всички необходими данни в RAM, за да прави заявките много бързи. Ако няма повече налична памет, зависи от операционната система да размени старите неща. Това има хубавия ефект, че вашите данни ще бъдат запазени в паметта, дори ако рестартирате процеса MongoDB; само ако рестартирате самия сървър, данните трябва да бъдат извлечени от диска отново. Мисля, че недостатъкът е, че процесът на базата данни може да има малко по-добро разбиране за това какво трябва да бъде заменено първо в сравнение с операционната система. Не използвам MongoDB на Windows и не съм виждал това съобщение на Mac или Linux (все още ), но операционната система трябва да се справи с това вместо вас (и автоматично да разменя части от информация, ако е необходимо). Опитахте ли да настроите драйвера на JOURNAL_SAFE (трябва да е добър компромис между сигурността на данните и скоростта)? При тази настройка не трябва да се губят данни, дори ако процесът MongoDB умре.
3) Като цяло MongoDB е създаден да използва възможно най-много налична памет, но може да сте в състояние да я ограничите с http://captaincodeman.com/2011/02/27/limit-mongodb-memory-use-windows/ - което не съм тествал, тъй като използваме (виртуални) Linux сървъри.
