[smegel]

> Mongodb expects that your working set fits into RAM along with the indexes for your database.

I don't really get this. Surely any database system is going to be faster if all frequently updated/accessed pages fit into ram...what makes mongo special in this regard? Why does it degrade so badly when it has to access disk (beyond the obvious)?

[jaimebuelta]

The problem with this in MongoDB in particular I (think) is due the fact that it tries to work transparently on memory, leaving all the internals of moving things from disk to memory to the OS. Therefore, the DB be accessing disk without knowing, and being able to make any possible mitigation strategy. Maybe other DBs can deal with it in a more intelligent way, working better in degraded performance mode.

But yes, this is a problem on any DB. The moment it hits disk, performance is terrible.

[acdha]

> But yes, this is a problem on any DB. The moment it hits disk, performance is terrible.

This is an over-simplification for any mature database unless all you care about are massive, completely random read workloads[1]. RAM will obviously be faster but there's a difference between terrible and performing at the level of the underlying disk subsystem. With a decent system, commits per second should track the underlying storage array's IOPS, large read / write traffic should be capable of approaching disk bandwidth, etc.

Where things do get bad is when the database is doing more random I/O than required by the workload – if storage is fragmented, it's playing sim-MySQL and creating lots of temporary tables, etc. you will see performance which is pathologically worse. This is a bug and should be fixed.

1. If writes aren't disk I/O limited, you should expect data loss because it's lying about durability.

[rsynnott]

Some databases are relatively tolerant of indexes not all fitting in RAM, especially if the access pattern is localised within the index.