AI 助理
备案控制台
开发者社区 阿里云MVP 文章 正文

实战-Mongo优化

2020-11-04 1651
版权
版权声明：
本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《 阿里云开发者社区用户服务协议》和 《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写 侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
本文涉及的产品
云数据库 MongoDB，独享型 2核8GB
推荐场景：
构建全方位客户视图
简介： Mongo集群CPU报警，查看现象是那一小段突然有一个请求小高峰，经过分析把问题定位到一个新增的接口上，这个接口中有一个Mongo的慢查询，这个慢查询对应的相关信息有:> 1. 集合总文档数超过 6 亿条2. 按条件查询后获取的数据也有几万条3. 之前已经加了几个索引，但效果不是特别理想

背景

Mongo集群CPU报警，查看现象是那一小段突然有一个请求小高峰，经过分析把问题定位到一个新增的接口上，这个接口中有一个Mongo的慢查询，这个慢查询对应的相关信息有:

  1. 集合总文档数超过 6 亿条
  1. 按条件查询后获取的数据也有几万条
  2. 之前已经加了几个索引，但效果不是特别理想

基本信息

总数据量:

> db.zwg_log.count()
[693090136]     // 6.9亿

查看文档结构:

> db.zwg_log.find().limit(3)
{
    _id: "add6a2c545fb389a96fed19730772e24",
    source_id: "xxxx",
    user_id: "zhaoweiguo",
    is_delete: "0",
    is_read: "0",
    time_created: ISODate("2018-03-11T04:47:14.621Z"),
    time_updated: ISODate("2018-03-11T04:47:14.621Z")
    ...
},
{
    _id: "add93f066c0e3e4c07f2962884799da4",
    source_id: "xxxx",
    user_id: "zhaoweiguo",
    is_read: "0",
    is_delete: "0",
    time_created: ISODate("2017-03-29T23:40:50.485Z"),
    time_updated: ISODate("2017-03-29T23:40:50.485Z")
    ...
},

相关索引主要有:

[
    {
      v: 2,
        key: {
            source_id: 1.0,
            is_delete: 1.0,
            time_created: -1.0
        },
        name: "source_id_1.0_is_delete_1.0_time_created_-1.0"
    }
    {
        v: 2,
        key: {
            is_delete: 1.0,
            user_id: 1.0,
            time_created: -1.0
        },
        name: "is_delete_1_user_id_1_time_created_-1"
    },
    {
        v: 2,
        key: {
            source_id: 1,
            user_id: 1,
            is_delete: 1,
            is_read: 1
        },
        name: "source_id_1_user_id_1_is_delete_1_is_read_1"
    }
]

现象分析

使用默认索引

使用explain命令验证慢查询的请求，发现
默认使用的是is_delete_1_user_id_1_time_created_-1索引

执行语句:

> db.zwg_log.explain("executionStats").find({
            "source_id": "XXXXXXXX85877cc4ada3217c7dff2627e11064d8",
            "user_id": "XXXXXXXX79441a98e6952befe5db9148",
            "is_delete": "0",
            "is_read": "0"
        }).sort({"time_created":-1}).limit(3)

执行结果:

executionStages: {
    stage: "SINGLE_SHARD",
    nReturned: 3,
    executionTimeMillis: 180,
    totalKeysExamined: 22387,
    totalDocsExamined: 22387,
    totalChildMillis: NumberLong(175),
    shards: [
        {
            shardName: "d-XXXXXXXXe0a5c484",
            executionSuccess: true,
            executionStages: {
                stage: "LIMIT",
                nReturned: 3,
                executionTimeMillisEstimate: 117,
                works: 22388,
                inputStage: {
                    stage: "FETCH",
                    nReturned: 3,
                    executionTimeMillisEstimate: 117,
                    works: 22387,
                    docsExamined: 22387,
                    inputStage: {
                        stage: "IXSCAN",
                        nReturned: 22387,
                        executionTimeMillisEstimate: 12,
                        works: 22387,
                        indexName: "is_delete_1_user_id_1_time_created_-1",
                        isMultiKey: true,
                        multiKeyPaths: {
                            is_delete: [
                            ],
                            user_id: [
                                "user_id"
                            ],
                            time_created: [
                            ]
                        },
                        keysExamined: 22387,
                    }
                }
            }
        }
    ]
}

