云数据库mongodb(mongodb使用场景是什么)

各位老铁们，大家好，今天由我来为大家分享云数据库mongodb，以及mongodb使用场景是什么的相关问题知识，希望对大家有所帮助。如果可以帮助到大家，还望关注收藏下本站，您的支持是我们最大的动力，谢谢大家了哈，下面我们开始吧！

mongodb使用场景是什么

使用场景：

（1）网站数据：MongoDB适合实时的插入，更新与查询，并具备网站实时数据存储所需的复制及高度伸缩性。

（2）缓存：由于性能很高，MongoDB也适合作为信息基础设施的缓存层。在系统重启之后，由MongoDB搭建的持久化缓存层可以避免下层的数据源过载。

（3）大尺寸，低价值的数据。

（4）高伸缩性的场景：MongoDB适合由数十或数百台服务器组成的数据库。

（5）用于对象及JSON数据的存储：MongoDB的BSON数据格式适合文档化格式的存储及查询。

mongodb设计特点：

（1）面向集合存储，容易存储对象类型的数据。在MongoDB中数据被分组存储在集合中，集合类似RDBMS中的表，一个集合中可以存储无限多的文档。

（2）模式自由，采用无模式结构存储。在MongoDB中集合中存储的数据是无模式的文档，采用无模式存储数据是集合区别于RDBMS中的表的一个重要特征。

（3）支持完全索引，可以在任意属性上建立索引，包含内部对象。MongoDB的索引和RDBMS的索引基本一样，可以在指定属性、内部对象上创建索引以提高查询的速度。除此之外，MongoDB还提供创建基于地理空间的索引的能力。

（4）支持查询。MongoDB支持丰富的查询操作，MongoDB几乎支持SQL中的大部分查询。

（5）强大的聚合工具。MongoDB除了提供丰富的查询功能外，还提供强大的聚合工具，如count、group等，支持使用MapReduce完成复杂的聚合任务。

云数据库和云存储有什么区别呢

云数据库和云存储的区别：

一、从服务层面来说

这两者都可以做为PaaS服务暴露给用户，云数据库可以包括关系型数据库以及非关系型数据库等，而云存储则可以包含块存储(BlockStorage)以及对象存储(Object Storage)等。

二、从数据的结构来说

一般云存储上存储的都是用户上传的比较零散的文件，每个文件的类型和组织的方式可以不一致，比如图片，音频，word文件之类的，而数据库中存储中的数据都由数据库进程来直接管理，包括表空间，表结构以及数据存储的方式，是有规则的。

三、从提供的服务来说

云存储:提供存储能力，更多面对的场景是非结构化类数据，如文件，图片，视频等。

云数据库：提供基础的数据库和数据对象管理能力，既包括oracle，mysql，sql server等关系型数据库，也可以包括类似mongodb, hbase等半结构化数据库。

四、从两者的关系来说

对于云存储当前基本都基于类似hdfs分布式文件系统进行封装，提供存储服务能力接口。也可以基于hdfs，上面再架构一层，形成一个数据库，再将数据库能力暴露出去，形成云数据库。

类似hbase，但是对于常见的关系型数据库,可以做为云数据库，但是他们底层不不是依赖的云存储能力。

扩展资料：

云存储的主要用途：

云存储通常意味着把主数据或备份数据放到企业外部不确定的存储池里，而不是放到本地数据中心或专用远程站点。支持者们认为，如果使用云存储服务，企业机构就能节省投资费用，简化复杂的设置和管理任务，把数据放在云中还便于从更多的地方访问数据。

数据备份、归档和灾难恢复是云存储可能的三个用途。

减少工作和费用是预计云服务在接下来几年会持续增长的一个主要原因。据研究公司IDC声称，全球IT开支当中有4%用于云服务;到2012年，这个比例会达到9%。

由于成本和空间方面的压力，数据存储非常适合使用云解决方案;IDC预测，在这同一期间，云存储在云服务开支中的比重会从8%增加到13%。

参考资料来源：百度百科-云存储

