关于 Django/Postgres 应用程序缓存的建议答案

【问题标题】：Advice on caching for Django/Postgres application关于 Django/Postgres 应用程序缓存的建议
【发布时间】：2015-04-27 23:55:06
【问题描述】：

我正在构建一个 Django Web 应用程序，我想要一些关于缓存的建议。我对缓存知之甚少。我读过the caching chapter in the Django book，但我很难将它与我的现实情况联系起来。

我的应用程序将是 Postgres 数据库上的 Web 前端，其中包含大量数据（150GB 的服务器日志）。

数据库是只读的：应用程序的目的是为用户提供一种查询数据的简单方法。例如，用户可能会要求从服务器 X 获取日期 A 和 B 之间的所有行。

所以我的数据库需要支持非常快速的读取操作，但它不需要担心写入操作（很多 - 我会每隔几个月添加一次新数据，而这需要多长时间并不重要） .

如果发出相同请求的客户端可以使用缓存，而不是再次调用 Postgres 数据库，那就太好了。

但我不知道我应该查看哪种缓存：Web 缓存或数据库缓存。或者即使 Postgres 是最好的选择（我只是想使用它，因为它与 Django 配合得很好，而且非常健壮）。有人可以建议吗？

Django 的书说 memcached 是 Django 最好的缓存，但它在内存中运行，其中一些查询的结果可能是几个 GB，所以 memcached 可能会很快填满机器的内存。但也许我并不完全理解 memcached 是如何运作的。

【问题讨论】：

我的建议是尽可能编写最简单的程序，并将任何性能问题留给 DBA（我的意思是，真正的 DBA，而不是冒充 DBA 的开发人员）——经过微调的数据库比缓存更好DBMS 前面的层。
HTTP 缓存可以“工作”（例如，每个响应都可以缓存很长一段时间，如果数据是静态的，则可能无限期地缓存）。我想这取决于您对“工作”的定义；您使用什么标准来比较您的选择？
@PauloScardine 遗憾的是，我无法访问 DBA！不过，编写最简单的程序是个好建议：)

【解决方案1】：

您的查询绝不应返回数 GB 的数据。这样做没有实际理由，因为用户一次无法吸收那么多数据。您的结果集应该被分页，这样用户一次只能看到 10、25 个，无论结果如何。然后，您还可以将查询限制为仅从基于页码的特定索引开始一次仅获取 10、25 条记录。

无论如何，缓存搜索结果页面并不是一个特别好的主意。一方面，不同用户曾经进行完全相同的搜索的可能性非常小，而且您最终会浪费 RAM 来缓存永远不会再次使用的结果集。此外，像日志这样的东西应该是实时的。如果您返回缓存的结果集，则可能会有未包含的新的相关结果，从而掩盖了搜索的实用性。

【讨论】：

【解决方案2】：

如上所述，您对缓存可以解决的问题存在限制。当您正在构建此应用程序时，我认为您没有理由不插入 Django Haystack 和 Whoosh 并查看它的执行情况，然后切换到其他一些更多的企业搜索后端是轻而易举的事。

【讨论】：