使用指定索引 source_id_1_user_id_1_is_delete_1_is_read_1

指定使用使用source_id_1_user_id_1_is_delete_1_is_read_1索引

执行语句:

> db.zwg_log.explain("executionStats").find({
            "source_id": "XXXXXXXX85877cc4ada3217c7dff2627e11064d8",
            "user_id": "XXXXXXXX79441a98e6952befe5db9148",
            "is_delete": "0",
            "is_read": "0"
        }).sort({"time_created":-1}).limit(3).hint({
            "source_id": 1,
            "user_id": 1,
            "is_delete": 1,
            "is_read": 1
        })

返回结果:

executionStages: {
    stage: "SINGLE_SHARD",
    nReturned: 3,
    executionTimeMillis: 1272,
    totalKeysExamined: 5856,
    totalDocsExamined: 5856,
    totalChildMillis: NumberLong(1263),
    shards: [
        {
            shardName: "d-XXXXXXXXe0a5c484",
            executionSuccess: false,
            executionStages: {
                stage: "SORT",
                nReturned: 0,
                executionTimeMillisEstimate: 1290,
                works: 5858,
                sortPattern: {
                    time_created: -1
                },
                memUsage: 5806,
                memLimit: 33554432,
                inputStage: {
                    stage: "SORT_KEY_GENERATOR",
                    nReturned: 5856,
                    executionTimeMillisEstimate: 1266,
                    works: 5857,
                    inputStage: {
                        stage: "FETCH",
                        nReturned: 5856,
                        executionTimeMillisEstimate: 1209,
                        works: 5856,
                        inputStage: {
                            stage: "IXSCAN",
                            nReturned: 5856,
                            executionTimeMillisEstimate: 26,
                            works: 5856,
                            indexName: "source_id_1_user_id_1_is_delete_1_is_read_1",
                            keysExamined: 5856,
                        }
                    }
                }
            }
        }
    ]
}

结论

使用索引 is_delete_1_user_id_1_time_created_-1 请求时间是180；而使用索引 source_id_1_user_id_1_is_delete_1_is_read_1的请求时间是1272ms。所以Mongo使用这个索引作为最佳索引没有问题。第2个索引时间主要消耗在排序上面了。

如果不按时间排序，则使用 source_id_1_user_id_1_is_delete_1_is_read_1 索引只需要扫描3条记录，时间会是几毫秒。参见:

> db.zwg_log.explain("executionStats").find({
            "source_id": "XXXXXXXX85877cc4ada3217c7dff2627e11064d8",
            "user_id": "XXXXXXXX79441a98e6952befe5db9148",
            "is_delete": "0",
            "is_read": "0"
        }).limit(3).hint({
            "source_id": 1,
            "user_id": 1,
            "is_delete": 1,
            "is_read": 1
        })

结果:

executionStats: {
    nReturned: 3,
    executionTimeMillis: 2,
    totalKeysExamined: 3,
    totalDocsExamined: 3,
    executionStages: {
        stage: "SINGLE_SHARD",
        nReturned: 3,
        executionTimeMillis: 2,
        totalKeysExamined: 3,
        totalDocsExamined: 3,
        totalChildMillis: NumberLong(1),
        shards: [
            {
                shardName: "d-2ze07ec75d921fa4",
                executionSuccess: true,
                executionStages: {
                    stage: "LIMIT",
                    nReturned: 3,
                    executionTimeMillisEstimate: 0,
                    limitAmount: 3,
                    inputStage: {
                        stage: "FETCH",
                        nReturned: 3,
                        executionTimeMillisEstimate: 0,
                        docsExamined: 3,
                        inputStage: {
                            stage: "IXSCAN",
                            nReturned: 3,
                            executionTimeMillisEstimate: 0,
                            works: 3,
                            indexName: "source_id_1_user_id_1_is_read_1_is_delete_1"
                        }
                    }
                }
            }
        ]
    }
}

