mongodb实时监控正在执行的语句-CSDN社区

MongoDB 是一个基于分布式文件存储的数据库。由 C++ 语言编写。旨在为 WEB 应用提供可扩展的高性能数据存储解决方案。 MongoDB 是一个介于关系数据库和非关系数据库之间的产品，是非关系数据库当中功能最丰富，最像关系数据库的。 Mongodb如今越来越火，要做好对mongodb的监控就需要从它的安装配置，到简单的command语句使用，再到对它运行机制以及状态获取方法的掌握。 mongodb有三种基本的状态获取方式： 1.mongostat 2.开启28017的监听端口，curl http://127.0.0.1:28017/_status 3

作为基于分布式文件存储的数据库，在目前的云计算实践中，MongoDB炙手可热。《深入云计算(MongoDB管理与开发实战详解)》系统全面的介绍了MongoDB开发、管理、维护和性能优化等方方面面。详细而深入，对MongoDB的开发和管理方法进行了详细的讲解，也对MongoDB的工作机制进行了深入的探讨。注重实战，通过实际中的案例为读者讲解使用MongoDB时遇到的各种问题，并给出了解决方案。本书旨在帮助云计算初学者迅速掌握MongoDB数据库，提升读者在云计算实践中的应用和开发能力。同时本书极强的系统性和大量翔实的案例对于有一定基础的中高级用户有非常好的参考价值。第1篇基础篇第1章 MongoDB简介 1．1 关系型数据库简介 1．2 关系型数据库面临的问题 1．3 NoSQL的崛起 1．4 MongoDB是如何解决这些问题的 1．5 初识MongoDB 1．5．1 MongoDB的特点 1．5．2 数据模型 1．5．3 扩展性 1．5．4 功能性 1．5．5 速度快 1．5．6 简便的管理 1．5．7 使用场合 1．6 本章小结第2章 MongoDB基本原理与安装 2．1 数据库结构 2．2 文档 2．3 集合 2．3．1 集合的无模式 2．3．2 集合的命名 2．4 MongoDB数据类型 2．4．1 基本数据类型 2．4．2 数字类型 2．4．3 日期类型 2．4．4 数组类型 2．4．5 内嵌文档类型 2．4．6 _id键和ObjectId对象 2．5 MongoDB的下载和安装 2．5．1 MongoDB的下载 2．5．2 在Windows平台下的下载与安装 2．5．3 在Linux平台下的下载与安装 2．6 MongoDB shell的使用 2．6．1 启动Shell 2．6．2 使用Shell对MongoDB的基本操作 2．6．3 使用Shell的诀窍 2．6．4 特殊的集合名 2．7 本章小结第3章文档的增加、修改及删除 3．1 插入并保存文档 3．1．1 插入的原理和作用 3．1．2 批量插入 3．2 删除文档 3．3 修改文档 3．3．1 整个文档的替换 3．3．2 使用修改器 3．3．3 upsert和save更新 3．3．4 修改多个文档 3．3．5 修改文档并返回修改后的文档 3．4 数据库响应 3．4．1 安全操作 3．4．2 捕获异常 3．5 客户端请求和MongoDB数据库连接 3．6 本章小结第2篇应用篇第4章查询 4．1 find简介 4．1．1 返回指定的键 4．1．2 find查询限制 4．2 条件操作符 4．2．1 $all匹配所有 4．2．2 $exists判断字段是否存在 4．2．3 null值处理 4．2．4 $mod取模运算 4．2．5 $ne不等于 4．2．6 $in包含 4．2．7 $nin不包含 4．2．8 $size数组元素个数 4．2．9 正则表达式匹配 4．2．10 Javascript 查询和$where 查询 4．2．11 count查询记录条数 4．2．12 limit限制返回记录数 4．2．13 skip 限制返回记录的起点 4．2．14 sort 排序 4．2．15 分页查询 4．2．16 随机抽取文档 4．3 distinct找出给定键所有不同的值 4．4 group分组 4．4．1 使用完成器 4．4．2 将函数作为键使用 4．5 游标 4．6 存储过程 4．7 本章小结第5章 Capped集合 5．1 特性 5．2 使用和约束 5．3 应用 5．3．1 创建 capped collection 5．3．2 限制capped collection中对象个数 5．4 注意事项 5．5 本章小结第6章 GridFS存储文件 6．1 为什么要用GridFS 6．2 如何实现海量存储 6．3 语言支持 6．4 简单介绍 6．5 命令行工具 6．6 内部原理 6．7 本章小结第7章 MapReduce统计 7．1 Map函数 7．2 Reduce函数 7．3 结果存储 7．4 对Reduce函数结果进一步处理 7．5 其他控制细节 7．6 本章小结第3篇管理篇第8章管理 8．1 启动和停止MongoDB 8．1．1 使用命令行启动 8．1．2 配置文件 8．1．3 Daemon方式启动 8．1．4 mongod参数说明 8．1．5 停止数据库 8．2 访问控制 8．2．1 绑定IP内网地址访问Mongo

