1) När det gäller hållbarhet kan du berätta för MongoDB java-drivrutinen (som Morphia använder), vilken strategi du ska använda, se https://github.com/mongodb/mongo-java-driver/blob/master/src/main/com/ mongodb/WriteConcern.java#L53
. Det är helt enkelt en avvägning mellan hastighet:NONE (inte ens anslutningsproblem kommer att orsaka ett fel) upp till FSYNC_SAFE (data skrivs definitivt till disken). För interna detaljer kolla in http://www.kchodorow.com/blog/2012/10/04/how-mongodbs-journaling-works/
2) Hela din data mappas till minnet (det är därför 32-bitarsutgåvan har en storleksgräns på 2GB), men den laddas faktiskt bara när det behövs. MongoDB överlåter det till operativsystemet genom att använda mmap. Så så länge det finns mer RAM-minne tillgängligt, kommer MongoDB med glädje att ladda all data den behöver till RAM-minnet för att göra frågor mycket snabba. Om det inte finns mer minne tillgängligt är det upp till operativsystemet att byta ut gamla saker. Detta har den fina effekten att dina data kommer att lagras i minnet även om du startar om MongoDB-processen; endast om du startar om själva servern måste data hämtas från disken igen. Jag tror att nackdelen är att databasprocessen kan ha en något bättre förståelse för vad som bör bytas ut först i jämförelse med operativsystemet. Jag använder inte MongoDB på Windows och har inte sett det meddelandet på Mac eller Linux (ännu ), men operativsystemet bör hantera det åt dig (och automatiskt byta ut information efter behov). Har du testat att ställa in drivrutinen på JOURNAL_SAFE (borde vara en bra kompromiss mellan datasäkerhet och hastighet)? I den inställningen bör ingen data gå förlorad, även om MongoDB-processen dör.
3) I allmänhet är MongoDB byggd för att använda så mycket tillgängligt minne som möjligt, men du kanske kan begränsa det med http://captaincodeman.com/2011/02/27/limit-mongodb-memory-use-windows/ - som jag inte har testat, eftersom vi använder (virtuella) Linux-servrar.