优化

原因找到了，优化就比较容易了。

根据上面分析，优化方法就显而易见了：增加一个联合索引

db.zwg_log.createIndex({
    "source_id": 1, 
    "user_id": 1,
    "is_delete": 1, 
    "is_read": 1,
    time_created:-1
},  {background: true})

优化后，执行:

> db.zwg_log.explain("executionStats").find({
            "source_id": "XXXXXXXX85877cc4ada3217c7dff2627e11064d8",
            "user_id": "XXXXXXXX79441a98e6952befe5db9148",
            "is_delete": "0",
            "is_read": "0"
        }).sort({"time_created":-1}).limit(3)

结果如下:

executionStats: {
    nReturned: 3,
    executionTimeMillis: 2,
    totalKeysExamined: 3,
    totalDocsExamined: 3,
    executionStages: {
        stage: "SINGLE_SHARD",
        nReturned: 3,
        executionTimeMillis: 2,
        totalKeysExamined: 3,
        totalDocsExamined: 3,
        totalChildMillis: NumberLong(2),
        shards: [
            {
                shardName: "d-XXXXXXXXe0a5c484",
                executionSuccess: true,
                executionStages: {
                    stage: "LIMIT",
                    nReturned: 3,
                    executionTimeMillisEstimate: 0,
                    inputStage: {
                        stage: "FETCH",
                        filter: {
                            is_read: {
                                $eq: "0"
                            }
                        },
                        nReturned: 3,
                        executionTimeMillisEstimate: 0,
                        inputStage: {
                            stage: "IXSCAN",
                            nReturned: 3,
                            executionTimeMillisEstimate: 0,
                            keyPattern: {
                                source_id: 1,
                                user_id: 1,
                                is_delete: 1,
                                time_created: -1
                            },
                            indexName: "source_id_1_user_id_1_is_delete_1_time_created_-1",
                            isMultiKey: true,
                        }
                    }
                }
            }
        ]
    }
},

就和不排序的请求使用索引 source_id_1_user_id_1_is_delete_1_is_read_1 效果一样了。

小插曲-特殊数据可能会特别快

在优化完成后，高兴之余遇到下面这么一个奇怪的问题:

在优化完成后强制指定使用索引 is_delete_1_user_id_1_time_created_-1 时，

发现它的执行效率居然和使用新增加的索引一样，都是毫秒级
更诡异的是连文档扫描数也一样是3条

指定使用索引 is_delete_1_user_id_1_time_created_-1 :

> db.zwg_log.explain("allPlansExecution").find({
            "source_id": "XXXXXXXXdbf62d674a034e982586dcc85ecf4e78",
            "user_id": "XXXXXXXX79441a98e6952befe5db9148",
            "is_delete": "0",
            "is_read": "0"
        }).sort({"time_created":1}).limit(3).hint({
            is_delete: 1,
            user_id: 1,
            time_created: -1
        })

结果如下:

executionStages: {
    stage: "SINGLE_SHARD",
    nReturned: 3,
    executionTimeMillis: 0,
    totalKeysExamined: 3,
    totalDocsExamined: 3,
    totalChildMillis: NumberLong(0),
    shards: [
        {
            shardName: "d-XXXXXXXXe0a5c484",
            executionSuccess: true,
            executionStages: {
                stage: "LIMIT",
                nReturned: 3,
                inputStage: {
                    stage: "FETCH",
                    nReturned: 3,
                    executionTimeMillisEstimate: 0,
                    docsExamined: 3,
                    inputStage: {
                        stage: "IXSCAN",
                        nReturned: 3,
                        executionTimeMillisEstimate: 0,
                        indexName: "is_delete_1_user_id_1_time_created_-1",
                        keysExamined: 3,
                    }
                }
            }
        }
    ]
}

