包含复杂对象的Mongo集合的数据模型建议

我们将苹果应用程序数据存储在数据库中（http://www.apple.com/itunes/affiliates/resources/documentation/itunes-enterprise-partner-feed.html）。包含复杂对象的Mongo集合的数据模型建议

我们要为一个类型的查询优化：查找满足一些条件的所有应用程序。标准：（1）应用程序的平均评分; （2）应用评级数量; （3）由app支持的设备; （4）出售应用程序的国家/地区; （5）应用的当前价格;和（6）应用程序免费时的日期。该查询应该尽可能快。示例查询：“查找所有具有> 600等级的应用程序，平均5星级，支持iPad和iPhone，在美国销售，并在两天前将其价格降至0.00美元。”

基于苹果的模式，对每一个国家的价格信息。假设苹果支持100个国家，每个应用程序将有100个价格 - 每个国家一个。我们还需要存储每个应用的历史价格，这意味着10个价格变化的应用将有1000个价格（假设有100个国家/地区）。

三个问题：

1）你怎么劝我们存储在蒙戈的价格数据进行查询快？现在，我们正在考虑将价格存储为一组对象。每个对象由三个元素组成：（1）日期; （2）国家; （3）价格。

2）如果我们店的价格数据作为一个数组对象，有什么事我们需要做的，使对价格数据的搜索速度非常快。再次，普通价格搜索就像是“找到所有在美国商店再次将价格降至0.00美元的应用程序”。

3）我们应当牢记在存储数据的任何陷阱？

来源

2013-02-26 Crashalot

就个人而言，我会在每天的价格数据分类收集 - 每一天的应用程序记录1（复合自然键），与当天的一套100个号码，该应用程序的。这样记录永远不需要增长或搬迁 - 这是一个巨大的胜利。通过适当的索引，大多数针对这个集合的查询都可以很好地执行。保持字段名称较小以提高存储效率。

我会保持一个单独的集合应用“主数据” - 每个应用程序1分的纪录。在这些记录中，您可以记住应用程序免费的最近日期，最新的按国家价格向量的快照以及可能形成应用程序搜索选择标准的任何其他“摘要”数据的类似快照值。计算并记录这些值的聚合，如果它们可能变得昂贵，则可以在方便的时候在后台执行。

希望这是一个帮助！很好，你提前提出这些问题。 :)

来源

2013-02-26 22:47:45 dampier

谢谢！如果我们将价格数据存储在单独的字段中，我们是不是会损失mongo的大部分功能和速度？我们的理解是，mongo需要数据在一个集合中存在才能达到最优。 – Crashalot 2013-02-26 22:52:58

我不这么认为。这完全是为了优化您预期的访问模式......最重要的原则是：避免任何闻起来像关系连接的东西，特别是*以回应每个最终用户的请求。根据您的描述，这听起来像摘要数据就足以满足大多数查询;尽可能允许尽可能多的页面以便一次装入RAM中。 – dampier 2013-02-26 23:20:39

包含复杂对象的Mongo集合的数据模型建议

回答

相关问题