如何在维护历史和当前数据时获得性能？

Question

我想将最近十年的股市数据维持在一张表中。某些分析只需要最近一个月的数据。当我做这个短期分析时，需要很长时间才能完成操作。

为了克服这个问题，我创建了另一张表来保存当年的数据。当我从这张表中执行分析时，它比前一个快20倍。现在

我的问题是：

1. 这是有一个单独的表这类问题的正确方法。 （或者我们使用单独的数据库而不是表）
2. 如果我有单独的表有没有什么方法可以自动更新辅助表。
3. 或者我们可以使用任何类似dematerialized视图或类似的东西来获得性能。

注意：我正在使用Postgresql数据库。

Answer 1

你想要table partitioning。这将自动分割多个表格之间的数据，并且通常会比手工完成更好。

Answer 2

我不确定PostgreSQL，但我可以确认你是在正确的轨道上。在处理大量数据时，将数据分区到多个表中，然后使用某种查询生成器来构建查询是绝对正确的方法。这种方法在数据仓库中尤其明确，尤其是在您的案例股票市场数据中。

但是，我很好奇为什么你需要更新你的历史数据？如果您正在处理股票拆分问题，那么通常使用与原始历史数据结合使用的单独乘数表来实现，以提供准确的价格/份额。

Answer 3

1. 对历史记录使用单独的表格是非常明智的。它更配有独立的数据库更多的问题，因为它不是简单的编写跨数据库查询
2. 自动更新 - 这是对的cronjob工具
3. 您可以使用部分指标这样的事情 - 他们做的出色的工作

Answer 4

我正在接近完全相同的问题。
表分区绝对是这里走的路。不过，我会分割一年多，这会给你更大程度的控制。只需设置您的分区，然后按月（或其他日期）约束它们。在你的postgresql.conf中，你需要关闭constraint_exclusion = on才能真正获得好处。这里额外的好处是，你只能索引你真正想要从中提取信息的确切表格。如果您将大量数据批量导入到此表中，则规则vs触发器和分区的结果可能会略好，我发现规则更容易维护。但对于较小的交易，触发器要快得多。 postgresql手册有很多关于通过继承进行分区的部分。

Answer 5

坦率地说，你应该检查你的执行计划，并在采取更激进的步骤之前尝试修复你的查询或索引。

索引的代价非常小（除非您进行大量插入操作），并且您的现有代码在没有修改的情况下会更快（如果您的索引正确）。

其他措施，如分配后来...