看到没有和前面的最优解除了使用的索引不同外，其他几乎完全一样。是什么原因造成的？是缓存吗？是query plans吗？当你对MongoDB不了解时，有很多的可能，你需要一点点排除。

query plans分析

首先不可能是query plans，因为我们使用的是指定索引。

缓存加速现象分析

是缓存造成的吗？

缓存的确能加快查询效率，但下面这种现象才真正是缓存造成的加速效果:

> db.zwg_log.explain("allPlansExecution").find({
            "source_id": "XXXXXXXX85877cc4ada3217c7dff2627e11064d8",
            "user_id": "XXXXXXXX79441a98e6952befe5db9148",
            "is_delete": "0",
            "is_read": "0"
        }).sort({"time_created":-1}).limit(3).hint({
            is_delete: 1,
            user_id: 1,
            time_created: -1
        })

第一次执行时效率如下:

executionStats: {
    nReturned: 3,
    executionTimeMillis: 1032,
    totalKeysExamined: 22387,
    totalDocsExamined: 22387,

第二次执行:

executionStats: {
    nReturned: 3,
    executionTimeMillis: 339,
    totalKeysExamined: 22387,
    totalDocsExamined: 22387,

第三次执行:

executionStats: {
    nReturned: 3,
    executionTimeMillis: 180,
    totalKeysExamined: 22387,
    totalDocsExamined: 22387,

我们看到，3次同样的执行，虽然因为缓存原因，查询速度越来越快，但文档扫描是不变的。而上面的现象文档扫描只有3次，所以排除缓存造成这么快。

真实原因

真实的原因其实是查询这个数据就是只需要扫描3条记录就能得到想要的数据，因为你下面语句执行

db.zwg_log.find({
            "user_id": "XXXXXXXX79441a98e6952befe5db9148",
            "is_delete": "0"
        }).sort({time_created:-1}).limit(3)

得到的结果是:

[
    {
        _id: "b5cd1fd5382c403292714f7ceb13e7b9",
        source_id: "XXXXXXXXdbf62d674a034e982586dcc85ecf4e78",
        user_id: "XXXXXXXX79441a98e6952befe5db9148",
        is_delete: "0",
        is_read: "0",
        ...
    },{
        _id: "518cbb3e9fb6b5c0c53e0d99ef6e0bcf",
        source_id: "XXXXXXXXdbf62d674a034e982586dcc85ecf4e78",
        user_id: "XXXXXXXX79441a98e6952befe5db9148",
        is_delete: "0",
        is_read: "0",
        ...
    },{
        _id: "c3703d2139a1b2f381eb3690678d7985",
        source_id: "XXXXXXXXdbf62d674a034e982586dcc85ecf4e78",
        user_id: "XXXXXXXX79441a98e6952befe5db9148",
        is_delete: "0",
        is_read: "0",
        ...
    }
]

前3条就完全能满足条件，所以这个查询条件下使用索引 is_delete_1_user_id_1_time_created_-1 和使用索引 source_id_1_user_id_1_is_delete_1_is_read_1_time_created_-1 效率是一样的。

使用其他数据证实

上面的原因是数据恰好合适，我使用其他 source_id 的值应该就不会这么快了吧

速度超快的文档扫描了3次:

optimize_index_zwg_log1.png

用另一个source_id文档扫描变成了2.2万次:

image.png

这种只有数据不同，其他都相同的，基本可以判断为『就是数据比较特殊，并没有代表性』

使用正序查询证实

现在再看看如果排序按时间正序，效果如何:

> db.zwg_log.explain("allPlansExecution").find({
            "source_id": "XXXXXXXXdbf62d674a034e982586dcc85ecf4e78",
            "user_id": "XXXXXXXX79441a98e6952befe5db9148",
            "is_delete": "0",
            "is_read": "0"
        }).sort({"time_created":1}).limit(3).hint({
            is_delete: 1,
            user_id: 1,
            time_created: -1
        })

结果如下:

executionStages: {
    stage: "SINGLE_SHARD",
    nReturned: 3,
    executionTimeMillis: 1141,
    totalKeysExamined: 9433,
    totalDocsExamined: 9433,
    totalChildMillis: NumberLong(1138),
    shards: [
        {
            shardName: "d-XXXXXXXXe0a5c484",
            executionSuccess: true,
            executionStages: {
                stage: "LIMIT",
                nReturned: 3,
                executionTimeMillisEstimate: 1089,
                works: 9434,
                limitAmount: 3,
                inputStage: {
                    stage: "FETCH",
                    nReturned: 3,
                    executionTimeMillisEstimate: 1089,
                    works: 9433,
                    docsExamined: 9433,
                    inputStage: {
                        stage: "IXSCAN",
                        nReturned: 9433,
                        executionTimeMillisEstimate: 47,
                        works: 9433,
                        indexName: "is_delete_1_user_id_1_time_created_-1",
                        keysExamined: 9433,
                    }
                }
            }
        }
    ]
}

好了，我们看到，只需把排序从倒序改为正序，时间就从毫秒级变成秒级。

为啥会有这种现象？为啥之前只需要扫描3条记录，现在需要扫描9433条了呢？

更深一步数据分析

> db.zwg_log.count({
            "user_id": "XXXXXXXX79441a98e6952befe5db9148",
            "is_delete": "0",
        })
[22410]   // 2.2万条
> db.zwg_log.count({
            "source_id": "XXXXXXXXdbf62d674a034e982586dcc85ecf4e78",
            "user_id": "XXXXXXXX79441a98e6952befe5db9148",
            "is_delete": "0",
            "is_read": "0"
        })
[12918]    // 1.2万条
> db.zwg_log.count({
            "source_id": "XXXXXXXX85877cc4ada3217c7dff2627e11064d8",
            "user_id": "XXXXXXXX79441a98e6952befe5db9148",
            "is_delete": "0",
            "is_read": "0"
        })
[5856]    // 5856条

这个表中有此用户相关数据是2.2万条，而满足 source_id="XXXXXXXXdbf62d674a034e982586dcc85ecf4e78" 的数据大都是最新生成的，所以按时间倒序时能快速命中，而按时间正序时，由于前面的数据都不满足 source_id="XXXXXXXXdbf62d674a034e982586dcc85ecf4e78" 这个条件，所以需要把前面的都扫描完成，才会命中所需要的数据。

如果在表 zwg_log 中按时间倒序前 12918 条数据的 source_id 都等于 XXXXXXXXdbf62d674a034e982586dcc85ecf4e78:

db.zwg_log.find({
            "user_id": "XXXXXXXX79441a98e6952befe5db9148",
            "is_delete": "0"
        }).sort({time_created:-1}).limit(12918)

那么当按时间正序使用索引 is_delete_1_user_id_1_time_created_ 查询时，需要的文档扫描数为 22410-12918+3=9495 也就是这种情况需要扫描9495条。而上面的分析文档扫描了9433次，这说明 source_id="XXXXXXXXdbf62d674a034e982586dcc85ecf4e78" 的数据并不完全是最新的 ，以上。

小插曲-排序与不排序的区别

现象

还有一个问题，如果我查询不指定排序，正常不指定的话应该使用 source_id_1_user_id_1_is_delete_1_is_read_1 索引吧，但很奇怪的是有时使用 source_id_1.0_is_delete_1.0_time_created_-1 这个索引。

db.zwg_log.find({
            "source_id": "XXXXXXXXdbf62d674a034e982586dcc85ecf4e78",
            "user_id": "XXXXXXXX79441a98e6952befe5db9148",
            "is_delete": "0",
            "is_read": "0"
        }).limit(3).explain()

怀疑是与MongoDB的查询计划(Query Plans)有关

查询计划相关知识

Mongo 自带了一个查询优化器会为我们选择最合适的查询方案:

  1. 如果一个索引能够精确匹配一个查询，那么查询优化器就会使用这个索引。
  1. 如果不能精确匹配呢？可能会有几个索引都适合你的查询，那 MongoDB 是怎样选择的呢？

MongoDB 的查询计划会将多个索引并行的去执行，最先返回第 101 个结果的就是胜者，
其他查询计划都会被终止，执行优胜的查询计划；
这个查询计划会被缓存，接下来相同的查询条件都会使用它；

缓存的查询计划在以下条件下会清空并重新评估:

集合收到 1000 次写操作

执行 reindex
添加或删除索引
mongod 进程重启

可能的原因

可能和上面一个小插曲一样，因为数据原因。

因为 user_id 与 souce_id 是一对多的关系。所以按 souce_id 查询与按 source_id + user_id 查询得到的结果相同；并且 is_read 的值都为0。 所以使用索引 source_id_1.0_is_delete_1.0_time_created_-1 和使用索引 source_id_1.0_is_delete_1.0_time_created_-1 都只需要扫描3次。

但这儿和上面说的『如果一个索引能够精确匹配一个查询，那么查询优化器就会使用这个索引。』相悖

现场如下：

1、is_read=1时，使用索引 source_id_1.0_is_delete_1.0_time_created_-1
image.png

2、is_read=0时，使用索引 source_id_1_user_id_1_is_delete_1_is_read_1
image.png

后续待研究确认……

扩展思考

这种表是否合适分片？分片后是否会提高查询效率？

我们DB是分片DB，这个文档目前还不是分片的

后续有时间会研究一下这个文档是否应该分片？分片后是否能按所想提高效率？

参考文档

文章标签：
云数据库 MongoDB 版
数据挖掘
NoSQL
索引
MongoDB
缓存
相关实践学习
MongoDB数据库入门
MongoDB数据库入门实验。
快速掌握 MongoDB 数据库
本课程主要讲解MongoDB数据库的基本知识，包括MongoDB数据库的安装、配置、服务的启动、数据的CRUD操作函数使用、MongoDB索引的使用（唯一索引、地理索引、过期索引、全文索引等）、MapReduce操作实现、用户管理、Java对MongoDB的操作支持（基于2.x驱动与3.x驱动的完全讲解）。 通过学习此课程，读者将具备MongoDB数据库的开发能力，并且能够使用MongoDB进行项目开发。   相关的阿里云产品：云数据库 MongoDB版 云数据库MongoDB版支持ReplicaSet和Sharding两种部署架构，具备安全审计，时间点备份等多项企业能力。在互联网、物联网、游戏、金融等领域被广泛采用。 云数据库MongoDB版（ApsaraDB for MongoDB）完全兼容MongoDB协议，基于飞天分布式系统和高可靠存储引擎，提供多节点高可用架构、弹性扩容、容灾、备份回滚、性能优化等解决方案。 产品详情: https://www.aliyun.com/product/mongodb
新溪
目录
相关文章
请回答1024
|
7月前
|
SQL 存储 关系型数据库
不允许你不知道的 MySQL 优化实战（三）
不允许你不知道的 MySQL 优化实战（三）
请回答1024
50 1
技术蜜糖罐
|
7月前
|
SQL 数据可视化 关系型数据库
轻松入门MySQL：深入探究MySQL的ER模型，数据库设计的利器与挑战（22）
轻松入门MySQL：深入探究MySQL的ER模型，数据库设计的利器与挑战（22）
技术蜜糖罐
698 0
请回答1024
|
7月前
|
SQL 关系型数据库 MySQL
不允许你不知道的 MySQL 优化实战（二）
不允许你不知道的 MySQL 优化实战（二）
请回答1024
49 2
技术蜜糖罐
|
6月前
|
NoSQL Shell 网络安全
MongoDB连接指南：从基础到进阶
MongoDB连接指南：从基础到进阶
技术蜜糖罐
188 1
请回答1024
|
7月前
|
SQL 关系型数据库 MySQL
不允许你不知道的 MySQL 优化实战（一）
不允许你不知道的 MySQL 优化实战（一）
请回答1024
61 2
阿兵云原生
|
存储 NoSQL MongoDB
【mongo 系列】mongodb 学习七，索引实操练习
向 mydoc 集合中，插入多条数据，mydoc 之前是没有存在过的，我们直接使用 db.mydoc.insertMany() ，mongodb 会默认给我们新建这个集合
阿兵云原生
135 0
阿兵云原生
|
存储 JSON NoSQL
【mongo 系列】mongodb 学习二，mongodb 的基本使用梳理
• 文档 是 mongodb 的最小数据集单位，是多个键值对有序租户在一起的数据单元，类似于关系型数据库的记录
阿兵云原生
265 4
阿兵云原生
|
机器学习/深度学习 分布式计算 NoSQL
【mongo 系列】mongodb 学习四，聚合知识点梳理
数据聚合（Data Aggregation）是指合并来自不同数据源的数据。. 聚类也称聚类分析，亦称为群集分析，是对于统计数据分析的一门技术， 在许多领域受到广泛应用，包括机器学习，数据挖掘，模式识别，图像分析以及生物信息。
阿兵云原生
321 4
阿兵云原生
|
存储 NoSQL MongoDB
【mongo 系列】mongodb 学习十三，内存引擎及配置
上次我们分享到了 wiredTiger 引擎以及他对于以前默认的 MMAPV1 引擎的优势 关于 wiredTiger 引擎 配置这里补充一下
阿兵云原生
342 0
阿兵云原生
|
NoSQL JavaScript 前端开发
【mongo 系列】mongodb 学习五，聚合操作实操
在 users 里面准备一组数据，包含 item ，qty，status，tags 和 size 字段，其中 size 是内嵌文档，size 里面又包含了 h，w，uom 字段
阿兵云原生
113 0

阿里云MVP

热门文章

最新文章

  • 1
    基于区块链的机器学习模型创建方案
  • 2
    阿里云服务器ECS搭建个人网站新手教程（超详细）
  • 3
    上云，你需要了解的账号管理模型
  • 4
    RDS入门——Excel文件转存到RDS数据库实践
  • 5
    优秀的代码都是如何分层的？
  • 6
    3、Python与设计模式--建造者模式
  • 7
    跟阿里云技术专家阙寒一起深度了解视频直播CDN技术
  • 8
    当人工智能遇上区块链，会发生什么？
  • 9
    力挑VMWare 红帽推新虚拟化技术
  • 10
    Ext 4 概述（七）之面板Panel & 杂项
  • 1
    【算法】——快排，分治算法合集
    33
  • 2
    【Spring】方法注解@Bean，配置类扫描路径
    104
  • 3
    【算法】栈
    30
  • 4
    【Spring】获取Bean对象需要哪些注解
    31
  • 5
    【Spring】IoC和DI，控制反转，Bean对象的获取方式
    28
  • 6
    【SpringBug】lombok插件失效，但是没有报错信息，@Data不能生成get和set方法
    29
  • 7
    【SpringMVC】应用分层
    22
  • 8
    【Spring项目】图书管理系统
    18
  • 9
    【Spring配置】idea编码格式导致注解汉字无法保存
    22
  • 10
    【算法】模拟
    19

    • 相关课程

    更多
  • MySQL实战进阶
  • RDS MySQL 高效设计及性能调优
  • Redis数据库入门
  • PostgreSQL实战进阶
  • MySQL企业常见架构与调优经验分享
  • MySQL实操课程

    • 相关电子书

    更多
  • MongoDB最佳实践及问题案例分析
  • 《玩转MongoDB 从入门到实战》
  • MySQL高并发场景实战

    • 相关实验场景

    更多
  • MySQL引擎及架构优化
  • 基于EBS部署高性能的MySQL服务
  • 云端MySQL的安装及应用
  • PolarDB MySQL HTAP：实时数据分析加速
  • RDS MySQL的SQL问题诊断与调优
  • 搭建PostgreSQL主从架构
    • 下一篇
    手把手教你白嫖阿里云服务器(免费领服务器)