传说阿里禁止使用存储过程?

开发 后端
针对存储过程优缺点的讨论(争论)由来已久,这里我们不妨来详细盘点一下存储过程的利与弊。

先说优点

毕竟还是有不少人在用,总要有点好处。

SQL 过程化

很少人提及存储过程的这个优点,似乎是认为理所当然。SQL 的语法要求数据处理必须写成一句,不管嵌套几层、用多少子查询,这对复杂数据处理简直是灾难。而存储过程让 SQL 也能支持分步计算,虽然是多个独立 SQL 语句拼接、虽然可能要频繁写临时表、虽然… ,但至少过程化解决了多少人的数据处理困难。

但是,过程计算并不是存储过程的专利,使用 Java 来指挥 SQL 也一样可以,仅此一条优点并不足以导致程序员偏爱存储过程。

界面与逻辑分离

界面与逻辑分离是现代应用开发的一个基本准则。相对于后台数据处理逻辑,界面会有更多样性的环境,如 PC、手机等,而且业务稳定性也不强,经常会改。如果能把两者分离,开发和维护界面时不必绑着数据处理逻辑一起改,成本就低很多。

使用存储过程能实现界面与逻辑分离。存储过程在后台数据库中运算,只要向前端提供数据,而不必关心界面的形式和异动。把所有的数据处理逻辑都写成存储过程,还有利于统一数据的出入口,易于实现数据权限管控。

再说一遍“但是”,实现界面与逻辑分离也不是存储过程的专利。只要做一个数据访问层,所有数据的进出都通过这个访问层,也会有同样效果,事实上也确实有些应用是这么做的,但在微服务流行以前并不普遍。这个原因在于开发复杂度上,处理结构化数据写 SQL 总比写 Java 要简单多得多。而微服务架构强制在 Java 中实现数据处理逻辑的机制,其实是牺牲了开发效率。

性能好

通常,使用存储过程会比在库外用 Java 指挥 SQL 完成数据处理性能更好一点。这个原因主要在于数据不出库。外部程序访问库内数据时必须通过数据库提供的接口,而这些接口的性能大都不好,特别是面向 Java 程序的 JDBC 接口。每次发出 SQL 让数据库执行都会调用这个接口,速度就上不去。如果应用程序和数据库不在同一台物理机器上时,还会有一些网络延迟,不过和接口的低性能相比并不算严重。在外部计算时,从数据库获取数据的时间常常会超过计算本身的时间。

存储过程的性能好主要得益于数据库低效的访问接口。

总结一下。存储过程的优点主要来源于两方面:一是 SQL 的数据处理能力,至少目前来看结构化数据处理尤其是复杂计算,SQL 仍然比 Java 强很多。二是库内计算的便利,数据不用出库省下的 IO 成本对数据密集型任务有莫大优势。

再说缺点

传说阿里有一条军规,“禁止使用存储过程,存储过程难以调试和扩展,更没有移植性”。我们这就来罗列一下存储过程的缺点。

移植性差

存储过程的移植确实很困难,一般业务逻辑复杂到需要写存储过程的地步,总会不可避免地用到数据库独有的特性和语法,更换数据库时这部分代码就需要重写。如果只是简单地替换函数名和参数规则(如日期转换等),那成本还不高;如果用到了新数据库不支持的某种特性,那还要重新设计算法来编写计算逻辑;如果还要再兼顾性能因素,有时候就会是个不可能完成的任务了。

调试困难

编辑调试是个大问题,存储过程的开发一直缺少有效的 IDE 环境。SQL 本身经常很长,调试式要把句子拆开分别独立执行,非常麻烦。存储过程中也常常有大量的长 SQL,当然也有同样的问题。即使是分步的运算,因为没有好的 IDE 支持,要看哪一步出错,也要把中间结果输出才行,仍然是非常麻烦。

存储过程的调试功能近年来略有起色,但离流畅实用始终差距甚远,数据库厂商似乎也无心解决。这和 Java 等拥有成熟的开发环境完全不可同日而语。困难的调试自然会导致低下的开发效率。

