TP 太撑上 AP，这几乎是业界的通识，而且也有了多年的成功实践，这还有什么可讨论的吗？
上了 AP 库确实能缓存 TP 库的计算压力，而且 AP 库通常计算性能更好，还能给用户带来更优的体验，这确实是数据库领域的通行做法。但是，并不表示这条路就无比通畅。

首先是成本。数据库的运维从来都不简单，一个 TP 库就已经有不少事了，现在还再要加一个，而且类型还不同，知识储备也不一样了。AP 数据库动不动就是分布式 MPP，不仅价格贵，运维复杂度也很高。有很多新的 AP 数据库快确实是快了，但功能却不足，对复杂 SQL 或以及存储过程支持得不够，这会造成较高的改造工作量。无论如何，成本飙升是不可避免的。

其次，把计算任务向 AP 库迁移也会有个尴尬。通常，不应该一次性把所有任务都迁过来，这不仅工作量巨大，也会面临很大的风险。比较稳妥的办法是逐步迁移，先把 TP 库上压力最大的任务迁出来，毕竟 TP 库只是跑得慢，并不是不能用了，分担掉一些压力后，也能跑得更顺畅了。
但这样，AP 库的选型就是个难题。我们知道，数据库是个封闭的体系，所有数据和任务都被数据库统一管理。随着数据和任务不断加入，数据库管理的内容也越来越多，这可能导致原先跑得顺畅的任务变得不那么顺畅了。初期迁移很少时，当然跑得顺畅，后期如果发现 AP 库难以支撑时，却已经积累了很多工作量了，只能尴尬地扩容。

数据库的封闭性还会造成 T+0 问题。单库天然就能实现全量数据的计算，不存在 T+0 问题。上了 AP 库后数据拆分到了两个库中，而多库混合计算对数据库本身来讲基本上是个不可能的任务，尤其是 AP 库和 TP 库类型不同的时候。要么借助专业的数据同步工具，但也很难做到非常顺畅和及时，要么就是在应用层开发，推高开发成本。
用 HTAP 库也不是个好办法，这类数据库的 AP 能力通常并不足，而且还要求把原来的 TP 库也换掉，风险太大了。

这么看来，TP 太撑上 AP，看上去是很美，其实问题多多。
那还有别的什么招吗？
esProc SPL 是个更轻量级且进退自如的解决方案。

esProc SPL 并不是一个数据库。但它拥有高计算性能，可以起到 AP 库的作用。这里有个 TPCH 100G 的测试结果（时间单位是秒）：

可以看出，esProc 的性能比 Oracle 为代表的 TP 数据库能高出数量级，可以比肩甚至超越专业的 AP 数据库。详细测试报告可参考 SPL 计算性能系列测试：TPCH

有了性能指标的保证，我们来看 esProc SPL 如何避免上 AP 库的尴尬。
esProc SPL 严格地说并不是一个数据库，而是个专业的计算引擎。它直接使用文件存储数据。esProc 没有“库”的概念，也就没有入库出库和库内库外的说法。数据文件可以按目录存放，随意搬动以及冗余，甚至可以放到云上，管理非常自由方便，数据存储的运维复杂度远远低于数据库。
和常规数据库不同之处在于，作为纯 Java 程序，esProc 可以完全无缝地嵌入到 Java 应用中执行。整个计算引擎都被内置于 esProc 的 JDBC 驱动包中，而不像数据库那样还需要有个独立服务器进程，esProc 核心包还不到 15M，加上各种第三方数据源驱动也就数百 M，甚至可以在安卓上流畅运行。esProc 就和程序员自己写的代码一样，打成一个大包，运行在同一进程内，一起享受成熟 Java 框架带来的架构优势，计算任务的运维也非常简单。

