[SERVER-11763] Support online compaction of a database Created: 18/Nov/13  Updated: 06/Dec/22  Resolved: 04/Mar/19

Status: Closed
Project: Core Server
Component/s: Storage
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major - P3
Reporter: Jeffrey Yemin Assignee: Backlog - Storage Execution Team
Resolution: Done Votes: 8
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
is depended on by SERVER-11764 Support online auto compaction of a d... Closed
Assigned Teams:
Storage Execution
Participants:

 Description   

The compact command is per collection, does not reclaim space on the file system, and blocks use of the database The repairDatabase is per database, does reclaim space, and blocks use of the server. Neither run automatically, and therefore must be scheduled externally.

This is a request for compaction of an entire database that can be done without blocking use of the server or even the database, similar to the VACUUM command in Postgres. Note that compact/repairDatabase is roughly equivalent to a VACUUM FULL.



 Comments   
Comment by Sara Williamson [ 04/Mar/19 ]

WiredTiger, unlike MMAPv1, doesn't need online compact so we are closing this ticket as gone away.

Comment by Kevin J. Rice [ 04/Mar/14 ]

1. IMHO, and please correct me if I'm wrong: the above 'power of 2' allocation CANNOT fix this case entirely. Even if the data is made contiguous (and I'm doubtful this feature will entirely enable contiguous placement), it does not solve the VERY large issue of disk space usage.

2. Given a collection with records of widely varying sizes, compaction has to be an active process. Presume a collection wherein records change size regularly (and drastically) as fields are removed / updated / added-to. The only thing that can change (for a single record) the amount of padding is the compaction process. This compaction, as now, will relocate records to be contiguous with specified padding factor.

So, there are 2 issues - Contiguous Records (filling empty spaces) and Disk Space Reclamation (returning disk space to the OS). This feature should encompass BOTH issues (as Postgres does with autovacuum, and other databases do in their own way).

Comment by Eliot Horowitz (Inactive) [ 22/Nov/13 ]

Terry - have you tried using power of 2 allocation, which should eliminate fragmentation?

Generated at Thu Feb 08 03:26:42 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.