存储过程用还是不用?我有话说!

Java技术栈

www.javastack.cn

关注阅读更多优质文章

很多朋友习惯以阿里禁止使用存储过程,来鼓吹项目中不该使用它。

我想问的是,阿里那帮程序员,为了不用存储过程,做过的那些努力,你看到了吗?在去 SP 的过程中,所使用的技术与编程模式,你会吗?

SP: Stored Procedure. 即存储过程

人云己不亦云,一直是我对自己的要求。

程序员的独立思考习惯,与其他行业从业人员相比,我认为一直占据上风。出现其他行业“群氓”的惯性思维,概率很低。这是一帮只认 0 和 1 的清醒思考份子。他们谁都不信,只相信自己经手的代码和逻辑。

该不该用存储过程,取决于很多因素。有项目本身因素,也有人员配置因素。

抛开项目说策略,就跟不以结婚为目的的谈恋爱一样。一个简单的匿名留言板,用贵上天的 Oracle 干吗,用 MongoDB,用 ElasticSearch,甚至用 Redis,不香嘛!

对信息系统理解不全面,脑袋里只有 OLTP 系统, 眼里只有 CRUD  一类的 M-I-O 应用,那么自然会觉得存储过程没有用的必要。用 Java, PHP 完全能胜任数据一进一出的功能。甚至能做得更好。

比如在迁移数据库的时候,在更换数据库软件的时候,只需在前端的 Helper, Utility 类中,更改下数据库驱动和连接,即可实现无缝转换。假如此时要把存储过程从 SQL Server 迁移到 Oracle 上,那必然得重招一批数据库开发。成本巨大,且不宜长久的事,哪家公司会做这样的好人?

再比如,在对接异构分布式数据库的时候,由前端语言接口,封装好对数据库的访问以及路由,就能自动承接各数据库来的各类型数据结构。关系型也好,半关系型,甚至离散数据,都能友好地组织起来。要用存储过程来实现,那必然要在数据库动态库上编程,使其适应各类平台的连接,参考 SQL Server HDInsight 对接 Spark 引擎的实现。

显然,动态链接库增加了数据库的复杂性和脆弱性,且不如前端实现,那么灵活与可扩展。写一个连接服务,部署到 10 台应用服务器中,就能扛起 10 倍的流量。而写一个动态链接库,放一台数据库服务器中,撑起的流量不变。

OLTP: Online Transaction Processing, 在线交易系统, 在线事务处理系统

CRUD:Create Retrieve Update Delete 即增删改查

M-I-O: Message IN And Out 消息输入输出

看到这,似乎没有一条有利于存储过程的存在。那是不是小编我就鼓吹不用存储过程了呢?我把开头的话,再讲一遍,抛开项目说策略,就跟不以结婚为目的的谈恋爱一样

时刻保持脑子可以清醒思考,是程序员的重要素质

除了 OLTP,这世界上还有一种叫做 OLAP 的应用。OLTP 系统运行多年后,承载了大量的用户数据,订单数据,行为数据。像用户画像,漏斗分析,运营决策这样的应用,大家耳朵上的茧子都听得长厚了。

这些需求一旦展开,往往牵扯到跨时长达3,5年的查询,数据量巨大,引起大量 CPU, Memory,IO   的开销,足够摧毁正常业务操作。说人话,一张报表拖死一个应用,常有的事儿。

OLAP 技术便应运而生,除了要给足这些应用硬件资源,还要搭配一些软件设计模式。在这个成熟的 OLAP 领域,不得不提 Kimball 和 Inmon 的维度建模思维和实战。广为大家所知的,便是 ETL ,Reporting 和 Data Modelling. 在整个数据管道的过程中,如果计算下聚合,都要跑前台应用程序过一遍,那么数据的流入流出,就已经花费极大的宽带流量和时间了。所以落地这些大型计算和存储,必定要存储过程来承担。

可能大家都知道,就连 Hadoop/Spark 都强调数据本地性的调优法则。这大概正是从数据库的存储过程中得到的启发。