百度百科-云数据库

云上MongoDB常见索引问题及最优索引规则大全

本文干货较多，建议收藏学习。先将文章结构速览奉上：

一、背景

二、MongoDB执行计划

2.1 queryPlanner信息

2.2 executionStats信息

2.3 allPlansExecution信息

三、云上用户建索引常见问题及优化方法

3.1等值类查询常见问题及优化方法

3.1.1同一类查询创建多个索引问题

3.1.2多字段等值查询组合索引顺序非最优

3.1.3最左原则包含关系引起的重复索引

3.1.4唯一字段和其他字段组合引起的无用重复索引

3.2非等值类查询常见问题及优化方法

3.2.1非等值组合查询索引不合理创建

3.2.2等值+非等值组合查询索引字段顺序不合理

3.2.3不同类型非等值查询优先级问题

3.3 OR类查询常见问题及优化方法

3.3.1普通OR类查询优化方法

3.3.2复杂OR类查询优化方法

3.4 SORT类排序查询常见问题及优化方法

3.4.1单字段正反序排序查询引起的重复索引

3.4.2多字段排序查询正反序问题引起索引无效

3.4.3等值查询+多字段排序组合查询

3.4.4等值查询+非等值查询+SORT排序查询

3.4.5 OR+SORT组合排序查询

3.5无用索引优化方法

四、MongoDB不同类型查询最优索引总结

腾讯云MongoDB当前已服务于游戏、电商、社交、教育、新闻资讯、金融、物联网、软件服务、汽车出行、音视频等多个行业。

腾讯MongoDB团队在配合用户分析问题过程中，发现云上用户存在如下索引共性问题，主要集中在如下方面：

本文重点分析总结腾讯云上用户索引创建不合理相关的问题，通过本文可以学习到MongoDB的以下知识点：

本文总结的《最优索引规则创建大全》不仅仅适用于MongoDB，很多规则同样适用于MySQL等关系型数据库。

判断索引选择及不同索引执行家伙信息可以通过explain操作获取， MongoDB通过explain来获取SQL执行过程信息，当前持续explain的请求命令包含以下几种：

aggregate, count, distinct, find, findAndModify, delete, mapReduce, and update。

详见explain官网链接：

https://docs.MongoDB.com/manual/reference/command/explain/

explain可以携带以下几个参数信息，各参数信息功能如下：

2.1 queryPlanner信息

获取MongoDB查询优化器选择的最优索引和拒绝掉的非最优索引，并给出各个候选索引的执行阶段信息，queryPlanner输出信息如下：

queryPlanner输出主要包括如下信息：

parsedQuery信息

内核对查询条件进行序列化，生成一棵expression tree信息，便于候选索引查询匹配。

winningPlan信息

rejectedPlans信息

输出信息和winningPlan类似，记录这些拒绝掉索引的执行stage信息。

2.2 executionStats信息

explain的executionStats参数除了提供上面的queryPlanner信息外，还提供了最优索引的执行过程信息，如下：

上面是通过executionStats获取执行过程的详细信息，其中字段信息较多，平时分析索引问题最常用的几个字段如下：

executionStats输出字段较多，其他字段将在后续《MongoDB内核index索引模块实现原理》中进行进一步说明。

在实际分析索引问题是否最优的时候，主要查看以下三个统计项：

executionStats.totalKeysExamined

executionStats.totalDocsExamined

executionStats.nReturned

如果存在以下情况则说明索引存在问题，可能索引不是最优的：

1. executionStats.totalKeysExamine远大于executionStats.nReturned

2. executionStats. totalDocsExamined远大于executionStats.nReturned

2.3 allPlansExecution信息

allPlansExecution参数对应输出信息和executionStats输出信息类似，只是多了所有候选索引(包括reject拒绝的非最优索引)的执行过程，这里不再详述。

2.4总结

从上面的几个explain执行计划参数输出信息可以看出，各个参数的功能各不相同，总结如下：

queryPlanner