esProc SPL 不要求大一统的管理体系。数据可以分散地存储在文件中，没有元数据概念，也没有数据之间的约束要求。运算逻辑也可以分散到各个应用中，后续任务和前序任务根本不必运行在同一套硬件资源上，不会发生资源抢夺以及关联耦合导致前序任务被后续任务影响的事情。这样，我们可以轻松自如地将计算业务逐步从 TP 库中迁移到 esProc 中（其实，“esProc 中”这个说法并不贴切，正确说法是由 esProc 承担计算任务。esProc 不像数据库那样有一块自己管理的领域，它只是计算引擎，没有“中”“外”这些概念）。
当然，esProc 也允许用户把所有计算任务集中起来在指定资源上执行。是分散还是集中还是混合模式，完全取决于用户的需求和条件。所以说，esProc 是个进退自如的方案，它不会限定用户的自由度。

T+0 就更是简单。esProc SPL 是个开放的计算引擎，连逻辑数据库都不算。它不需要事先定义元数据，任何能访问到的数据源都能随时被计算，小数据（内存表）和大数据（游标）都可以支持。这样就可以轻松实现跨源计算，特别是 TP 库和 esProc 文件之间的混合计算。T+0 是 esProc 带来的一项天然福利。

esProc 没有再采用 SQL，而是有一套自己发明的程序语言 SPL。SPL 拥有 SQL 的全部运算能力：

Orders.sort(Amount) // 排序
Orders.select(Amount*Quantity>3000 && like(Client,"*S*")) // 过滤
Orders.groups(Client; sum(Amount)) // 分组
Orders.id(Client) // 去重
join(Orders:o,SellerId ; Employees:e,EId) // 连接
...

但无论如何，这需要掌握一门新的程序语言，而且也要把原来 SQL 写的计算任务改写成 SPL。用户也许会担心这会带来较大的迁移工作量。
初看一下是这样的，但仔细分析后会知道，采用 esProc 的开发工作量并不会比采用 AP 数据库高出多少，长期使用的开发效率反而会大幅提高。
简单的计算任务对应的 SQL 也比较简单，可以非常容易地移植到 AP 库中，有时甚至可以原封不动地运行。如果要改成 SPL 确实会稍麻烦些，虽然也不难，但毕竟语法形式完全不同，总要改写一遍。不过，真正费事的是那些复杂任务（所谓二八原理，80% 的工作量消耗在 20% 较难的事情上），这些 SQL 动不动几百上千行，还会用数据库的特有函数甚至存储过程。而 AP 库在这方面和 TP 库常常也是相差巨大的，即便仍然用 SQL 写，工作量也接近于重新开发，如果碰到 AP 库支持不足的功能（比如存储过程），可能还要借助外部第三方程序或者 UDF 才能完成了。

SPL 的运算功能要远远强于 SQL，对于复杂的运算，SPL 会比 SQL 方便得多。比如这个任务，计算一支股票最长连续上涨的天数，SQL 要写成多层嵌套，冗长且难懂：

select max(ContinuousDays) from (
    select count(*) ContinuousDays from (
        select sum(UpDownTag) over (order by TradeDate) NoRisingDays from (
            select TradeDate,case when Price>lag(price) over ( order by TradeDate) then 0 else 1 end UpDownTag from Stock ))
    group by NoRisingDays )

同样的计算逻辑，用 SPL 写起来要简单得多：

Stock.sort(TradeDate).group@i(Price<Price[-1]).max(~.len())

如果经常碰到的是这种任务，哪个的开发工作量更大呢？

SQL 及存储过程的调试困难是全世界都臭名昭著的，而且还看不到任何改进的迹象。SPL 则有非常方便的调试界面，这一下又能把开发效率拉开：

（SPL 代码写在格子里，这和普通程序语言很不像，参考这里 写在格子里的程序语言 ）

SPL 能够实现更多高性能算法，运算性能也强于 SQL，经常可以实现单机顶集群的效果，绝大多数情况可以限制分布式，又能节省一大笔采购和运维的成本。限于篇幅这个话题不再详述，可参考 单机顶集群的大数据技术来了 。

最后，esProc SPL 是开源免费的。在这里 https://github.com/SPLWare/esProc 。