Hacker News Reader

HNHacker News

Top New Best Ask Show Jobs

Comment by wireprotocol | Hacker News Reader

Parent Full thread

wireprotocol·

> They should be doing compactions and are not.

https://jira.mongodb.org/browse/SERVER-11763

It looks like compaction is an offline process. That really puts the user between a rock and a hard place.

View on HN

In a proper production environment, you just compact each slave one at a time because you have a replica set rather than a single instance.

Of course, if you aren't replicating your business's production database, you have a whole world of problems.

Of course, if you aren't replicating your business's production database, you have a whole world of problems.

Not really. In RDBMS you can have offline backups (assuming you aren't building for high availability). I don't know if that exists for MongoDB.

Even pre-auto-vacuuming Postgres (ie, before Postgres v8) would allow you to vacuum the database while online. You had a performance hit, but there was no need to switch to a backup server or anything.

Good point, but that would make me a little nervous. What happens if the compaction takes a while and the replica gets far behind? And wouldn't the compaction time just keep getting longer and longer as data grows?

Can you repartition the data online to keep the cleanup work bounded?

> In a proper production environment, you just compact each slave one at a time because you have a replica set rather than a single instance.

That's the solution?? That sounds like a workaround in a production environment.

Yes and no. Deleting is a hard problem that many databases don't handle well. Explicitly deciding to punt the problem like this is a much better approach than allowing performance to degrade unpredictably.

Reply on news.ycombinator.com