输出索引的候选索引，包括最优索引及其执行stage过程(winningPlan)+其他非最优候选索引及其执行stage过程。

注意： queryPlanner没有真正在表中执行整个SQL，只做了查询优化器获取候选索引过程，因此可以很快返回。

executionStats

相比queryPlanner参数，executionStats会记录查询优化器根据所选最优索引执行SQL的整个过程信息，会真正执行整个SQL。

allPlansExecution

和executionStats类似，只是多了所有候选索引的执行过程。

在和用户一起优化腾讯云上MongoDB集群索引过程中，以及和头部用户的交流中发现很多用户对如何创建最优索引有较为严重的错误认识，并且很多是绝大部分用户的共性问题，因此在本文中将这些问题汇总如下：

3.1等值类查询常见问题及优化方法

如下三个查询：

用户创建了如下3个索引：

{a:1, b:1, c:1}

{b:1, a:1, c:1}

{c:1, a:1, b:1}

实际上这3个查询属于同一类查询，只是查询字段顺序不一样，因此只需创建任一个索引即可满足要求。验证过程如下：

从上面的expalin输出可以看出，3个查询都走向了同一个索引。

例如test表有多条数据，每条数据有3个字段，分别为a、b、c。其中a字段有10种取值，b字段有100种取值，c字段有1000种取值，称为各个字段值的“区分度”。

用户查询条件为db.test.find({"a":"xxx","b":"xxx","c":"xxx"})，创建的索引为{a:1, b:1, c:1}。如果只是针对这个查询，该查询可以创建a，b，c三字段的任意组合，并且其SQL执行代价一样，通过hint强制走不通索引，验证过程如下：

从上面的执行计划可以看出，多字段等值查询各个字段的组合顺序对应执行计划代价一样。绝大部分用户在创建索引的时候，都是直接按照查询字段索引组合对应字段。

但是，单就这一个查询，这里有个不成文的建议，把区分度更高的字段放在组合索引左边，区分度低的字段放到右边。这样做有个好处，数据库组合索引遵从最左原则，就是当其他查询里面带有区分度最高的字段时，就可以快速排除掉更多不满足条件的数据。

例如用户有如下两个查询：

用户创建了如下两个索引：

{b:1, c:1}

{a:1,b:1,c:1}

这两个查询中，查询2中包含有查询1中的字段，因此可以用一个索引来满足这两个查询要求，按照最左原则，查询1字段放左边即可，该索引可以优化为：b,c字段索引+a字段索引，b,c字段顺序可以根据区分排序，加上c字段区分度比b高，则这两个查询可以合并为一个{c:1, b:1, a:1}。两个查询可以走同一个索引验证过程如下：

从上面输出可以看出，这两个查询都走了同一个索引。

例如用户有以下两个查询：

用户为这两个查询创建了两个索引，{a:1, b:1}和{a:1, c:1}，但是a字段取值是唯一的，因此这两个查询中a以外的字段无用，一个{a:1}索引即可满足要求。

3.2非等值类查询常见索引错误创建方法及如何创建最优索引

假设用户有如下查询：

a,c两个字段都是非等值查询，很多用户直接添加了{a:1, c:1}索引，实际上多个字段的非等值查询，只有最左边的字段才能走索引，例如这里只会走a字段索引，验证过程如下：

从上面执行计划可以看出，索引数据扫描了10行(也就是a字段满足a:{$gte:1}条件的数据多少)，但是实际上只返回了4条满足{a:{$gte:1}, c:{$lte:1}}条件的数据，可以看出c字段无法做索引。

同理，当查询中包含多个字段的范围查询的适合，除了最左边第一个字段可以走索引，其他字段都无法走索引。因此，上面例子中的查询候选索引为{a:1}或者{b:1}中任何一个就可以了，组合索引中字段太多会占用更多存储成本、同时占用更多IO资源引起写放大。

例如下面查询：

如上查询，d字段为非等值查询，e字段为等值查询，很多用户遇到该类查询直接创建了{d:1, e:1}索引，由于d字段为非等值查询，因此e字段无法走索引，验证过程如下：

