我开发了一个提供非常通用的数据存储的网站。目前它的工作正常，但我正在考虑优化速度。
INSERT / SELECT比率难以预测，并且针对不同情况进行了更改，但通常选择SELECT更常见。 INSERT足够快。 SELECTs让我担心。 LEFT JOIN有很多。例如。每个对象都可以有一个存储在单独表格中的图像（因为它可以跨越多个对象）并存储有关图像的其他信息。
每次选择最多可以进行8次连接，处理时间最长可达1秒 - 平均值约为0.3秒。每个请求可以有多个这样的选择。它已经在SQL端进行了多次优化，并且没有太多可以在那里完成。
除了购买更强大的数据库机器外，可以做些什么（如果有的话）？
Django在这里也不是速度恶魔，但我们仍然有一些优化。如果必须，切换到PyPy。在数据库方面，我有一些想法，但在那里它们似乎并不常见 - 找不到任何真实的情况。
是否有任何有意义的事情，或者它是否能够获得更快的内存并获得更多内存，增加rdbms中的缓存大小，获得SSD并保留它。专注于优化其他部分，如池化数据库连接，因为它们也很昂贵。
使用的技术：PostgreSQL 9.1和Django（python）。
总结一下。问题是：在优化所有SQL部分索引，聚类等之后。当结果的静态超时缓存不是一个选项（不同的请求参数，不同的结果）时，可以做些什么来进一步优化。
--- 编辑 30-08-2012 ---
我们已经在每天使用检查慢查询。这是我们的瓶颈。我们只对索引进行排序和过滤。另外，很抱歉没有明确这一点 - 我们不会在db中存储实际图像。只是文件路径。
JOIN和ORDER BY在这里扼杀了我们的表现。例如。吐出20 000个结果的一个复杂查询需要1800毫秒（使用EXPLAIN ANALYZE）。这假设我们没有使用任何基于JOINed表的过滤。
如果我们跳过所有JOINS，我们将减少到110毫秒。这是疯了......这就是为什么我们想到某种可搜索的缓存或扁平拷贝NoSQL。
没有订购，我们得到了60毫秒，这很棒，但是在PostgreSQL中有什么JOIN性能？ 是否有一些不同的数据库可以为我们做得更好？最好是免费的。
答案 0 :(得分：3)
首先，虽然我认为在数据库中存储图像文件的时间和地点，但一般来说，您将拥有与此类操作相关的额外I / O和内存。如果我正在考虑优化这个，我会为每个图像添加一个路径，并能够将这些图像大量保存到fs。这样它们仍然在你的数据库中用于备份，但你可以拉出相对路径并生成链接，从而节省了大量的SQL查询并减少了开销。通过基于Web的后端，您无法在生成HTML和检索图像之间使事务处理得非常好，因为它们来自不同的HTTP请求。
至于速度，我不知道你是在查看总的http请求时间还是db时间。但是你需要做的第一件事就是将所有东西分开，寻找大部分时间都花在哪里。这可能会让你感到惊讶接下来是获取那些查询速度慢的查询的查询计划：
http://heatware.net/databases/how-to-find-log-slow-queries-postgresql/
然后从那里开始使用explain analyze来找出问题所在。
同样在决定升级硬件时，您希望了解当前面临限制的位置。更多的RAM通常有帮助（如果您的数据库可以很好地适应RAM），这是有帮助的，但除此之外，将更快的存储放入cpu绑定的服务器或切换到I / O绑定中具有更快cpu的服务器是没有意义的服务器。顶部是你的朋友。同样，根据并发性问题，可能（或可能不会）对select语句使用热备份是有意义的。
但是如果没有更多信息，我无法告诉你进一步优化数据库的最佳方法是什么。 PostgreSQL能够在合适的条件下快速运行并且可以很好地扩展。