数据计算

SQL 计算有序集合的位置非常麻烦，代码繁琐。Python 要方便很多，但索引不够自动化，位置运算不够丰富，复杂的任务显啰嗦，SPL 位置运算很独特，有简洁的天然序号和丰富的定位函数，可以轻松实现~

使用数据库存储数据很常见，数据库不仅提供了多种存储策略，还可以满足数据一致性的要求，基于数据库还能很方便完成数据计算，但使用数据库存储数据也有一些缺点，在一些场景下并非最佳选择。与数据库相对的是使用文

SQL 对关联的定义过于简单，关联就是两个表做笛卡尔积后再过滤，在语法上写成 A JOIN B ON …的形式。Python 关联基本上是延用 SQL 的方式，概念和方法都差不多。 esProc SP

传统数据库，特别是交易（TP）数据库，用于分析型计算经常会出现性能问题。TP数据库的性能优化主要是提高事务处理和写操作（增删改）的效率，这和分析型计算的优化方向并不一致，也就很难让分析计算跑的快。 常

MongoDB 作为主流 NoSQL 数据库，灵活自由的文档结构让它成为处理非结构化数据的利器。但用过的都懂——这玩意儿的计算能力实在不太行。 NoSQL 的代价，就是放弃了 SQL 的简单。举个例子

ORM 技术确实简化了基础 CRUD 操作，但面对复杂计算时也有很多局限性。Hibernate 的 HQL 能力明显不足，难以实现动态列运算和多层关联；JOOQ 通过 DSL 提升了灵活性，但分组计算

DuckDB 和 esProc SPL 都能嵌入到应用作为计算引擎，这里比较一下哪个更轻量一些。“轻量”不仅指体积大小，也体现在开发维护的简洁性上。 DuckDB 用起来确实方便，Python 里直接

存储过程是个让人爱恨交加的东西。 它的意义自不必提，各大老牌数据库都支持，而且经常以此来挤兑一些还不支持存储过程的新数据库。反过来，它的缺点也很明显，能见到很多开发团队在努力拆除存储过程，在应用程序中

某库表记录了特定日期计划的入库量和入库后的库存，比如 2 月 26 日计划入库 0.6，入库后库存为 3。 现在要根据指定的日期，用计划的入库量和入库后的库存倒推出初始日期，也就是零库存或负库存的那一

数据量大或者数据库繁忙都会导致数据库查询变慢，这时将数据用 esProc 导出存成文件再计算可以大幅提升性能。 数据与用例 MySQL 数据库有 orders_30m 表存储着历年的订单数据，表结构如

业务数据经常存在层次关系，比如订单包含日期、客户和订单明细，订单明细又包含价格、数量、产品，产品则包含名称和分类。 json 的可嵌套结构很适合描述这种关系，比如订单数据： 订单既有普通属性“订单号、

标准 SQL 中提供了五种最常用的聚合运算：SUM/COUNT/AVG/MIN/MAX，都是对集合计算出单值。 比如日志表中找出用户 1001 第一次登录的时间，SQL 很简单： 聚合运算还常常用在分

问题描述 时空碰撞定义 某时间区间（例如7天）被分成多个固定时长（如15分钟）的时间切片，对象a和对象b在同一时间切片内的相同位置出现过，称为一次碰撞。 规则1：相同时间切片内，多次碰撞只记一次。 规

列式存储是提高数据分析计算性能的重要手段。如果数据表的总列数很多而计算涉及的列很少，采用列存就只读取需要的列即可，能够减少硬盘访问量，提高性能。而且，同一列数据往往是同一类型的，甚至有些情况取值都很接

拥有集合化特性的程序语言能让我们用很少的语句写出针对集合的复杂运算，其中处于核心地位的是 Lambda 语法设计得是否方便，直接决定了程序语言的描述效率。 我们来从简单到复杂考查集合运算的可能情况，看

TP 太撑上 AP，这几乎是业界的通识，而且也有了多年的成功实践，这还有什么可讨论的吗？ 上了 AP 库确实能缓存 TP 库的计算压力，而且 AP 库通常计算性能更好，还能给用户带来更优的体验，这确实

从一体机、超融合到云计算、HTAP，我们不断尝试将多种应用场景融合在一起并试图通过一种技术来解决一类问题，借以达到使用简单高效的目标。现在很热的湖仓一体（Lakehouse）也一样，如果能将数据湖和数

我们知道，数据库的数据处理能力是封闭的。所谓封闭性，这里是指要被数据库计算和处理的数据，必须事先装入数据库之内，数据在数据库内部还是外部是很明确的。 数据库一般有 OLTP 和 OLAP 两个用途。

Hibernate,Mybatis 以及新兴的 JOOQ 等 ORM 技术能够方便地将数据库表映射成 Java 对象，并提供自动读写能力。ORM 技术使得用 Java 开发数据库应用变得更为高效。 不

随着数据量不断增长和业务复杂度逐渐攀升，数据处理效率面临巨大挑战。最典型的表现是面向分析型场景的数据仓库性能问题越来越突出，压力大、性能低，查询时间长甚至查不出来，跑批跑不完造成生产事故等问题时有发生