Lepus（天兔）是数据库企业监控系统，针对互联网企业开发的一款专业、强大的企业数据库监控管理系统，企业通过Lepus可以对数据库的实时健康和各种性能指标进行全方位的监控。目前已经支持MySQL、Oracle、MongoDB、Redis数据库的全面监控. Lepus可以在数据库出现故障或者潜在性能问题时,根据用户设置及时将数据库的异常进行报警通知到数据库管理员进行处理和优化,帮助企业解决数据库性能监控问题，及时发现性能和瓶颈,避免由数据库潜在问题造成的直接经济损失。Lepus能够查看各种实时性能状态指标，并且对监控、性能数据进行统计分析，从运维者到决策者多个层面的视角，查看相关报表。帮助决策者对未来数据库容量进行更好的规划，从而降低了硬件成本。 Lepus是一个真正的能够帮助企业解决数据库监控和运维的问题，主要可以帮企业解决如下问题： 1.帮助企业解决数据库性能监控问题，及时发现性能和瓶颈,避免由数据库潜在问题造成的直接经济损失 "Lepus数据库企业监控系统"是针对互联网企业开发的一款专业、强大的企业数据库监控管理系统，企业通过Lepus可以对数据库的实时健康和各种性能指标进行全方位的监控。目前已经支持MySQL、Oracle、MongoDB、Redis数据库的全面监控. Lepus可以在数据库出现数据库无法连通、会话数、进程数、等待事件、同步、延时等故障或者潜在性能问题时,根据用户设置阀值及时将数据库的异常进行报警通知到数据库管理员进行处理和优化,避免因数据库故障或性能瓶颈造成直接的经济损失。 2.帮助企业运维领导决策者更好的统筹数据库容量资源，降低企业硬件成本 Lepus采用列式方式呈现监控指标，适合中大型互联网公司大规模数据库的监控管理。通过WEB界面，企业运维人员和决策者可以进行任意几台主机或所有主机监控的数据库性能、系统资源使用情况对比,并提供数据库性能资源按不同维度排序功能，以及系统资源Top信息图表，帮助决策者更好的发现哪些数据库性能开销大,哪些比较空闲,从运维者到决策者多个层面的视角，查看相关报表。帮助决策者对未来数据库容量进行更好的规划，从而降低了硬件成本。 3.帮助企业DBA运维人员解决重复和枯燥的工作，提高运维人员工作效率面对几时台甚至上百台数据库服务器，如果没有统一的数据库的基础信息，将会使数据库运维管理变的无序，如果想了解数据库的基本健康状态信息，则需要登录数据库或登录服务器。重复的工作容易使人疲惫和厌倦。Lepus提供数据库的基础数据指标采集，比如数据库版本，运行时间，基本健康状态,核心配置参数等基础数据，有了这些基础数据，无需登录机器即可通过系统集中查询，减少了DBA运维人员的重复性工作和枯燥的敲命令工作。 4.慢查询推送和AWR性能报告，降低数据库运维人员和开发人员的沟通成本 Lepus拥有创新的MySQL慢查询分析，TopSQL自动推送，基于时间范围的MySQL AWR性能报告功能。打破了数据库管理人员被动的联系开发人员解决SQL问题的常规低效率现象。Lepus会定时收集影响数据库稳定性的慢SQL,并根据计划任务定时推送查询次数最多,查询时间最长的TopSQL给相关开发人员，开发人员也可以通过有限的权限自主查询任意时间内的慢SQL语句。也可以通过在线AWR性能报告功能查询数据库历史任意时间的数据库性能问题和瓶颈。降低数据库运维人员和开发人员的沟通成本。

