0

一个星期以来一直试图解决这个问题，但在我的所有研究中都找不到任何解决方案，所以我想我会问大家。

我有一个“Product”表和一个“productSent”表，这里有一个快速的方案来帮助解释：

class Product(ndb.Model):
  name = ndb.StringProperty();
  rating = ndb.IntegerProperty

class productSent(ndb.Model): <--- the key name here is md5(Product Key+UUID)
  pId = ndb.KeyProperty(kind=Product)
  uuId = ndb.KeyProperty(kind=userData)
  action = ndb.StringProperty()
  date = ndb.DateTimeProperty(auto_now_add=True)

我的目标是向用户展示他们以前从未见过的评分最高的产品——快速。因此，为了跟踪用户看到的产品，我使用 productSent 表。我创建了这个表而不是使用光标，因为每次评级顺序发生变化时，光标都有可能跳过新的更高排名的产品。一个例子：假设用户在数据库中看到了产品 1-24。接下来，有 5 个用户喜欢产品 #25，使其成为数据库中的 #10 产品——我担心该产品将永远不会再次显示给用户（并且可能会在更大范围内搞砸）。

我现在这样做的问题是，一旦用户超过了前 1,000 个产品，它就真的开始降低查询性能。因为我实际上是在提取 1,000 多个结果，通过查询 productSent 表（执行 keyName 查找以加快处理速度）检查它们是否已发送，并遍历循环直到检测到 15 个新结果。

我想到的一个解决方案是在所有看过产品的用户的产品表中添加一个重复属性（listProperty）。或者，如果我不想使用不等式过滤器，我可以将所有未看过产品的用户的重复属性放在一起。这样，当我查询时，我可以动态地将它们取出。但我担心当我有 1,000 多个用户时会发生什么：

a) 我将在一个实体中重复属性的限制上一探究竟。b) 索引大小会增加大小成本

以前有没有人处理过这个问题（我相信有人有！）关于构建它的最佳方法的任何提示？

更新 好的，所以有另一个想法。为了最大限度地减少评分（喜欢的数量）发生变化时发生的变化，我可以有一个只有 3 个可能值的辅助列：正面、中性、负面。并按此排序？当然，对于评分为 0 并获得“喜欢”（使它们成为正面）的项目，仍然有可能出现故障或被光标跳过——但可能性较小。大家觉得呢？

4

2 回答 2

2

听起来像相反，productNotSent在这里会很好用。每次添加新产品时，都会productNotSent为每个用户添加一个新实体。当用户想要查看他们未见过的最高评价产品时，您只需查询productNotSent与该用户匹配的实体。如果你rating直接把它放在productNotSent你可以加快查询速度，因为你只需要查询一个模型。

另一个想法是限制productNotSent每个用户的实体数量。所以每个用户一次只有大约 100 个这样的实体。这意味着无论您拥有多少产品或用户，您的查询对于每个用户都是不变的。不过，新productNotSent实体的创建将变得更加复杂。您必须有一个 cron 作业或在用户用完productNotSent一些实体时“充值”用户的实体集合的东西。您可能还需要仔细检查评级高于用户productNotSent实体集合中的那些产品是否被推入那里。这些有点困难，并且需要一些设计权衡。

希望这可以帮助！

于 2013-11-10T02:58:58.307 回答
0

我不知道您的预期数量和确切问题（只是快速阅读了您的问题），但您可以考虑使用 Json TextProperty 存储作为您计划的一部分。创建字典/列表并通过 json.dump() 将它们存储到 TextProperty 中。当客户端调用时，只需将 TextProperties 发送给客户端，并在您 JSON.parse() 后在客户端计算出所有内容。我们用这种方式在 JS 中做了一些非常大的数组/对象处理，而且速度非常快（尤其是索引数组）。当用户点击某物时，发回交易以更新他们的记录。设置一些拉取或推送队列流程来处理您的整体产品列表更新、主要客户记录更新等。

一个缺点是你的应用程序的带宽更高，但我认为考虑到 GAE 的潜在处理节省，这个成本将是最小的。如果您的结构正确，您可以使用 get_by_id() 来替换所有或大部分计划的索引和查询。我们发现 json.loads() 和 json.dumps() 在应用程序中非常快，但我们只使用简单的字典/列表结构。但是，这种方法将是一个很大的量子度量，比您的计划使用要低的查询。另一个潜在问题是非常大的对象可能会遇到软内存限制。确保您的 Json 对象相当简单+轻量级以避免这种情况（例如，在 Json 项目中不包括产品描述、子对象等，仅包括产品编号等基础知识）。HTH，-步骤

于 2013-11-10T14:40:58.457 回答