从上面验证过程可以看出，等值类和非等值类组合查询对应组合索引，最优索引应该优先把等值查询放到左边，上面查询对应最优索引{e:1, d:1}

前面用到的非等值查询操作符只提到了比较类操作符，实际上非等值查询还有其他操作符。常用非等值查询包括：$gt、$gte、$lt、$lte、$in、$nin、$ne、$exists、$type等，这些非等值查询在绝大部分情况下存在如下优先级：

从上到下优先级更高，例如下面的查询：

如上，该查询等值部分查询最优索引{a:1, b:1}(假设a区分度比b高)；非等值部分，因为$in操作符优先级最高，排他性更好，加上多个字段非等值查询只会有一个字段走索引，因此非等值部分最优索引为{g:1}。

最终该查询最优索引为：”等值部分最优索引”与”非等值部分最优索引”拼接，也就是{a:1,b:1, g:1}

3.3 OR类查询常见索引错误创建方法及如何创建最优索引

例如下面的OR查询：

该查询很多用户直接创建了{b:1, d:1, c:1, a:1}，用户创建该索引后，发现用户还是全表扫描。

OR类查询需要给数组中每个查询添加索引，例如上面or数组中实际包含{ b: 0, d:0}和{"c":1,"a":{$gte:4}}查询，需要创建两个查询的最优索引，也就是{b:1, d:1}和{c:1, a:1}，执行计划验证过程如下(该测试表总共10条数据)：

从上面执行计划可以看出，如果该OR类查询走{b:1, d:1, c:1, a:1}索引，则实际上做了全表扫描。如果同时创建{b:1, d:1}、{c:1, a:1}索引，则直接走两个索引，其执行key和doc扫描行数远远小于全表扫描。

这里在提升一下OR查询难度，例如下面的查询：

上面的查询可以转换为如下两个查询：

如上图，查询1拆分后的两个查询2和查询3组成or关系，因此对应最优索引需要创建两个，分表是：{f:1, g:1, b:1, d:1}和{f:1, g:1, b:1, d:1}。对应执行计划如下：

同理，不管怎么增加难度，OR查询最终可转换为多个等值、非等值或者等值与非等值组合类查询，通过如上变换最终可以起到举一反三的作用。

说明：这个例子中可能在一些特殊数据分布场景，最优索引也可能是{f:1, g:1}或者{f:1, g:1, b:1, d:-1}或者{ f:1, g:1, c:1, a:1}，这里我们只考虑大部分通用场景。

3.4 SORT类排序查询常见索引错误创建方法及如何创建最优索引

例如用户有以下两个查询：

这两个查询都不带条件，排序方式不一样，因此很多创建了两个索引{a:1}和{a:-1}，实际上这两个索引中的任何一个都可以满足两种查询要求，验证过程如下：

假设有如下查询：

其中a字段为正序，b字段为反序排序，很多用户直接创建{a:1, b:1}索引，这时候b字段内容就存在内存排序情况。多字段排序索引，如果没有携带查询条件，则最优索引即为排序字段对应索引，这里切记保持每个字段得正反序和sort完全一致，否则可能存在部分字段内存排序的情况，执行计划验证过程如下：

例如如下查询：

该类查询很多人直接创建{a:1, b:1, c:1, d:1}，结果造成内存排序。这种组合查询最优索引=“多字段等值查询最优索引_多字段排序类组合最优索引”，例如该查询：

{"a": 3,"b": 1}等值查询假设a区分度比b高，则对应最优索引为：{a：1, b：1}

{ c:-1, d:1}排序类查询最优索引保持正反序一致，也就是:{ c:-1, d:1}

因此整个查询就是这两个查询对应最优索引拼接，也就是{a:1, b:1, c:-1, d:1}，对应执行计划过程验证如下：

假设有下面的查询：

腾讯云很多用户看到该查询直接创建{a:1, b:1, c:1, d:-1, e:1}索引，发现存在内存排序。等值+非等值+sort排序组合查询，由于非等值查询右边的字段不能走索引，因此如果把d, e放到c的右边，则d，e字段索引无效。

