Postgresql 在生产环境中使用postgres进行数据挖掘-有更好的方法吗？

有一个web应用程序运行了一年，在其生命周期内，该应用程序收集了大量用户数据。数据存储在关系数据库（postgres）中。并不是所有这些数据都需要运行应用程序（执行业务）。然而，业务人员不时要求我提供这些数据的报告。这就产生了一些问题：

有时，这些SQL查询是长时间运行的

针对生产数据库执行要求（不酷）

每周或每月提交报告并不容易

某些部分数据的存储方式不适合这种情况 查询（查询效率低下）

我的想法（请注意，我是一名开发人员，不是数据挖掘专家）是如何改进整个报告交付过程：

创建单独的数据库，定期更新生产数据

优化数据的存储方式

创建仪表板以显示报告

问题：但是有更好的方法吗？是否有其他数据库更适合此类数据分析？还是应该研究现代数据挖掘工具

---

谢谢

有一千种方法可以解决这个问题，但我认为对你来说阻力最小的方法是postgres复制。查看本教程，了解快速的概念验证。（当你在谷歌上搜索postgres复制时，有很多点击，而这个链接只是其中之一。）下面是一个来自PostgreSQL网站wiki的链接

我之所以建议这样做，是因为它符合您的所有标准，并且不受您熟悉的技术的限制。唯一的学习曲线是复制部分

复制解决了您的问题，因为它将创建第二个数据库，该数据库实际上将成为“只读”数据库，并通过复制过程进行更新。您可以保持模式不变，但您的索引可以更改，报告/仪表盘可以自定义。这是您要查询的数据库。您的主数据库将是服务于用户的事务数据库，而复制数据库将服务于涉众

这是一个广泛的话题，所以请大家努力研究。但是，它也可以为您工作，并且可以快速扭转局面。

您真的进行数据挖掘（如：分类、聚类、异常检测），还是“数据挖掘”可以为您报告数据？在后一种情况下，所有“现代数据挖掘工具”都会让您失望，因为它们的用途不同

你是否很好地使用了Postgres的索引功能？您的场景听起来好像选择和聚合是大部分工作，而SQL数据库在这方面非常出色——如果设计得当的话

---

例如，物化视图和触发器可用于将数据处理为更适合您报告的方案。

对于报告，我们使用非事务（只读）数据库。我们不关心正常化。如果我是你，我会使用另一个数据库进行报告。我将按照OLAP原则（星型模式、雪花）设计表，并使用ETL工具定期（可能每周）将数据转储到只读数据库，以开始创建报告

---

报告用于决策支持，因此它们不必是实时的，通常也不必是最新的。换句话说，创建截至上周或上月的报告是可以接受的

如果您真的想尝试使用PostgreSQL进行数据挖掘，可以使用一些工具

最简单的方法是。它很容易安装。它有全功能的数据挖掘工具。您可以直接从数据库访问数据，处理数据并将其保存回数据库

核心方式是。它直接在Postgres中安装Python和C中的数据挖掘函数，以便您可以使用SQL查询进行挖掘

---

这两个项目都足够稳定，可以试用。

谢谢您的意见！我相信我会使用第二个数据库进行数据分析。关于你的问题“你是否很好地使用了Postgres的索引功能？”。是，也缺少索引。这也将固定在第二分贝。