体系封闭

说到封闭性,其实是数据库的问题。数据库有“库”的概念,外部数据只有入库才能计算。而现代应用数据源众多,临时转入的效率很低(因为数据库的 IO 成本高),很可能跟不上访问需求,定时批量转入又很难获得最新的数据,同样影响计算结果的实时性。同时,ETL 往往有时间窗口(如当天夜里到第二天凌晨),赶上业务繁忙的时候还可能因为时间窗口不足无法完成 ETL 工作而影响第二天的业务。

不仅如此,把外部数据存储在数据库中,又会形成众多中间表,面临中间表的各种问题。而且有些互联网上取过来的数据常常是多层的 json 或 XML 格式,在关系数据库中还要建立多个关联的表来存储,会进一步加剧中间表的问题,占用过多宝贵的数据库空间。

存储过程在数据库中运算自然继承了封闭性的特点,想混合计算外部数据很不方便。

耦合性高

存储过程通常是为前端应用服务的,理论上两者应该在一起,从而组成完整的业务功能点。但存储过程与数据库紧密耦合,所以实践中存储过程与前端应用是物理分离的,且无法使用统一的技术路线。对于同一个功能点的存储过程和前端应用,维护其中一处,通常就要维护另一处,但两者物理上分离,维护因此变得很困难,而不统一的技术路线则加剧了这种困难。

存储过程与数据库紧密耦合,反而与前端应用分离,这就容易使同一个存储过程被多个前端应用共享。时间一长,哪个存储过程到底被哪些应用调用就变成了谜团。如果某个应用的计算发生变化,面对谜团一般的共享调用关系,管理员只能新建存储过程而不敢修改原存储过程。这样恶性循环下去,存储过程越来越多,谜团越来越大,终将变得不可收拾。

管理困难

存储过程的目录是扁平的,而不是文件系统那样的树形结构,脚本少的时候还好办,一旦多起来,目录就会陷入混乱。可以想象,多个项目的存储过程、同一个项目不同模块的存储过程、同一模块不同年份或不同版本的存储过程,这些如果混杂在同一个目录下,区分起来会非常困难,除非加大管理幅度,比如按项目、模块、年代、版本命名,这显然又会影响开发效率。有些项目管理较弱的团队,在开发周期紧张时,常常就顾不得这些规矩了,先赶着让项目上线再说,而上线之后这些遗留问题又容易被忘掉,结果常常一直存在很久。

安全性差

很多存储过程是为查询分析服务的,而这类业务的需求经常在变,由于存储过程与数据库紧密结合,所以程序员每次修改存储过程代码之后,都要提交给数据库管理员,由管理员编译并发布,无疑会大大增加管理员的工作负担。所以通常的做法是:给程序员赋予高级权限,至少也是创建存储过程的权限,这样就不用频繁打扰管理员了。这样做虽然方便,但存在严重的安全隐患。本来做报表查询只需要对数据库有“读”权限,而可以编译存储过程的权限就太大了,几乎可以做一切了。程序员如果失误,很可能删除或修改了数据,造成严重的安全事故。

开源SPL充当库外存储过程

从罗列的优缺点数量上看,缺点比优点多不少,所以就不难理解阿里的军规了:存储过程能不用还是不要用了。当然了,用不用存储过程完全是自己综合自己的情况考虑,如人饮水冷暖自知。

其实存储过程也并非不可替代,开源 SPL 就可以搞定存储过程的各类缺点,同时延续其优点, 实现“库外存储过程”。

集算器 SPL 是一款专业的开源数据计算引擎,提供不依赖数据库的计算能力,数据库更换不需要更改 SPL 计算脚本,解决存储过程的移植性问题;简洁易用的 IDE 环境编辑调试功能齐全,算法实现更加简单;SPL 体系更加开放,可以直接使用多样数据源计算;“外置存储过程”不依赖数据库,可随应用存放解决耦合性问题;借助文件系统的树状结构进一步解决管理问题;SPL 独立数据库运行,更不会带来安全问题。

