【AICon】探索RAG 技术在实际应用中遇到的挑战及应对策略!AICon精华内容已上线73%>>> 了解详情
写点什么

在关系型数据库中运行计算

  • 2014-03-21
  • 本文字数:1577 字

    阅读完需:约 5 分钟

近日, JOOQ 的官方博客上发表了一篇文章,针对Stack Overflow 上“如何使用Hibernate 映射处理庞大的数据表”这样一个问题,作者认为有必要提醒下开发人员,不要犯 Java 开发人员编写 SQL 时常犯的十个错误中的第二项错误:在 Java 内存中处理数据。

Stack Overflow 上的问题可以归结为:从下面的中型表中计算出每个应用程序 ID 对应多少个状态为 0 或 1 的文档。用 Hibernate 该如何实现?

复制代码
AppID | DocID | DocStatus
------+-------+----------
1 | 100 | 0
1 | 101 | 1
2 | 200 | 0
2 | 300 | 1
... | ... | ...

“NO! 不要用 Hibernate!你要用 SQL。Es-Queue-EI!……”,作者认为,有许多简单的方法可以让 SQL 服务器来运行这种查询,而且时间很短,又不用在聚合之前将所有的数据加载到 Java 内存。他分别使用 GROUP BY、嵌套查询、SUM()和 PIVOT 给出了四种实现方式,并认为其中任何一种的性能都会在数量级上超过任何基于 Java 的实现。文章的结尾这样写道:

任何时候,只要合适就使用 SQL! 能用 SQL 的地方远比你想象的多。

该文在 reddit 用户之间引发了激烈的讨论。ggtsu_00 认为:

……如果计算减少了返回结果的行数,那么最好在数据库里计算。不过,许多计算是后处理或格式修改,这些最好是在应用服务器上进行。

对于 ggtsu_00 的观点,lukasedar 进行了补充,认为“争论的焦点是通过网络在处理数据的节点之间传输的数据量”。Grauenwolf 则表示,如果将该观点中的“返回结果的行数”改为“返回结果的行数或列数”,那么他也赞同。而该观点的后半部分则引发了进一步的争论。ItsMeCaptainMurphy 认为:

这要看你做什么,构建数据库通常是用来尝试并行的,对于行级操作尤其如此。……而且你的数据库服务器的性能可能比 Web 服务器或客户端更强大。那么,有些事情确实是最好在应用程序端做,但并不是所有情况,甚至不是多数情况。

不过,emn13 则认为这与数据库服务器的性能无关,而与代码性能相关:

本地或近似本地代码的性能通常是 SQL 的 1000 倍,而且可能更高。即使是像 Ruby 或 Python 这样相当慢的语言在简单表达式求值方面也可能比大部分 SQL 服务器要快。

SQL 不是一个很好的通用计算器。如果计算没能减少返回结果的行数,就不能想当然地认为一台高性能的数据库服务器实际上会超过一部手机。

……

总而言之,由于大部分计算都很简单,所以没有减少数据也没关系。但当计算代价很高时,SQL 通常是缓慢的。

为了使自己的观点更有说服力,他结合自身的经验作了进一步的说明:

1000 倍这个数量级是我在 MS SQL SERVER 上实现一个有向图节点计分算法时观察到的,不是假想的场景。

Ulukai 对上述观点表示了赞同,他还补充说

如果有非常复杂的逻辑需要执行,那么你应该仔细考虑。比如,我不会在数据库代码中执行“最短路径”算法,除非它获得原生支持。

在关系型数据库中进行计算,除了应用场景的问题,还有知识结构和使用习惯的问题。人们已经花了很多时间和精力来学习 ORM 框架的所有最细微的细节,所以他们真的不喜欢他们应该更好地学习 SQL 这样的建议。但 crimson_chin 认为:

学习任何一个而不学习另一个都会让你处于不利地位。如果学了 SQL 没有学 ORM,那你就要面临代码可能过于冗长且难以维护的风险。如果你学了 ORM 没有学 SQL,那么你就要面临自我折磨的风险,因为一个查询为了获取项的名称列表却拉回了 200 列。

但同时,他认为数据库代码难以测试、管理和维护。因此,只有在可以明确地知道是最佳实践的时候,他才会使用数据库的特性来进行开发。

