今天到了公司打开邮箱，惊喜地发现有MongoDB的新闻信，打开一看竟然是2.0更新了，哈哈，于是迫不急待地开始尝试，因为我平时主要只维护数据库，并不涉及开发部分，所有理解有限，大部分还是以翻译为主。以下为官方文档地址：http://www.mongodb.org/display/DOCS/2.0+Release+Notes?mkt_tok=3RkMMJWWfF9wsRonv6TPZKXonjHpfsX%2B6eopWKag38431UFwdcjKPmjr1YICRMt0dvycMRAVFZl5nV0IHeWb#2.0ReleaseNotes-Journalingenhancements
Compact Command整理命令
事实上我也不知道到底应该将这个命令翻译成什么比较合适，它的作用是整理collection,将其中的内容全部抽出后重新排列整齐，有点类似系统的磁盘整理，所以我就这么叫它了。在2.0版本之前，需要进行类似的操作，要使用整理命令是以collection为单位进行操作的。使用这个命令的方法有两种：
- db.runCommand({compact:'myCollcetionName'})
- db.mycollction.runCommand("compact")
这个命令要等完成后才会返回状态，可以通过mongod的log文件来查看过程纪录，或是在另一个mongo实例中通过命令db.currentOp() 远程查看正在进行整理的collection的在内存中的状态。需要特别注意的是，在运行这个命令时是无法进行其它操作的，所以推荐在Replica Sets中使用。同时，在Replica Sets中使用时，也有一些要注意的是：
- 对于Replica Sets中的Primary instance,直接运行这个命令会报错，需要使用force:true作参数来强制运行，所以并不建议在Primary上运行。
- 对于Replica Sets中的Secondary instance,开始运行这个命令时，该instance会自动降为"recovery"状态，直到命令完成。
- 在整个Replica Set中，需要在每上instance上分别进行Compact操作，这种整理的行为并不会自动同步。
官方文档上提供的说明是进行 Compact操作带来的明显效果是能去掉了数据库中所有的Padding Factor，Padding Factor是Mongo为了提高数据操作的效率而预留的一部分磁盘空间，所以说其实Compact功能并不完全适合需要经常进行数据更新的 Collection,但是对于比较稳定不常进行update操作的数据库来说，还是可以提高查询速度的。
另外在杀掉Compact进程时要特别注意的，Compact操作是将所有的内容从一个Collection中取出，最后再将它们在collection中重建，所以中断这个Compact 会带来数据丢失。此时就需要Journal来减少这种损失了。Journal在1.9+时就作为一个重点的测试功能出现了，因为考虑到它还不稳定，我没敢在实际项目中试用它，只作了一些小测试，2.0中它已经是正式出道了，我会好好地疼爱它的= v =，以上内容基本上取自官方文档，我会在随后附上实际实验。