SPL 在库外实现存储过程,不再依赖数据库,这样原来绑定数据库带来的各种问题也就解决了。

直观易用的开发环境

相对存储过程的编辑调试困难,SPL 提供了简洁易用的开发环境,单步执行、设置断点,所见即所得的结果预览窗口…,开发效率更高。

库外计算降低耦合性,提升移植性与安全性

SPL 提供了不依赖数据库的计算能力,在库外实施计算。原来不得不依赖存储过程的两个能力(计算和分步)完全可以使用 SPL 替代,实现“库外存储过程”。这样原本紧耦合在数据库中的计算逻辑可以完全独立到应用中,从而降低与数据库的耦合性。

与数据库解耦以后,数据库变化无需修改 SPL 的计算逻辑,可以做到轻松移植。同时,SPL 实现的“库外存储过程”创建和使用不需要对数据库有写权限,使用存储过程带来的安全性问题就可以彻底避免。

在运维方面,SPL 是解释执行的,天然支持热切换。可以很好适应微服务架构下多变的服务修改需求,应用修改不需要重启即时生效。

数据处理逻辑位于 SPL 文件(.splx)中,修改后实时生效,相对 Java 等编译型语言需要重启服务有很大优势。

在管理方面,SPL 文件使用文件系统管理机制,树状结构可以很清晰地存放各个应用、各个模块的计算逻辑,不会不知道有哪些模块在使用的情况,使用和管理都很方便。

多源支持与开放体系

不同于数据库需要数据先入库再计算,SPL 面对多样性数据源时可以直接计算。数据入库不仅时效性差,也无法保证数据的实时性。此外不同数据源有各自的优点,文件的 IO 效率很高,NoSQL 可以存储文档数据,RDB 计算能力较强,数据入库就无法享受这些优点了。

SPL 提供了开放的数据源支持,你听说过还是没听说过的数据源几乎都能支持,不仅可以连接取数,还可以进行跨数据源混合计算。SPL 可以充分利用各类数据源的优点后,再实施跨源计算也更加高效。

开放体系下,不再有“库”的概念,充分利用各类数据源的特点,发挥其优势。

支持过程的简洁代码提高开发效率

存储过程虽然支持过程计算,但 SQL 本身在实现复杂计算时就比较困难,这是由 SQL 的特性(缺乏离散性、集合化不彻底等)决定的,比如根据股票记录查询某只股票最长连续上涨天数,SQL(oracle)的写法如下:

SELECT code, MAX(ContinuousDays)-1
FROM (
SELECT code, NoRisingDays, COUNT(*) ContinuousDays
FROM (
SELECT code,
SUM(RisingFlag) OVER (PARTITION BY code ORDER BY day) NoRisingDays
FROM (
SELECT code, day,
CASE WHEN price>
LAG(price) OVER (PARTITION BY code ORDER BY day)
THEN 0 ELSE 1 END RisingFlag
FROM stock
)
) GROUP BY NoRisingDays
)
GROUP BY code

可以尝试读一下这个 SQL 在算什么。是不是很绕?其实按照分步解法,只需要 3 步就能搞定,根本不用这么绕来绕去。

而存储过程是用 SQL 实现的自然继承了这个缺点,我们经常能在项目中看到上千行、上百 KB 存储过程的情况,就是因为 SQL 对复杂计算支持不好的缘故。

SPL 不仅支持天然支持过程计算,数据处理可以分多步、按照自然思维一步一步实施,而且提供了丰富的计算类库和敏捷语法,基于 SPL 可以更容易实现复杂计算。

上一段代码看一下效果:

【计算目标】要找出销售额占到一半的前 n 个客户(大客户)的订单情况。


A

1

=file(“/opt/ods/orders.csv”).import@tc()

2

=A1.groups(customer;sum(amount):amount).sort(amount:-1)

