[SERVER-6847] one file per table (or files per table) Created: 24/Aug/12 Updated: 06/Dec/22 Resolved: 12/Apr/17 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Internal Code |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | New Feature | Priority: | Major - P3 |
| Reporter: | mark nielsen | Assignee: | Backlog - Storage Execution Team |
| Resolution: | Done | Votes: | 2 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
any |
||
| Assigned Teams: |
Storage Execution
|
| Backwards Compatibility: | Fully Compatible |
| Participants: |
| Description |
|
Currently, we have one set of files for a database. Operations on one table should not affect the other in a database. So, a little history. For MySQL, one-file-per-table was resisted a lot until it finally got pushed in, and it made a BIG difference. You could reclaim diskspace for a specific table without having to reload your entire database to free up the diskspace. one-file-per-table as a huge benefit to operations. Something like this for Mongo would be great. The other solution is to do one table per database, but practically that just isn't going to happen and programmers don't think like that. |
| Comments |
| Comment by Eric Milkie [ 12/Apr/17 ] |
|
The default storage engine, WiredTiger, now has one file per collection (or rather, multiple files per collection and associated indexes). |