RethinkDB 设计用来存储 JSON 文档的分布式数据库，可通过简单操作实现多机分布式存储。支持表的联合和分组查询。什么是RethinkDB?RethinkDB 是从头打造的第一个开源、可扩展的JSON数据库，用于搭建实时网页。全新的访问模型颠覆了传统的数据库结构：开发者只需告诉RethinkDB，实时连续地将查询更新结果推送到应用就可以了，不用每次都去poll一遍。RethinkDB的实时推送结构为搭建可扩展实时应用节省了大量时间精力。除了为实时应用提供了全新的设计之外，RethinkDB 还提供了一种灵活的查询语言、直观的操作和监控API，安装学习起来也非常容易。你可以查看这篇 Advancing the realtime web 得到更多RethinkDB计划的技术细节。什么时候RethinkDB是一个好的选择?当你的应用很大程度上有赖于数据的实时反馈时，RethinkDB 就会成为一个很棒的选择。“查询-响应”式的数据库访问模型在web上的确很有用，它可以直接映射到HTTP的“请求-响应”。而现代应用则需要将数据直接实时地传送到客户端。能够最大化得益于RethinkDB实时推送架构的例子包括：协作网站和移动应用数据流分析应用多人在线游戏实时交易场所设备联机举个例子：在协作设计一个app的时候，其中一个用户改变了某个按钮的位置，服务器就必须在第一时间通知所有在完成同一项目的其他用户。网页浏览器能够通过WebSockets和http持久连接来支持这一功能，但数据库系统要迎合实时需求仍然是一个大的工程难题。而RethinkDB作为第一个开源、可扩展的数据库，就是特别为实时推送数据到应用而设计的。哪些人在用 RethinkDB？RethinkDB 的用户包括上百个科技创业公司、咨询工作室和世界五百强企业。这里是其中的一些：Jive Software 和 Mediafly 使用RethinkDB搭建强大的响应式网页和移动应用Pristine.io 和 Narrative Clip 使用RethinkDB搭建用于设备连接的云架构Platzi 和 Workshape.io 使用RethinkDB进行实时分析CMUNE 和 NodeCraft 使用RethinkDB构建大规模可扩展多人游戏RethinkDB 拥有超过十万开发者的活跃社区和上百个来自世界各地的代码贡献者。RethinkDB是基于现有技术的吗?高效实现实时推送架构需要重新设计绝大部分的数据库成分，包括查询执行引擎、分布式系统、超高速缓存子系统和存储引擎。因为架构影响到每一个数据库组成部分，RethinkDB不得不从C 开始一步步写起来。RethinkDB 是由数据库专家组成的团队花了五年时间做出来的，还得到了来自世界各地上百个代码贡献者的帮助。RethinkDB和realtime sync不同在哪里?和Firebase, PubNub 或者Pusher 这类实时同步API相比，RethinkDB主要不同在以下三个方面：首先，实时同步API是云服务，而RethinkDB 是开源项目。RethinkDB也有云端，可以通过我们的合作伙伴 Compose.io 和 Amazon AWS获得。它还可以部署在你自己的架构中，没有任何限制。其次，同步实时API只局限于同步文档，而RethinkDB是一个有着更普遍应用范围的数据库系统。在RethinkDB中你可以运行任意query，包括table joins, subqueries, geospatial queries, aggregation, 还有map-reduce。实时同步服务有更多查询功能上的限制。最后，实时同步API的设计是直接从浏览器访问。这使得基本的app能够快速地跑起来，然而一旦app扩展了，灵活性就会受到限制。 RethinkDB的设计是从应用服务器进行访问，这一点上更像是传统的数据库。可能会要多花一点设置代码，但拥有足够的灵活性去适应应用的成熟。RethinkDB和MongoDB又不同在哪里?RethinkDB所基于的架构和MongoDB非常不同。开发者只需告诉RethinkDB，实时连续地将查询更新结果推送到应用就可以了，不用每次都去poll一遍。你同样可以在RethinkDB上用传统的“查询-响应”范式来书写应用。然后在你开始为app添加实时功能时再去订阅实时数据流。举个例子，这是你让RethinkDB查询一个文件时的命令：r.table('users').get('coffeemug').run()然后这是你从RethinkDB订阅更新流时用到的语句，在任何时候文档发生了变化就会推送：r.table('users').get('coffeemug').changes().run()RethinkDB的实时架构可以和MongoDB的oplog相提并论，但前者提供了更高层次的抽象。RethinkDB的数据流与查询计算引擎无缝整合，并允许你订阅查询结果的变化，而不仅仅是把数据复制过来。这种架构大幅度地减少了搭建实时app所需的时间和精力。除了实时推送架构，RethinkDB 还有许多胜过 MongoDB的地方:一种高级的查询语言，能够支持table joins, subqueries 和大规模并行式分布计算。融合了查询语言的操作和监控API，大幅度降低了RethinkDB扩展的难度。简洁美观的UI 易于复制转发，拥有在线文档支持和查询语言建议。可以看看这篇 technical comparison of RethinkDB and MongoDB 里面的评论比较中立一些。想听听个人观点的，请看@coffeemug 的what makes RethinkDB different.什么时候RethinkDB是一个不好的选择？当你需要用到完整ACID支持或者更强大的架构实施，RethinkDB就不大好用了。在这种情况下你最好用一些传统的MySQL或者PostgreSQL数据库。如果你需要做深度、密集型计算分析的话，你最好用Hadoop或者类似于Verticaa的面向列的存储工具。在某些情况下RethinkDB会在一定程度上牺牲书写可用性(write availability)来保证数据一致性(data consistency)。如果高要求的书写可用性对你来讲很重要，那你也不要纠结了，像Riak这样的Dynamo式系统可能更适合你。想要更多地学习RethinkDB?阅读 ten-minute guide 开始学习RethinkDB。对于熟悉分布式系统的程序员可以直接阅读 architecture overview 。走捷径用 cookbook，你可以看到许多常用的 RethinkDB查询例子。标签：分布式数据库