【问题标题】:Optimising a basic group_by aggregation优化基本的 group_by 聚合
【发布时间】:2023-01-22 05:18:39
【问题描述】:

可能我太天真了,但我认为这种聚合会更快,因为它有点简单——没有任何类型的复杂连接,所有数据都在一个简单的表中。

这个问题的答案也可能是数据大小之一,而不是有效查询或数据库设置之一,但我正在寻找下表的快速聚合和总和:

id time
1 0
2 0
3 0
2 30
1 22
2 17

这个想法是按 id 分组并对时间列求和。可能有 300 到 500 个名称,平均有 300 万行。在 mongo 和 sql 中,id 列都被索引。

使用 pymongo 给我大约 3 秒的时间来对 3M 条目的静态数据库执行查询,而 SQLAlchemy 给我大约 2 秒的时间来处理相同的数据。

我可以安全地假设它应该花那么长时间输入 300 万个条目,或者我是否明显遗漏了一些东西,比如直接 SQL 查询(而不是执行基于 python 的 sqlalchemy 查询)可能更快?

另外,请注意,我想要 JSON 格式的结果,我认为这是 sqlalchemy 的缓慢部分——创建结果的 python 对象,然后继续发送。

我对使用 SQLAlchemy 和 pymongo 很熟悉并且很有信心,但除此之外没有太多,所以如果有另一个更快的数据库解决方案我肯定会考虑它,因为我想经常运行这个查询并且 2-4 秒的延迟有点不愉快。

【问题讨论】:

  • 将方法添加到表的模型以返回对象列表格式 [{}, {}, ...] 的结果会更高效吗?
  • 使用 pymongo,我运行了 "$group" 管道,并在 MongoDB Atlas 服务器和我的笔记本电脑上使用 bson.json_util.dumps 转换为 JSON 字符串。对于具有 500 个唯一 "id"s 的 3M 文档(使用 mgodatagen 插入数据库),Atlas 服务器 (v5.0.14) 花费了大约 4 秒,而我的本地 MongoDB 服务器 (v6.1.1) 花费了大约 2.6 秒。您的收藏经常更新吗? On-Demand Materialized View 在这里有帮助吗?
  • 谢谢@rickhg12hs。我意识到我在问题中犯了一个小错误,尽管它似乎不会对您的表现产生太大影响 - 有 3000 到 5000 个唯一 ID。它确实会定期更新(1-20/s),但不会经常被请求,因此按需物化视图可能会起作用。唯一的问题是我们也试图允许按需过滤结果,比如排除特定 ID 或其他一些未显示的字段(例如是否应用掩码)。我想有可能将它们分成不同的集合并聚合具体化的结果?
  • 看起来你有一些探索的可能性。没有“免费的午餐”,但增加存储空间以减少时间可能是一种有效的方法。在操作查询之前移动“过滤时间”也可以。除了基准测试之外,我不知道有什么方法可以确定。
  • 同意。只需要生成一个虚拟数据集并使用不同的选项来找到性能和定制之间的最佳平衡。我想最初的问题只是为了得到“什么是正常的”的答案,而且我得到的似乎是正常的。我确实有另一种方法,它是每秒一次的动态方法,它只根据新数据和过期数据进行计算,并将结果写入另一个表,但不允许定制查询。谢谢你的帮助。

标签: python sqlite sqlalchemy pymongo


【解决方案1】:

看起来这个处理时间似乎是正常的,加快速度的唯一方法是使用 @rickhg12hs 推荐的 On-Demand Materialized View 来生成一些常见的预先计算的数据集,如果所需的查询比这些默认值更复杂,然后只需接受 2-5 秒的处理时间。

【讨论】:

    猜你喜欢
    • 2018-02-18
    • 1970-01-01
    • 2019-11-27
    • 2021-12-17
    • 2010-12-18
    • 2017-11-03
    • 2014-12-14
    • 1970-01-01
    • 2017-08-22
    相关资源
    最近更新 更多