6

讨论:应不应该用存储过程?

 3 years ago
source link: https://kimmking.blog.csdn.net/article/details/106098692
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client
讨论:应不应该用存储过程?

事情起因于群里转发一篇文章《为什么阿里巴巴禁止使用存储过程?

作者用自己的亲身经历讲解存储过程维护的不方便。

然后大家讨论存储过程的优势和缺点。

引子:存储过程

大白:存储过程在很多场景时有其优势,比如性能。但对于业务逻辑的通用方法,非常不推荐将其写在存储过程中,代码复用、扩展与客户端语言比,相差甚远。也许终究能实现,但代价与风险比客户端语言要高,得不偿失。

花也花不完:我的想法是可以用,分场景

如果应用的当,省时省力

我用的比较多

主要是性能是第一,依据自身去控制

Steven:用起来,比较难控制,把握度

曾经在做ERP的时候把整个计划翻单用存储过程实现

然后没有人能改,牵扯表太多,逻辑有太复杂,那时候有些炫SQL的感觉,现在想来比较坑人

后来项目,部长禁止存储过程

康利山:现在很多公司, 是一刀切, 不让用不是说这个东西不好, 只是大家场景可能用不熟导致安全问题

Steven:如果人员变化比较频繁,存储过程的确会增加业务理解时间,相对于牺牲些速度,也不是很在意了吧。写不好,速度反而更慢。写得好,自然是省事、省力

花也花不完:

不是这样你们是要性能还是要可读,想好

存储过程,对他限制,一定是没有能力去驾驭

不能怪存储过程

一个存储过程4000多行代码,我写过,解决了20TB数据的处理时间有原来8小时压缩到7分钟处理好

存储过程是一个双向的,关键是看你怎么去用好和管理好,性能是一个坎

场景:低延迟

kimmking:高效低延迟,一定是数据和计算放到一起,远古时代是存储过程。现代则是redis+lua,voltdb/hazelcast+java这种。我们叫 数据亲密性 data affinity。

看你要啥,一般情况,确实没必要用存储过程

存储过程,即不好编写,也不好调试,不适合大规模的业务系统协作开发

早期像银行核心的业务就没几个人懂,都是年纪大的老专家(中医,划掉),他们写好存储过程,外面用什么东西封装起来,变成指令,给前置系统调用就成了。这样,核心是稳定的,业务也是二十年不变的。

现在的互联网,上午定的需求,下午就不行了,你得敏捷。

花也花不完:找我,我可以玩转它

kimmking:哈,,,所以,企业需要的不是一个能搞定它的专家,而是一帮搬砖的,也能一起干活。

这叫软件开发的分布式。

就像我们用廉价pc的集群,去代替小机,mainframe,高端存储。

smith :

深度绑定了oracle 要换其他数据库很难

kimmking:

一样,我第一份工作是用的db2

10来年前,每年license2000-3000万,单位一旦过几年培养了一批db2专家,就直接去了IBM的DB2团队。

康利山:这差距也太大了吧

kimmking:

可以预期,存储过程里,可以用cursor一点点往前走,又抛去了网络开销

花也花不完:

 有一种东西交工具化,我不相信人可以一直坚持下去,让程序去做吧,该放手了

kimmking: 肯定在数据量大的时候,会快。

也是工具化,只是工具不同,

一般企业级开发,提倡快速开发框架RDP,半成品的脚手架之类的

花也花不完:

有空了,我们聊聊,我给你看看黑科技

kimmking:

说个关键词看看

vonneumann:

很多现代工程实践和设计理念确实没法做在存储过程里 太难管理了

kimmking:

我一直搞核心系统,低延迟交易我比较关注,这一块的黑科技,大概就是SPDK,RDMA,PM之类的

绕过操作系统通信,硬件加速,持久化内存。

花也花不完:

不知道怎么说了,就像c++一样,没有几人能玩转了

花也花不完:

在说存储过程好,估计有人要打我了

韩铮 vonneumann:

说极限场景意义不大哈 毕竟不是单打独斗 有几个人能用存储过程搞70倍性能优化

具体的几个技术

kimmking:

redis支持lua,大家知道吧

redis看做数据库,然后做点简单的计算,丢一段lua脚本给redis server,他算完了给你结果。

避免了大量的trip round

hazelcast,内存网格,支持动态的给一些类,同步到内存数据节点,计算完了给你结果,可以分布式的做聚合

voltdb更牛逼了,内存+关系数据库,作者是图灵奖获得者,数据库领域宗师,直接支持用java写“存储过程”

花也花不完:

接近内核运算

8小时这么快?以前SAP有个系统出报表要7天,客户居然习惯的

kimmking:

我们去年上半年系统的调研和POC过,voltdb真心nb

花也花不完:

越贴进内核运算,是越好的,其它的就是概念

kimmking:

绑定cpu,cache对齐

低延迟的核心要素就是,离cpu能有多近就多近,离io能有多远就多远

vonneumann:

存储过程不是不好 是太容易被误用


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK