数据库具有封闭的数据处理能力。关闭意味着要计算或处理的数据必须提前加载到数据库中。数据库数据和外部数据库数据之间有明确的界限。
数据库通常用于OLTP和OLAP。 OLTP需要数据一致性，仅在定义范围内讨论时才有意义。这将自动导致封闭的数据库系统，该系统将并且只能确保其内部数据的一致性。
但是，OLAP不需要数据一致性。但通常，用于执行它们的数据仓库使用数据库。结果，这些数据仓库也被关闭。
有时，名称中的基础部分使得很容易错误地认为数据库旨在用于数据存储，尽管事实并非如此。它们主要用于在现实情况下，尤其是在大数据方案中计算数据，几乎完全用于OLAP方案。数据库存储也主要用于提供计算。数据库具有相当不错的计算能力，比大多数其他软件产品要好得多，因此通常会部署它们以满足计算需求。
然而，封闭的系统不仅是不必要的，而且对用于计算的产品有害。这就是为什么今天的数据库在处理数据处理任务方面变得越来越尴尬。
封闭数据库系统的问题
ETL成为ELT，甚至让
典型的现象是ETL已成为ELT，甚至是让。 ETL过程按顺序涵盖了三个步骤，E，T和L。如果可以保持合理设计的订单，那将是最好的。由于数据库将计算能力锁定在其中并且无法处理外部数据，因此我们需要首先将数据加载到其中，以执行E和T，这实际上是某种计算。更糟糕的是，ETL进程中的源数据通常不是数据库数据，也不是用于处理当前计算的数据库中的至少是数据库中的数据，而是来自多个数据库。无论如何，在能够计算之前，应将数据聚集到一个数据库中。这意味着L步骤是在E和T之前进行的，破坏了E-T-L的计划顺序。
封闭的数据库系统还设置了一个检查点，导入数据和导出的数据都必须通过并进行某些检查。这是必不可少的 - 对于需要数据一致性的OLTP而不是有效的，但这是无用的，并且浪费了ETL的时间。
资源消耗并引起紧密耦合的中间桌
中间表是另一个问题。当有大量原始数据时，将其直接汇总（例如报告查询）会带来较差的性能和不良的用户体验。解决方案是执行某些聚合操作，以提前获得结果，并基于这些中间结果获得进一步的计算或数据表示/可视化。在其他时候，计算逻辑是复杂的，报告开发过程将因报告生成时的临时计算而变得过于复杂，并且为了获得清晰的过程，原始数据将预先计算，并将结果存储为中间数据。中间结果或数据通常以表格的形式存储在数据库中，称为中间表。在数据库中存储中间结果或数据的目的是利用数据库的计算能力。中间表，而不是直接使用，需要更多的处理来查询。与其他形式的存储相比，数据表可以方便地计算SQL。
前端的聚合操作不是一种静态操作，而是经常发生更改和添加，积累了越来越多的中间表。
由于强制性的先验数据加载，ETL变化和让我们还会导致许多中间表。
一方面，中间桌子占据了巨大的珍贵数据库存储空间，这导致了昂贵的缩放；另一方面，由于存储过程的更改会定期更新数据库计算资源，从而降低了数据库性能。
太多的中间表也带来了管理问题。数据库以线性方式组织和管理数据表，当其中只有少数数量时，它可以很好地工作，但是当它们太多（例如成千上万的）时会造成混乱。管理项目堆的最流行方式是多级树结构。但是，关系数据库不支持它（尽管它们具有可以理解为两级结构的模式的概念）。 RDB可以通过将表格且尴尬的名称及其分类和区分来应对这一问题，这是不便的，需要高的开发和管理技能。但是，未能通过在某些时间给表不当的名字来观察命名规则，尤其是在紧急截止日期要满足时，会随着时间的推移产生大量混乱的中间表。
中间表引起应用之间的紧密耦合。该数据库是一个单独的过程，可提供不属于任何应用程序的独立计算能力。多个应用程序共享一个数据库并访问其资源。可能是由应用程序（或模块）生成的中间表由其他或更多应用程序（或模块）使用，从而在应用程序（或模块）之间导致高耦合。即使已经脱机，也无法删除中间表，因为它可以由其他或更多应用程序使用。中间表的无尽积累加剧了数据库存储空间和计算资源的短缺。
无法处理各种数据源方案
各种数据源已在当今的应用中很普遍。不乏源自外部服务的数据。将外部数据加载到数据库中以进行计算非常不便。临时数据加载效率过低（因为数据库IO正在耗时），无法满足密集的数据库访问请求。常规时间的数据加载很容易错过最新数据，从而获得了较少的实时结果。
在数据库中加载和存储外部数据会产生许多会导致相对问题的中间表。通常，直接从网站删除的数据是多级JSON或XML格式，并且需要在关系数据库中创建多个关联表以存储它，从而使中间表问题变得更糟。
。存储程序带来的安全性和耦合问题
经常使用的存储过程具有许多缺点（例如不可迁移，难以编码和调试），但是它们支持逐步编码，并使用户能够利用数据库的计算能力。封闭的数据库只能在其中执行数据计算，但是很难在单个SQL语句中表达复杂的计算逻辑。
对查询和分析的存储程序经常发生更改。由于存储过程与数据库紧密编织，因此将存储过程的每次修改都提交到数据库管理员进行检查和编译肯定会降低工作效率。赋予程序员汇编存储程序的特权保持效率，但构成了严重的安全威胁。特权太高了，有可能错误地删除存储的过程代码，甚至是其他应用程序的数据。实际上，读取特权足以用于报告查询，并且如果不使用存储过程，则会引起数据库写入错误。
存储过程也可能导致应用之间的紧密耦合。基本原因与中间表问题背后的原因相同 - 多个应用程序（模块）使用了一个存储过程。
低数据处理性能
数据随着业务的扩展而累积到巨大的规模，查询性能降低，有时达到影响生产系统的水平。为了保持稳定的系统，人们通过将历史冷数据与当前热数据分开，通过将它们存储在不同的数据库中。查询大量的冷数据不会影响系统的稳定性，并查询少量热数据不会给生产系统带来很大的压力。
然而，冷和热数据的分离使实时查询很难（t+0查询）。封闭的数据库系统不允许或难以计算工作数据库之外的数据，例如跨数据库查询，这对于在冷数据和热数据分开存储后实时查询数据是必需的。尽管其性能不好，但仍有在相同类型数据库中获得查询的技术。在现实情况下，冷数据和热数据通常存储在不同类型的数据库中。通常在生产系统中，热数据存储在RDB良好处理OLTP中，冷数据存储在用于OLAP的数据仓库中。数据库在不同类型的数据库之间执行查询特别困难。
封闭数据库系统触发的问题在技术发展时越来越明显。在满足当今的应用程序框架的满足要求中，传统的基础式计算似乎很尴尬。
开源ESPROC SPL对这些数据库问题有有效的响应。
SPL（结构化过程语言）是专门研究结构化数据计算的计算引擎。它提供了大量的类库，支持程序计算，并在完成各种复杂的计算方面表现出色。它具有开放的计算系统，该系统支持各种数据源混合计算，而无需将数据加载到基础中。该语言支持热交换并提供标准的JDBC驱动程序。
SPL的开放计算解决方案
直接计算多元化/多个来源
SPL可以直接从不同来源计算数据，避免效率低下和非实时数据加载数据库所需的数据。由于每个数据源都有自己的强度 - 具有有效的IO，NOSQL可以存储文档数据，并且RDB具有出色的计算能力，将数据加载到数据库中会使这些好处远离。
高度开放的数据源支持包括几乎所有现有的数据源，通过有效利用数据源的优势来实现数据检索和有效的跨数据源混合计算。
让ETL作为E-T-L进行
SPL具有独立的计算功能来处理具有多种或多种数据源的各种数据处理方案。它可以完成数据库外ETL的E和T步骤，然后将准备好的数据加载到数据库中，以其原始序列实现ETL。
有时可以将ETL的结果（而不是被加载到数据库中）作为文本文件或SPL的专有数据格式存储，从而有助于获得高查询性能并减少更多数据库负载。
外部数据库存储程序避免安全问题
SPL的独立计算能力使其能够在没有数据库的情况下计算数据。像存储过程一样，SPL还支持逐步实现任何复杂计算的程序编码。因此，存储的过程两种优势 - 计算能力和逐步编码 - 找到更好的车辆，可以称为外部数据库存储程序。
创建和使用外部数据库存储过程不需要数据库写入特权，摆脱了由数据库存储过程带来的安全风险。
用文件替换中间表，以减少耦合和数据库加载
由于SPL可以通过其多样的数据源支持直接计算文件，因此我们可以将以前必不可少的中间表中的数据移出数据库中，以存储在文件系统中，并使用SPL的独立计算进一步计算中间数据功能。
如果从数据库中间表的侧面查看，则可以将上述SPL动作视为外部数据库中间表的实现。 - 外部数据库中间表从数据库中脱离了中间数据，减少了数据库负载，并可以使用文件系统的树结构来管理中间文件。该结构将中间数据及其相应的应用程序或模块（作为存储的过程）存储，从而阻止了其通过多个应用程序或模块的共享用法，从而消除了耦合。
分离冷数据和热数据以实现T+0查询
SPL提供数据路由服务，该服务根据计算要求定位正确的源并执行跨数据源混合计算。冷数据和热数据的分离使得在SQL中获得完整的数据查询变得方便，并实现上层应用程序的透明度，就好像查询基于一个数据库一样。
我们可以将历史冷数据存储为文件（具有快速的IO，灵活的压缩比和方便的并行处理），并在数据库（存储热数据的地方）和文件之间执行混合计算以实现高性能T+使用SPL的跨数据源支持能力的0查询。此外，SPL的高性能专有数据格式可以进一步提高计算性能。
开放的SPL系统与当今的应用程序框架集成在一起。 SPL可以通过集成到微服务中来替换Java来完成数据处理作业，并且可以在数据中心中充当计算引擎以处理数据，从而使其非常适应于当今的应用程序框架。
起源：https://blog.scudata.com/open-source-spl%ef%bc%9a-the-breaker-of-closed-database-computing-system/
SPL源代码：https://github.com/SPLWare/esProc