赶紧来学习学习~~~

芝麻开门芝麻开门

芝麻開門

学习了，学习了。  

请问下各位，假设表A里有一条记录是{"foo":{"bar":"baz"}} ,我用db.getCollection('A').aggregate([{$project:{"foo.bar":1}}]) 在shell中执行，可以得到结果，然后我在java代码里写就没有任何结果 。。

Aggregation.project("foo.bar");

回复一下，才能看里面的内容。

想看此内容，回复芝麻开门

不错的文章，学习了。

索引对于一个数据库的影响相信大家一定了解，如果一个查询命令进入到数据库中后，查询优化器没有找到合适的索引，那么数据库会进行全集合扫描(在RDBMS中也叫全表扫描)，全集合查询对于性能的影响是灾难性的。没有索引的查询就如同在词典那毫无规律的海量词汇中获得某个你想要的词汇，但这个词典是没有目录的，只能通过逐页来查找。这样的查找可能会让你耗费几个小时的时间，但如果要求你查询词汇的频率如同用户访问的频率一样的话。。。嘿嘿，我相信你一定会大喊“老子不干了！”。显然计算机不会这样喊，它一直是一个勤勤恳恳的员工，不论多么苛刻的请求他都会完成。

 

　　在MongoDB中索引的类型与RDBMS中大体一致，我们不做过多重复，我们来看一下在MongoDB中如何才能更高效的利用索引。

 1.索引越少越好

　　索引可以极大地提高查询性能，那么索引是不是越多越好？答案是否定的，并且索引并非越多越好，而是越少越好。每当你建立一个索引时，系统会为你添加一个索引表，用于索引指定的列，然而当你对已建立索引的列进行插入或修改时，数据库则需要对原来的索引表进行重新排序，重新排序的过程非常消耗性能，但应对少量的索引压力并不是很大，但如果索引的数量较多的话对于性能的影响可想而知。所以在创建索引时需要谨慎建立索引，要把每个索引的功能都要发挥到极致，也就是说在可以满足索引需求的情况下，索引的数量越少越好。

一.  隐式索引

//建立复合索引 db.test.ensureIndex({"age": 1,"no": 1,"name": 1 })

　　我们在查询时可以迅速的将age,no字段进行排序，隐式索引指的是如果我们想要排序的字段包含在已建立的复合索引中则无需重复建立索引。

db.test.find().sort("age": 1,"no": 1) db.test.find().sort("age": 1)

　　如以上两个排序查询，均可使用上面的复合索引，而不需要重新建立索引。

 

二. 翻转索引

//建立复合索引 db.test.ensureIndex({"age": 1})

　　翻转索引很好理解，就是我们在排序查询时无需考虑索引列的方向，例如这个例子中我们在查询时可以将排序条件写为"{'age': 0}"，依旧不会影响性能。

 

2.索引列颗粒越小越好

　　什么叫颗粒越小越好？在索引列中每个数据的重复数量称为颗粒，也叫作索引的基数。如果数据的颗粒过大，索引就无法发挥该有的性能。例如，我们拥有一个"age"列索引，如果在"age"列中，30岁占了40%，如果现在要查询一个30岁，名叫"Tom"的人，我们则需要在表的40%的数据中查询，索引的作用大大降低。所以，我们在建立索引时要尽量将数据颗粒小的列放在索引左侧，以保证索引发挥最大的作用。

时隔一年回复这个帖子，我遇到和题主同样的问题，只是你的是脚本循环执行mongoimport，我的是循环执行mongorestore。导入的备份文件大小有25G左右，一共2500左右个库，我的mongo是个docker环境，有8G内存和32Gswap，数据盘500G，cpu够用。情况是这样的，开始导入很快，导入1000个库左右会慢下来，这时候发现mongo开始使用swap，随着时间的推移，swap占用越多，数据导入越慢。后来导入结束后，我看系统日志发现一个很有意思的事情。
如图所示，导入结束后，mongo才开始清理lock，并且此时swap占用开始慢慢降低，降得比较慢。
所以我猜想，我脚本中虽然是执行完一个mongorestore并且进行了一些其他的判断后才开始执行下一个，但这次执行mongorestore所占用的资源并没有完全释放，例如lock，其他资源占用暂时不知道怎么查看。所以造成内存占用过高，swap占用过高，从而引发出来的一些其他问题

