972
mongodb续
索引性能的分析
索引的建立对于数据库性能有什么影响？ 建立索引有没有什么原则？
我们了解了索引的原理之后知道，查询的时候，如果查询条件不依赖主见，如果不建立索引就会引发全表扫描，如果数据量比较大时，全表扫描根本不可行，建立索引可以直接加快检索速度，IO 也呈指数即下降，那sh那是不是索引建的越多就愈好尼，也不尽然，因为查询期间索引表需要load到内存中，索引也不是越多越好，数据量比较大时，索引也会占去相当一本分内存，，而且索引应该建立在一些不经常更新并且数据重复量比较少的字段上，如果这个字经常更新，其对应的索引也需要更新，这个消耗比较高，还有就是如果这个字段在数据库的cho就是如果这个字段的数据在数据库的重复率较高的话，建立索引的意义就没有那么大了，比如查找age=20的结果非常多，这样的效率跟全表扫描不相上下，，还有就是有时候复合索引建立，如果我们要在age和name上建立索引，只需建立两个字段的复合索引，复合索引表中结点是有两个字段组成，不用单个在两个字段上都建立索引，便可以实现高效chaxu便可以实现高效查询，
性能优化问题：
现在假设有book和user两个集合，book和user的关系是一对多的关系，在mongodb，我们用嵌套的方式来biaosh嵌套的方式来表示这种关系，这样查询起来就非常方便，不用关联，，但是如果业务需求需要经常use但是如果业务需求需要经常更新user集合的age字段，这会产生怎么样的问题尼，，
不仅要修改user集合的age字段，也要去book扫描所有嵌套的文档将age属性改掉，这样的话，更新的效率是非常低的
如果 age对于book表不是必须的，我们可以在book的嵌套字段里面把age剔出，这样只需要更新user集合，往往查询效率和写的效率是冲突的，如何处理好这种关联关系很值得我们去思考和学习，所以说嵌套文档的处理适合那些数据比较稳定持久的字段，如果这个字段需要经常更新，就需要去考虑如何设计好这种关系结构。
填充因子的问题
我们知道mongodb数据的存储结构是顺序表的形式存储在磁盘上，也就是说每一个文档在物理位置上是相邻的，现在我们可以思考一个问题，如果说现存的某一个文档的字段值发生了变化，占用的存储空间增大，，这时原来存储这个字段的扇区空间b空间不够用了，必然导致这个文档往后所有的文档都向后移动，了解顺序表的都知道，顺序表最大的缺点jiush顺序表最大的缺点就是元素的移动，这种操作的性能消耗是巨大的，所以在存储文档时就应该为文档预留相应的冗余空间，防止文档的大量移动，，我们这里提到的填充因子就是为文档扩展提供的预留空间，
这里有两种解决方案
1增加初始分配空间。在集合的属性中包含一个 usePowerOf2Sizes 属性，当这个选项为true时，系统会将后续插入的文档，初始空间都分配为2的N次方。这种分配机制适用于一个数据会频繁变更的集合使用，他会给每个文档留有更大的空间，但因此空间的分配不会像原来那样高效，如果你的集合在更新时不会频繁的出现移动现象，这种分配方式会导致写入速度相对变慢。
2.我们可以利用数据强行将初始分配空间扩大。
是的，这样看起来可能不太优雅…但有时却很有效！当我们对这个文档进行增长式修改时，只要将stuff字段删掉即可。当然，这个stuff字段随便你怎么起名，包括里边的填充字符当然也是可以随意添加的。
最后更新：2017-08-21 17:32:38