前言
MongoDB是由C++语言所编写的一种面向文档的非关系型数据库(是一种NoSql数据库实现),也是介于关系型数据库和非关系型数据库之间的数据存储产品,而众所周知SQL与NoSQL最大的不同之一就是不支持JOIN,在传统的数据库中,SQL JOIN子句允许你使用普通的字段,在两个或者是更多表中的组合表中的每行数据。例如,如果你有表books和publishers,你可以像下面这样写命令:
SELECT book.title, publisher.name FROM book LEFT JOIN book.publisher_id ON publisher.id;
换句话说,book表中的publisher_id字段引用了publishers表中的id字典。这些都是很常见的例子:对于每个publisher都可以拥有成千上万本书,如果你想更新publisher的信息的时候,我们只需要更改一条记录。数据的冗余是很小的,因为我们不需要为每本书来重复更新他的publisher信息,这种技术已基本当做一种规范化的东西了。SQL数据库提供了一些列的规范与约束条件来保障数据关联性。
--------------------------------------------------------------------------------
NoSQL == No JOIN"color: #ff0000">MongoDB Aggregation
$lookup仅仅在 aggregation操作中才被允许使用,想想他作为一个管道操作:查询,过滤,组合结果。一个操作的输出被作为下一个的输入。Aggregation比简单的查询操作更难于理解,而且这些操作通常运行很慢,然而他们很高效,Aggregation可以使用一个很好的例子来解释,假设我们使用user数据集合来创建一个社交平台,在每个独立的文档中存储没个用户的信息,例如:
{ "_id": ObjectID("45b83bda421238c76f5c1969"), "name": "User One", "email: "userone@email.com", "country": "UK", "dob": ISODate("1999-09-13T00:00:00.000Z") }
我们可以向user这个集合中添加足够多的用户,但是每个MongoDB文档都必须有一个为一个_id字段值,这个_id字段值就像SQL中的键,在我们没有明确指定_id的时候会被自动的加入到文档中。我们的社交网站现在需要一个post集合,这个结合存储用户的评论,这个文档存储纯文本,时间,评分,一个被写到user_id字段的玩家引用。
{ "_id": ObjectID("17c9812acff9ac0bba018cc1"), "user_id": ObjectID("45b83bda421238c76f5c1969"), "date: ISODate("2016-09-05T03:05:00.123Z"), "text": "My life story so far", "rating": "important" }
我们现在想要显示最近具有important评论的二十条数据,这些数据来自所有的用户,并且是按照时间排序的。每一个返回的文档中应该包含评论的文本,发布评论的时间,以及相关的用户的名字和国家。
MongoDB数据库的aggregate查询是通过传递管道操作的数组,这个数组中顺序的定了每个操作。首先,我们需要从所有的post集合中提取出所有的文档,这些文档使用$match记性准确rating过滤。
{ "$match": { "rating": "important" } }
我们现在需要对过滤出来的文档按照时间,使用$sort操作进行排序。
{ "$sort": { "date": -1 } }
因为我们要仅仅返回二十条数据,我们可以使用$limit来限制我们需要处理的文档数量。
{ "$limit": 20 }
我们现在使用$lookup操作从user集合中连接数据,这个操作需要一个四个参数的对象:
1、localField:在输入文档中的查找字段
2、from:需要连接的集合
3、foreignField:需要在from集合中查找的字段
4、as:输出的字段名字
所以我们的操作是这样的:
{ "$lookup": { "localField": "user_id", "from": "user", "foreignField": "_id", "as": "userinfo" } }
在我们的输出中将会创建一个名为userinfo的新字段,他是一个数组,其中每个元素都是在user集合中匹配的元素。
"userinfo": [ { "name": "User One", ... } ]
在post.user_id与user._id之间,我们具有一对一的关系,因为对于每一个post只有一个用户。因此我们的userinfo数组将会仅仅包含一个元素,我们可以说使用 $unwind操作来解构他并插入到一个自文档中。
{ "$unwind": "$userinfo" }
现在的输出将会转化成更加常用的结构:
"userinfo": { "name": "User One", "email: "userone@email.com", … }
最终我们可以在管道中使用 $project操作返回评论信息,评论的时间,评论的用户名,国家等。
{ "$project": { "text": 1, "date": 1, "userinfo.name": 1, "userinfo.country": 1 } }
合并上面所有的操作
我们最终的聚合查询匹配的评论,按照顺序排序,限制最新的二十条信息,连接用户的数据,扁平用户数组,最后只返回我们需要的必须数据,总的命令如下:
db.post.aggregate([ { "$match": { "rating": "important" } }, { "$sort": { "date": -1 } }, { "$limit": 20 }, { "$lookup": { "localField": "user_id", "from": "user", "foreignField": "_id", "as": "userinfo" } }, { "$unwind": "$userinfo" }, { "$project": { "text": 1, "date": 1, "userinfo.name": 1, "userinfo.country": 1 } } ]);
结果是一个拥有二十个文档的集合,例如:
[ { "text": "The latest post", "date: ISODate("2016-09-27T00:00:00.000Z"), "userinfo": { "name": "User One", "country": "UK" } }, { "text": "Another post", "date: ISODate("2016-09-26T00:00:00.000Z"), "userinfo": { "name": "User One", "country": "UK" } } ... ]
MongoDB的$lookup很好用而且很高效,但是上面这个基础的例子只是一个组合的集合查询。他不是一个对SQL中的更加高效的JOIN子句的替代。而且MongoDB也提供了一些限制,如果user集合被删除了,post文档还是会保留。
理想情况下,这个$lookup操作应该不会经常使用,如果你需要经常使用它,那么你就使用了错误的数据存储了(数据库):如果你有相关联的数据,应该使用关联数据库(SQL)。
也就是说$lookup是一个MongoDB 3.2新加入的,他解决了当在Nosql数据库中使用一些小的相关联的数据查询的时候一些令人失望的问题。
总结
以上就是这篇文章的全部内容了,希望本文的内容对大家的学习或者工作能带来一定的帮助,如果有疑问大家可以留言交流,谢谢大家对的支持。
免责声明:本站资源来自互联网收集,仅供用于学习和交流,请遵循相关法律法规,本站一切资源不代表本站立场,如有侵权、后门、不妥请联系本站删除!
更新日志
- 证声音乐图书馆《夏至 爵士境地》[320K/MP3][70.37MB]
- 孙露《同名专辑》限量1:1母盘直刻[低速原抓WAV+CUE]
- 【宝丽金唱片】群星《鼓舞飞扬》WAV+CUE
- 莫扎特弗雷德沃夏克肖斯塔科维奇《钢琴五重奏》(DG24-96)FLAC
- 证声音乐图书馆《夏至 爵士境地》[FLAC/分轨][360.16MB]
- 证声音乐图书馆《日落琴声 x 弦乐》[320K/MP3][71.2MB]
- 证声音乐图书馆《日落琴声 x 弦乐》[FLAC/分轨][342.58MB]
- 谢采妘2011《难忘的旋律(Non-StopChaCha)》马来西亚版[WAV+CUE]
- 林翠萍《听见林翠萍,记忆就会醒来》2CD[WAV+CUE]
- 木村好夫《天龍HIFI木吉他、木村好夫精选好歌》日本天龙版[WAV整轨]
- 证声音乐图书馆《日出琴声 x 民谣》[320K/MP3][53.76MB]
- 证声音乐图书馆《日出琴声 x 民谣》[FLAC/分轨][239.29MB]
- 证声音乐图书馆《绿意森林·吉他絮语》[320K/MP3][65.77MB]
- 证声音乐图书馆《绿意森林·吉他絮语》[FLAC/分轨][295.2MB]
- 证声音乐图书馆《流动与延展 彼拉提斯》[320K/MP3][56.88MB]