OLAP: Online Analysis Processing, 在线分析处理

存储过程将会在很长一段时间内,继续占据商业数据库应用市场。但 NoSQL 以及分布式大数据平台 (可看成 NewSQL)这支力量,也不可小觑。很多应用不再以数据库为中心,更多采用去中心化设计。

比如以往记录日志,会选择以数据库为存储,不仅耗费大量昂贵的数据库存储空间,还加大数据库的开销。自从 MongoDB,ElasticSearch 出现之后,日志类文件最佳使用方法,便是记录到这些 NewSQL 数据库中。

这些数据库不仅仅以廉价的机器作为存储,更可以负担一些以往落在数据库上的操作。并且,这些系统出现时,就瞄准了传统商业数据库难以水平扩展的难题,他们的架构使得水平扩展集群性能变得容易。

配以这幅图,这肯定不难理解。

当中央数据库被划分为 5 大地区数据库后,服务能力提升是明显的。但传统数据库就没有这么好的扩展性。所以各家数据库服务商拼命地都往云上赶,就是这个道理。云服务扩展的便利,简单得令人发指,千百台机器,点击便可完成。前提当然是,甲方爸爸非常有钱。

那么,存储过程在这个时候,就不得不让位于分布式编程。如果写SQL的朋友,一直不往其他领域扩展,等到有大数据分布式相关项目的时候,就只能眼睁睁看着机会溜走。岂不可惜?

但,是不是这些 NoSQL,NewSQL 能直接取代传统数据库了呢,并不是。举个例子,他们现阶段难以掌控的事务控制,像MongoDB, ElasticSearch,事务控制加在了文档一层,单个文档可以保证ACID,但多个文档就需要程序员自己控制。像Redis这样的缓存级数据层,在多表聚合这类操作上,还要大大依赖前端开发人员的编程实现。

即使有程序库可以完成这些操作,那也将是类存储过程的这种实现,像MongoDB用 JavaScript 模板。那么为什么要放弃团队中会存储过程,这种已经熟得不能再熟的技术呢?这不是每个程序员必会的技能么。

程序本质上是人类思考的结果,无论用存储过程还是Java,PHP前端语言(与数据库后端相比,其他语言都可划为前端),我们完成的始终是业务的计算。那么自然是哪个方便,用哪个;哪个最有效率,用哪个。

与其纠结于用什么实现业务逻辑,倒不如考虑业务复杂度和团队协作便利性。如果有全栈工程师,从前到后,都可以玩得来,那么就让他快速迭代产品。如果前端工程师对数据库有认识上的偏差,对于调优和事务不能很好控制,又或者项目紧张,一个全栈工程师忙不过来,那么就把前端和后端独立开来,招两端各自优秀的工程师,各司其职就好。

但无论怎么样,我们最好前后及后都懂些,然后选一个精通。这可以完美避免,互相指着鼻子骂对方是猪队友的尴尬情况。

:除了数据库, 其他都可称前端;

:存储基础业务库的数据库端;

及后的后:服务 OLAP 的数据平台,即包括数据库,还有分布式大数据平台。

最近热文:

1、Tomcat 又爆出高危漏洞!8.5 ~ 10 中招…

2、Spring Boot 干掉了 Maven 拥抱 Gradle!

3、打破你的认知,数字除以0一定会崩溃吗?

4、写了个全局变量的bug,被同事们打脸!

5、Java 14 祭出神器,Lombok 被干掉了?

6、为什么 Redis 单线程能达到百万+QPS?

7、Spring Boot 2.3 优雅关闭新姿势,真香!

8、玩大发了,Tomcat 8.5 升级有坑…

9、我天!xx.equals(null) 是什么骚操作??

10、Spring Boot 2.3.1 发布, 10 个新特性!

扫码关注Java技术栈公众号阅读更多干货。

点击「阅读原文」获取面试题大全~

展开阅读全文
©️2020 CSDN 皮肤主题: 大白 设计师: CSDN官方博客 返回首页
实付0元
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值