MongoDB find getmore操作慢问题排查

MongoDB find getmore操作慢问题排查_第1张图片
本文来自获得《2021MongoDB技术实践与应用案例征集活动》入围案例奖作品

作者：张家侨

问题描述

本文介绍一次帮助业务排查线上查询操作慢的问题的详细过程以及解决方法。

业务在使用find().limit()命令查询数据时遇到卡顿，一次操作卡最多1分钟，问题描述如下：

db.xxx_collection.find({timetag: { $gt: 1636513802167 }, $or: [ { nto: "zhang" }, { nfrom:"zhang" } ], nid: 50, status: 0 }).sort({ timetag: 1 }).limit(200)

业务反馈：出问题的MongoDB版本为4.2.12。这个查询从慢日志来看要四五十秒，但是直接跑的话第一批返回数据很快，getmore的时候就慢了，你看下为啥会慢在getmore

从问题描述来看，直观上是getmore造成了查询卡顿，可能原因有如下：

getmore操作内核出现卡顿 -- 内核问题可能性较低

查询计划与被查询数据不匹配 -- 可能性较高

下面问题排查将从这两个主要问题点入手。

问题重现

将数据恢复到一个备用集群，然后使用业务的查询进行操作：

db.xxx_collection.find({timetag: { $gt: 1636513802167 }, $or: [ { nto: "zhang" }, { nfrom: "zhang" } ], nid: 50, status: 0 }).sort({ timetag:1 }).limit(200)

第一次查询立刻返回，当获取数据条数到102条时，出现卡顿。操作产生慢日志，发现是触发了一次getmore操作。日志输出如下：