总之,JOOQ 的博文虽然引发了一场讨论,但文章本身的内容似乎没有多大的争议。至于什么时候应该在关系型数据库中进行计算,什么时候应该在应用程序端进行计算,大家也有一定的共识。具体做法则要视应用场景,并根据 SQL、ORM 各自的优缺点进行综合分析和测试,而这当然离不开对 SQL 和 ORM 的学习和使用经验。

公众号推荐:

2024 年 1 月,InfoQ 研究中心重磅发布《大语言模型综合能力测评报告 2024》,揭示了 10 个大模型在语义理解、文学创作、知识问答等领域的卓越表现。ChatGPT-4、文心一言等领先模型在编程、逻辑推理等方面展现出惊人的进步,预示着大模型将在 2024 年迎来更广泛的应用和创新。关注公众号「AI 前线」,回复「大模型报告」免费获取电子版研究报告。

AI 前线公众号
2014-03-21 20:212064
用户头像

发布了 256 篇内容, 共 81.2 次阅读, 收获喜欢 11 次。

关注

评论

发布
暂无评论
发现更多内容

中国AI的下一站:从两会高地奔涌向产业河谷

脑极体

如何进行数据挖掘?

郑州埃文科技

数据挖掘 数据库

轻松应对1亿+月活,《迷你世界》背后有啥黑科技

华为云开发者联盟

分布式数据库 中间件 RDS 迷你世界

Redis二三事之事前预防和事中恢复

NoLongerConfused

3月月更

教你如何解决JS/TS里特定String进行拆分然后遍历各个元素

华为云开发者联盟

JavaScript string 遍历 字符串 元素

JavaScript深入理解之闭包

锋享前端

低代码实现探索(三十七)业务的流程,开发的框架

零道云-混合式低代码平台

三级等保是最高的吗?有什么用?

行云管家

网络安全 等保 等保2.0

【IT运维】多台海外主机运维用什么工具好?

行云管家

服务器 IT运维 服务器运维 海外主机

ICASSP 2022 | 前沿音视频成果分享:基于可变形卷积的压缩视频质量增强网络

阿里云视频云

阿里云 计算机视觉 音视频 视频编码 视频云

【51单片机】室友用一把王者时间,学会了去使用数码管

謓泽

3月月更

虎符交易所HOO持续创造今年新高,你的HOO囤够了吗?

区块链前沿News

加密资产 Hoo 虎符交易所 平台币

浏览器工作原理和V8引擎

CRMEB

【ELT.ZIP】OpenHarmony啃论文俱乐部——多维探秘通用无损压缩

ELT.ZIP

OpenHarmony 压缩算法

小白入门HarmonyOS Connect设备开发的“芯”路历程

HarmonyOS开发者

芯片 HarmonyOS 设备

TiDB 可观测性方案落地探索 | “我们这么菜评委不会生气吧”团队访谈

PingCAP

MySQL系列文章---初识MySQL中的锁

NoLongerConfused

3月月更

Java基础系列文章---异常

NoLongerConfused

3月月更

web前端培训:react高频面试题分享

@零度

前端开发 React

数字化时代下,智能运维全栈监控解决方案及案例盘点

云智慧AIOps社区

运维 解决方案 场景应用 自动化运维 运维安全

Jaeger docker部署实操

非晓为骁

Docker Jaeger Go 语言 http client

昇思MindSpore全场景AI框架 1.6版本,更高的开发效率,更好地服务开发者

Geek_32c4d0

mindspore 昇思 全场景AI框架

N个技巧,编写更高效 Dockerfile|云效工程师指北

阿里云云效

阿里云 云原生 Dockerfile 部署与维护 构建工具

Go HTTP Server 基于OpenTelemetry 使用Jaeger - 代码实操

非晓为骁

Go Docker Trace Jaeger OpenTelemetry

RocketMQ系列文章---RocketMQ整体架构

NoLongerConfused

RocketMQ

基于CREATE TYPE语法自定义新数据类型

华为云开发者联盟

数据库 数据类型 CREATE TYPE 复合类型

数据预处理和特征选择

云智慧AIOps社区

数据挖掘 机器学习 算法 特征选择 数据预处理

大数据培训:Hadoop和MPP有什么区别

@零度

hadoop MPP 大数据开发

【直播回顾】OpenHarmony知识赋能第四期直播——标准系统HDF开发

OpenHarmony开发者

直播 HDF OpenHarmony

java培训:SpringBoot高频面试考点分享

@零度

JAVA开发 springboot

企业知识管理的目标是什么?

小炮

在关系型数据库中运行计算_数据库_马德奎_InfoQ精选文章