1.数组的定位修改器
若数组有多个值,只想对其中一部分进行修改.可以通过位置或定位操作符.
如将上篇的email数组的第一个值"295240648@163.com"修改为"295240648@136.com"
db.users.update(
{"userName":"refactor"},
{
"$set":
{
"emails.0":"295240648@136.com"
}
}
)
很多情况下,不预查询就不知道要修改数组的下标.MongoDB提供了定位操作符"$",用来
定位查询文档已经匹配的元素,并进行更新.
2.修改器速度
有的修改器运行较快."$inc"不需要改变文档的大小,只需要将键的值修改一下,所以修改速度很快.
数组修改器可能更改文档的大小,就会慢一些,"$set"能在文档大小不发生改变时立即修改,否则性能也会有所下降.
MongoDB预留了些空白给文档,来适应大小的变化(事实上,系统会根据文档的通常的大小变化情况来相应
的调整留的空白大小),但是要是超过了原来的空间,最后还是要分配一块新的空间.空间分配除了会减慢速度,
同时会随着数组的变长,MongoDB需要更长的时间来遍历整个数组,对每个数组的修改也会慢下来.
"$push"或者其他数组修改器是推荐使用的.但要是"$push"成为效率瓶颈,就需要将内嵌数组独立出来,放到
一个单独的集合里面.
3.upsert
upsert是一个特殊的更新,要是没有文档符合更新条件,就会以这个条件和更新文档为基础创建一个新文档.
如果找到了匹配的文档,则正常更新.upsert不比预置集合,同一套代码可以创建,又可以更新文档.
以前创建的网站计数器,就可以采用upsert的方式.如果不存在就创建文档,如果存在就更新.
db.users.insert(
{
"url":"http://www.cnblogs.com/refactor",
"pageViews":12345
}
)
使用upsert
db.users.update(
{"url":"http://www.cnblogs.com/refactor"},
{"$inc":{"pageViews":1}},
true
)
注意update的第三个参数的意思是:启用upsert.
从集合去除:
db.users.remove({"url":"http://www.cnblogs.com/refactor"})
使用upsert
db.users.update(
{"url":"http://www.cnblogs.com/refactor"},
{"$inc":{"pageViews":1}},
true
)
4.save shell
save是一个shell函数,可以在文档不存在时插入,存在时更新.它只有一个参数:文档.要是这个文档有
"_id"键,save会调用upsert,否则会调用插入.程序员可以很方便的使用这个函数在shell中修改文档
可以看出db.users.save(x)和db.users.update({"_id":x._id},x)效果是一样的.
5.更新多个文档
默认情况下,更新只能对符合条件的第一个文档执行操作.要使有多个符合条件文档都得到更新,可以设置update的
第四个参数为true.
只会更新第一个匹配项
db.users.update(
{"url":"http://www.cnblogs.com/refactor"},
{"$set":{"pageViews":50000}}
)
更新所有匹配项
db.users.update(
{"url":"http://www.cnblogs.com/refactor"},
{"$set":{"pageViews":50000}},
false,
true
)
注意:以后可能会更改update的行为(服务器可能默认会更新所有匹配的文档,只有第四个参数为false的时候才会更新
第一个文档),所以建议每次都显示表明要不要进行多文档更新.
想要知道多文档更新到底更新了多少文档,可以用getLastError命令,键"n"的值就是要的数字.
可以用findAndModify命令来获得更新的文档.
6.瞬间完成
插入,删除和更新这三个操作都是瞬间完成的,因为他们都不需要等待数据库响应.这不是异步操作,客户端将文档发送给
服务器后就不管了,客户端不会收到服务器端的响应操作,如:服务器操作失败.
这个特点的优点是速度快,它只受客户端发送的速度或网络速度的制约.但这样也会出现很多问题,客户端可能会向根本
不存在的服务器发送文档等等.
7.安全操作
如果要完成一个电子商系统,如果某人订购了某物,应用程序需要时间确保订单顺利.当执行时出现了错误,还要重来.
MongoDB默认选择了不安全的版本,因为构建在关系型数据库的应用程序基本都不关心返回的代码,也不会检查
返回码,但又得等待这个返回码,这会造成性能下降.
安全的版本在执行完了操作立即运行getLastError命令,来检查是否执行成功.驱动程序会等待数据库响应,然后
适当的处理错误,一般会抛出异常.这样开发者就能用自己的语言来处理数据库的错误了.要是操作成功,getLastError
会给出额外的信息作为响应(如:对于更新,删除文档,会给出受影响的文档数量)
安全的代价就是性能.即便忽略客户端处理异常的开销(这个开销一般是重量级的),等待数据库响应本身的时间比只发送
消息的时间多一个数量级,所以要权衡数据库的重要性和速度需求.
8.捕获常规错误
安全操作也是调试数据库"奇怪"行为的好方法.即便安全操作最后会在生产环境中移除,但是开发过程中还是应该大量的
使用,这样可以避免很多常见的数据库使用错误,最常见的就是键重复的错误.
键重复的错误经常发生在试图将一个已被占用"_id"值插入.MongoDB不允许在一个集合里面有多个"_id"值一样的文档,
如果做的是安全插入,发生了键重复错误,安全检查会发现这个服务器错误,并抛出异常.在不安全模式下,数据库没有响应,
所以根本不知道插入失败了.
9.请求和连接
数据库会为每一个MongoDB数据库连接创建一个队列,存放这个连接的请求.当客户端发送一个请求,会被放到队列的末尾.
只有队列中的请求都执行完毕,后续的请求才会执行.
注意,每个连接都有独立的队列,要是打开两个shell,就有两个数据库连接.在一个shell中执行插入,之后在另一个shell中进行
查询不一定能得到插入的文档,但是在同一个shell中,插入后再执行查询一定是能查到的.手动复现这个行为不容易,但在繁忙
的服务器,交错的插入/查找就很有可能了.当开发者用一个线程插入数据,用伊利个线程检查是否成功插入时,就会经常的遇到
这个问题.有那么一两秒时间,好像根本没有插入数据,但随后数据又冒出来了.
使用C#的驱动程序要特别注意这种行为,因为驱动程序使用了连接池.为了提高效率,驱动程序和服务器简历了多个连接
(一个连接池),并将请求分散到这些连接中去.好在驱动程序提供了一些机制来确保一系列的请求都由一个连接处理.