前一段时间使用repair命令修复线上的数据库，发现数据库中碎片巨大，占用200多G的数据在repair之后只有50多G，然后就研究了一下Mongodb是如何利用已经删除了的空间的。
分析下源码（源码版本2.2.2,新版本可能随时更新）：
Mongodb在执行删除（文档）操作时，并不会进行物理删除，而是将他们放入每个命名空间维护的删除列表里。
1. //pdfile.cpp delete()
2. /* add to the free list */
3. {
4. ....
5. d->addDeletedRec((DeletedRecord*)todelete, dl);
6. }
7. }
8.
9.
10.
11.
12. //namespace_detail.cpp addDeletedRec(..)
13. ....
14. else {
15. int b = bucket(d->lengthWithHeaders());
16. & list = deletedList[b];
17. = list;
18. ().writingDiskLoc(list) = dloc;
19. ->nextDeleted() = oldHead;
20. }
上面的deletedList就是维护的删除数据列表。
1. //namespace_detail.h
2. /* deleted lists -- linked lists of deleted records -- are placed in 'buckets' of various sizes so you can look for a deleterecord about the rightsize.
3. */
4. const int Buckets = 19;
5. const int MaxBucket = 18;
6. [Buckets];
7. int bucketSizes[] = { 32, 64, 128, 256, 0x200, 0x400, 0x800, 0x1000, 0x2000, 0x4000, 0x8000, 0x10000, 0x20000, 0x40000, 0x80000, 0x100000, 0x200000,0x400000, 0x800000};
可以看到，deleteList数组实际保存的是DiskLoc，长度19，跟bucketSizes[]的长度一致。DiskLoc就是文档在磁盘上的位置，并且有后指针，可以指向下一个DiskLoc，从而组成一个列表。deleteList中实际就保存了19个列表，每个列表就是已经被删除文档地址，且这些文档都在bucketSizes所规定的的范围内。描述不太清楚，上图吧：
插入文档时，Mongodb会先计算需要开辟多大的空间，然后去找deleteList中的位置，如果deleteList中不满足,那么才会去开辟新的空间。
1. //pdfile.cpp
2. int lenWHdr = d->getRecordAllocationSize( len + Record::HeaderSize );
3. DiskLoc loc;
4. if( addID || tableToIndex || d->isCapped() ) {
5. // if need id, we don't do the early indexing. this is not the common case so that is sort of ok
6. = false;
7. = allocateSpaceForANewRecord(ns, d, lenWHdr, god);
8. }
9. else {
10. loc = d->allocWillBeAt(ns, lenWHdr);
11. if( loc.isNull() ) {
12. // need to get a new extent so we have to do the true alloc now (not common case)
13. = false;
14. = allocateSpaceForANewRecord(ns, d, lenWHdr, god);
15. }
16. }
我们暂时不讨论cappedCollection(固定大小的集合)，只看常规集合
1. /* predetermine location of the next alloc without actually doing it.
2. if cannot predetermine returns null (so still call alloc() then)
3. */
4. ::allocWillBeAt(const char *ns, int lenToAlloc) {
5. if ( ! isCapped() ) {
6. = (lenToAlloc + 3) & 0xfffffffc;
7. return __stdAlloc(lenToAlloc, true);
8. }
9. ();
10. }
11.
12. /* for non-capped collections.
13. and don't reserve
14. is
15. */
16. ::__stdAlloc(int len, bool peekOnly) {
17. *prev;
18. *bestprev = 0;
19. ;
20. int bestmatchlen = 0x7fffffff;
21. int b = bucket(len);
22. DiskLoc cur = deletedList[b];
23. = &deletedList[b];
24. int extra = 5; // look for a better fit, a little.
25. int chain = 0;
26. while ( 1 ) {
27. {
28. int a = cur.a();
29. if ( a < -1 || a >= 100000 ) {
30. () << "~~ Assertion - cur out of range in _alloc() " <<
31.
32. cur.toString() <<
33. " a:" << a << " b:" << b << " chain:" << chain << '\n';
34. ();
35. if ( cur == *prev )
36. ->Null();
37. .Null();
38. }
39. }
40. if ( cur.isNull() ) {
41. // move to next bucket. if we were doing "extra",
42. if ( bestmatchlen < 0x7fffffff )
43. ;
44. ++;
45. if ( b > MaxBucket ) {
46. // out of space. alloc a new extent.
47. ();
48. }
49. = deletedList[b];
50. = &deletedList[b];
51. ;
52. }
53. DeletedRecord *r = cur.drec();
54. if ( r->lengthWithHeaders() >= len &&
55. ->lengthWithHeaders() < bestmatchlen ) {
56. = r->lengthWithHeaders();
57. = cur;
58. = prev;
59. }
60. if ( bestmatchlen < 0x7fffffff && --extra <= 0 )
61. ;
62. if ( ++chain > 30 && b < MaxBucket ) {
63. // too slow, force move to next bucket to
64. //b++;
65. = 0;
66. .Null();
67. }
68. else {
69. /*this defensive check only made sense for the mmap storage engine:
70. if ( r->nextDeleted.getOfs() == 0 ) {
71. () << "~~ Assertion - bad nextDeleted " << r->nextDeleted.toString()
72.
73. <<
74. " b:" << b << " chain:" << chain << ", fixing.\n";
75. ->nextDeleted.Null();
76. }*/
77. = r->nextDeleted();
78. = &r->nextDeleted();
79. }
80. }
81.
82. /* unlink ourself from the deleted list */
83. if( !peekOnly ) {
84. *bmr = bestmatch.drec();
85. *getDur().writing(bestprev) = bmr->nextDeleted();
86. ->nextDeleted().writing().setInvalid(); // defensive.
87. (bmr->extentOfs() < bestmatch.getOfs());
88. }
89.
90. ;
91. }
上面这段就是Mongodb在deleteList中寻找合适插入位置的算法.
1. int b = bucket(len);
2. DiskLoc cur = deletedList[b];
这是最初始的寻找位置的算法，解释一下，bucket函数就是寻找跟len（插入文档的大小）最接近的bucketSize，比如说len=68，那么应该在64-128这个范围内，在deleteList中应该是第3个列表，那么b=2,cur就是返回的第三个列表的起始位置。如果找到了，那么就是用列表中的值，如果找不到，就继续往下一个列表中寻找。找到之后，将找到的位置从deleteList中删除，返回。
如果所有的列表都遍历完成还是找不到，那么mongodb就会去硬盘上真的开辟一段空间。我们上面说过Mongodb会先计算需要开辟的空间大小，有两种方式
1. //namespace_detail.cpp
2. int NamespaceDetails::getRecordAllocationSize( int minRecordSize ) {
3. if ( _paddingFactor == 0 ) {
4. () << "implicit updgrade of paddingFactor of very old collection" << endl;
5. setPaddingFactor(1.0);
6. }
7. ( _paddingFactor >= 1 );
8.
9.
10. if ( isUserFlagSet( Flag_UsePowerOf2Sizes ) ) {
11. int allocationSize = bucketSizes[ bucket( minRecordSize ) ];
12. if ( allocationSize < minRecordSize ) {
13. // if we get here, it means we're allocating more than 8mb
14. // the highest bucket is 8mb, so the above code will never return more than 8mb for allocationSize
15. // if this happens, we are going to round up to
16. ( 16439, bucket( minRecordSize ) == MaxBucket );
17. = 1 + ( minRecordSize | ( ( 1 << 20 ) - 1 ) );
18. }
19. ;
20. }
21.
22. <int>(minRecordSize * _paddingFactor);
23. }
第一种padding方式，Mongodb会计算一个_paddingFactor，开辟doclen*(1+paddingFactor)大小，以防止update引起的长度变大，需要移动数据。第二种方式usePowerOf2Size，Mongodb为文档开辟的空间总是2的倍数，如之前我们说过的，文档大小68字节，那么就会开辟128字节，bucket函数就是从bucketSize数组中寻找最接近文档长度的那个2的次方值。
1. //namespace_detail.cpp
2. int bucketSizes[] = {
3. , 64, 128, 256, 0x200, 0x400, 0x800, 0x1000, 0x2000, 0x4000,
4. , 0x10000, 0x20000, 0x40000, 0x80000, 0x100000, 0x200000,
5. ,
6. };
这两种方式各有优劣，padding方式会为文档开辟更合适的大小，而且paddingFactor比较小，一般为0.01-0.09，不会浪费空间，文档更新小的话也不会移动文档位置。但是当大量更新和删除的时候，这种方式重复利用空间的能力就比较小，因为在deleteList中，不太容易找到合适的已删除文档，而且一旦更新就会又移动位置，磁盘重复利用率低，增长快，碎片多。相比之下，usePowerOf2Size方式，Mongodb每次都会开辟比文档大的多的空间，使用空间变多，但是更新和删除的容错率就会比较高，因为在deleteList列表中更容易找到合适的删除文档（每个列表中的文档大小都是相同的固定的），更新的时候也不会大量移动位置，磁盘重复利用率高，增长慢。
所以，在读操作较多的应用中，可以使用padding方式，也是mongodb默认的方式，在写操作较多的应用中，可以使用usePowerOf2Size方式。
usePowerOf2Size是在创建集合的时候指定的
db.runCommand( {collMod: "products", usePowerOf2Sizes : true }) //enable
db.runCommand( {collMod: "products", usePowerOf2Sizes : false })//disable
usePowerOf2Size只影响新插入和更新引起的分配空间大小，对之前的文档不起作用。
