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