为了获得更好的数据库计算性能，经常会采用 MPP 数据库，如 Greenplum、Vertica、IQ、TD Aster Data 等。MPP 有较好的性能，但应用成本很高。MPP 的硬件资源消耗很大，需要较高的硬件成本，如果使用商用软件还需要支付昂贵的授权费用。MPP 的运维也很复杂，每个节点需要单独维护，分布式架构下数据均匀分布和一致性保证等都会增加运维的复杂度。总之一句话，就是沉重昂贵。

但，还有什么别的办法吗？

采用 MPP 主要是为了更好的计算性能，如果能轻量级低成本地解决性能问题那就用不上 MPP 了。能做到吗？

我们仔细梳理一下当前的结构化数据（数据库）计算场景会发现，现在绝大部分场景任务的数据量并不是特别大。比如数据量较大的金融机构，一个有数千万帐户的银行，一年的交易记录也就数亿条，这不算很大，有着数百上千万账户的电商系统积累的数据也还是这种规模。除了几个头部企业，绝大多数用户场景并没有特别大的数据量，单任务的数据规模在物理上仅仅几十 GB，上百 G 的都很少，远远达不到很多大数据厂商宣称的 PB 级。

按说这个数据规模用常规数据库应该能轻松处理，但实际却不是。现实世界中的跑批任务动不动就几个小时，出个错连重跑的时间都没有；一些报表查一次要几十秒到几分钟，稍微一并发就得出去抽根烟才能看到。

于是，用户就会琢磨着上个 MPP 来提速了。

为什么数据量不大，还会出现这些情况呢？

主要原因在于当前数据库并没有把硬件跑满，硬件资源并没有得到充分利用。换个说法就是数据库的性能太低。

进一步原因有两方面。

一方面，我们看到 MPP 大量采用了数据压缩、列存、索引以及向量计算等众多工程优化手段来服务 AP 场景，有了这些手段计算效率会高很多。但这些技术却很少出现在传统数据库中，跑不快是自然而然的了。如果传统数据库也应用这些技术，性能也会提高，但很遗憾现在采用这些技术的都是 MPP。

另一方面，这些跑得慢的运算虽然数据量不大，却通常有相当的复杂性。而 SQL 本身存在限制，很多较复杂的运算实现起来非常困难，勉强写出来，其运算量也特别大。如涉及次序的多步骤运算用 SQL 不仅很难写，而且跑得也很慢。SQL 缺少像记录类型、有序运算、过程计算这些特性，很多高性能算法写不出来，只能用慢算法，所以性能很差。

跑得慢就要靠硬件来弥补，所以我们看到即使数据规模不大，数据库也搞不定，进而需要分布式的 MPP 了。

我们当然希望有高铁的速度，同时还希望有小轿车的体量。但在已知范围内我们似乎还找不到能达到高铁速度的小轿车，只能妥协上了沉重的高铁。

轻量级的 esProc SPl 弥补这个空缺，用 SPL 这辆小轿车一样可以跑出高铁（MPP）的速度！

不需要分布式

作为开源计算引擎，SPL 是专门为结构化数据处理而设计。SPL 提供的高性能机制可以充分利用硬件资源，让单机发挥出集群的计算能力，从而不需要分布式就能搞定大多数之前要用 MPP 的计算场景。

在工程上，SPL 也采用了压缩、列存、索引、向量计算等 MPP 常用的手段，保证在工程方面做到足够优秀。SPL 设计了支持这些机制的高性能文件存储，不需要封闭的数据库管理系统，文件存储可以直接分布在任何的文件系统之上，表现更加开放。不仅性能高，SPL 即装即用，表现也更轻。

更重要的是，由于 SQL 的先天缺陷，SPL 没有再基于 SQL 体系，而是采用了独立的程序语言，即 Structured Process Language。在 SPL 中，提供了更多数据类型和运算，从根本上做了革新（要知道，理论上的缺陷很难在工程上弥补）。我们知道，软件改变不了硬件速度，但如果能使用更低复杂度的算法就可以让硬件少执行一些运算，这样性能就更高了。SPL 提供了大量这样的高性能算法，像前面提到的复杂多步有序运算用 SPL 就很容易实现，写得简单的同时跑得也快。

性能高，硬件需求就少，这个关系我们已经说了多次。在实际应用场景中，SPL 用单机可以搞定绝大多数看似需要 MPP 的场景，节省硬件成本不说，单机运维也很方便。

部分案例参考：

SPL 提速天体聚类任务 2000 倍

开源 SPL 将银行手机账户查询的预先关联变成实时关联

开源 SPL 提速保险公司团保明细单查询 2000+ 倍

开源 SPL 提升银行自助分析从 5 并发到 100 并发

开源 SPL 提速银行用户画像客群交集计算 200+ 倍

多并发也能搞定

除了计算性能，分布式有时还用来应对多并发请求。对于多并发的情况，有时单机确实就不太够用了，这时就需要上 MPP 了吗？