看一看看一看看一看

11111111111111111

查看後半部分，謝謝！

正在学习mongodb

之前在使用SQL时，我们经常会使用到Len()函数来返回文本字段中值的长度。那Mongodb是否有这样的操作呢，在version 3.4增加了此功能$strLenCP 如：有一个客户购买商品信息集合orderdetail

{"_id": ObjectId("5821757bf28fbb3e3516eeaa"), "memid" : "f5869354", "orderno" : "s00023","productno":"20206539", "comment"："这个平底锅太好用了，性价比高"，"telephone" :"18385669845"} {"_id": ObjectId("5821776ff28fbb3e3516eeab"), "memid" : "daisy", "orderno" : "s04567", "productno":"20225699","address"："comment"，"衣服穿起来很舒服好评" :"18855448645"} {"_id": ObjectId("5821829ef28fbb3e3516eeac"), "memid" : "lucy", "orderno" : "s08795", "productno":"20256339","address"："comment"，"还行" :"13869669585"} {"_id": ObjectId("582182b0f28fbb3e3516eead"), "memid" : "c5633256", "orderno" : "s45689","productno":"20285639","address"："comment"，"不好用，不建议买" :"13699869588"}

我们想统计客户评论信息的长度,操作如下：

db.orderdetail.aggregate( [ { $project: { "_id":0, "orderno": 1, "productno":1, "comlength": { $strLenCP: "$comment" } } } ] ) {"orderno" : "s00023", "productno":"20206539", "comlength":14} {"orderno" : "s04567", "productno":"20225699", "comlength":10} {"orderno" : "s08795", "productno":"20256339", "comlength":2} {"orderno" : "s45689", "productno":"20285639", "comlength":8}

这样就可以得出长度，也可以通过这个length继续后面的分析

比如说想看看评论长度大于10的商品

db.orderdetail.aggregate( [ { $project: { "_id":0, "orderno": 1, "productno":1, "comlength": { $strLenCP: "$comment" } } }， { $match:{comlength:{$gt:10}} } ] ) {"orderno" : "s00023", "productno":"20206539", "comlength":14}

需要注意一点的是$strLenCP和$strLenBytes功能相近，但是在统计字符的时候有区别

$strLenByte会区分字符类型，比如：汉字会默认为3个字节，特殊字符如€为3个字节，λ为2个字节，é也为2个字节

当然想要实现上述功能，还可以通过$where来实现，但是多数情况下都避免使用$where查询，比常规查询慢很多，每个文档都要从BSON转换成JavaScript对象，然后通过$where表达式来运行，而且不能使用索引。这样看来通过管道操作来实现会是不错的选择。

@Jerry 審核沒問題，請通知 @pennyhung  將此文檔放到教學區，謝謝!

方法一：通过 oplog 恢复

如果部署的是 MongoDB 复制集，这时还有一线希望，可以通过 oplog 来尽可能的恢复数据；MongoDB 复制集的每一条修改操作都会记录一条 oplog，所以当数据库被误删后，可以通过重放现有的oplog来「尽可能的恢复数据」。前不久遇到的一个用户，运气非常好，数据库是最近才创建的，所有的操作都还保留在oplog里，所以用户通过oplog把所有误删的数据都找回了。

通过 oplog 恢复数据的流程非常简单，只需要把oplog集合通过mongodump导出，然后通过mongorestore 的 oplogReplay 模式重放一下。

