第lt;0gt;页课程.ppt

* 正文 第六章 第31页 第3节 插入文档 简单的MongoDB操作 第三点 插入文档 _id key _id是MongoDB自有产物，存储在集合中的每个文档都有一个默认的主键_id，名称固定，类型可以是MongoDB支持任何类型，但默认是ObjectId，但是同一个集合中文档的_id的值必须是唯一的，不能重复。 即使插入文档的时候没有指定_id，MongoDB也会自动生成。同样不支持自增主键。 * 正文 第六章 第32页 第四节 更新文档 简单的MongoDB操作 第四点 更新文档 将name是ruanrc的文档的hobby字段修改成riding_bak: db.users.update({name:”ruanrc”},{$set:{hobby:”riding_bak”}}); remove： find： * 正文 第六章 第33页 第五节 删除文档 简单的MongoDB操作 第五点 删除文档 将name是luodw的文档从users集合删除: db.users.remove({name:”luodw”}); update： find： * 正文 第六章 第34页 第六节 复杂查询和修改 简单的MongoDB操作 第六点 复杂查询和修改 更新内嵌的字段 db.users.update({name:”ruanrc”},{$set:{“hobby.num”:”9527”}}); 返回指定的字段 db.users.find({name:”ruanrc”},{_id:0}); 1 Sort排序 db.users.find().sort({age:1}); 或查询 db.users.find( { $or: [ { name:”ruanrc”}, { addr:”dblab 303”} ] } ); 2 3 4 * 第35页 MapReduce MapReduce 第七章 欲知详情，请听下回分解！ * 第36页 封面页 谢谢聆听！ 导师：林子雨 演讲者：阮榕城 封面 目录 MongoDB的目标不是没有蛀牙，我觉得超越想取代Mysql的地位。 说明MongoDB在非关系型数据中功能是最丰富的，最像关系数据库的。单表查询查询说明不支持Join表单的联立。这么只是笼统的概念，那MongoDB具体到底是怎么样的，我们先看看MongoDB在国内的使用案例。毕竟大家说好才是真的好！ 在追求高性能的大数据时代，越来越多的公司关注到了MongoDB. HULK平台则是360公司的平台，负责内部开发人员的代码管理还有360手机应用中心的平台支持。 1：如果要定义用户的业务爱好的时候，在关系型数据时候，我们可以设计表结构。但是可能业余爱好不是只有这些。 2：如果要从所有数据里面取得键1等于骑行的数据，这么显得十分的麻烦。 大数据时代里面，数据量飞速增加。在存储方面，利用升级也是有极限的。MongoDB采用的面向文档的数据模型可以自动在多台服务器上面分散数据…… 之前说过，MongoDB是介于关系型和非关系型之间的数据库。是非关系型数据库里面功能最丰富的。 索引：进行快速查询，存储JavaScript:在增删改查里可以使用js语句；聚合：支持MapReduce;固定集合：相当集合的大小是有上限的，对于文档型数据比如（日志）有用。文件存储：MongoDB有自己的协议支持大型文件。 预分配文件空间，利用空间换取性能的稳定；使用内存映射文件，内存方面管理由操作系统自己去处理。 比如在分布式的环境下，主服务器挂了，MongoDB自动切换到备份服务器上面，把备份服务器提升到主服务器，自动继承和配置新节点 任何数据库不可能是完美的，MongoDB肯定也有其不足之处 创建和更新不会实时写入硬盘，所以也会有数据丢失风险。 既然MongoDB优势和不足都这么明显，那么我们是否需要从关系型数据库迁移到MongoDB? Uptime：系统负载 传统的关系型数据模型是不同表利用共同的字段进行关联，表结构复杂。而MongoDB建模不再是基于表格的关系模型了，允许数据冗余，数据尽量一起，查询的时候能把想要的信息一下子查询出来。比如我拥有的宠物这个字段里面，如果在关系型数据库中，应该建立另外一张表，两张表关联！ 比如在一个简单的博客系统中，用关系型数据库可能就需要5张表，但是我们MongoDB中，可能我们就只需要两张表，尽量把文章的所有信息建立在同一个集合里面。 但是这两张表是不能关联使用的。 _id：请先注意这个特殊字段，后面我们会讲到！ 可以看到，我们把联系方式和用户权限都放在一个文档里面 多对多关系，比如：用户和角色有多个对应，一个用户可以对应多个角色，一个角色也可以同时对应多个用户；因为不能join连表，规范