仍不需要。

SPL 提供了云模式，可以动态根据并发请求临时启动和停止计算节点，实现弹性计算。这与 MPP 相对固定的集群模式完全不同，SPL 可以弹性应对并发请求，消耗最少的硬件资源。

前面我们提到 SPL 提供的高性能文件存储可以充分保障计算性能。但与数据库要将数据封闭在内部不同，SPL 并不绑定存储，这些数据文件在本地或异地都可以。

我们知道，数据库有元数据，元数据十分占用资源，而且随着使用元数据会越来越大，整个系统会越来越慢，一些数据冗余、空间换时间的手段也不利于实施。SPL没有元数据，使用起来很轻量。

由于 SPL 的存储和计算不绑定，加之没有元数据的约束，SPL天然支持存算分离。即使使用 SPL 提供的高性能文件，在整个系统中的表现与使用文本一样，都可以将其存放在本地或网络文件系统中，还可以直接使用 S3 等云上对象存储。在存算分离的支持下，SPL 就可以进行弹性扩展，极容易应对高并发场景，相对 MPP 灵活性和扩展性更好。

还有更多

简单技术栈

我们再来讨论一下 SPL 和 SQL 的差异。从相同点来看，二者都是用于结构化数据的计算语言。不同之处在于 SQL 的语言能力并不完善，即使只是数据任务也常常难以独立完成。比如股票连涨问题以及更复杂一些的电商漏斗运算（这些并不是多奇怪的需求，业务中经常会碰到），用 SQL 实现就非常非常困难，通常要借助 Python 或 Java 来实施。这会带来技术栈的复杂，使用和运维都不方便。

相比 SQL 有很多实现困难甚至实现不了的场景，SPL 则提供了更简洁的语法和更完善的能力。像计算股票最长连涨天数，SPL 一句就能写出来：

stock.sort(trade_date).group@i(close_price<close_price [-1]).max(~.len())

而同样的计算 SQL 则要嵌套多层用非常绕的思路实现。

除了常规的结构化计算类库，SPL 还提供了 SQL 支持不好的有序计算，以及保留分组集合的分组运算，还有不同的关联方式等等。另外，SPL 语法还设计了独特的选项语法、层次参数以及增强的 Lambda 语法，使得复杂计算实现更为简单。

关于 SPL 语法的更多内容可以参考：写在格子里的程序语言

语法简洁、能力完善带来的直接结果是开发高效，不需要再借助其他技术让技术栈更为简单，在一个体系内就能完成所有事情，使用和运维自然更加简单方便。

多样数据源

我们经常发现这样的情况，上了 MPP 性能是好了，但很不方便，多源数据都要搬进来才能算，数据时效性变差，这些数据搬进来持久化成本高，占用空间，影响运维。而且，MPP 并不能替代原有的 TP 数据库，这又导致 T+0 热计算需要跨库，很难搞。。

SPL 不仅不绑定存储，还支持多种数据源连接和混合计算，这使得 SPL 具备良好的开放性，这与数据库数据入库才能使用的封闭性截然不同。

SPL 擅长的数据包括常规结构化数据、多层结构化数据（json/xml 等）、以及字符串文本数据和矩阵向量等数学数据。特别对 json,xml 等多层结构化数据有强大的支持能力，远远超过传统数据库。所以 SPL 可以很好地和 mongodb 以及 kafka 等类 json 数据源配合，也能方便地和 HTTP/Restful 以及微服务交换数据并提供计算服务。特别地，SPL 很容易实现和 TP 数据库的混合运算，非常适合 T+0 实时查询统计。

开放性的好处不言而喻，不仅可以避免 ETL 带来的数据库容量和性能方面的问题，还可以充分保障数据和计算的实时性，对 T+0 计算场景十分友好。

更轻量

SPL 的轻量除了表现在不绑定存储、没有元数据外，使用环境也很简单，只要有 JDK1.8 及以上的 JVM 环境的任何操作系统都可以运行，包括常见的 VM 和 Container，安装后空间不到 1G。

更特别的是，SPL 除了独立部署外，还可以与应用嵌入集成，在应用内提供强计算能力。这样应用不必依赖中央的 MPP 就能获得强计算能力，应用之间的数据处理也没有耦合，使用灵活，管理也方便，不会发生多个应用抢占中央计算资源的冲突。这些都是 MPP 没法做到的。

总体来看，对于绝大部分数据量不大的场景没必要用 MPP，SPL 单机就可以很好满足。即使单机不够用（并发高），SPL 良好的伸缩性相比 MPP 也更有优势，体量更轻、技术栈更简单、运维更方便。

以前想跑 300 公里时速我们只能寄希望于建设一个全系统的高铁（MPP），现在家家（应用）都可以拥有小轿车（SPL）跑出这个速度。尽管两种工具各有利弊，但小轿车更加轻松方便是显而易见的。

或许你只需要一个能跑 300 公里时速简单轻便的小轿车！