把数据取出来算还是在数据库里算，是个经典但也是个常被忽略的问题，被忽略是因为“拿个锤子看什么都像钉子”的惯性思维无处不在。这个问题的答案通常认为是取决于数据的大小和处理需求；如果数据量较小，可以直接取出来算；但如果数据量很大，算法复杂，或者需要频繁访问数据库，则更建议在数据库中进行处理，这可以减少带宽使用和数据传输的开销，同时还可以利用数据库的高性能和可扩展性。但往往数据库的高性能可能会因处理大量数据而变慢，导致应用系统的性能下降；扩展数据库的成本可能会很高，而且 AP 业务场景下，线性扩展机器的数量几乎没有效果；对于某些特殊的处理需求，SQL 可能不够灵活，不能满足要求。因此，是否在数据库中进行处理，需要根据一些更的具体情况进行权衡和决策; 另外，库内还是库外也不总是非此即彼的，有些情况将两者结合能极大的降本增效。

本文讨论的计算问题和解决方案主要是面向 AP 业务场景下的在线查询。库内计算就是指在数据库的封闭体系内，利用 SQL 计算存储在数据库里的数据；库外计算是指在应用程序一侧，利用数据计算框架提供的语言或类库完成与数据库中相同的计算任务。

👉 数据在应用程序里算的好处是什么？

• 性能优化：在应用程序中进行数据计算，可以提高单独系统的性能。 数据库集中存储了各种业务数据，需要为多个应用提供计算服务，并发任务越多响应越慢； SQL 是数据库的标配，具备简单易上手的语法，但当需要处理大量数据或进行复杂的计算时，SQL 可能无法满足高性能计算的要求，这时可以使用其他高性能计算技术，比如，esProc SPL，是一种快速、通用的数据处理框架，不仅可以在内存中处理大量数据，还提供了高性能文件格式存储数据，能有效降低数据库的压力。

• 更好的灵活性：在应用程序中计算数据可以根据需求进行自定义开发，以满足特定的业务需求。
  比如，根据前端查询情况，将高频使用的热数据通过 esProc SPL 加载到内存中，用于高速访问和计算；高频使用的温数据采用其提供的高性能文件格式进行存储，使用时直接读取文件进行计算；而极少使用的大量冷数据仍然存储在数据库中。编写 SPL 将前端查询请求任务分别路由到数据所在地进行计算（SPL 提供了相应 SQL 解析和转换功能），即热数据和温数据由 SPL 计算，冷数据由数据库计算，最后由 SPL 进行归并返回给应用端。这样大部分（高频数据）计算都由 SPL 来完成，只有少量查询会转发给数据库处理，灵活的处理带来了优质的前端查询体验。方案介绍参见 可路由计算引擎实现前置数据库

👉 数据在应用程序里算而不在数据库中计算的难题是什么？

• 代码冗长：将数据计算代码与业务逻辑代码混合在一起，会使代码变得冗长，难以维护和扩展。

• 复杂的数据处理逻辑：当数据处理逻辑变得复杂时，它会使代码难以理解和维护，影响开发效率。

• 增加错误风险：如果不熟悉数据处理技术，开发人员很容易犯错误，导致数据处理结果不正确。

• 降低代码复用性：将数据处理代码与业务逻辑代码混合在一起，会使代码难以复用，降低开发效率。

  因此，使用专业的结构化计算语言和技术进行数据处理是一个最佳选择，可以帮助提高开发效率并简化代码。

👉 不依赖数据库，在 Java 应用程序里做结构化数据计算，易用且开源解决方案是什么？

• 开源数据计算框架 esProc SPL
  主要应用于在线查询和线下跑批两个数据分析型应用场景。esProc SPL 更具备低代码、高性能、轻量级、全功能等特点。esProc SPL 提供了大量高性能算法以及高性能存储可以达到更快的计算速度；esProc SPL 可以独立使用也可以集成嵌入，辅助在线查询系统，只要引入几个 jar 包即可；还可以基于多种数据源直接计算，具备更加轻量开放的特性。商业化开源，有大量实际案例可供参考，SPL 方案与案例

• 开源数据管理框架 Apache Calcite
  使用 Apache Calcite 的优点：统一数据访问方式，通过统一不同数据源的访问方式，可以更加方便快捷地访问数据，无需关心数据源是如何实现的。提高数据查询效率，Calcite 可以对查询语句进行优化，从而提高数据查询的效率。减少数据存储空间，Calcite 支持计算的数据不必存储，只需在查询时进行计算即可，因此可以有效减少数据存储空间的使用。支持多种数据源，Calcite 支持多种数据源，包括关系数据库、文件、流式数据等。
  总体来说，使用 Apache Calcite 可以让应用程序更加灵活，提高数据访问效率，减少数据存储空间的使用，支持异构数据源的查询，它的动态和灵活的查询优化是最被广泛使用的功能。