View这个词对专业人士来说不是很陌生,翻译一下就是“视图”。在MongoDB之前的版本里面,如果要构造一个集合的子集,个人理解应该有两个办法,一是重新创建一个集合,冗余一下下,还是很方便的。这种方法性能基本没有影响,但是如果数据是动态变化的,同步会有些小小麻烦。二来就是直接操刀用MongoDB聚合框架来完成,不过说实在的,太多中括号、大括号,有时候看的都嫌累。于是视图腾空出世也非偶然,而且绝对是开“大阳线”的时候了!在Mongo的视图里,是不存在真正的数据的,可以把它简单的看成是一个“伪集合”。需要访问视图的内容时,视图数据都是通过实时聚合来自于源集合的。很显然,完全没有空间占用问题,这比冗余强的太多。当然也有一个小小例外,就是system.views集合,这里面存放了所有视图的定义内容,好在占不了多少空间。
1.构建
视图的创建非常简单,db.createView跟着三个参数,第一是视图名,第二是源集合名,第三是聚合条件。于是我们可以创建一个视图包含state为“AL”的所有数据:
然后直接通过db.State_AL进行查询操作,并列举前3条数据。
2.操作
了解了视图的创建后,到底可以进行哪些操作呢?一旦视图被创建,就可以对视图进行任何查询操作,操作内容和标准查询操作完全一致,而且可以继续进行聚合框架操作。但是切记,这是只读视图,不能写!当然,还是有些小小限制的,诸如不能用MapReduce,不能用$text进行全文检索等等。 例如在上面State_AL视图之上再次进行聚合,只显示city和zip字段:
3.场景
实际上产品最有价值的地方不在功能,而是在于是不是有用武之地,这才是其安身立命之地。所以看看MongoDB的视图到底能用在哪里?这才是最关键的!
(1).扩展安全
我们知道MongoDB的安全性整体相比其他非关系型数据库,整体还是做得不错的,特别是企业版里的增强CRUD升级、加密引擎等等。但是安全和方便基本永远走不到一起,所以配置安全基于角色进行字段级别控制还是需要费些脑细胞的。 能不能让安全简单一些呢?事实上,视图就是一个不错的方法。假设您有一个数据集合包含了所有的数据,但是我不想把所有的数据都开放给开发人员访问,如信用卡字段、身份证号等等,那么无法进行一个过滤生成一个新的视图,问题就迎刃而解了。 所以简单来说,隔离只读访问是一个不错的视图用例。
(2).简化逻辑
MongoDB的聚合框架确实不错,而且越来越多的函数被加入到聚合框架,于是长长的过滤条件写起来还是挺费时间的。但是通过视图,那些被频繁使用的过滤聚合可以被固化下来,那么针对子集的查询会变的更简单、应用逻辑也可简化。例如假设应用系统要求每个州只能查本地的zipcode,那么刚才zip数据里面用 match匹配某一个州的数据的方法就可以非常方便的分割数据,然后继续被应用访问。
4.暗礁
只读视图确实还是蛮好用的,但是重要的事情需要说三遍,只读、只读、还是只读。尝试写入当然只能接受失败:
另外有几点需要注意一下:
5.练习
(1).创建视图并排序
(2).创建视图并排序、然后选定字段
(3).创建视图分组并排序
(4).创建视图分组并排序、然后将字段重命名
此时查询数据: