11

我们的应用程序的某些部分需要加载大量数据（>2000 个实体）并在该数据集上执行计算。每个实体的大小约为 5 KB。

在我们最初的、幼稚的实现中，瓶颈似乎是加载所有实体所需的时间（2000 个实体约为 40 秒），而执行计算本身所需的时间非常短（<1 秒）。

我们尝试了几种策略来加快实体检索：

  • 将检索请求拆分为多个并行实例，然后合并结果：~20 seconds for 2000 entity。
  • 将实体存储在驻留后端的内存缓存中：约 5 秒用于 2000 个实体。

计算需要动态计算，因此在写入时进行预计算并存储结果在我们的情况下不起作用。

我们希望能够在一秒钟内检索到大约 2000 个实体。这在 GAE/J 的能力范围内吗？我们可以为这种检索实施任何其他策略吗？

更新：提供有关我们的用例和并行化结果的附加信息：

  • 我们在数据存储区中有超过 200.000 个相同类型的实体，并且该操作仅用于检索。
  • 我们用 10 个并行工作实例进行了实验，我们获得的典型结果可以在这个 pastebin中看到。将实体传输回主实例时所需的序列化和反序列化似乎会妨碍性能。

更新2：举例说明我们正在尝试做的事情：

  1. 假设我们有一个 StockDerivative 实体，需要对其进行分析以了解它是否是一项好的投资。
  2. 执行的分析需要基于许多外部因素（例如用户的偏好、市场状况）和内部因素（即来自实体的属性）的复杂计算，并且会输出一个单一的“投资得分”值。
  3. 用户可以请求根据其投资分数对衍生品进行排序，并要求提供 N 个得分最高的衍生品。
4

5 回答 5

4

200.000 x 5kb 是 1GB。您可以将所有这些保存在最大后端实例的内存中或拥有多个实例。这将是最快的解决方案——没有什么比记忆更好了。

您是否需要每个实体的全部 5kb 进行计算？在计算之前查询时是否需要所有 200k 实体？查询是否涉及所有实体？

另外，请查看BigQuery。它可能适合您的需求。

于 2012-01-05T21:32:12.767 回答
1

使用内存缓存。我不能保证它就足够了，但如果不是，您可能必须转移到另一个平台。

于 2012-01-05T17:02:06.563 回答
0

这很有趣，但是是的，它是可能的，而且我看到了一些令人难以置信的结果。

我也会这样做；map-reduce 概念

如果您能向我们提供更多关于您使用多少并行实例以及每个实例的结果如何的指标，那就太好了？

此外，我们的流程包括单独检索还是检索和存储？

您的数据存储中有多少元素？4000？10000？原因是您可以从上一个请求中缓存它。

问候

于 2012-01-05T14:33:04.337 回答
0

最后，我们似乎无法在一秒钟内从单个实例中检索超过 2000 个实体，因此我们被迫使用放置在后端实例上的内存缓存，如原始问题中所述。如果有人提出了更好的答案，或者我们为这个问题找到了更好的策略/实现，我会更改或更新接受的答案。

于 2012-04-22T13:34:16.203 回答
0

我们的解决方案包括定期读取后台任务中的实体并将结果存储在 json blob 中。这样我们可以快速返回超过 100k 行。所有过滤和排序都是使用 SlickGrid 的 DataView 模型在 javascript 中完成的。

正如有人已经评论过的，MapReduce 是 GAE 的必经之路。不幸的是，MapReduce 的 Java 库对我来说已损坏，因此我们使用非最佳任务来完成所有阅读，但我们计划在不久的将来（和/或 Pipeline API）开始使用 MapReduce。

请注意，上次我检查时，Blobstore 没有返回大于 1MB 的 gzip 压缩实体，所以目前我们正在从压缩实体加载内容并将其扩展到内存中，这样最终的有效负载就会被 gzip 压缩。我不喜欢这样，它会引入延迟，我希望他们能尽快解决 GZIP 问题！

于 2012-09-26T00:37:53.103 回答