数据库为什么要分嵌入的和独立的？
提到数据库首先想到的会是 Oracle、DB2、SQL Server、MySQL、PostgreSQL 等大名鼎鼎的产品，这些数据库都采用独立进程的方式运行，即独立部署数据库服务通过接口与应用交互，这是目前数据库的主流。除了数据库服务器（Database Server）外，还有一种可以与应用集成使用的嵌入式数据库（Embedded Database），不需要部署独立的数据库服务，与应用共属同一进程，作为应用的一部分使用，比如 SQLite、Derby、H2、HSQL DB 等。
为什么数据库会分独立和嵌入的呢？而且这两类产品往往互不相通，基本都只属于某一类。
我们知道，独立的数据库服务可以支撑业务量更大的应用系统，我们可以给数据库服务器配置更好的硬件，甚至搭建数据库集群来同时满足多个业务系统的数据存储和访问的需要，显然这是一个重型方案。
我们也知道，有的应用可能很小，再部署重型的数据库服务器显然不太现实，这时嵌入式数据库就发挥作用了，比较典型的是现在的各种移动类应用。嵌入式数据库的体积小、易集成、可移植、功能还相对齐全就成了优点，像 SQLite 整个才几 M，非常适合随小型应用集成使用。
还有另一种常见的场景。有时企业部署了独立数据库（比如中央数据仓库）为多个应用服务，但每个应用的还有很多个性化需求，中央数据库满足不了；或者由于中央数据库压力过大，没办法满足每个应用的所有需求；如此种种。但应用的需求又要满足，怎么办呢？
选择有两个，在贴近应用处再部署一个独立的数据库专门为本应用服务，这时选择与中央数据库同一类型可以更方便地同步数据、移植程序，但部署独立的数据库比较重，同时要运维多个独立数据库很繁琐。另外一种做法是使用嵌入式数据库，集成到应用中随应用一起部署维护很轻很方便，但由于嵌入式数据库与中央数据库类型不同，在使用时又要面临学习两套数据库，SQL 不兼容还要移植程序等问题。
其实有时候到底应该使用独立数据库还是嵌入数据库并非泾渭分明，完全取决于应用的需要。独立数据库不够用了就可能需要嵌入数据库分担压力；同样，嵌入数据库容量不足时就可能需要再部署独立数据库。如果一个数据库同时支持两种模式，上面提到的这些问题就能很好解决了。但很遗憾，现在绝大部分数据库都只支持一种模式，没法同时兼顾两种场景。
不过，少并不是没有，esProc SPL 就可以充当同时支持独立和嵌入使用的分析型数据库。
严格来讲，SPL（Structured Process Language）是一个计算引擎，主要面向结构化和半结构化数据计算而设计。由于其功能完全超过了当前分析型数据库的能力范畴，因此可以替代传统意义上的数据库使用。
SPL 既可以单独部署独立服务，甚至搭建集群，也可以直接与应用集成嵌入作为应用的一部分使用。
先说嵌入能力。
SPL 采用纯 Java 开发，可以在任何提供 JVM 的环境下运行，其核心包不足 15M，天然适合与 Java 应用集成，甚至可以在 Android 上流畅运行。
SPL 虽然采用 Java 开发，但本身却是解释执行的，支持热切换。随应用部署后，当计算需求改变可以随时更改 SPL 脚本，实时修改，实时生效。
再看独立部署。
作为专门面向分析场景的计算引擎，SPL 既支持单机部署也支持分布式部署，支持集群负载均衡和容错机制。SPL 设计的集群规模相对较小，将更多的资源用于计算（而非管理和调度）。不过，由于 SPL 的高性能（存储和算法），经常单机就能满足大部分应用需要。更多参考： 有了轻量级的 SPL，MPP 还有多大必要？
SPL 提供了 JDBC/ODBC/RESTful 接口供应用调用，这点与其他独立数据库类似。
我们前面提到一个场景，当中央数据库无法满足应用需要时经常要再单独部署一个贴近应用的数据库或者使用类型不同的嵌入式数据库，这两种做法的缺点都很大。现在有了 SPL，就可以只应用一种技术（SPL）就能满足独立和嵌入使用需求，简单轻量易维护，同时一种技术栈也更方便。
但这个场景还存在一个问题，应该将哪些数据同步到应用端数据库使用？量小了不够用，量大了又容纳不了。SPL 为了解决类似的问题，更好地结合两种模式的使用，提供了计算路由的机制。只将应用使用的高频热数据同步过去，而大量低频数据仍然存储在中央数据库中，这样大部分计算就都可以在应用中实施；要查询低频数据时，SPL 会将计算自动路由到中央数据库中完成，从而实现应用的所有需求。这样既能满足应用的需要，使用和运维也更简单。
除此以外，SPL 还提供多源计算支持，无论何种数据源 SPL 都可以实时接入并计算，这样可以节省传统数据库入库的动作，灵活性和实时性都更强。
有了 SPL 这些能力以后，独立还是嵌入不再是单选，结合应用需求自由选择或组合都好。不管是传统大型应用，还是小型应用、微服务、移动应用，用这一种方式就都能搞定了。
