1) Jeśli chodzi o trwałość, możesz określić sterownik java MongoDB (którego używa Morphia), której strategii użyć, patrz https://github.com/mongodb/mongo-java-driver/blob/master/src/main/com/ mongodb/WriteConcern.java#L53
. To po prostu kompromis między szybkością:NONE (nawet problemy z łącznością nie spowodują błędu) do FSYNC_SAFE (dane są zdecydowanie zapisywane na dysku). Aby uzyskać szczegółowe informacje wewnętrzne, sprawdź http://www.kchodorow.com/blog/2012/10/04/how-mongodbs-journaling-works/
2) Twoje całe dane są mapowane do pamięci (dlatego wersja 32-bitowa ma limit rozmiaru 2 GB), jednak są one faktycznie ładowane tylko wtedy, gdy jest to wymagane. MongoDB pozostawia to systemowi operacyjnemu za pomocą mmap. Tak długo, jak dostępna jest większa ilość pamięci RAM, MongoDB z radością załaduje wszystkie potrzebne dane do pamięci RAM, aby bardzo szybko wykonać zapytania. Jeśli nie ma więcej dostępnej pamięci, system operacyjny musi wymienić stare elementy. Daje to miły efekt, że twoje dane będą przechowywane w pamięci, nawet jeśli zrestartujesz proces MongoDB; dopiero po ponownym uruchomieniu samego serwera dane muszą zostać ponownie pobrane z dysku. Myślę, że wadą jest to, że proces bazy danych może mieć nieco lepsze zrozumienie tego, co należy najpierw zamienić w porównaniu z systemem operacyjnym. Nie używam MongoDB w systemie Windows i nie widziałem tego komunikatu na Macu lub Linuksie (jeszcze ), ale system operacyjny powinien to za Ciebie obsłużyć (i automatycznie zamienić fragmenty informacji zgodnie z wymaganiami). Czy próbowałeś ustawić sterownik na JOURNAL_SAFE? (powinien być dobrym kompromisem między bezpieczeństwem danych a szybkością)? W takim ustawieniu żadne dane nie powinny zostać utracone, nawet jeśli proces MongoDB umrze.
3) Ogólnie MongoDB jest zbudowany tak, aby wykorzystywać jak najwięcej dostępnej pamięci, ale możesz ją ograniczyć za pomocą http://captaincodeman.com/2011/02/27/limit-mongodb-memory-use-windows/ - którego nie testowałem, ponieważ używamy (wirtualnych) serwerów Linux.
