SQL 可搜索缓存 - 高可扩展性 [关闭]

Question

我开发了一个提供非常通用的数据存储的网站。目前它工作得很好，但我正在考虑优化速度。

INSERT/SELECT 比率很难预测并且会因不同情况而变化，但通常 SELECT 更频繁。 INSERT 足够快。 SELECT 让我担心。有很多 LEFT JOIN。例如。每个对象都可以有一个图像，该图像存储在单独的表中（因为它可以跨越多个对象）并存储有关图像的其他信息。

每次选择最多进行 8 次连接，处理过程最多可能需要 1 秒 - 平均值约为 0.3 秒。每个请求可以有多个这样的选择。已经在 SQL 端进行了多次优化，没有太多可以做的。

除了为 DB 购买更强大的机器之外，还能做什么（如果有的话）？

在这里，Django 也不是速度恶魔，但我们仍然有一些优化。如果必须，切换到 PyPy。在 DB 方面，我有一些想法，但它们似乎并不常见 - 找不到任何真实案例。

• 为这部分使用不同的存储速度更快。我们需要事务，我们需要一致性检查，所以它可能不是可取的。
• 可搜索缓存？这里有意义吗？例如。维护以 NoSQL 或其他方式组合的所有表的平面副本。插入会更昂贵——如果一些常见的表发生变化，它需要更新 NoSQL 中的多条记录。也很难维护。

有什么是有意义的，或者它只是最快的，可以获得更多的 RAM，增加 rdbms 中的缓存大小，获得 SSD 并离开它。专注于优化其他部分，例如池化数据库连接，因为它们也很昂贵。

使用的技术：PostgreSQL 9.1 和 Django (python)。

总结一下。问题是：在优化了所有 SQL 部分 - 索引、集群等之后。当无法选择静态超时缓存结果时（不同的请求参数，不同的结果），可以做些什么来进一步优化。

---编辑 30-08-2012---

我们已经在每天检查慢查询。这是我们的瓶颈。我们只对索引进行排序和过滤。另外，很抱歉不清楚这一点 - 我们不会将实际图像存储在数据库中。只是文件路径。

JOIN 和 ORDER BY 正在扼杀我们的表现。例如。一个输出 20 000 个结果的复杂查询需要 1800 毫秒（使用了 EXPLAIN ANALYZE）。这假设我们没有使用任何基于 JOINed 表的过滤。

如果我们跳过所有的 JOINS，我们将缩短到 110 毫秒。这太疯狂了...这就是为什么我们正在考虑某种可搜索的缓存或平面副本 NoSQL。

在没有排序的情况下，我们得到了 60 毫秒，这很棒，但是 PostgreSQL 中的 JOIN 性能如何？ 是否有一些不同的数据库可以为我们做得更好？最好是免费的。

Answer 1

首先，虽然我认为在数据库中存储图像文件的时间和地点都存在，但通常情况下，此类操作会产生额外的 I/O 和内存。如果我正在考虑对此进行优化，我会将每个图像都放在一个路径中，并能够将它们批量保存到 fs.这样它们仍然在您的数据库中用于备份目的，但您可以将相对路径拉出并生成链接，从而为您节省大量 sql 查询并减少开销。通过基于 Web 的后端，您将无法让事务在生成 HTML 和检索图像之间运行得非常好，因为它们来自不同的 HTTP 请求。

至于速度，我不知道您查看的是总 http 请求时间还是 db 时间。但是您需要做的第一件事是将所有内容分开并寻找大部分时间都花在了哪里。这可能会让你大吃一惊。接下来是获取那些慢查询的查询计划：

http://heatware.net/databases/how-to-find-log-slow-queries-postgresql/

然后从那里开始使用解释分析来找出问题所在。

在决定升级硬件时，您还想清楚了解当前面临的限制。更多的内存通常会有所帮助（如果您的数据库可以舒适地放入内存中，这将很有帮助），但除此之外，将更快的存储放入受 CPU 限制的服务器或切换到 I/O 限制中具有更快 CPU 的服务器是没有意义的服务器。上面是你的朋友。同样，根据并发问题，为您的 select 语句使用热备用可能（也可能不会！）有意义。

但如果没有更多信息，我无法告诉您进一步优化数据库的最佳方法是什么。 PostgreSQL 能够在适当的条件下运行得非常快，并且可以很好地扩展。