等值+非等值+sort排序最优索引组合字段顺序为：等值_sort排序_非等值，因此上面查询最优索引为:{a:1, b:1, d:-1, e:1, c:1}。执行计划验证过程如下：

例如如下查询：

上面组合很多人直接创建{b:1, d:1, c:1, a:1, e:1}，该索引创建后还是会扫表和内存排序，实际上OR+SORT组合查询可以转换为下面两个查询：

所以这个复杂查询就可以拆分为等值组合查询+sort排序查询，拆分为上面的两个查询，这样我们只需要同时创建查询2和查询3对应最优索引即可。该查询最终拆分后对应最优索引需要添加如下两个：

{b:1, d:1, e:-1}和{c:1, a:1, e:-1}

非最优索引和最优索引执行计划验证过程如下：

OR+SORT类查询，最终可以《参考前面的OR类查询常见索引错误创建方法》把OR查询转换为多个等值、非等值或者等值与非等值组合查询，然后与sort排序对应索引字段拼接。例如下面查询：

拆分后的两个查询组成or关系，如下：

如上，查询1= or: [查询2，查询3]，因此只需要创建查询2和查询3两个最优索引即可满足查询1要求，查询2和查询3最优索引可以参考前面《or类查询常见索引错误创建方法》，该查询最终需要创建如下两个索引：

{f:1, g:1, b:1, d:1, e:-1}和{ f:1, g:1, c:1, a:1, e:-1}

说明：这个例子中可能在一些特殊数据分布场景，最优索引也可能是{f:1, g:1}或者{f:1, g:1, b:1, d:1, e:-1}或者{ f:1, g:1, c:1, a:1, e:-1}，这里我们只考虑通用场景。

3.5避免创建太多无用索引及无用索引分析方法

在腾讯云上，我们还发现另外一个问题，很多实例存在大量无用索引，无用索引会引起以下问题：

存储成本增加

没增加一个索引，MongoDB内核就会创建一个index索引文件，记录该表的索引数据，造成存储成本增加。

影响写性能

用户没写入一条数据，就会在对应索引生成一条索引KV，实现索引与数据的一一对应，索引KV数据写入Index索引文件过程加剧写入负载。

影响读性能

MongoDB内核查询优化器原理是通过候选索引快速定位到满足条件的数据，然后采样评分。如果满足条件的候选索引越多，整个评分过程就会越长，增加内核选择最优索引的流程。

下面以一个真实线上实例为例，说明如何找出无用索引：

MongoDB默认提供有索引统计命令来获取各个索引命中的次数，该命令如下：

该聚合输出中的几个核心指标信息如下表：

上表中的ops代表命中次数，如果命中次数为0或者很小，说明该索引很少被选为最优索引使用，因此可以认为是无用索引，可以考虑删除。

说明：

本文总结的《最优索引规则大全》中的规则适用于绝大部分查询场景，但是一些特殊数据分布场景可能会有一定偏差，请根据实际数据分布进行查询计划分析。

DBbrain for MongoDB

最后，本文中所介绍的优化原理即将集成到腾讯云DBbrain for MongoDB的智能索引推荐(规则+代价计算)功能中，届时可帮助用户一键优化索引，无需亲自反复推敲验证，欢迎体验。

腾讯云MongoDB当前服务于游戏、电商、社交、教育、新闻资讯、金融、物联网、软件服务等多个行业；MongoDB团队(简称CMongo)致力于对开源MongoDB内核进行深度研究及持续性优化(如百万库表、物理备份、免密、审计等)，为用户提供高性能、低成本、高可用性的安全数据库存储服务。后续持续分享MongoDB在腾讯内部及外部的典型应用场景、踩坑案例、性能优化、内核模块化分析。

﹀

﹀

﹀

叮咚买菜自建MangoDB上腾讯云实践

好了，本文到此结束，如果可以帮助到大家，还望关注本站哦！