PostgreSql和检索实时业务统计数据会导致查询时间过长：解决方案？

Question

我们有一个国家申请＆amp;用户希望获得有关某些表的准确业务统计信息。

我们正在使用tomcat，Spring Ws＆amp;在此基础上休眠。

我们想到了很多解决方案：

1. 每个用户请求的普通旧查询。问题是这些表包含数百万条记录。每个查询至少需要几秒钟。解决方案从未使用过。

2. 使用的实际解决方案：创建触发器。但创造和创造是痛苦的。难以维护（没有OO，没有很酷的EDI，没有真正的调试）。唯一有帮助的部分是可以在更高级别创建Junit Test以验证预期结果。对于表上的每个不同统计信息，我们必须为此表创建另一个触发器。

3. 使用石英框架在X分钟后整合数据。

我了解到，对于这些繁重而复杂的查询，数据库未设计。

单独的数据仓库优化只读取查询会更好。 （OLAP ??） 但我没有任何线索从postGresql开始。 （pentaho是解决方案还是仅仅是一部分？）

1. 我们如何从生产数据库中提取数据？使用一些提取器？
2. 什么时候？每天晚上？
3. 如果是定期的 - 如果数据只是每天一次丢弃在我们的数据仓库上，我们将如何设法保持接近实时的统计数据？

Answer 1

“我已经了解到数据库并非针对这些繁重且复杂的查询而设计。” 那么你需要忘掉它。数据库仅针对这些类型的查询而设计。在我责备核心技术之前，我会责怪你正在使用的软件的糟糕设计。

Answer 2

我似乎被误解了。

对于那些认为经典数据库设计用于处理具有数十亿数据查询的实时统计数据的人来说，他们可能需要阅读有关OLAP原点的文章。如果性能的答案仅仅是一个设计问题，为什么有些人会费心去设计产品呢。

“在我责备核心技术之前，我会责怪你正在使用的软件的糟糕设计。” 顺便说一句，我不使用任何软件（或pgadmin计数？）。我有两个基本的表，你不能让它变得更简单，当你有数十亿的数据要用于统计数据时，就会出现问题。

对于那些认为这只是一个设计问题的人，我很高兴听到他们聪明的回答（没有触发我知道这个问题）到一个简单的问题： 想象一下，你有两张桌子：员工＆amp;手机。员工可能有0到N部手机。 现在让我们说你有10000万员工和30 000 000部电话。

最终用户想要实时了解：
 1-每位用户的平均电话数量
 2 - 拥有3部以上电话的用户的平均年龄
 3 - 在公司工作超过10年的员工的电话数量

您可能有100个用户希望随时获得这些实时统计信息。

当然，任何查询都不需要超过1/4秒。

Answer 3

逐步总结数据..？ 频率取决于您的要求，在极端情况下，您可能需要更多硬件，但这种情况不太可能。

1. 批量加载新数据
2. 使用新数据和现有状态
计算新状态[delta]
3. 合并/更新状态
4. 将新数据插入永久表（如有必要）
5. NOTIFY wegotsnewdata
6. 提交

StarShip3000是正确的，顺便说一句。