2021-12-15T10:21:55.007+0800 I COMMAND [conn857] command xxx_db.xxx_collection appName: "MongoDB Shell" command: getMore { getMore: 1244654399487918694, collection: "xxx_collection", planSummary: IXSCAN { timetag: 1 } cursorid:1244654399487918694 keysExamined:11338296 docsExamined:11338296cursorExhausted:1 numYields:88583 nreturned:99 reslen:100170 locks:{ReplicationStateTransition: { acquireCount: { w: 88584 } }, Global: { acquireCount: { r: 88584 } }, Database: { acquireCount: { r: 88584 } }, Collection: { acquireCount: { r: 88584 } }, Mutex: { acquireCount: { r: 1 } } } storage:{ data: { bytesRead: 15442700982, timeReadingMicros: 40865619 },timeWaitingMicros: { cache: 33773 } }protocol:op_msg 65270ms

问题排查

确认是否是getmore的问题

在MongoDB中，其查询返回结果批大小默认为101。也就是说，MongoDB一次查询会找到101个结果然后一次性返回，当需要更多结果时再查找101个结果，通过getmore返回。

我们是可以通过batchSize操作来设置MongoDB一次返回的数据个数的，包括getmore操作。

如果是getmore的问题，理论上调整其batchSize并不会影响问题的出现，所以我们进行了如下调整。

将batchSize设置为150：

db.xxx_collection.find({timetag: { $gt: 1636513802167 }, $or: [ { nto: "zhang" }, { nfrom: "zhang" } ], nid: 50, status: 0 }).sort({ timetag:1 }).batchSize(150).limit(200)

第一次查询立刻返回结果，超过batchSize数据后，getmore又卡顿，问题依旧：

2021-12-15T10:25:54.781+0800 I COMMAND [conn859] command xxx_db.xxx_collection appName: "MongoDB Shell" command: getMore { getMore: 8826588127480667691, collection: "xxx_collection", batchSize: 150, planSummary: IXSCAN { timetag: 1 }cursorid:8826588127480667691 keysExamined:11338234 docsExamined:11338234cursorExhausted:1 numYields:88582 nreturned:50 reslen:50818 locks:{ReplicationStateTransition: { acquireCount: { w: 88583 } }, Global: { acquireCount: { r: 88583 } }, Database: { acquireCount: { r: 88583 } }, Collection: { acquireCount: { r: 88583 } }, Mutex: { acquireCount: { r: 1 } } } storage:{ data: { bytesRead: 16610295032, timeReadingMicros: 30201139 },timeWaitingMicros: { cache: 17084 } }protocol:op_msg 53826ms

调整为199后效果也类似，但是调整为200后，问题变为第一次查询就出现卡顿：

db.xxx_collection.find({timetag: { $gt: 1636513802167 }, $or: [ { nto: "zhang" }, { nfrom: "zhang" } ], nid: 50, status: 0 }).sort({ timetag:1 }).batchSize(200).limit(200)

相应慢日志如下：

2021-12-15T10:27:23.729+0800 I COMMAND [conn859] command xxx_db.xxx_collection appName: "MongoDB Shell" command: find { find: "xxx_collection", filter: { timetag: { $gt: 1636513802167.0 }, $or: [ { nto: "zhang" }, { nfrom: "zhang" } ], nid: 50.0, status: 0.0 }, projection: {$sortKey: { $meta: "sortKey" } }, sort: { timetag: 1.0 }, limit: 200, batchSize: 200, planSummary: IXSCAN { timetag: 1 }keysExamined:11338445 docsExamined:11338445 cursorExhausted:1 numYields:88582nreturned:200 queryHash:ECA82717 planCacheKey:AC7EC9E3 reslen:202045 locks:{ReplicationStateTransition: { acquireCount: { w: 88583 } }, Global: { acquireCount: { r: 88583 } }, Database: { acquireCount: { r: 88583 } }, Collection: { acquireCount: { r: 88583 } }, Mutex: { acquireCount: { r: 2 } } } storage:{ data: { bytesRead: 17688667726, timeReadingMicros: 14907251 },timeWaitingMicros: { cache: 11784 } }protocol:op_msg 36654ms

所以我们可以基本排除是getmore操作本身的问题。从慢操作日志我们可以看出，查询计划使用timetag索引来进行数据获取和过滤，一共遍历了1千万的数据。问题应该和数据查询计划以及数据分布有关，具体在查询进行第199～200个结果获取时发生了卡顿，且遍历timetag索引不够快。

所以我们的分析方向转为查询计划以及查询的数据上，确认是否存在问题，即查询计划不适合目标数据。

分析查询的数据分布

首先，我们需要了解业务数据的分布格式以及查询的目的，业务数据关键字段如下：

{ "nto" : , "nfrom" : , "nid" : , "timetag" : , "status" : }

从库表名以及数据格式来看，查询数据为某种消息的传递记录。

目标查询如下：

db.xxx_collection.find({timetag: { $gt: 1636513802167 }, $or: [ { nto: "zhang" }, { nfrom: "zhang" } ], nid: 50, status: 0 }).sort({ timetag:1 }).limit(200)

而查询所要做的就是要找到某人在某个时间点后，接收到或者发送的消息记录，且nid = 50 & status = 0。所以整个查询比较重要的条件就是时间timetag以及用户名。而大于某个时间点这种查询可能存在目标数据量特别大的情形，下面进行确认。

数据在timetag上的分布

mongos>db.xxx_collection.count()
538058824

由上我们可以看出，整个目标集合数据量为5亿多，数据量较大。下面针对性取出造成卡顿的第199个和第200个查询结果的timetag。

第199个结果timetag：

{ "_id" : ObjectId("618b380a82010a586b4265e6"), "timetag" : NumberLong("1636513802759") }

第200个结果timetag：

{ "_id" : ObjectId("618ce26682010a586be027f9"), "timetag" : NumberLong("1636622950801") }

以查询条件的时间点1636513802167为T0，第199个结果的时间点1636513802759为T1，第200个结果的时间点1636622950801为T2。下面以这三个时间为节点，对数据进行分段分析。

查询数据的分布

T0后总的数据量：

mongos>db.xxx_collection.find({ timetag: { $gt: 1636513802167 }}).count()
191829505

处于目标时间段的数据总量为1.9亿多，数据量比较大

T0~T1的数据量：

mongos>db.xxx_collection.find({ $and: [{timetag: {$gt: 1636513802167}}, {timetag: {$lte: 1636513802759}}]}).count()
287

T1~T2之间的数据量：

mongos>db.xxx_collection.find({ $and: [{timetag: {$gt: 1636513802759}}, {timetag: {$lt: 1636622950801}}]}).count()
11338157

T2后的数据量：

mongos>db.xxx_collection.find({timetag: {$gte: 1636622950801}}).count()
180491061

查询结果的分布

总查询结果：

mongos>db.xxx_collection.find({ timetag: { $gt: 1636513802167 }, $or: [ { nto: "zhang" }, { nfrom: "zhang" } ], nid: 50, status: 0 }).sort({ timetag:1 }).count()
428

T0~T1：

mongos>db.xxx_collection.find({ $and:[{timetag: { $gt: 1636513802167 }}, {timetag: {$lte: 1636513802759}}], $or: [ { nto: "zhang" }, { nfrom: "zhang" } ], nid: 50, status: 0 }).sort({ timetag:1 }).count()
199

T1~T2：

mongos>db.xxx_collection.find({ $and:[{timetag: { $gt: 1636513802759 }}, {timetag: {$lt: 1636622950801}}], $or: [ { nto: "zhang" }, { nfrom: "zhang" } ], nid: 50, status: 0 }).sort({ timetag:1 }).count()
0

T2后：

mongos>db.xxx_collection.find({ timetag: { $gte: 1636622950801 }, $or: [ { nto:"zhang" }, { nfrom: "zhang" } ], nid: 50, status: 0}).sort({ timetag: 1 }).count()
229

从数据以及相应结果数量的分布可以看出，查询结果主要分布在T0~T1和T2后的时间段内。T1～T2时间段内不存在符合条件的结果，有1千万不符合条件的数据存在。总结来说，结果分布在timetag字段上呈现两头分布，中间存在巨大空洞。

分析执行的查询计划

原查询计划

db.xxx_collection.find({timetag: { $gt: 1636513802167 }, $or: [ { nto: "zhang" }, { nfrom: "zhang" } ], nid: 50, status: 0 }).sort({ timetag:1 }).limit(200).explain("executionStats")

得到的查询计划：


"parsedQuery" : {
"$and" : [
{
"$or" : [
{
"nfrom" : {
"$eq" : "zhang"
}
},
{
"nto" : {
"$eq" : "zhang"
}
}
]
},
{
"nid" : {
"$eq" : 50
}
},
{
"status" : {
"$eq" : 0
}
},
{
"timetag" : {
"$gt" : 1636513802167
}
}
]
},
"winningPlan" : {
"stage" : "LIMIT",
"limitAmount" : 200,
"inputStage" : {
"stage" : "FETCH",
"filter" : {
"$and" : [
{
"$or" : [
{
"nfrom" : {
"$eq" : "zhang"
}
},
{
"nto" : {
"$eq" : "zhang"
}
}
]
},
{
"nid" : {
"$eq" : 50
}
},
{
"status" : {
"$eq" : 0
}
}
]
},
"inputStage" : {
"stage" : "IXSCAN",
"keyPattern" : {
"timetag" : 1
},
"indexName" : "timetag_1",
"isMultiKey" : false,
"multiKeyPaths" : {
"timetag" : [ ]
},
"isUnique" : false,
"isSparse" : false,
"isPartial" : false,
"indexVersion" : 2,
"direction" : "forward",
"indexBounds" : {
"timetag" : [
"(1636513802167.0, inf.0]"
]
}
}
}
}

由上面的结果我们可以看出，原查询的查询计划为利用timetag的索引进行扫描，然后逐个过滤出符合timetag条件的记录。在数据分布分析中我们知道，符合目标timetag的数据有1.9亿，而扫描这些数据将会非常慢，即使使用索引。因为getmore操作使用的cursor是原查询计划产生的，同一个查询内只会使用同一个查询计划。下面通过分段执行原查询计划来佐证扫描timetag慢。

T0～T1数据段执行原计划

使用上述查询计划查询T0~T1的数据：

"parsedQuery" : {
"$and" : [
{
"$or" : [
{
"nfrom" : {
"$eq" : "zhang"
}
},
{
"nto" : {
"$eq" : "zhang"
}
}
]
},
{
"nid" : {
"$eq" : 50
}
},
{
"status" : {
"$eq" : 0
}
},
{
"timetag" : {
"$lte" : 1636513802759
}
},
{
"timetag" : {
"$gt" : 1636513802167
}
}
]
},
"winningPlan" : {
"stage" : "LIMIT",
"limitAmount" : 200,
"inputStage" : {
"stage" : "FETCH",
"filter" : {
"$and" : [
{
"$or" : [
{
"nfrom" : {
"$eq" : "zhang"
}
},
{
"nto" : {
"$eq" : "zhang"
}
}
]
},
{
"nid" : {
"$eq" : 50
}
},
{
"status" : {
"$eq" : 0
}
}
]
},
"inputStage" : {
"stage" : "IXSCAN",
"keyPattern" : {
"timetag" : 1
},
"indexName" : "timetag_1",
"isMultiKey" : false,
"multiKeyPaths" : {
"timetag" : [ ]
},
"isUnique" : false,
"isSparse" : false,
"isPartial" : false,
"indexVersion" : 2,
"direction" : "forward",
"indexBounds" : {
"timetag" : [
"(1636513802167.0, 1636513802759.0]"
]
}
}
}
},

结果立刻得到，因为总的需要扫描的数据量只有287。

T1～T2数据段执行原计划

使用上述查询计划查询T1～T2的数据：

"parsedQuery" : {
"$and" : [
{
"$or" : [
{
"nfrom" : {
"$eq" : "zhang"
}
},
{
"nto" : {
"$eq" : "zhang"
}
}
]
},
{
"nid" : {
"$eq" : 50
}
},
{
"status" : {
"$eq" : 0
}
},
{
"timetag" : {
"$lt" : 1636622950801
}
},
{
"timetag" : {
"$gt" : 1636513802759
}
}
]
},
"winningPlan" : {
"stage" : "SORT",
"sortPattern" : {
"timetag" : 1
},
"limitAmount" : 200,
"inputStage" : {
"stage" : "SORT_KEY_GENERATOR",
"inputStage" : {
"stage" : "FETCH",
"filter" : {
"$and" : [
{
"nid" : {
"$eq" : 50
}
},
{
"status" : {
"$eq" : 0
}
}
]
},
"inputStage" : {
"stage" : "OR",
"inputStages" : [
{
"stage" : "IXSCAN",
"keyPattern" : {
"nto" : 1,
"validflag" : 1,
"timetag" : 1
},
"indexName" : "nto_1_validflag_1_timetag_1",
"isMultiKey" : false,
"multiKeyPaths" : {
"nto" : [ ],
"validflag" : [ ],
"timetag" : [ ]
},
"isUnique" : false,
"isSparse" : false,
"isPartial" : false,
"indexVersion" : 2,
"direction" : "forward",
"indexBounds" : {
"nto" : [
"[\"zhang\", \"zhang\"]"
],
"validflag" : [
"[MinKey, MaxKey]"
],
"timetag" : [
"(1636513802759.0, 1636622950801.0)"
]
}
},
{
"stage" : "IXSCAN",
"keyPattern" : {
"nfrom" : 1,
"timetag" : 1
},
"indexName" : "nfrom_1_timetag_1",
"isMultiKey" : false,
"multiKeyPaths" : {
"nfrom" : [ ],
"timetag" : [ ]
},
"isUnique" : false,
"isSparse" : false,
"isPartial" : false,
"indexVersion" : 2,
"direction" : "forward",
"indexBounds" : {
"nfrom" : [
"[\"zhang\", \"zhang\"]"
],
"timetag" : [
"(1636513802759.0, 1636622950801.0)"
]
}
}
]
}
}
}
},

查询计划变了，强制使用timetag_1索引来使用原查询计划：

mongos>db.xxx_collection.find({ $and:[{timetag: { $gt: 1636513802759 }}, {timetag:{$lt: 1636622950801}}], $or: [ { nto: "zhang" }, { nfrom:"zhang" } ], nid: 50, status: 0 }).sort({ timetag: 1}).limit(200).hint("timetag_1").explain("executionStats")

查询计划：

"parsedQuery" : {
"$and" : [
{
"$or" : [
{
"nfrom" : {
"$eq" : "zhang"
}
},
{
"nto" : {
"$eq" : "zhang"
}
}
]
},
{
"nid" : {
"$eq" : 50
}
},
{
"status" : {
"$eq" : 0
}
},
{
"timetag" : {
"$lt" : 1636622950801
}
},
{
"timetag" : {
"$gt" : 1636513802759
}
}
]
},
"winningPlan" : {
"stage" : "LIMIT",
"limitAmount" : 200,
"inputStage" : {
"stage" : "FETCH",
"filter" : {
"$and" : [
{
"$or" : [
{
"nfrom" : {
"$eq" : "zhang"
}
},
{
"nto" : {
"$eq" : "zhang"
}
}
]
},
{
"nid" : {
"$eq" : 50
}
},
{
"status" : {
"$eq" : 0
}
}
]
},
"inputStage" : {
"stage" : "IXSCAN",
"keyPattern" : {
"timetag" : 1
},
"indexName" : "timetag_1",
"isMultiKey" : false,
"multiKeyPaths" : {
"timetag" : [ ]
},
"isUnique" : false,
"isSparse" : false,
"isPartial" : false,
"indexVersion" : 2,
"direction" : "forward",
"indexBounds" : {
"timetag" : [
"(1636513802759.0, 1636622950801.0)"
]
}
}
}
},

查询耗时：

2021-12-15T11:18:43.650+0800 I COMMAND [conn913] command xxx_db.xxx_collection appName: "MongoDB Shell" command: find { find: "xxx_collection", filter: { $and: [ { timetag: { $gt: 1636513802759.0 } }, { timetag: { $lt: 1636622950801.0 } } ], $or: [ { nto: "zhang" }, { nfrom: "zhang" } ], nid: 50.0, status: 0.0 }, projection: {$sortKey: { $meta: "sortKey" } }, sort: { timetag: 1.0 }, hint: { $hint: "timetag_1" }, limit: 200, runtimeConstants: { localNow: new Date(1639538294423), clusterTime:Timestamp(1639538291, 1) },shardVersion: [ Timestamp(0, 0), ObjectId('000000000000000000000000') ], planSummary: IXSCAN {timetag: 1 } keysExamined:11338157 docsExamined:11338157 cursorExhausted:1numYields:88579 nreturned:0 reslen:386 locks:{ ReplicationStateTransition: {acquireCount: { w: 88580 } }, Global: {acquireCount: { r: 88580 } }, Database:{ acquireCount: { r: 88580 } },Collection: { acquireCount: { r: 88580 } }, Mutex: {acquireCount: { r: 2 } } } storage:{data: { bytesRead: 16223299833,timeReadingMicros: 9431804 },timeWaitingMicros: { cache: 14082 } }protocol:op_msg 29226ms

我们发现，查询T1～T2的空洞区域非常慢，耗时29秒，因为需要扫描1千万多的数据。

T2后数据段执行原计划

mongos> db.xxx_collection.find({timetag: { $gt: 1636622950801 }, $or: [ { nto: "zhang" }, { nfrom: "zhang" } ], nid: 50, status: 0 }).sort({ timetag:1 }).limit(200).explain("executionStats")

查询计划：

"parsedQuery" : {
"$and" : [
{
"$or" : [
{
"nfrom" : {
"$eq" : "zhang"
}
},
{
"nto" : {
"$eq" : "zhang"
}
}
]
},
{
"nid" : {
"$eq" : 50
}
},
{
"status" : {
"$eq" : 0
}
},
{
"timetag" : {
"$gt" : 1636622950801
}
}
]
},
"winningPlan" : {
"stage" : "SORT",
"sortPattern" : {
"timetag" : 1
},
"limitAmount" : 200,
"inputStage" : {
"stage" : "SORT_KEY_GENERATOR",
"inputStage" : {
"stage" : "FETCH",
"filter" : {
"$and" : [
{
"nid" : {
"$eq" : 50
}
},
{
"status" : {
"$eq" : 0
}
}
]
},
"inputStage" : {
"stage" : "OR",
"inputStages" : [
{
"stage" : "IXSCAN",
"keyPattern" : {
"nto" : 1,
"validflag" : 1,
"timetag" : 1
},
"indexName" : "nto_1_validflag_1_timetag_1",
"isMultiKey" : false,
"multiKeyPaths" : {
"nto" : [ ],
"validflag" : [ ],
"timetag" : [ ]
},
"isUnique" : false,
"isSparse" : false,
"isPartial" : false,
"indexVersion" : 2,
"direction" : "forward",
"indexBounds" : {
"nto" : [
"[\"zhang\", \"zhang\"]"
],
"validflag" : [
"[MinKey, MaxKey]"
],
"timetag" : [
"(1636622950801.0, inf.0]"
]
}
},
{
"stage" : "IXSCAN",
"keyPattern" : {
"nfrom" : 1,
"timetag" : 1
},
"indexName" : "nfrom_1_timetag_1",
"isMultiKey" : false,
"multiKeyPaths" : {
"nfrom" : [ ],
"timetag" : [ ]
},
"isUnique" : false,
"isSparse" : false,
"isPartial" : false,
"indexVersion" : 2,
"direction" : "forward",
"indexBounds" : {
"nfrom" : [
"[\"zhang\", \"zhang\"]"
],
"timetag" : [
"(1636622950801.0, inf.0]"
]
}
}
]
}
}
}
},

查询计划变了，强制使用timetag_1索引来使用原查询计划：

mongos>db.xxx_collection.find({ timetag: { $gt: 1636622950801 }, $or: [ { nto: "zhang" }, { nfrom: "zhang" } ], nid: 50, status: 0 }).sort({ timetag:1 }).limit(200).hint("timetag_1").explain("executionStats")

查询计划：

"parsedQuery" : {
"$and" : [
{
"$or" : [
{
"nfrom" : {
"$eq" : "zhang"
}
},
{
"nto" : {
"$eq" : "zhang"
}
}
]
},
{
"nid" : {
"$eq" : 50
}
},
{
"status" : {
"$eq" : 0
}
},
{
"timetag" : {
"$gt" : 1636622950801
}
}
]
},
"winningPlan" : {
"stage" : "LIMIT",
"limitAmount" : 200,
"inputStage" : {
"stage" : "FETCH",
"filter" : {
"$and" : [
{
"$or" : [
{
"nfrom" : {
"$eq" : "zhang"
}
},
{
"nto" : {
"$eq" : "zhang"
}
}
]
},
{
"nid" : {
"$eq" : 50
}
},
{
"status" : {
"$eq" : 0
}
}
]
},
"inputStage" : {
"stage" : "IXSCAN",
"keyPattern" : {
"timetag" : 1
},
"indexName" : "timetag_1",
"isMultiKey" : false,
"multiKeyPaths" : {
"timetag" : [ ]
},
"isUnique" : false,
"isSparse" : false,
"isPartial" : false,
"indexVersion" : 2,
"direction" : "forward",
"indexBounds" : {
"timetag" : [
"(1636622950801.0, inf.0]"
]
}
}
}
},

日志时间输出：

2021-12-15T11:36:34.388+0800 I COMMAND [conn918] command xxx_db.xxx_collection appName: "MongoDB Shell" command: explain { explain: { find: "xxx_collection", filter: { timetag: { $gt: 1636622950801.0 }, $or: [ { nto: "zhang" }, { nfrom: "zhang" } ], nid: 50.0, status: 0.0 }, sort: { timetag: 1.0 }, hint: { $hint: "timetag_1" }, limit: 200, ****** $db: "xxx_db" } numYields:1109015 reslen:2691 locks:{ReplicationStateTransition: { acquireCount: { w: 1109016 } }, Global: { acquireCount: { r: 1109016 } }, Database: { acquireCount: { r: 1109016 } }, Collection: { acquireCount: { r: 1109016 } }, Mutex: { acquireCount: { r: 2 } } } storage:{ data: { bytesRead: 195293544507, timeReadingMicros: 518472952 },timeWaitingMicros: { cache: 272870 } }protocol:op_msg 801697ms

由上面可以看出，查询T2后的数据时，需要800秒，因为需要扫描1.8亿的数据。因为原查询使用limit(200)限制了查询的总结果数，且只有一个结果在这个时间段内，所以查询找到一个结果即可返回，不需要扫描整个时间段。

问题原因总结

总结来说，问题出现原因是MongoDB给出的查询计划不符合目标数据的查询。

原查询计划为使用timetag索引来进行扫描，获取结果后再根据其他条件进行过滤。

我们发现，查询结果在timetag上分段分布，分布在timetag的两头，中间存在一大段无效数据。第1～199的结果分布在T0～T1时间段内，第200后的结果分布在T2时间段后。

如果使用原查询计划，即只使用timetag索引来扫描全表，在查询第199个后的结果时将会非常慢，因为这些结果分布在1.9亿的数据里。这也解释了第一次查询获取101个结果快，因为只需查扫描T0～T1时间段内400多个数据，第二次查询需要获取第102～202个数据则慢，因为需要先扫描1千多万的无效数据然后才能返回结果。原查询计划不够高效，导致扫描比较慢。

问题解决方案

只使用timetag索引进行数据遍历较低效，使用聚合索引来在遍历数据时进行过滤，减少遍历的数据量。所以预期要使用timetag和nfrom以及timetag和nto的联合索引来进行并行查询，最后将两个查询结果进行合并。由于MongoDB的查询优化器不能将原有的查询转化为上面预期的查询计划，所以我们需要改写查询计划，便于MongoDB的查询优化器进行识别。

将原查询：

db.xxx_collection.find({timetag: { $gt: 1636513802167 }, $or: [ { nto: "zhang" }, { nfrom: "zhang" } ], nid: 50, status: 0 }).sort({ timetag:1 }).limit(200)

转化为等价的优化查询：

db.xxx_collection.find({$or: [ {$and: [{nto: "zhang"}, {timetag: {$gt: 1636513802167}}, { nid:50}, {status: 0}]}, {$and: [{nfrom: "zhang"}, {timetag: {$gt: 1636513802167}}, { nid:50}, {status: 0}]} ] }).sort({timetag:1}).limit(200)

并在nto和timetag以及nfrom和timetag（备注：原库已经有nfrom和timetag的联合索引）上建立联合索引：

{
"v" : 2,
"key" : {
"nfrom" : 1,
"timetag" : 1
},
"name" : "nfrom_1_timetag_1",
"ns" : "xxx_db.xxx_collection"
},
{
"v" : 2,
"key" : {
"nto" : 1,
"timetag" : 1
},
"name" : "nto_1_timetag_1",
"ns" : "xxx_db.xxx_collection"
},

得到的查询计划：

"parsedQuery" : {
"$or" : [
{
"$and" : [
{
"nfrom" : {
"$eq" : "zhang"
}
},
{
"nid" : {
"$eq" : 50
}
},
{
"status" : {
"$eq" : 0
}
},
{
"timetag" : {
"$gt" : 1636513802167
}
}
]
},
{
"$and" : [
{
"nid" : {
"$eq" : 50
}
},
{
"nto" : {
"$eq" : "zhang"
}
},
{
"status" : {
"$eq" : 0
}
},
{
"timetag" : {
"$gt" : 1636513802167
}
}
]
}
]
},
"winningPlan" : {
"stage" : "SUBPLAN",
"inputStage" : {
"stage" : "LIMIT",
"limitAmount" : 200,
"inputStage" : {
"stage" : "PROJECTION_SIMPLE",
"transformBy" : {
"timetag" : 1
},
"inputStage" : {
"stage" : "SORT_MERGE",
"sortPattern" : {
"timetag" : 1
},
"inputStages" : [
{
"stage" : "FETCH",
"filter" : {
"$and" : [
{
"nid" : {
"$eq" : 50
}
},
{
"status" : {
"$eq" : 0
}
}
]
},
"inputStage" : {
"stage" : "IXSCAN",
"keyPattern" : {
"nfrom" : 1,
"timetag" : 1
},
"indexName" : "nfrom_1_timetag_1",
"isMultiKey" : false,
"multiKeyPaths" : {
"nfrom" : [ ],
"timetag" : [ ]
},
"isUnique" : false,
"isSparse" : false,
"isPartial" : false,
"indexVersion" : 2,
"direction" : "forward",
"indexBounds" : {
"nfrom" : [
"[\"zhang\", \"zhang\"]"
],
"timetag" : [
"(1636513802167.0, inf.0]"
]
}
}
},
{
"stage" : "FETCH",
"filter" : {
"$and" : [
{
"nid" : {
"$eq" : 50
}
},
{
"status" : {
"$eq" : 0
}
}
]
},
"inputStage" : {
"stage" : "IXSCAN",
"keyPattern" : {
"nto" : 1,
"timetag" : 1
},
"indexName" : "nto_1_timetag_1",
"isMultiKey" : false,
"multiKeyPaths" : {
"nto" : [ ],
"timetag" : [ ]
},
"isUnique" : false,
"isSparse" : false,
"isPartial" : false,
"indexVersion" : 2,
"direction" : "forward",
"indexBounds" : {
"nto" : [
"[\"zhang\", \"zhang\"]"
],
"timetag" : [
"(1636513802167.0, inf.0]"
]
}
}
}
]
}
}
}
},

这个查询计划符合我们的预期。

查询等价证明

上述优化的查询计划可以通过布尔等价运算得到。

原查询为：

db.xxx_collection.find({timetag: { $gt: 1636513802167 }, $or: [ { nto: "zhang" }, { nfrom: "zhang" } ], nid: 50, status: 0 }).sort({ timetag:1 }).limit(200)

我们将find的查询条件定义抽象如下：

a：timetag > 1636513802167

b：nto = "zhang"

c：nfrom = "zhang"

d：nid = 50

e：status = 0

所以原查询条件相当于一个合取范式：

$$ a \bigwedge (b \bigvee c) \bigwedge d \bigwedge e $$

通过逻辑运算，可以转化为一个析取范式：

$$ (a \bigwedge b \bigwedge d \bigwedge e) \bigvee (a \bigwedge c \bigwedge d\bigwedge e) $$

对应如下查询：

db.xxx_collection.find({$or: [ {$and: [{nto: "zhang"}, {timetag: {$gt: 1636513802167}}, { nid:50}, {status: 0}]}, {$and: [{nfrom: "zhang"}, {timetag: {$gt: 1636513802167}}, { nid:50}, {status: 0}]} ] }).sort({timetag:1}).limit(200)

查询计划等价得证

关于作者：网易游戏 张家侨

你可能感兴趣的:(mongodb)

  • MongoDB Oplog 窗口 喝醉酒的小白 MongoDB运维
    在MongoDB中，oplog（操作日志）是一个特殊的日志系统，用于记录对数据库的所有写操作。oplog允许副本集成员（通常是从节点）应用主节点上已经执行的操作，从而保持数据的一致性。它是MongoDB副本集实现数据复制的基础。MongoDBOplog窗口oplog窗口是指在MongoDB副本集中，从节点可以用来同步数据的时间范围。这个窗口通常由以下因素决定：Oplog大小：oplog的大小是有限
  • nosql数据库技术与应用知识点 皆过客，揽星河 NoSQLnosql数据库大数据数据分析数据结构非关系型数据库
    Nosql知识回顾大数据处理流程数据采集(flume、爬虫、传感器)数据存储(本门课程NoSQL所处的阶段)Hdfs、MongoDB、HBase等数据清洗(入仓)Hive等数据处理、分析(Spark、Flink等)数据可视化数据挖掘、机器学习应用(Python、SparkMLlib等)大数据时代存储的挑战(三高)高并发(同一时间很多人访问)高扩展(要求随时根据需求扩展存储)高效率(要求读写速度快)
  • MongoDB知识概括 GeorgeLin98 持久层mongodb
    MongoDB知识概括MongoDB相关概念单机部署基本常用命令索引-IndexSpirngDataMongoDB集成副本集分片集群安全认证MongoDB相关概念业务应用场景：传统的关系型数据库（如MySQL），在数据操作的“三高”需求以及应对Web2.0的网站需求面前，显得力不从心。解释：“三高”需求：①Highperformance-对数据库高并发读写的需求。②HugeStorage-对海量数
  • Mongodb Error: queryTxt ETIMEOUT xxxx.wwwdz.mongodb.net 佛一脚 errorreactmongodb数据库
    背景每天都能遇到奇怪的问题，做个记录，以便有缘人能得到帮助！换了一台电脑开发nextjs程序。需要连接mongodb数据，对数据进行增删改查。上一台电脑好好的程序，新电脑死活连不上mongodb数据库。同一套代码，没任何修改，搞得我怀疑人生了，打开浏览器进入mongodb官网毫无问题，也能进入线上系统查看数据，网络应该是没问题。于是我尝试了一下手机热点，这次代码能正常跑起来，连接数据库了！！！是不
  • springboot整合MongoDB时碰到的问题 生产队队长 DatabaseSpringAllmongodbspring
    1.账号总是不对，导致查不出数据，报错Auth…权鉴错误这次，我也是第一次接触MongoDB，非常的生疏springboot整合MongoDB，要在properties文件中配置账号mongodb基本语法：useDATABASE_NAME;--创建数据库showdbs;--查看我们所有的库，注意，我们刚创建的库，如果没有数据，是不会被显示的showusers;--查看当前库所有拥有的账号db.cr
  • java mongodb group分组使用 yank1225 mongodbjavamongodbgroup
    mongodb的关键字及介绍.mongodb的查询是有一定规则的,刚开始接触老是各种错误,参照以下内容有很多帮助https://docs.mongodb.com/manual/reference/sql-aggregation-comparison/另外出现这种错误时Apipelinestagespecificationobjectmustcontainexactlyonefield是因为条件不对
  • MongoDB Atlas与LangChain集成指南 afTFODguAKBF mongodblangchain数据库python
    引言MongoDBAtlas是一款全托管的云数据库解决方案,可在AWS、Azure和GCP上使用。最新版本支持在MongoDB文档数据上进行原生向量搜索。本文将介绍如何使用LangChain将MongoDBAtlas与语言模型集成,以实现高效的向量搜索和语义缓存。安装和设置1.安装langchain-mongodb包pipinstalllangchain-mongodb向量存储LangChain提
  • 数据库管理的利器Navicat —— 全面测评与热门产品推荐 界面开发小八哥 数据库Navicat数据库开发sqlmysql
    在数据库管理领域，Navicat无疑是一款深受欢迎的软件。作为一个强大的数据库管理和开发工具，它支持多种数据库类型，包括MySQL、MariaDB、MongoDB、SQLServer、Oracle、PostgreSQL等。本文将全面测评Navicat的核心功能，同时推荐几款热门的Navicat产品。Navicat的主要特点1.跨平台支持：Navicat支持Windows、Mac和Linux平台，可
  • MongoDB C++库编译，windows平台+VS2015（QT中也可以用） hp_cpp C++
    编译准备工作：（1）mongo-c-driver下载地址：https://github.com/mongodb/mongo-c-driver/releases下载最新版：mongo-c-driver1.12.0的Soucecode版（2）mongodb/mongo-cxx-driver下载地址：https://github.com/mongodb/mongo-cxx-driver/releases
  • 使用docker部署MongoDB数据库 数据小白的进阶之路 数据库dockermongodb
    最近由于工作需要搭建MongoDB数据库：将解析的车端采集的数据写入到数据库，由于MongoDB高可用、海量扩展、灵活数据的模型，因此选用MongoDB数据库；由于现公司只有服务器，因此考虑容器化部署MongoDB数据，特此记录一下~一、镜像拉取使用如下命令拉取最新MongoDB镜像dockerpullmongo二、创建MongoDB容器2.1创建宿主机目录执行如下代码：mkdir-p/home/
  • MongoDB数据库 weixin_34104341 数据库jsonshell
    一简介MongoDB是一款强大、灵活、且易于扩展的通用型数据库1.易用性MongoDB是一个面向文档（document-oriented）的数据库，而不是关系型数据库。不采用关系型主要是为了获得更好得扩展性。当然还有一些其他好处，与关系数据库相比，面向文档的数据库不再有“行“（row）的概念取而代之的是更为灵活的“文档”（document）模型。通过在文档中嵌入文档和数组，面向文档的方法能够仅使用
  • 【Docker】MongoDB 容器化部署 轻云UC 运维部署mongodbdocker数据库
    MongoDBdocker容器化部署MongoDB标准软件基于BitnamiMongoDB构建。当前版本未7.0.5你可以通过轻云UC部署工具直接安装部署，也可以手动按如下文档操作配置文件地址:https://gitee.com/qingplus/qingcloud-platformQinghubStudio在线体验初始化一个新实例使用Docker容器网络，应用程序容器可以轻松访问容器内运行的Mo
  • MongoDB ：第五章：MongoDB 插入更新删除查询文档 2401_84558091 作者\/mongodb数据库
    “_id”:ObjectId(“56064f89ade2f21f36b03136”),“title”:“MongoDB”,“description”:“MongoDB是一个Nosql数据库”,“by”:“菜鸟教程”,“url”:“http://www.runoob.com”,“tags”:[“mongodb”,“database”,“NoSQL”],“likes”:100}可以看到标题(title
  • 数据库有关c语言 h海棠溪 数据库学习c语言linux
    数据库的概念SQL（StructuredQueryLanguage）是一种专门用来与数据库进行交互的编程语言，它允许用户查询、更新和管理关系型数据库中的数据。关系型数据库是基于表（Table）的数据库，其中表由行（Row）和列（Column）组成，每一行代表一个记录（Record），每一列代表一个字段（Field）。非关系型数据库MongoDB1、分类：大型中型小型ORACLEMYSQL/MSSQ
  • 使用 MongoDB 构建 AI：Patronus 如何自动进行大语言模型评估来增强对生成式 AI 的信心 MongoDB 数据平台 AI应用客户案例人工智能mongodb
    大语言模型可能不可靠，这几乎算不上头条新闻。对于某些用例，这可能会带来不便。而对于其他行业，尤其是受监管行业，后果则要严重得多。于是，业内首个大语言模型自动评估平台PatronusAI应运而生。PatronusAI由MetaAI和MetaRealityLabs的机器学习专家创立，旨在增强企业对生成式AI应用程序的信心，在塑造值得信赖的AI生态方面处于领先地位。Patronus联合创始人兼首席技术官
  • MongoDB-副本集PSA架构搭建配置手册 玩亚索的小孔 MongoDBMongoDB副本集PSA
    1安装配置------------------------------------------------------------------------------------机器准备：•系统：RedHatEnterpriseLinuxServerrelease7.3(Maipo)•MongoDB版本：mongodb-linux-x86_64-rhel70-3.4.16•下载地址:http://
  • 解决方案| MongoDB PSA 架构痛点以及如何应对？ MongoDB中文社区 MongoDBmongodb架构数据库
    一.背景最近MongoDB群里面有群友遇到2次重启MongoDB后一直处于实例恢复状态(应用OPLOG)，多达几天甚至更长才完成重启，通常MongoDB副本集三个实例作为标准，重启主库会发生重新选出新主节点(通常在12s内完成)重新对外服务，通常不符合官方标准化或者内部发生异常导致的。经过了解副本集采用PSA架构且存在一个数据从节点不可达的情况(甚至有的从节点宕机几个月没有发现)，来分析这些情况以
  • MongoDB之写关注及PSA架构相关问题 吃饭端住碗 MongoDBmongodb架构数据库
    MongoDB的写关注主要指定了写入操作的确认级别。具体来讲就是客户端在向MongoDB执行比如delete、insert、update等相关写入操作时，MongoDB的写入行为，比如是否立刻刷盘、是否需要等待Secondary节点确认等。写关注说明写关注配置主要包含以下3个字段：{w:,j:,wtimeout:}w选项指定了写入操作需要等待确认的副本集成员个数。取值如下：“majority”：写
  • mongoDB 对一个做了索引的字段，要不要给默认值？ hongkid mongodb数据库
    引言在设计数据库模式时，如何处理字段的默认值是一个值得深入探讨的话题。对于MongoDB这样的NoSQL数据库来说，灵活性是其一大特点，但这同时也意味着开发者需要更加谨慎地考虑数据的一致性和完整性。本文将探讨在一个已创建索引的字段上，在插入文档时是否应该显式设置默认值的问题，并给出具体的建议。MongoDB中的索引与字段设置在MongoDB中，索引可以帮助提高查询性能，特别是在处理大规模数据集时。
  • MongoDB-聚合查询操作介绍 侯晓阳丶 MongoDBmongodb数据库linuxdba经验分享
    目录前言db.collection.aggregate()db.collection.aggregate()示例一db.collection.aggregate()示例二复杂的聚合操作通过mongoimport导入测试数据复杂的聚合操作示例聚合操作的偏好设置-project函数聚合操作的偏好设置-unwind函数前言MongoDB聚合操作相当于关系型数据库SQL语句的"groupby"、“orde
  • Docker搭建MongoDB Replica Set高可用集群+数据丢失&被黑解决+自动备份与恢复脚本+持久化慢查询记录 秋风お亦冷 运维企业实战笔录运维dockermongodb数据库
    文章目录引节点规划配置文件创建持久化目录创建并推送证书启动临时容器修改配置文件单节点参考mongod.confdocker-compose.ymlReplicaSet参考mongod.confdocker-compose.yml部署与配置部署集群配置集群验证集群增删节点增加节点删除节点查看节点常用命令重置集群备份数据关闭服务删除持久化数据启动集群配置集群验证集群创建用户验证集群用户管理权限说明创建
  • vue+jsonrpc+mongoDB文件传输解决方案（任意格式文件） weideng_san 前端java文件传输jsonrpcmongoDBvue
    环境及需求：前端采用vue；后端采用spring，但是只用到了spring的对象注入功能，未使用springweb相关功能。前后端通信采用jsonrpc，现需要在前端选中文件（格式未知，上传到后端，后端将其存储在mongoDB中）。背景：springweb可以直接使用controller接受MultipartFile对象；但是jsonrpc不能直接传输文件类型，jsonrpc是轻量级通信框架，擅长
  • mongodb 在 Windows 环境下迁移数据库的问题 Eagsen CEO 数据库mongodb
    mongodb是一款非常优秀的文档数据库，它的社区版本是免费的。但是mongodb的迁移和其他传统的关系数据库不太一样，通过官方提供的图形化的客户端工具无法备份和迁移，需要下载命令行工具进行。首先下载命令行工具：DownloadMongoDBCommandLineDatabaseTools|MongoDBWindows安装后，使用管理员身份打开cmd命令窗口，导航到安装目录的bin目录下，如果是默
  • python网络爬虫（五）——爬取天气预报 光电的一只菜鸡 pythonpython爬虫开发语言
    1.注册高德天气key  点击高德天气，然后按照开发者文档完成key注册；作为爬虫练习项目之一。从高德地图json数据接口获取天气，可以获取某省的所有城市天气，高德地图的这个接口还能获取县城的天气。其天气查询API服务地址为https://restapi.amap.com/v3/weather/weatherInfo?parameters，若要获取某城市的天气推荐2.安装MongoDB  Mong
  • Spring常用中间件 贺仙姑 spring中间件java
    1.数据库中间件（1）MySQL:常用的关系型数据库，支持JDBC和JPA。（2）PostgreSQL:功能强大的开源关系型数据库，支持复杂查询。（3）MongoDB:NoSQL数据库，适合存储非结构化数据。（4）Redis:内存数据结构存储，常用于缓存和消息队列。2.消息队列（1）RabbitMQ:开源消息代理，支持多种消息协议，适合异步处理。（2）Kafka:分布式流处理平台，适合处理大规模数
  • Node.js 数据库操作详解：构建高效的数据持久化层 Switch616 前端node.js数据库运维服务器系统架构前端框架前端
    Node.js数据库操作详解：构建高效的数据持久化层目录MongoDB使用mongoose连接MongoDB定义模型和数据验证实现CRUD操作️MySQL使用mysql或mysql2模块连接MySQL执行SQL查询处理结果和错误SQLite使用sqlite3模块连接SQLite执行SQL查询处理事务MongoDB使用mongoose连接MongoDBmongoose是一个为MongoDB提供对象数
  • MongoDB的WiredTiger存储引擎 云掣YUNCHE mongodb数据库
    作者：太阳从MongoDB3.2开始，MongoDB实例默认的存储引擎为WiredTiger，WiredTiger存储引擎具体以下几大优点：文档级并发将数据持久化到磁盘快照和checkpoint数据压缩本地数据加密一、文档级别并发1、WiredTiger使用文档级别并发，意味着在同一时间，MongoDB实例允许多个对不同文档间的写操作并发执行（复制应用oplog时同样可以做到文档级并发应用）。2、
  • mongodb中常用的运算符和正则表达式 手搓二十四种设计模式 mongodb
    在mongodb中不能>=，----$gt=----$gte<=----$lte!==----$ne例如：查询id比三大的所有记录db.students.find({id:{$gt:3}});2.逻辑运算符：$or逻辑或例如：查询年龄为十岁或九岁的数据db.students.find({$or:[{age:10},{age:9}]});$and逻辑与：例如：查询年龄大于十一岁且小于二十四的db.s
  • SpringCloud 结合 MongoTemplate 打印执行语句log kikiki1
    在调度MongoTemplate的时候，我们无法确定我们写的方法是否能发出正确的语句,这时候我们需要将语句给打印出来。springcloud使用方法在application.yml文件中增加如下配置即可logging:level:org.springframework.data.mongodb.core.MongoTemplate:DEBUG
  • 2024年Python最新Python爬虫教程-新浪微博分布式爬虫分享(2) 2401_84584682 程序员python爬虫新浪微博
    开发语言：Python2.7开发环境：64位Windows8系统，4G内存，i7-3612QM处理器。数据库：MongoDB3.2.0、Redis3.0.501（Python编辑器：Pycharm；MongoDB管理工具：MongoBooster；Redis管理工具：RedisStudio）爬虫框架使用Scrapy，使用scrapy_redis和Redis实现分布式。分布式中有一台机充当Maste
  • scala的option和some 矮蛋蛋 编程scala
    原文地址： http://blog.sina.com.cn/s/blog_68af3f090100qkt8.html 对于学习 Scala 的 Java™ 开发人员来说，对象是一个比较自然、简单的入口点。在 本系列 前几期文章中，我介绍了 Scala 中一些面向对象的编程方法，这些方法实际上与 Java 编程的区别不是很大。我还向您展示了 Scala 如何重新应用传统的面向对象概念，找到其缺点
  • NullPointerException Cb123456 androidBaseAdapter
        java.lang.NullPointerException: Attempt to invoke virtual method 'int android.view.View.getImportantForAccessibility()' on a null object reference     出现以上异常.然后就在baidu上
  • PHP使用文件和目录 天子之骄 php文件和目录读取和写入php验证文件php锁定文件
    PHP使用文件和目录 1.使用include()包含文件 (1)：使用include()从一个被包含文档返回一个值 (2)：在控制结构中使用include()   include_once()函数需要一个包含文件的路径，此外，第一次调用它的情况和include()一样，如果在脚本执行中再次对同一个文件调用，那么这个文件不会再次包含。   在php.ini文件中设置
  • SQL SELECT DISTINCT 语句 何必如此 sql
    SELECT DISTINCT 语句用于返回唯一不同的值。 SQL SELECT DISTINCT 语句 在表中，一个列可能会包含多个重复值，有时您也许希望仅仅列出不同（distinct）的值。 DISTINCT 关键词用于返回唯一不同的值。 SQL SELECT DISTINCT 语法 SELECT DISTINCT column_name,column_name F
  • java冒泡排序 3213213333332132 java冒泡排序
    package com.algorithm; /** * @Description 冒泡 * @author FuJianyong * 2015-1-22上午09:58:39 */ public class MaoPao { public static void main(String[] args) { int[] mao = {17,50,26,18,9,10
  • struts2.18 +json,struts2-json-plugin-2.1.8.1.jar配置及问题！ 7454103 DAOspringAjaxjsonqq
    struts2.18  出来有段时间了！ （貌似是 稳定版）   闲时研究下下！  貌似 sruts2 搭配 json 做 ajax 很吃香！   实践了下下！ 不当之处请绕过！ 呵呵   网上一大堆 struts2+json  不过大多的json 插件 都是 jsonplugin.34.jar   strut
  • struts2 数据标签说明 darkranger jspbeanstrutsservletScheme
    数据标签主要用于提供各种数据访问相关的功能，包括显示一个Action里的属性，以及生成国际化输出等功能 数据标签主要包括： action ：该标签用于在JSP页面中直接调用一个Action，通过指定executeResult参数，还可将该Action的处理结果包含到本页面来。 bean ：该标签用于创建一个javabean实例。如果指定了id属性，则可以将创建的javabean实例放入Sta
  • 链表.简单的链表节点构建 aijuans 编程技巧
    /*编程环境WIN-TC*/ #include "stdio.h" #include "conio.h" #define NODE(name, key_word, help) \  Node name[1]={{NULL, NULL, NULL, key_word, help}} typedef struct node {  &nbs
  • tomcat下jndi的三种配置方式 avords tomcat
    jndi(Java Naming and Directory Interface，Java命名和目录接口)是一组在Java应用中访问命名和目录服务的API。命名服务将名称和对象联系起来，使得我们可以用名称 访问对象。目录服务是一种命名服务，在这种服务里，对象不但有名称，还有属性。          tomcat配置
  • 关于敏捷的一些想法 houxinyou 敏捷
    从网上看到这样一句话：“敏捷开发的最重要目标就是：满足用户多变的需求，说白了就是最大程度的让客户满意。” 感觉表达的不太清楚。 感觉容易被人误解的地方主要在“用户多变的需求”上。 第一种多变，实际上就是没有从根本上了解了用户的需求。用户的需求实际是稳定的，只是比较多，也比较混乱，用户一般只能了解自己的那一小部分，所以没有用户能清楚的表达出整体需求。而由于各种条件的，用户表达自己那一部分时也有
  • 富养还是穷养，决定孩子的一生 bijian1013 教育人生
    是什么决定孩子未来物质能否丰盛？为什么说寒门很难出贵子，三代才能出贵族？真的是父母必须有钱，才能大概率保证孩子未来富有吗？-----作者：@李雪爱与自由 事实并非由物质决定，而是由心灵决定。一朋友富有而且修养气质很好，兄弟姐妹也都如此。她的童年时代，物质上大家都很贫乏，但妈妈总是保持生活中的美感，时不时给孩子们带回一些美好小玩意，从来不对孩子传递生活艰辛、金钱来之不易、要懂得珍惜
  • oracle 日期时间格式转化 征客丶 oracle
    oracle 系统时间有 SYSDATE 与 SYSTIMESTAMP； SYSDATE：不支持毫秒，取的是系统时间； SYSTIMESTAMP：支持毫秒，日期，时间是给时区转换的，秒和毫秒是取的系统的。 日期转字符窜： 一、不取毫秒： TO_CHAR(SYSDATE, 'YYYY-MM-DD HH24:MI:SS') 简要说明， YYYY 年 MM   月
  • 【Scala六】分析Spark源代码总结的Scala语法四 bit1129 scala
    1. apply语法   FileShuffleBlockManager中定义的类ShuffleFileGroup，定义：   private class ShuffleFileGroup(val shuffleId: Int, val fileId: Int, val files: Array[File]) { ... def apply(bucketId
  • Erlang中有意思的bug bookjovi erlang
      代码中常有一些很搞笑的bug，如下面的一行代码被调用两次（Erlang beam） commit f667e4a47b07b07ed035073b94d699ff5fe0ba9b Author: Jovi Zhang <[email protected]> Date: Fri Dec 2 16:19:22 2011 +0100 erts:
  • 移位打印10进制数转16进制-2008-08-18 ljy325 java基础
    /** * Description 移位打印10进制的16进制形式 * Creation Date 15-08-2008 9:00 * @author 卢俊宇 * @version 1.0 * */ public class PrintHex { // 备选字符 static final char di
  • 读《研磨设计模式》-代码笔记-组合模式 bylijinnan java设计模式
    声明： 本文只为方便我个人查阅和理解，详细的分析以及源代码请移步 原作者的博客http://chjavach.iteye.com/ import java.util.ArrayList; import java.util.List; abstract class Component { public abstract void printStruct(Str
  • 利用cmd命令将.class文件打包成jar chenyu19891124 cmdjar
    cmd命令打jar是如下实现： 在运行里输入cmd，利用cmd命令进入到本地的工作盘符。(如我的是D盘下的文件有此路径 D:\workspace\prpall\WEB-INF\classes) 现在是想把D:\workspace\prpall\WEB-INF\classes路径下所有的文件打包成prpall.jar。然后继续如下操作： cd D: 回车 cd workspace/prpal
  • [原创]JWFD v0.96 工作流系统二次开发包 for Eclipse 简要说明 comsci eclipse设计模式算法工作swing
                           JWFD v0.96 工作流系统二次开发包 for Eclipse 简要说明     &nb
  • SecureCRT右键粘贴的设置 daizj secureCRT右键粘贴
    一般都习惯鼠标右键自动粘贴的功能，对于SecureCRT6.7.5 ，这个功能也已经是默认配置了。 老版本的SecureCRT其实也有这个功能，只是不是默认设置，很多人不知道罢了。 菜单： Options->Global Options ...->Terminal 右边有个Mouse的选项块。 Copy on Select Paste on Right/Middle
  • Linux 软链接和硬链接 dongwei_6688 linux
    1.Linux链接概念Linux链接分两种，一种被称为硬链接（Hard Link），另一种被称为符号链接（Symbolic Link）。默认情况下，ln命令产生硬链接。 【硬连接】硬连接指通过索引节点来进行连接。在Linux的文件系统中，保存在磁盘分区中的文件不管是什么类型都给它分配一个编号，称为索引节点号(Inode Index)。在Linux中，多个文件名指向同一索引节点是存在的。一般这种连
  • DIV底部自适应 dcj3sjt126com JavaScript
    <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml&q
  • Centos6.5使用yum安装mysql——快速上手必备 dcj3sjt126com mysql
    第1步、yum安装mysql [root@stonex ~]#  yum -y install mysql-server 安装结果： Installed:     mysql-server.x86_64 0:5.1.73-3.el6_5                   &nb
  • 如何调试JDK源码 frank1234 jdk
    相信各位小伙伴们跟我一样，想通过JDK源码来学习Java，比如collections包，java.util.concurrent包。 可惜的是sun提供的jdk并不能查看运行中的局部变量，需要重新编译一下rt.jar。 下面是编译jdk的具体步骤：         1.把C:\java\jdk1.6.0_26\sr
  • Maximal Rectangle hcx2013 max
    Given a 2D binary matrix filled with 0's and 1's, find the largest rectangle containing all ones and return its area.   public class Solution { public int maximalRectangle(char[][] matrix)
  • Spring MVC测试框架详解——服务端测试 jinnianshilongnian spring mvc test
    随着RESTful Web Service的流行，测试对外的Service是否满足期望也变的必要的。从Spring 3.2开始Spring了Spring Web测试框架，如果版本低于3.2，请使用spring-test-mvc项目（合并到spring3.2中了）。   Spring MVC测试框架提供了对服务器端和客户端（基于RestTemplate的客户端）提供了支持。 &nbs
  • Linux64位操作系统（CentOS6.6）上如何编译hadoop2.4.0 liyong0802 hadoop
    一、准备编译软件   1.在官网下载jdk1.7、maven3.2.1、ant1.9.4，解压设置好环境变量就可以用。     环境变量设置如下：   （1）执行vim /etc/profile （2）在文件尾部加入: export JAVA_HOME=/home/spark/jdk1.7 export MAVEN_HOME=/ho
  • StatusBar 字体白色 pangyulei status
    [[UIApplication sharedApplication] setStatusBarStyle:UIStatusBarStyleLightContent]; /*you'll also need to set UIViewControllerBasedStatusBarAppearance to NO in the plist file if you use this method
  • 如何分析Java虚拟机死锁 sesame javathreadoracle虚拟机jdbc
    英文资料： Thread Dump and Concurrency Locks   Thread dumps are very useful for diagnosing synchronization related problems such as deadlocks on object monitors. Ctrl-\ on Solaris/Linux or Ctrl-B
  • 位运算简介及实用技巧（一）：基础篇 tw_wangzhengquan 位运算
    http://www.matrix67.com/blog/archives/263    去年年底写的关于位运算的日志是这个Blog里少数大受欢迎的文章之一，很多人都希望我能不断完善那篇文章。后来我看到了不少其它的资料，学习到了更多关于位运算的知识，有了重新整理位运算技巧的想法。从今天起我就开始写这一系列位运算讲解文章，与其说是原来那篇文章的follow-up，不如说是一个r
  • jsearch的索引文件结构 yangshangchuan 搜索引擎jsearch全文检索信息检索word分词
    jsearch是一个高性能的全文检索工具包，基于倒排索引，基于java8，类似于lucene，但更轻量级。   jsearch的索引文件结构定义如下：     1、一个词的索引由=分割的三部分组成：        第一部分是词        第二部分是这个词在多少
按字母分类： ABCDEFGHIJKLMNOPQRSTUVWXYZ其他