数据计算

传统数据库，特别是交易（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 开发数据库应用变得更为高效。 不

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

任意的 SQL 语句都可移植是做不到的。因为各种数据库的功能并不一样，某些数据库的语法在另一种数据库中根本就没有对应的实现机制，这时当然就不可能移植了。 如果我们不用数据库的特殊功能，只在国际标准的范

我们经常听到大数据产品宣传自己性能好，“万亿秒查”是个常见的说法，大概意思就是上万亿行数据中找出查出满足条件的数据，可以秒级返回。 这是真地吗？ 看过“1T 数据到底有多大”那期的同学大概都会觉得不可

现代大数据应用的结构大概是这样的： 作为数据中心（中间部分）处于各种应用与数据源之间，对下对接多种数据源处理分析所有数据，对上要为各个应用提供数据服务，其重要性不言而喻。数据中心由于要处理的数据规模庞