Liút

最近在尝试将一部分数据切换到（不是替换哦）MongoDB，由于MongoDB支持非常强大的查询操作，给相关的业务模块带来了极大的操作便利，再配合模块更新方法的同步或异步操作以实现数据一致性，这或许会改变未来业务模块的结构设计方向。

以下记录一些使用过程中总结的经验和感受：

=关于固定尺寸（指存储大小）的表（Capped Collections）

固定尺寸的表有更高的操作性能，但只适合特定的数据，不常修改的且定期淘汰的数据，如日志等

固定尺寸表的特性：

• 新插入的数据如果达到容量限制，会把最旧的（也即最先插入的）替换掉
• 可以修改数据（条目），但是，但是——为了这个我只能放弃使用它——更新的数据不可以增大（就是比原数据字节长），除非不修改
• 在32系统下固定尺寸最大只能到10亿字节（不到1G）；在64位系统上则取决于硬盘空间；当然了，推荐用64位系统
• 如果要改变固定大小，只能整个表(Collection)删除(drop掉)，然后重建

=关于索引

大多数在MySQL、PostgreSQL等关系数据库下的索引优化经验也适于MongoDB

• 为了最大化性能，要根据实际查询设置索引
• 如果你的表有个字段叫status，可能的值是0和1，这个字段单独健个索引对查询帮助不大，甚至是白占空间，建议将它和别的字段一起做联合索引
• 多和explain分析查询，其他关系数据库也是这个原则
• 争取做到每个查询都正好仅有一个索引满足它
• 如果数据更新很频繁，最好少建索引

=其他建议和唠叨

• 用实际的主键重命名为 _id 以替换 MongoDB 内部的主键
• 字段的名称也占用每条记录的存储空间，所以，尽量用较短的字段名
• PHP下的pecl-mongo扩展，里面的多数写方法，都有个safe选项，建议添加并设为true，这样在发生错误时会抛出异常，方便后端处理

更多资料参考： MongoDB 手册