|
|
|
|
|
|
by jaimebuelta
4572 days ago
|
|
|
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. |
|
|
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.