0

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

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 部分 - 索引、集群等之后。当静态超时缓存结果不是一个选项（不同的请求参数，不同的结果）时，可以做些什么来进一步优化。

---编辑2012 年 8 月 30 日---

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

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

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

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

4

1 回答 1

3

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

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

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

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

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

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

于 2012-08-30T00:42:39.473 回答