Step1: 导出 oplog 集合 mongodump -d local -c oplog.rs -d -o backupdir Step2: 拷贝oplog集合的数据 mkdir new_backupdir cp backupdir/local/oplog.rs.bson new_backupdir/oplog.bson Step3: 重放oplog mongorestore --oplogReplay new_backupdir 方法二：通过备份集恢复

如果对 MongoDB 做了全量备份 + 增量备份，那么可以通过备份集及来恢复数据。备份可以是多种形式，比如

通过 mongodump 等工具，对数据库产生的逻辑备份拷贝 dbpath 目录产生的物理备份文件系统、卷管理等产生的快照等

从这里其实也可以看出一个问题，就是「部署了多节点的复制集，为什么还需要做数据备份？」；遇到误删数据库这种问题，dropDatabase 命令也会同步到所有的备节点，导致所有节点的数据都被删除。

看看 学习学习  提高提高

一、概述

DB的性能调优也是很重要的部分，我们熟知的Oracle、SQLServer是可以通过查看执行计划后来进行调优，

同样我们的MongoDB也可以，当然除了查看执行计划，还有其他调优的方法，让我们一起来看一下吧

二、MongoDB性能调优

1、查看执行执行

使用explain()函数来查看分析是否用来全表扫描，是否使用索引，返回查询数据所用时间等信息来判断是否需要优化

这个在之前的分享的文章中已经有提到，详情可看回之前的文章，这里我们简单说一下

MongoDB Enterprise > db.test1.find().explain("executionStats") { "queryPlanner" : { "plannerVersion" : 1, "namespace" : "test.test1", "indexFilterSet" : false, "parsedQuery" : { "$and" : [ ] }, "winningPlan" : { "stage" : "COLLSCAN", "filter" : { "$and" : [ ] }, "direction" : "forward" }, "rejectedPlans" : [ ] }, "executionStats" : { "executionSuccess" : true, "nReturned" : 1, "executionTimeMillis" : 0, "totalKeysExamined" : 0, "totalDocsExamined" : 1, "executionStages" : { "stage" : "COLLSCAN", "filter" : { "$and" : [ ] }, "nReturned" : 1, "executionTimeMillisEstimate" : 0, "works" : 3, "advanced" : 1, "needTime" : 1, "needYield" : 0, "saveState" : 0, "restoreState" : 0, "isEOF" : 1, "invalidates" : 0, "direction" : "forward", "docsExamined" : 1 } }, "serverInfo" : { "host" : "mongotest1", "port" : 27017, "version" : "3.2.8", "gitVersion" : "ed70e33130c977bda0024c125b56d159573dbaf0" }, "ok" : 1 }

从上面返回的一些参数我们可以看出

"executionTimeMillis" : 0,执行所用时间0

"stage" : "COLLSCAN",全表扫描

"indexFilterSet" : false, 没有使用索引

再根据返回的这些信息从添加索引或者修改查询方式等去优化。

2、profiling

a.查看是否开启这功能

MongoDB Enterprise > db.getProfilingLevel() 0

返回的值有0、1、2三种情况：

0 ：表示不开启 1 ：表示记录慢命令 (默认是100ms，这个默认值是可以修改的) 2 ：表示记录所有命令

 b.设置

MongoDB Enterprise > db.setProfilingLevel(1,10); { "was" : 1, "slowms" : 10, "ok" : 1 } MongoDB Enterprise > db.getProfilingLevel(); 1

显然我们已经设置为1，也同时把默认值100改为10

当然这里有一点需要注意的是

MongoDB Enterprise > db.setProfilingLevel(0,10); { "was" : 1, "slowms" : 10, "ok" : 1 } MongoDB Enterprise > db.getProfilingLevel(); 0

我们设置的是0，但是后面带有修改默认值10，这里表示的是Log档会记录时间>10ms的语句

还有就是开启profiling功能跟很多数据库监控一样也是会消耗系统资源，所以要根据实际情况再使用。

三、总结

