讨论:应不应该用存储过程?
事情起因于群里转发一篇文章《为什么阿里巴巴禁止使用存储过程?》
作者用自己的亲身经历讲解存储过程维护的不方便。
然后大家讨论存储过程的优势和缺点。
引子:存储过程
大白:存储过程在很多场景时有其优势,比如性能。但对于业务逻辑的通用方法,非常不推荐将其写在存储过程中,代码复用、扩展与客户端语言比,相差甚远。也许终究能实现,但代价与风险比客户端语言要高,得不偿失。
花也花不完:我的想法是可以用,分场景
如果应用的当,省时省力
我用的比较多
主要是性能是第一,依据自身去控制
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:
存储过程不是不好 是太容易被误用
版权声明: 本文为 InfoQ 作者【kimmking】的原创文章。
原文链接:【http://xie.infoq.cn/article/1c565e9af135cb2b1c47ae433】。
本文遵守【CC-BY 4.0】协议,转载请保留原文出处及本版权声明。
评论