使用 appengine 提高数据库记录检索吞吐量答案

【问题标题】：Improving database record retrieval throughput with appengine使用 appengine 提高数据库记录检索吞吐量
【发布时间】：2013-03-31 08:30:52
【问题描述】：

使用带有 Python 的 AppEngine 和 HRD 按顺序检索记录（通过索引字段，它是一个递增的整数时间戳），我们在 30-45 秒内返回了 15,000 条记录。（使用了批处理和限制。）我曾尝试在两个实例上并行执行查询，但仍实现了相同的总体吞吐量。

有没有办法在不更改任何代码的情况下提高这个总数？我希望我们可以多付一些钱并获得更好的数据库吞吐量。（您可以为更大的前端支付更多费用，但这不会影响数据库吞吐量。）

我们将更改代码以将多个基础数据项存储在一个数据库记录中，但希望有一个短期的解决方法。

编辑：这些是正在下载到另一个系统的日志记录。我们会在未来修复它并且知道如何修复它，但我宁愿先处理更重要的事情。

【问题讨论】：

只是出于好奇，您为什么要一次检索如此大量的实体？如果您有这样的要求，那么您的设计可能存在问题，而不是 HRD 性能问题。
我会支持上面@illia-frenkel 所说的话。也许考虑设计您的应用程序以包括使用memcache 并可以缓存？由于您没有提供更多信息，我建议您观看 App Engine Datastore Under the Covers youtube.com/watch?v=tx5gdoNpcZM 和 Building Scalable Web Apps with App Engine youtube.com/watch?v=Oh9_t5W6MTE from Google IO 2008。另请阅读 Jeff Dean 的 highscalability.com/numbers-everyone-should-know
我添加了一个澄清的编辑。我看过其他类似性能的报告。 Google 让您为更多的前端性能付费，所以我希望他们也会让您为更多的数据库吞吐量付费。
我似乎记得过去（关于组）的讨论，即递增整数时间戳会对检索产生负面影响，因为基础数据位于同一个“平板电脑”上，这意味着提取会丢失一些数据存储区不同部分的并发级别，（好吧，也许我没有正确描述它。;-) 请注意，随着即将到来的更新，自动生成的键的 ID 将被分发。来自发行说明“dev_appserver 现在默认使用 'scattered' id 分配策略分配自动 id。”，
请注意我可能完全错了;-)

【解决方案1】：

移动到任何内存数据库。如果您有 Oracle 数据库，使用 TimesTen 将提高数倍的吞吐量。

【讨论】：

【解决方案2】：

尝试将记录拆分为不同的实体组。这可能会迫使他们转到不同的物理服务器。从多个线程或实例中并行读取实体组。对于大型表，使用缓存可能效果不佳。

【讨论】：

我们的计划是将更多的记录填充到 AppEngine 看到的每条记录中，这将有很大帮助。使用不同的实体组是类似的开发工作量，并且是我在更新代码时会考虑的事情。遗憾的是，这不是一个短期的解决方案。

【解决方案3】：

也许你可以缓存你的记录，比如使用 Memcache：

这绝对可以加快您的应用程序访问速度。我认为 App Engine Datastore 的设计目的不是为了速度，而是为了可扩展性。然而，Memcache 是。

顺便说一句，如果您意识到 GAE 根据您支付的费用提供的性能，那么也许您可以尝试设置自己的 App Engine 云：

两者都有积极的社区支持。我在本地环境中使用 CapeDwarf，它仍处于测试阶段，但它可以工作。

【讨论】：

由于数据和查询的性质，Memcache 在这种情况下无济于事。我将数据下载到本地工作站并使用 MongoDB，我可以在其中每秒检索 30k 条记录，其中包括一个复杂的查询和跨它们进行上下文处理的单线程 Python 代码。最终我们计划使用 AWS 或类似的东西。无论您向 Google 支付 0 美元并拥有一个低端前端，还是支付数百美元并拥有多个前端，数据存储区每 30-45 秒为您提供 15k 条记录，我仍然感到有些惊讶。
好吧，我明白了，为什么不使用纯 MongoDB 解决方案，那可能会更快。他们说 MongoDB 是最快的……
我们知道中长期要做什么。这个问题纯粹是在短期内做什么 - 我真的希望答案涉及向 Google 支付更多费用以提高性能。