对于海量数据的查询，我们调优的方式经常会加添加索引，或者调整一些相关的SQL语法，但是这些都是暂时解决问题的办法，

最根本的解决还是要从最先的数据库设计开始，所以在设计搭建数据库架构的时候，要先做好各种方案的评估才是数据库优化的

重点所在。

一、概述

   MongoDB中的explain()函数可以帮助我们查看查询相关的信息，查询分析可以确保我们创建的索引是否有效，是查询语句性能分析的重要工具。

二、explain()基本用法

explain()的用法是必须放在最后面，语法如下：

db.collecton.find({x:1}).explain()

explain()常用是直接跟在find()函数后面，表示查看find()函数的执行计划，举例：

MongoDB Enterprise mongos> db.emp.find({"id":{$lt:1000}}).explain() { "queryPlanner" : { serverInfo" : { "host" : "mongotest1", "port" : 27021, "version" : "3.2.8", "gitVersion" : "ed70e33130c977bda0024c125b56d159573dbaf0" }, "plannerVersion" : 1, "namespace" : "testdb.emp", "indexFilterSet" : false, "parsedQuery" : { "id" : { "$lt" : 1000 } }, winningPlan" : { "stage" : "FETCH", "inputStage" : { "stage" : "SHARDING_FILTER", "inputStage" : { "stage" : "IXSCAN", "keyPattern" : { "id" : 1 }, "indexName" : "id_1", "direction" : "forward", }， "rejectedPlans" : [ ] }, "ok" : 1 }

参数说明：

以上我们看到的是explain()默认参数的情况，其实MongoDB 3.0之后，explain的返回与使用方法与之前版本有了很大的变化，

3.0+版本的explain有三种模式，分别是：queryPlanner、executionStats、allPlansExecution。常用的是queryPlanner和executionStats模式

那我们再来看看executionStats这种模式

MongoDB Enterprise mongos> db.emp.find({"id":{$lt:1000}}).explain("executionStats") { "queryPlanner" : { "mongosPlannerVersion" : 1, "winningPlan" : { "stage" : "SHARD_MERGE", }， "rejectedPlans" : [ ] }, "executionStats" : { "nReturned" : 999, "executionTimeMillis" : 35, "totalKeysExamined" : 999, "totalDocsExamined" : 999, "executionStages" : { "stage" : "SHARD_MERGE", "nReturned" : 999, "executionTimeMillis" : 35, "totalKeysExamined" : 999, "totalDocsExamined" : 999, "totalChildMillis" : NumberLong(33), "shards" : [ { "shardName" : "shard1", "executionSuccess" : true, "executionStages" : { "stage" : "FETCH", "nReturned" : 980, "executionTimeMillisEstimate" : 30, "works" : 981, "advanced" : 980, "needTime" : 0, "needYield" : 0, "saveState" : 7, "restoreState" : 7, "isEOF" : 1, "invalidates" : 0, "docsExamined" : 980, "alreadyHasObj" : 0 }, "ok" : 1 }

executionStats的参数说明：

在此看来，executionStats这种模式比默认的queryPlanner给出来个更多的可参考的信息，

另外一种模式allPlansExecution是用来获取所有执行计划，参数基本与以上的相同，这里就不再详细说明。

三、总结

原来explain()也是可以接收不同的参数，通过设置不同参数我们可以查看更详细的查询计划。

queryPlanner：查询计划的选择器，首先进行查询分析，最终选择一个winningPlan，是explain返回的默认模式

executionStats：为执行统计模式，返回winningPlan的统计结果

allPlansExecution：为返回所有执行计划的统计，包括rejectedPlan

所以：我们在查询优化的时候，只需要关注queryPlanner， executionStats即可，因为queryPlanner为我们选择出了winningPlan， 而executionStats为我们统计了winningPlan的所有关键数据。

整体来说，通过explain()查看执行计划，分析查询性能情况，可以帮助我们更好的分析和优化，必要的时候可以创建索引，提升查询性能。