数据每天都在变化

以几个典型业务为例。订单系统里，一个订单可能会经历：创建；支付；发货；签收；退款。

用户画像也是如此：用户标签不断变化，积分不断变化，推荐特征不断变化。广告系统同样如此：曝光数据不断累计，点击率持续修正，转化数据不断回流。

这些数据都有一个共同特点：不是 Append，而是持续 Update。 数据库真正需要解决的问题，也随之发生变化。

Update 比 Query 难得多

很多开发者第一次接触分析数据库时都会有一个疑问。为什么查询那么快。更新却没有那么容易？

原因很简单。分析数据库最擅长的是顺序扫描。而 Update 本质上是一种随机修改。一条 Update，看起来只是修改一行。实际上可能涉及：主键定位；旧版本处理；索引维护；数据重写；后台 Compaction；缓存刷新；事务一致性。

当这种 Update 每秒发生几十万次以后，数据库面对的已经不是 SQL 优化问题，而是整个存储引擎的问题。

因此，真正决定实时分析能力的，往往不是一条 SQL，而是整个写入链路。

为什么越来越多团队开始关注 Upsert

如果数据每天只导入一次。那么 Update 几乎不存在。但现在越来越多数据来自：CDC；Kafka；Flink；实时业务系统。

很多团队已经不再每天导入一次。而是：每秒都在导。甚至一直导。

这个时候，一个数据库需要回答几个新的问题。例如：高频导入会不会影响查询？主键模型如何维护？部分字段更新是否需要重写整行？大量小批次导入是否能够自动合并？

这些能力，在过去的数据仓库时代关注并不多。今天却越来越成为数据库选型的重要依据。

Doris 和 StarRocks 在这个问题上的思路并不完全相同

从公开能力来看，两者都支持主键模型，也都支持行更新和部分列更新。真正开始出现差异的是持续高频更新场景。

Apache Doris 增加了灵活列更新（Flexible Column Update）、Group Commit、time series compaction，以及基于 segment 的索引按需加载和并发索引更新等机制，希望降低持续写入对系统稳定性的影响。

StarRocks 同样提供 Update 能力，但在灵活列更新、Group Commit、time series compaction 等方面，目前公开能力覆盖相对较少。

这并不意味着一种设计一定优于另一种。而是两者对于实时工作负载的侧重点有所不同。如果主要是结构化分析，查询性能仍然是核心指标。如果业务持续发生大量数据修改，那么更新链路的重要性会不断提高。

Benchmark 很难体现这种差异

很多数据库 Benchmark 都采用：导入数据。执行查询。统计耗时。这种测试方式非常适合衡量查询能力。却很难覆盖真实生产环境。

例如：持续 CDC；持续 Update；持续 Delete；持续 Merge。

因此，一个数据库在 Benchmark 上表现优秀，并不能完全代表持续更新场景下的生产表现。真正的验证方式，通常还是结合具体业务模型进行压力测试。

数据库开始重新设计写入链路

近几年，不少分析数据库都在持续增强实时更新能力。原因并不是查询已经不重要。而是企业的数据越来越"活"。数据不会等到晚上统一导入。它一直在变化。

因此，一个实时分析数据库不仅需要回答："SQL 能跑多快？" 还需要回答另一个越来越重要的问题： "数据一直在变的时候，它还能不能稳定运行？"

这也是为什么今天重新比较 Doris 和 StarRocks 时，越来越多团队开始把实时更新能力，与查询性能放在同等重要的位置。

让这些能力落到生产环境

当高频实时更新从小规模验证走向生产规模，团队往往还需要云托管、企业级部署、SLA 保障与商业支持。SelectDB 是基于 Apache Doris 构建的商业产品，提供云数仓与企业级服务，可在同一技术底座上获得生产级支持，无需脱离 Doris 生态即可满足企业落地需求。