当前,绝大多数核心系统采用oracle,DB2的存储过程来实现的,而且不可否认的是存储过程确实好用,一个几十次数据库读写操作需要应用与数据库间几十次的数据调用往返,编写成存储过程后,变成单次往返,可以提升性能和安全性,并降低时延。
但分布式数据库场景下实施存储过程存在很多难点,毕竟数据被分散到不同的分片上,存储过程在哪里执行?跨分片数据处理的存储过程如何实现?存储过程的业务调用路由如何实现?

又或者形成分布式存储过程?
几个问题:
1、为什么核心系统一般用存储过程
核心系统一般要求稳定性高、吞吐量大、延迟低、数据一致性高,而且同时有数据处理特别简单的特点。这就导致了最好不要跟数据库多次交互(减少获取数据量与网络开销),在数据节点上直接执行简单的业务计算,然后只返回计算结果,就是一个最好办法。这个办法常见的实现就是存储过程。
2、分布式数据库怎么做存储过程
先说结论:目前的分布式数据库or分布式数据中间件,一般来说不支持所谓的存储过程。
分布式数据库,一般都是通过可以直接数据复制和分片做水平扩容和高可用,这样带来了管理的复杂性和数据一致性的复杂性。可以采用复杂的分布式事务在应用层面来解决部分问题。
但是存储过程需要执行在底层的具体数据节点上,这就意味着依然需要在上层的业务逻辑层对多个不同数据节点的存储过程执行结果进行合并处理等进一步加工,大大提升了复杂性。同时对于大型的核心系统来说,数据库厂商提供的高配置的“单机“数据库通过不断提升配置来扩展是更简单可控的办法(成本不是问题)。毕竟做大型核心系统的公司,钱都不是问题,问题是周期、稳定性、强一致性和性能。
3、有没有其他方案
如果在互联网领域,抛开强一致性之类的约束,我们考虑像“存储过程”一样把数据和计算放到一起,提升性能,降低延迟,常见的还不少,比如:
● redis里,我们用lua片段在redis里处理数据
● mongodb里,我们用js函数传到server执行
● hazelcast/ignite/voltdb,直接用java写计算代码,放到数据节点去
更多产品了解
欢迎扫码加入云巴巴企业数字化交流服务群
产品交流、问题咨询、专业测评
都在这里!



抖音算法推流核心指标是互动率而非GMV。天志互联直播抽盒系统从订单秒级上屏、一键拆盒、氛围引爆三个维度拉高互动率,驱动算法推流的正循环。

从"换皮联名"到"游戏化体验共创"——拆解彩棠敦煌联名案例的壁画修复小游戏设计逻辑、奶茶品牌联名翻车教训和中小品牌三条低成本高ROI的IP联名路径。

低代码时代品牌游戏化运营体系的"乐高式"搭建指南——从选模板、搭积分闭环、数据迭代到多活动并行管理和团队交接的全流程实操方法。

一个快消品牌用游戏化方法三个月救活240个死群的完整复盘——从签到排行榜、互动任务、习惯养成到赛季制防疲劳的六周运营节奏拆解。

游戏化社交裂变的三个底线原则深度拆解——让转发不像广告、让奖品有炫耀价值、给用户不转发的自由,加3%超级用户识别策略和三个常见翻车点避坑指南。