3

=A2.sum(amount)/2

4

=0

5

=A2.pselect((A4=A4+amount,A4>=A3))

6

=A2.(customer).to(,A5)

7

=A1.select(A6.pos(A1.customer))

通过分步的方式,先找到符合条件的大客户,再查询这些客户的详细订单信息。这些计算都是在库外完成的,甚至可以使用文件数据源。从实现的过程来看,SPL 的过程计算比存储过程更加优秀,语法也更为简洁。

而前面提到的计算某只股票最长连续上涨天数,SPL 的实现是这样的:


A

1

=db.query("select * from stock order by day")

2

=A1.group@i(price<price[-1]).max(~.len())-1

按交易日排好序,将连涨的记录分到一组,然后求最大值 -1 就是最长连续上涨天数了,完全按照自然思维实现,不用绕来绕去。SQL 虽然比 Java 在某些场合方便了点,但仍然差很多,SPL 不仅支持过程计算,实现复杂计算也更简单,比 SQL 更有优势。

降低数据库负担并获得更高性能

不过,SPL 是一种库外计算引擎,需要将数据从数据库中取出来再计算。这样在涉及数据量较大时,可能会因为数据库 IO 性能低下导致低性能。

这一点,SPL 也有应对方法,可以实现数据外置。将数据库中大量历史冷数据外置到文件中,使用 SPL 读取文件直接计算,这样不仅可以降低数据库负担(数据库不再需要承担过多的数据存储和数据计算工作自然压力降低),基于文件还可以获得更高的 IO 效率。

将大历史数据外置后,借助 SPL 的多源混算能力,还很容易实现 T+0 查询。从数据库中读取当期热数据,从文件中读取历史冷数据,二者混合计算完成 T+0 全量实时数据查询。

此外,使用 SPL 还能获得更高的运算性能。

SPL 提供了众多高性能数据存储和高性能算法机制,SQL 中很难实现的高性能算法及存储方案用 SPL 却可以轻松实现,而软件提高性能关键就在于算法和存储。

例如,SPL 可以把 TopN 理解为聚合运算,这样可以将高复杂度的排序转换成低复杂度的聚合运算,而且很还能扩展应用范围。


A


1

=file(“data.ctx”).create().cursor()


2

=A1.groups(;top(10,amount))

金额在前 10 名的订单

3

=A1.groups(area;top(10,amount))

每个地区金额在前 10 名的订单

相比之下,SQL 描述 TopN 会涉及大排序,性能非常低下,只能寄希望于数据库的优化。但在稍复杂的情况(比如 A3 中伴随分组运算)数据库优化器就会失效。

总体看来,SPL 可以作为存储过程很好的替代和延伸。

责任编辑:庞桂玉 来源: Java技术栈
相关推荐

2021-06-17 06:19:20

存储SQL数据库

2020-11-02 13:24:49

MySQL数据库存储

2009-11-03 15:13:13

ADO .NET存储过

2009-05-13 10:29:01

存储过程OracleJava

2010-09-14 10:16:57

sql server

2010-11-12 12:01:08

Oracle存储过程

2011-03-22 09:05:04

存储过程益处

2010-11-16 14:30:32

Oracle存储过程

2011-04-28 09:36:22

海量数据存储

2009-01-19 08:59:04

PHP调用MySQL存储过程MySQLi扩展

2010-10-26 14:50:11

oracle存储过程

2011-07-08 16:07:41

Oracle job存储过程

2011-04-11 09:16:31

Sybase存储

2010-10-20 16:17:17

SQL Server角

2020-09-08 16:25:18

Apache BeancopyJava

2020-07-30 12:16:33

阿里巴巴Apache对象

2009-11-11 11:19:57

ADO.NET使用

2009-10-22 15:09:40

CLR存储过程

2020-09-22 11:40:53

BigDecimalequalsJava

2010-10-09 16:41:54

MYSQL存储过程
点赞
收藏

51CTO技术栈公众号