仓库PostgreSQL数据库架构推荐答案

【问题标题】：Warehouse PostgreSQL database architecture recommendation仓库PostgreSQL数据库架构推荐
【发布时间】：2013-07-17 16:04:04
【问题描述】：

背景：

我正在开发一个允许用户生成大量不同报告的应用程序。数据存储在PostgreSQL中，具有自然唯一的组键，一个组键的数据完全独立于其他组键的数据。一次仅使用 1 个组键构建报告，因此所有查询都使用“WHERE groupKey = X;”条款。 PostgreSQL 中的数据通过并行进程密集更新，将数据添加到不同的组中，但我不需要实时报告。每 30 分钟更新一次即可。

问题：

已经有大约 4 gigs 的数据，我发现一些报告需要很长时间才能生成（最多 15 秒），因为它们需要查询的不是单个表，而是其中的 3-4 个。

我想做的是在不显着改变解决方案的技术或方案的情况下减少创建报告所需的时间。

可能的解决方案

我当时的想法是：

将一个数据库拆分为多个数据库，每个组键对应一个数据库。然后我将摆脱 WHERE groupKey = X（尽管我在每个表中的该列上都有索引）并且每次要处理的行数会大大减少。
为只读创建从属数据库。然后我必须将数据与 PostgreSQL 的复制机制同步一次，例如每 15 分钟一次（我真的可以这样做吗？或者我必须编写自定义代码）

我不想将数据库更改为 NoSQL，因为我将不得不重写所有 sql 查询而且我不想这样做。如果它是免费的并且在 Windows 上运行，我可能会切换到另一个支持列存储的 SQL 数据库（抱歉，没有 Linux 服务器，但如果我必须有的话可能会有）。

您的想法

您会推荐什么作为最初的简单步骤？

【问题讨论】：

标签： database postgresql architecture

【解决方案1】：

立即想到两个关于报告的想法：

1)。设置一些汇总（又名“聚合”）表，这些表是用户可能运行的查询的预计算结果。例如。包含按不同维度分组的计数和总和的表。这可以是一个自动化过程——通过您选择的作业调度程序运行 db 函数（或脚本）——每 N 分钟刷新一次数据。

2)。关于复制，如果您使用的是流式复制（PostgreSQL 9+），则主数据库中的更改将复制到从数据库（热备用=只读）以进行报告。

【讨论】：

1.这可能是一个可能的解决方案，但我必须重写所有使用初始表的函数才能使用这些聚合，对吧？
2.我会检查这个。这似乎是目前最简单的解决方案，但我不明白这是否真的有帮助
对于上面的第 1 点，正确，需要重写查询。我不能说到什么程度——它可以像删除一些 JOIN 并从单个表或视图中选择一样简单，而不是从多个表中选择。
对于第2点，查询保持不变，只需要更改要连接的集群和数据库。

【解决方案2】：

调整报告查询。使用解释。如果可以在纯 sql 中执行，请避免使用过程。
调整服务器；内存、磁盘、处理器。查看服务器配置。
升级 postgres 版本。
抽真空。

在 4 个中，只有 1 个需要对应用程序进行重大更改。

【讨论】：

是否有带有 UI 的 postgresql 查询分析器？我只看到了将数据转储到难以分析的文件中的嵌入式。你用过吗？
本身不是 UI，但如果您将 EXPLAIN ANALYZE 的输出剪切并粘贴到 explain.depesz.com 中，您可以更好地了解正在发生的事情。该计划是自下而上阅读的。
好吧，目前我没有使用任何分析器，幸运的是还没有 sql 性能问题：D 你可以试试 EnterpriseDB 的 SQL Profiler