需要Heroku数据库性能体验吗？

Question

我们的智能搜索引擎/聚合器正在经历一些严重的扩展挑战.我们的数据库拥有大约200k个对象.从分析和新版本来看,我们的大部分麻烦似乎都来自数据库.我们正在使用Heroku提供的最小的专用数据库(Ronin).

我们一直在研究索引和缓存.到目前为止,我们设法通过减少数据库调用和智能缓存内容来解决我们的问题,但现在甚至这似乎已经结束了.我们不断问自己,我们的代码/配置是否足够好,或者我们是否只是没有使用足够的"硬件".

我们怀疑我们从Heroku购买的数据库解决方案可能表现不佳.例如,在200k项目上进行简单计数(无连接,无任何操作)大约需要250ms.这似乎很长一段时间,尽管postgres以其糟糕的表现而闻名？

我们还开始使用基于纬度/经度的地理定位查找.两列都是索引浮点数.进行距离计算涉及相当复杂的数学,但我们使用的是非常好推荐的geocoder宝石,怀疑它运行非常优化的查询.甚至地理编码器仍然需要4-10秒来执行查找,比如说40.000个对象,只返回第一个最接近10的限制.这听起来好像很长一段时间,我们咨询的所有有经验的人说这听起来很奇怪,再次暗示数据库性能.

基本上我们想知道:我们对数据库有什么期望？可能有问题吗？如果我们决定升级,我们还能期待什么呢？

我的另一个问题是:我在这里读到,我们可以通过将整个数据库加载到内存中来提高性能.我们是否应该自己配置,如果是这样的话？

关于最后一个问题的更新: 我从Heroku支持的乐于助人的人那里得到了这个:

"这意味着有足够的内存(足够大的专用数据库)将热数据集存储在内存中.这不是你必须手动完成的事情,Postgres配置自动使用我们专用数据库上的所有可用内存.

我看了一下你的数据库,看起来你现在正在使用大约1.25 GB的RAM,所以你还没有最大化你的内存使用量."

更新数字和数字

好的,现在我有时间查看数字和数字,我将尝试回答以下问题:

• 首先,数据库由大约29个表组成,并且有很多关系.但实际上,大多数查询都是在一个表上完成的(一些额外的资源被加入,为视图提供所有需要的信息).
• 该表有130列.
• 目前它拥有大约20万条记录,但只有70k是活跃的 - 因此所有索引都作为这个"状态"的部分索引.
• 我们搜索的所有列都正确索引,没有一个是文本类型,很多只是布尔值.

问题的答案:

1. 嗯基线性能很难说,我们有很多不同的选择.所需的时间通常在90ms到250ms之间变化,选择20行的限制.我们在同一张桌子上有很多计数,从250毫秒到800毫秒不等.
2. 嗯,这很难说因为他们不会试一试.
3. 我们有大约8-10个用户/客户端同时运行请求.
4. 我们的查询加载:在新文件的数据库报告中,它说过去24小时: throughput: 9.0 cpm, total time: 0.234 s, avg time: 25.9 ms
5. 是的,我们已经检查了长时间运行的查询的查询计划.计数查询速度特别慢,通常超过500毫秒,对索引列上的70k记录进行非常简单的计数,结果大约为300

Answer 1

我已经调整了在Heroku上托管的一些Rails应用程序,并且还托管在其他平台上,通常问题分为几个基本类别:

1. 在dbme中做太多可以在db级别完成(排序,过滤,连接数据等)
2. 慢查询
3. 索引使用效率低下(不够,或者太多)
4. 尝试在db中完成所有操作(这在rails中并不常见,但确实发生了)
5. 不优化可缓存数据
6. 没有有效地使用后台处理

现在很难帮助你,因为你的问题不包含任何细节.如果您确定需要帮助的最大问题然后再问,我想你会得到更好的回应.

一些有助于我们帮助您的信息:

1. 您的行动的平均响应时间是多少？(来自新遗物,请求日志分析器,日志)
2. 您需要帮助的最慢请求是什么？
3. 该请求中的查询和代码是什么？
4. 当你在本地运行它与heroku时,网站的性能是否不同？

最后我想你会发现它不是特定于Heroku的问题,如果你的应用程序部署在亚马逊,发动机厂等,你将拥有相同的性能.好消息是我认为你的问题很常见,一旦你做了一些基准测试和分析,就不应该太难修复.

- 约翰麦卡弗里

Answer 2

我们经常问......

......这似乎很多......

......被怀疑......

......我们能期待什么......

好消息!你可以放弃和结束看似,怀疑通过测量的魔力想知道和期待!

但是说真的,你没有提到获得有用答案所需的任何基本要点:

1. 运行顺序扫描和单行索引提取的数据库的基准性能是多少？你说Heroku说你的数据库适合RAM,所以你测量时不应该看到磁盘I/O问题.
2. 这个性能是否与Heroku所说的相符？
3. 有多少并发客户端？
4. 您的查询负载是什么 - 查询和频率是多少？
5. 您是否检查过任何可疑的长时间查询的查询计划？

一旦你得到这种信息,也许有人可以说一些有用的东西.因为它代表你在这里读到的任何东西都只是猜测.