MongoDB的分析查询
我是MongoDB的新手,在执行解决方案时遇到困难。 考虑在那里我有两个集合的情况下:在客户端和销售收取这样的设计MongoDB的分析查询
Client
==========
id
full name
mobile
gender
region
emp_status
occupation
religion
Sales
===========
id
client_id //this would be a DBRef
trans_date //date time value
products //an array of collections of product sold in the form {product_code, description, units, unit price, amount}
total sales
现在有开发另一个收集分析查询的要求,其中以下问题都可以回答
- 按性别,地区和emp_status的销售分布情况如何?
- 什么是在特定地区的客户主要购买产品?
我考虑实现一个非常规范化的集合来创建销售和客户端集合的属性的平坦和广泛集合,以便我可以使用map-reduce来进一步回答问题。 在关系型数据库管理系统中,通过连接返回的聚合将回答这些问题,但我对如何使Map-Reduce或Agregation帮助失去了帮助。
问题: 如何实现Map-Reduce以映射2个集合? 是否可以链接MapReduce操作?
问候。
MongoDB不会做JOINs - 期!
MapReduce总是运行在一个集合上。你不能有一个从多个集合中选择的MapReduce作业。这同样适用于聚合。
当您想要进行一些数据挖掘(而不是MongoDBs最强套装)时,您可以创建一个非规格化的所有Sales
集合以及嵌入的对应Client
对象。你将不得不写一个小程序或脚本,在所有客户端进行迭代,并且
- 查找所有
Sales
文件的客户为例 - 合并来自
Client
相关领域到每个文件 - 插入所得到的文档进新的集合
当你Client
文件小,并且不经常改变,你可能会考虑到总是将其嵌入到电子书ach Sales
。这意味着你将拥有冗余数据,从经验丰富的RDB老手的角度来看,这看起来非常邪恶。但请记住,MongoDB不是一个关系数据库,因此您不应该应用未反映的所有RDBMS教条。数据库规范化的“无冗余”规则只有在JOIN相对便宜且无痛时才可行,而MongoDB则不是这种情况。此外,有时您可能需要冗余来确保数据持久性。当你想知道你所在地区销售的历史发展情况时,你想知道客户购买产品时居住的地区,而不是现在居住的地区。当每个Sale
仅引用当前的Client
文档时,该信息将丢失。当然,你可以通过单独的Address
文件解决这个问题,这些文件有日期范围,但这会使它更加复杂。
另一种选择是在每个Client
中嵌入Sales
的数组。但是,MongoDB不喜欢随着时间推移而增长的文档,所以当你的客户倾向于经常返回时,这可能导致低于标准的写入性能。
谢谢菲利普,我赞成反规范化策略,并且聚合更简单。 – okmich