我打算为一些基本聚合设置数据库。该计划是向我们的用户提供诸如SELECT SUM(energy) WHERE ...之类的查询。
energy是一个纯数字字段。 WHERE子句更有趣，因为我们向用户展示了一些（有限的）可定制性，基本上只是AND为平等提供了一些字段。像A=3，A=3 AND B=92等
我不是DBA，但是我的表现感到刺痛。就目前情况而言，我希望数据库一次加载O(user * record)，如果一次将所有查询都触发。有没有更好的优化方法？
如果WHERE条件是固定的，那么我们可以简单地提供一个视图或以其他方式预先计算并缓存总和。不幸的是，在这种情况下，我们提供的定制WHERE表达式的能力有限，基本上为用户提供了一些AND随意填写的字段。
在我看来，这些聚合查询中的每一个基本上都会遍历整个表或表的重要子部分，每个用户查询都会遍历一次。这有道理吗？
有哪些方法可以优化这种工作流程？我是否应该分摊我的许多领域？我正在考虑使用多少个副本，尽管由于聚合查询的数据总量，我不确定|replicas|是否能够超过用户或数据的增长。
就低级性能而言，将这些查询结构化为SELECT SUM(energy)>N WHERE ...是否有意义，并希望PostgreSQL足够聪明，可以在发现小计已经超过阈值{时就尽早终止{ {1}}？
最后，NoSQL或TSDB是否可以为该工作流程提供优势，或者它们的性能可与SQL数据库媲美？
更新
由于大多数查询将按计划运行，我想我会错开它们以分散一天中的负载。但是，如果一堆活跃用户突然一次全部提交聚合查询，我仍然渴望找到更好的方法来为此负载优化表。