MongoDB 是一个基于分布式文件存储的数据库。由 C++ 语言编写。旨在为 WEB 应用提供可扩展的高性能数据存储解决方案。
MongoDB 是一个介于关系数据库和非关系数据库之间的产品,是非关系数据库当中功能最丰富,最像关系数据库的。
一、索引
MongoDB 提供了多样性的索引支持,索引信息被保存在system.indexes 中,且默认总是为_id创建索引,它的索引使用基本和MySQL 等关系型数据库一样。其实可以这样说说,索引是凌驾于数据存储系统之上的另一层系统,所以各种结构迥异的存储都有相同或相似的索引实现及使用接口并不足为 奇。
1.基础索引
在字段age 上创建索引,1(升序);-1(降序):
db.users.ensureIndex({age:1})
_id 是创建表的时候自动创建的索引,此索引是不能够删除的。当系统已有大量数据时,创建索引就是个非常耗时的活,我们可以在后台执行,只需指定“backgroud:true”即可。
db.t3.ensureIndex({age:1} , {backgroud:true})
2.文档索引
索引可以任何类型的字段,甚至文档:
db.factories.insert( { name: "wwl", addr: { city: "Beijing", state: "BJ" } } ); //在addr 列上创建索引 db.factories.ensureIndex( { addr : 1 } ); //下面这个查询将会用到我们刚刚建立的索引 db.factories.find( { addr: { city: "Beijing", state: "BJ" } } ); //但是下面这个查询将不会用到索引,因为查询的顺序跟索引建立的顺序不一样 db.factories.find( { addr: { state: "BJ" , city: "Beijing"} } );
3. 组合索引
跟其它数据库产品一样,MongoDB 也是有组合索引的,下面我们将在addr.city 和addr.state上建立组合索引。当创建组合索引时,字段后面的1 表示升序,-1 表示降序,是用1 还是用-1 主要是跟排序的时候或指定范围内查询 的时候有关的。
db.factories.ensureIndex( { "addr.city" : 1, "addr.state" : 1 } ); // 下面的查询都用到了这个索引 db.factories.find( { "addr.city" : "Beijing", "addr.state" : "BJ" } ); db.factories.find( { "addr.city" : "Beijing" } ); db.factories.find().sort( { "addr.city" : 1, "addr.state" : 1 } ); db.factories.find().sort( { "addr.city" : 1 } )
4. 唯一索引
只需在ensureIndex 命令中指定”unique:true”即可创建唯一索引。例如,往表t4 中插入2 条记录:
db.t4.ensureIndex({firstname: 1, lastname: 1}, {unique: true});
5.强制使用索引
hint 命令可以强制使用某个索引。
db.t5.find({age:{$lt:30}}).hint({name:1, age:1}).explain()
6.删除索引
//删除t3 表中的所有索引 db.t3.dropIndexes() //删除t4 表中的firstname 索引 db.t4.dropIndex({firstname: 1})
二、explain执行计划
MongoDB 提供了一个 explain 命令让我们获知系统如何处理查询请求。利用 explain 命令,我们可以很好地观察系统如何使用索引来加快检索,同时可以针对性优化索引。
db.t5.ensureIndex({name:1}) db.t5.ensureIndex({age:1}) db.t5.find({age:{$gt:45}}, {name:1}).explain() { "cursor" : "BtreeCursor age_1", "nscanned" : 0, "nscannedObjects" : 0, "n" : 0, "millis" : 0, "nYields" : 0, "nChunkSkips" : 0, "isMultiKey" : false, "indexOnly" : false, "indexBounds" : { "age" : [ [45,1.7976931348623157e+308] ] } }
字段说明:
•cursor: 返回游标类型(BasicCursor 或 BtreeCursor)
•nscanned: 被扫描的文档数量
•n: 返回的文档数量
•millis: 耗时(毫秒)
•indexBounds: 所使用的索引
三、优化器profile
在MySQL 中,慢查询日志是经常作为我们优化数据库的依据,那在MongoDB 中是否有类似的功能呢?答案是肯定的,那就是MongoDB Database Profiler。
1.开启profiling功能
有两种方式可以控制 Profiling 的开关和级别,第一种是直接在启动参数里直接进行设置。启动MongoDB 时加上–profile=级别 即可。也可以在客户端调用db.setProfilingLevel(级别) 命令来实时配置,Profiler 信息保存在system.profile 中。我们可以通过db.getProfilingLevel()命令来获取当前的Profile 级别,类似如下操作:
db.setProfilingLevel(2);
上面profile 的级别可以取0,1,2 三个值,他们表示的意义如下:
1.0 – 不开启
2.1 – 记录慢命令 (默认为>100ms)
3.2 – 记录所有命令
Profile 记录在级别1 时会记录慢命令,那么这个慢的定义是什么?上面我们说到其默认为100ms,当然有默认就有设置,其设置方法和级别一样有两种,一种是通过添加 –slowms 启动参数配置。第二种是调用db.setProfilingLevel 时加上第二个参数:
db.setProfilingLevel( level , slowms ) db.setProfilingLevel( 1 , 10 );
2.查询 Profiling 记录
与MySQL 的慢查询日志不同,MongoDB Profile 记录是直接存在系统db 里的,记录位置system.profile ,所以,我们只要查询这个Collection 的记录就可以获取到我们的 Profile 记录了。列出执行时间长于某一限度(5ms)的 Profile 记录:
db.system.profile.find( { millis : { $gt : 5 } } )
MongoDB Shell 还提供了一个比较简洁的命令show profile,可列出最近5 条执行时间超过1ms 的 Profile 记录。
四、常用性能优化方案
1.创建索引
2.限定返回结果数
3.只查询使用到的字段
4.采用capped collection
5.采用Server Side Code Execution
6.使用Hint,强制使用索引
7.采用Profiling
五、性能监控工具
1. mongosniff
此工具可以从底层监控到底有哪些命令发送给了MongoDB 去执行,从中就可以进行分析:以root 身份执行:
$./mongosniff --source NET lo
然后其会监控位到本地以localhost 监听默认27017 端口的MongoDB 的所有包请求。
2.Mongostat
此工具可以快速的查看某组运行中的MongoDB 实例的统计信息 字段说明:
•insert: 每秒插入量
•query: 每秒查询量
•update: 每秒更新量
•delete: 每秒删除量
•locked: 锁定量
•qr | qw: 客户端查询排队长度(读|写)
•ar | aw: 活跃客户端量(读|写)
•conn: 连接数
•time: 当前时间
它每秒钟刷新一次状态值,提供良好的可读性,通过这些参数可以观察到一个整体的性能情况。
3. db.serverStatus
这个命令是最常用也是最基础的查看实例运行状态的命令之一。
4.db.stats
下面给大家介绍下mongodb的监控
mongodb可以通过profile来监控数据,进行优化。
查看当前是否开启profile功能用命令
db.getProfilingLevel() 返回level等级,值为0|1|2,分别代表意思:0代表关闭,1代表记录慢命令,2代表全部开始profile功能为
db.setProfilingLevel(level); #level等级,值同上level为1的时候,慢命令默认值为100ms,更改为db.setProfilingLevel(level,slowms)如db.setProfilingLevel(1,50)这样就更改为50毫秒通过db.system.profile.find() 查看当前的监控日志。
如:
> db.system.profile.find({millis:{$gt:500}}) { "ts" : ISODate("2011-07-23T02:50:13.941Z"), "info" : "query order.order reslen:11022 nscanned:672230 \nquery: { status: 1.0 } nreturned:101 bytes:11006 640ms", "millis" : 640 } { "ts" : ISODate("2011-07-23T02:51:00.096Z"), "info" : "query order.order reslen:11146 nscanned:672302 \nquery: { status: 1.0, user.uid: { $gt: 1663199.0 } } nreturned:101 bytes:11130 647ms", "millis" : 647 }
这里值的含义是
ts:命令执行时间
info:命令的内容
query:代表查询
order.order: 代表查询的库与集合
reslen:返回的结果集大小,byte数
nscanned:扫描记录数量
nquery:后面是查询条件
nreturned:返回记录数及用时
millis:所花时间
如果发现时间比较长,那么就需要作优化。
比如nscanned数很大,或者接近记录总数,那么可能没有用到索引查询。
reslen很大,有可能返回没必要的字段。
nreturned很大,那么有可能查询的时候没有加限制。
mongo可以通过db.serverStatus()查看mongod的运行状态
> db.serverStatus() { "host" : "baobao-laptop",#主机名 "version" : "1.8.2",#版本号 "process" : "mongod",#进程名 "uptime" : 15549,#运行时间 "uptimeEstimate" : 15351, "localTime" : ISODate("2011-07-23T06:07:31.220Z"),当前时间 "globalLock" : { "totalTime" : 15548525410,#总运行时间(ns) "lockTime" : 89206633, #总的锁时间(ns) "ratio" : 0.005737305027178137,#锁比值 "currentQueue" : { "total" : 0,#当前需要执行的队列 "readers" : 0,#读队列 "writers" : 0#写队列 }, "activeClients" : { "total" : 0,#当前客户端执行的链接数 "readers" : 0,#读链接数 "writers" : 0#写链接数 } }, "mem" : {#内存情况 "bits" : 32,#32位系统 "resident" : 337,#占有物理内存数 "virtual" : 599,#占有虚拟内存 "supported" : true,#是否支持扩展内存 "mapped" : 512 }, "connections" : { "current" : 2,#当前链接数 "available" : 817#可用链接数 }, "extra_info" : { "note" : "fields vary by platform", "heap_usage_bytes" : 159008,#堆使用情况字节 "page_faults" : 907 #页面故作 }, "indexCounters" : { "btree" : { "accesses" : 59963, #索引被访问数 "hits" : 59963, #所以命中数 "misses" : 0,#索引偏差数 "resets" : 0,#复位数 "missRatio" : 0#未命中率 } }, "backgroundFlushing" : { "flushes" : 259, #刷新次数 "total_ms" : 3395, #刷新总花费时长 "average_ms" : 13.108108108108109, #平均时长 "last_ms" : 1, #最后一次时长 "last_finished" : ISODate("2011-07-23T06:07:22.725Z")#最后刷新时间 }, "cursors" : { "totalOpen" : 0,#打开游标数 "clientCursors_size" : 0,#客户端游标大小 "timedOut" : 16#超时时间 }, "network" : { "bytesIn" : 285676177,#输入数据(byte) "bytesOut" : 286564,#输出数据(byte) "numRequests" : 2012348#请求数 }, "opcounters" : { "insert" : 2010000, #插入操作数 "query" : 51,#查询操作数 "update" : 5,#更新操作数 "delete" : 0,#删除操作数 "getmore" : 0,#获取更多的操作数 "command" : 148#其他命令操作数 }, "asserts" : {#各个断言的数量 "regular" : 0, "warning" : 0, "msg" : 0, "user" : 2131, "rollovers" : 0 }, "writeBacksQueued" : false, "ok" : 1 } db.stats()查看某一个库的原先状况 > db.stats() { "db" : "order",#库名 "collections" : 4,#集合数 "objects" : 2011622,#记录数 "avgObjSize" : 111.92214441878245,#每条记录的平均值 "dataSize" : 225145048,#记录的总大小 "storageSize" : 307323392,#预分配的存储空间 "numExtents" : 21,#事件数 "indexes" : 1,#索引数 "indexSize" : 74187744,#所以大小 "fileSize" : 1056702464,#文件大小 "ok" : 1 }
查看集合记录用
> db.order.stats() { "ns" : "order.order",#命名空间 "count" : 2010000,#记录数 "size" : 225039600,#大小 "avgObjSize" : 111.96, "storageSize" : 307186944, "numExtents" : 18, "nindexes" : 1, "lastExtentSize" : 56089856, "paddingFactor" : 1, "flags" : 1, "totalIndexSize" : 74187744, "indexSizes" : { "_id_" : 74187744#索引为_id_的索引大小 }, "ok" : 1 }
mongostat命令查看运行中的实时统计,表示每秒实时执行的次数
mongodb还提供了一个机遇http的监控页面,可以访问http://ip:28017来查看,这个页面基本上是对上面的这些命令做了一下综合,所以这里不细述了。
本文向大家介绍MongoDB查询性能优化验证及验证,包括了MongoDB查询性能优化验证及验证的使用技巧和注意事项,需要的朋友参考一下 结论: 1、 200w数据,合理使用索引的情况下,单个stationId下4w数据。mongodb查询和排序的性能理想,无正则时client可以在600ms+完成查询,qps300+。有正则时client可以在1300ms+完成查询,qps140+。 2、 Mon
本文介绍 TiDB 集群在使用中的各类调优手段,包括系统调优、软件调优、SQL 性能调优。 系统调优 参阅操作系统性能参数调优。 软件调优 参阅 TiDB 内存调优及其他内容。 SQL 性能调优 参阅 SQL 性能调优概览及其他内容。
有许多因素影响你的 Web 应用程序的性能。有些是环境, 有些是你的代码,而其他一些与 Yii 本身有关。 在本节中,我们将列举这些因素并解释如何通过调整这些因素来提高应用程序的性能。 优化你的 PHP 环境 一个好的 PHP 环境是非常重要的。为了得到最大的性能, 使用最新稳定版本的 PHP。 PHP 的主要版本可能带来显著的性能提升。 启用字节码缓存 Opcache(PHP 5.5或更高版本)
使用 YOG2 我们可以轻松的实现多种性能优化功能。 压缩 yog2 release --dest dev --optimize # 也可以使用等价缩写 yog2 release -od dev 压缩功能将会对 JavaScript, CSS, PNG 三种资源进行压缩。 MD5戳 在使用 fis 管理了静态资源后,我们可以通过开启 MD5 戳来实现静态资源的强缓存,关于 MD5戳的优点,可
页面性能优化 桌面端性能优化 网络加载 减少 HTTP 请求次数; 减小 HTTP 请求大小; 将 CSS 或 JavaScript 放到外部文件中,避免使用标签直接引入; 避免页面中空的 href 和 src 属性; 为 HTML 指定 Cache-Control 或 Expires; 合理设置 Etag 和 Last-Modified; 减少页面重定向; 使用静态资源分域存放来增加下载并行数;
当应用于数以百万计的用户或权限的生产环境时,您可能会在Casbin 的强制执行中遇到性能降级,通常有两个原因: 高访问量 每秒到来的请求数量非常庞大,例如:单个Casbin实例每秒就能收到10000条请求。 在这种情况下,仅靠一个Casbin实例通常难以处理完所有请求。 现在有两种解决方案: 运用多线程来运行多个Casbin实例,这样以来您就可以充分利用机器中的所有内核。 详情请参阅:多线程 将C