分享 | MongoDb优化指南

从性能优化的角度来看，集合的设计我们需要考虑的是集合中数据的常用操作，例如我们需要设计一个日志（log）集合，日志的查看频率不高，但写入频率却很高，那么我们就可以得到这个集合中常用的操作是更新（增删改）。如果我们要保存的是城市列表呢？显而易见，这个集合是一个查看频率很高，但写入频率很低的集合，那么常用的操作就是查询。

对于频繁更新和频繁查询的集合，我们最需要关注的重点是他们的范式化程度，在上篇范式化与反范式化的介绍中我们了解到，范式化与反范式化的合理运用对于性能的提高至关重要。然而这种设计的使用非常灵活，假设现在我们需要存储一篇图书及其作者，在MongoDB中的关联就可以体现为以下几种形式：

1、完全分离（范式化设计）

示例1：

{  
     "_id" : ObjectId("5124b5d86041c7dca81917"),  
     "title" : "如何使用MongoDB",   
      "author" : [   
               ObjectId("144b5d83041c7dca84416"),  
              ObjectId("144b5d83041c7dca84418"),  
              ObjectId("144b5d83041c7dca84420"),  
     ]  
 } 

我们将作者(comment) 的id数组作为一个字段添加到了图书中去。这样的设计方式是在非关系型数据库中常用的，也就是我们所说的范式化设计。在MongoDB中我们将与主键没有直接关系的图书单独提取到另一个集合，用存储主键的方式进行关联查询。当我们要查询文章和评论时需要先查询到所需的文章，再从文章中获取评论id，最后用获得的完整的文章及其评论。在这种情况下查询性能显然是不理想的。但当某位作者的信息需要修改时，范式化的维护优势就凸显出来了，我们无需考虑此作者关联的图书，直接进行修改此作者的字段即可。

2、完全内嵌（反范式化设计）

示例2：

{  
       "_id" : ObjectId("5124b5d86041c7dca81917"),  
       "title" : "如何使用MongoDB",  
       "author" : [  
                {  
                     "name" : "丁磊"  
                     "age" : 40,  
                     "nationality" : "china",  
                },  
                { 
 
                     "name" : "马云"  
                     "age" : 49,  
                     "nationality" : "china",  
                },  
                {  
                     "name" : "张召忠"  
                     "age" : 59,  
                     "nationality" : "china",  
                },  
      ]  
  } 

（编辑：常州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!