晚上十点，老张的小炒店打烊了。他翻开三个账本，叹了口气：今天的流水散在收银纸、手机备忘录和外卖平台报表里，怎么也对不上。这个场景，像极了今天很多公司的数据库——数据散落在单机 MySQL、Redis 缓存、ClickHouse 数仓里，事务与分析彼此割裂。要治好这种“账本焦虑”，我们需要一次数据库架构的进化。这篇文章用“路边小餐馆 → 连锁餐厅 → 智能餐厅”的成长故事，讲清楚云原生存储里的两个重要概念：NewSQL 和 HTAP。NewSQL 像连锁总部，把分布式事务、自动分片这些“统一账本”能力做好；HTAP 像智能厨房，在出菜的同时实时算出每道菜的成本和利润。读完你会知道：它们分别解决什么问题、差异在哪、怎么选型。

岗位关联

理解 NewSQL 与 HTAP，能帮你在设计数据架构时找准技术方向，让事务与分析不再“打架”，是 AI 应用落地与数据平台建设的关键能力。

目录
  1. 可视化演示
  2. 1. 云原生之变
  3. 2. 传统之困
  4. 3. NewSQL 原理
  5. 4. HTAP 创新
  6. 5. 全面对比
  7. 6. 选型指南
  8. 7. 实践案例
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

展示NewSQL分片与Raft副本的一致性机制、HTAP事务与分析统一引擎的处理，以及两类架构的读写性能对比，可切换三种模式观察。

本节配有交互动效（进入视口后自动加载，约 3KB）。

NewSQL：分片与副本 数据按范围或哈希分片到多个节点 每个分片通过Raft协议维护多副本保证高可用 Raft多数派 = 半数以上副本确认 跨分片事务用2PC或优化协议保证原子性。

1. 云原生之变

十年前街角有一家“老张小炒”，菜单十道菜，收银靠手写，厨房只有一个人。顾客一多，老张不是没想过扩张，但他最怕新店开张后账目、菜谱、采购全部失控。直到他决定把餐厅“体系化”——菜谱统一、流程标准、后厨设备可复制。这个决定，就像传统软件向云原生架构的迁徙：应用从“一次性交付的代码”变成“随时可复制、可弹性伸缩的标准化服务”。

云原生不是某一项单一技术，而是一整套方法论。容器让应用像集装箱一样标准化，微服务把庞大系统拆成小团队自治的小模块，Kubernetes 负责自动化调度与故障自愈，DevOps 让发布变成流水线。数据库作为业务数据的底座，同样被要求“云原生”：按需扩容、故障自愈、资源隔离。这也正是 NewSQL 和 HTAP 诞生的时代背景——没有云原生这个“购物中心”，再好的连锁餐厅也无处扎根。

传统数据库跑在物理机上，CPU、内存、磁盘被绑死在一个“机箱”里，扩容只能换更大的机器，也就是所谓的“垂直扩展”。云原生数据库则采用“存储与计算分离”：计算节点只管跑 SQL，可以像加开档口一样快速增减；存储节点用分布式盘保存数据，通过多副本保证可用性。流量高峰时加计算节点，低峰时缩容省钱，这是“水平扩展”的典型形态。数据量也在飞速膨胀：

老张的连锁店后来不再关心“这台服务器是几核”，而是像租商场铺位一样按需使用底层资源。这就是云原生带来的第一步变化：地基标准化。后面的所有故事，都从这块标准化的地基上长出来。

D(t)=D0×2 t/Tdouble\displaystyle D(t) = D_0 \times 2^{\,t / T_{\text{double}}}
这个公式是说：业务数据量会按照“翻倍周期”指数增长。T_double 越小，数据涨得越快，越需要弹性架构。
  1. 初始数据量D_0 是当前的数据基线，例如 1 亿条订单记录。
    D0D_0
  2. 翻倍周期T_{\text{double}} 是数据量翻一倍所需的时间，比如 12 个月。
    TdoubleT_{\text{double}}
  3. 指数增长时间每走一个周期，数据量就乘一次 2，增速远超线性。
    2 t/Tdouble2^{\,t / T_{\text{double}}}
  4. 整体预测D(t) 表示 t 时刻的数据总量，用来倒推架构是否需要“弹性底座”。
    D(t)=D0×2 t/TdoubleD(t) = D_0 \times 2^{\,t / T_{\text{double}}}

2. 传统之困

老张的店越开越多，账本却还停留在“每家分店各记各的”。月底财务一合计，发现 A 店记的采购、B 店记的销售，对不上账。这就是传统单机数据库在业务增长后的真实挣扎：数据量大了、并发高了，单台机器的 CPU、内存、磁盘先撑不住。

为了让数据库“扛住”，常见做法是加缓存、加只读从库，把读请求分摊出去。可一旦写入量也上来，或者数据总量大到单机磁盘装不下，这些手段就到头了。工程师们开始“分库分表”，也就是把一张大表按某个键拆到多个数据库或数据表里，期望每台机器只承担一部分数据。

分库分表确实解决了容量问题，却带来新的连锁反应：跨库 JOIN 做不了，跨节点的分布式事务难以保证，原来一个事务涉及的多表可能被拆到不同分片；当节点数 N 变化时，数据映射关系还会大洗牌：

账本碎片化之后，店与店之间互相“欠账”，老张发现真正缺的不是更多账本，而是一个能统一对账的总部系统。数据库界也一样：分库分表只是权宜之计，人们开始呼唤一种既能像单机一样写 SQL、又能像分布式系统一样扩展的架构。

node=hash(key) mod N\displaystyle \text{node} = \text{hash}(\text{key}) \bmod N
一旦 N 从 4 变成 5，几乎一半的 key 都要重新迁移，这就是扩容时的“rehash 风暴”。
  1. 计算哈希值对主键 key 执行哈希函数，得到一个分布相对均匀的整数。
    hash(key)\text{hash}(\text{key})
  2. 对节点数取模用 N 取模，决定这条数据最终落在哪个分片上。
     mod N\bmod N
  3. 节点数变化扩容缩容时 N 改变，绝大多数 key 的落点跟着改变，触发大规模数据搬迁。
    node=hash(key) mod N\text{node} = \text{hash}(\text{key}) \bmod N

3. NewSQL 原理

连锁总部的做法是：统一菜谱、统一下单系统、统一对账。每家分店不用再单独记账，“账”被总部用一套系统管起来。NewSQL 的思路完全一致：既要 SQL 这种成熟的声明式查询语言，又要分布式系统水平扩展的能力，还要保证任何时刻读到一致的数据。

它和传统的“分库分表中间件”不同点在于：数据怎么拆、怎么路由、怎么恢复，全部由数据库自己管理。你创建一个表，它会自动拆成多个分区并在多个节点上存副本；节点故障时，副本自动晋升。开发者依然写标准 SQL，感知不到底层有几台机器。

这里最核心的技术之一是分布式事务。当一条业务操作要修改多个节点上的数据时，数据库必须保证“要么全部成功，要么全部失败”。常用方案是两阶段提交（2PC）：先问所有节点“你们能提交吗？”，全部回答“能”之后，再统一发“提交”命令。这个过程的固定开销如下：

老张后厨上菜前，总要先和分店确认两遍：菜备齐了吗？确认后再说“上菜”。虽然比小饭馆多了一道工序，但全国连锁的账目永远严谨。NewSQL 正是用这点“额外确认”，换来了极高的数据一致性。

Tcommit=2Troundtrip+Tfsync\displaystyle T_{\text{commit}} = 2T_{\text{roundtrip}} + T_{\text{fsync}}
两阶段提交至少需要两轮网络往返，外加一次日志刷盘，所以它比单机事务慢，但保证了全局原子性。
  1. 协调者发 prepare协调节点向所有参与者发送“准备提交”请求，等待全部确认。
    TroundtripT_{\text{roundtrip}}
  2. 参与者写日志每个参与者把事务写入本地重做日志并刷盘，保证断电后也能恢复。
    TfsyncT_{\text{fsync}}
  3. 两轮网络往返prepare 和 commit 各需一次完整往返，合计两倍往返时延。
    2Troundtrip2T_{\text{roundtrip}}
  4. 求和得到总时延所有耗时相加，就是一次分布式事务从开始到提交的最小时间。
    Tcommit=2Troundtrip+TfsyncT_{\text{commit}} = 2T_{\text{roundtrip}} + T_{\text{fsync}}

4. HTAP 创新

连锁店有了统一账本，可老张还想知道“今天哪道菜最赚钱、哪个门店库存快见底”。传统做法是打烊后让财务把所有订单重新算一遍，第二天早上才能看到报表。智能餐厅却不是这样：后厨炒菜的同时，大厅大屏实时跳动着每道菜的成本、利润和库存。

NewSQL 这类 OLTP 数据库擅长处理“下单、扣库存”这类事务，但分析型查询往往需要全表扫描、聚合计算，行式存储跑起来很慢。于是传统架构把数据定期通过 ETL 搬到独立数仓，分析延迟按小时计。HTAP 的目标是打破这堵墙：一份数据，既能支撑事务，又能支撑实时分析。

HTAP 的关键技术是“行列混合存储”与“实时数据同步”。行存引擎服务点查和更新，列存引擎服务聚合和分析；事务写入后，通过日志或 MVCC 版本机制，把新增数据近乎实时地同步到列存侧。应用只需发出一条 SQL，数据库内部自动路由到合适的引擎：

当大厅大屏上的库存数字以秒级跳动时，老板才能第一时间决定要不要下架某道菜。HTAP 就是这台大屏背后的引擎，它让“边炒菜边算账”从梦想变成现实。

LHTAP(AP)≈LTP+Lsync\displaystyle L_{\text{HTAP}}(\text{AP}) \approx L_{\text{TP}} + L_{\text{sync}}
分析延迟约等于事务写入延迟加同步延迟。同步延迟足够小，分析就接近实时——这正是 HTAP 的“近实时”承诺。
  1. 事务写入延迟L_{\text{TP}} 是事务从发起到提交的时间，包含网络和刷盘。
    LTPL_{\text{TP}}
  2. 同步延迟L_{\text{sync}} 是行存引擎把增量数据同步给列存引擎的时间。
    LsyncL_{\text{sync}}
  3. 分析可见延迟L_{\text{HTAP}}(\text{AP}) 表示分析查询看到这些最新数据需要等待多久。
    LHTAP(AP)L_{\text{HTAP}}(\text{AP})
  4. 求和约等于只要同步链路足够高效，分析侧几乎和事务侧同时看到数据。
    Lsync≪LTP⇒LHTAP(AP)≈LTPL_{\text{sync}} \ll L_{\text{TP}} \Rightarrow L_{\text{HTAP}}(\text{AP}) \approx L_{\text{TP}}

5. 全面对比

选 NewSQL 还是 HTAP，有点像选“专做翻台率的快餐店”还是“全能型智能餐厅”。前者把出餐速度做到极致，后者则同时兼顾出餐和经营分析。没有绝对更好，只有更匹配需求。

在技术维度上，二者有清晰的分工。NewSQL 的强项在于：极致的点查与写入性能、完善的 SQL 支持、强一致事务，适合订单、账户、库存等关键的在线交易。HTAP 的强项在于：省去 ETL 数据搬运、分析查询近乎实时、一个入口同时访问事务和分析两套能力，适合实时看板、实时风控等场景。

不过 HTAP 并非没有代价：行列两种格式通常意味着更大的存储成本，双引擎也带来更高的资源消耗和实现复杂度。选型可以抽象成一个带权重的优化问题——把事务延迟和分析延迟按业务重要性加权：

一家店如果只做“翻台率”生意，把快餐做到极致就够了；如果想边卖菜边看毛利，那就得上智能系统。数据库选型，本质上是先明确自己的“权重”。

S∗=arg⁡min⁡S∈{NewSQL, HTAP}(w⋅LTP(S)+(1−w)⋅LAP(S))\displaystyle S^* = \arg\min_{S \in \{\text{NewSQL},\, \text{HTAP}\}}\Big( w \cdot L_{\text{TP}}(S) + (1 - w) \cdot L_{\text{AP}}(S) \Big)
w 越接近 1，说明业务越看重事务性能，越倾向 NewSQL；w 越接近 0，说明越看重分析实时性，越倾向 HTAP。
  1. 事务权重大小w 是业务对事务延迟的重视程度，0 到 1 之间由需求决定。
    ww
  2. 分析权重互补1 - w 是对分析延迟的重视程度，二者之和恒为 1。
    1−w1 - w
  3. 各方案的延迟L_TP(S) 和 L_AP(S) 分别代表方案 S 在事务和分析负载上的延迟。
    LTP(S)+LAP(S)L_{\text{TP}}(S) + L_{\text{AP}}(S)
  4. 选择最小者argmin 表示在所有候选方案中，选总加权延迟最小的那一个。
    S∗=arg⁡min⁡S∈{NewSQL, HTAP}…S^* = \arg\min_{S \in \{\text{NewSQL},\, \text{HTAP}\}} \dots

6. 选型指南

老张想开第三家店时，不再凭感觉：他会先看选址的客流、菜单的毛利结构、团队的运营能力。数据库选型也一样，起手式是“量化需求”，而不是追逐热门名词。

三个关键问题决定方向：第一，写多还是读多？写密集且分析要求不高，NewSQL 的自动分片和强一致会让你睡得安稳。第二，分析需要多实时？如果老板要看“实时经营大屏”或业务要做“毫秒级风险决策”，HTAP 的价值立刻显现；如果日报 T+1 就能接受，传统数仓成本更低。第三，团队能不能运维分布式系统？NewSQL/HTAP 都要求团队掌握分布式原理、故障排查和性能调优。

把选项铺开，其实是一个成本收益问题：新技术带来的查询加速、实时性提升，能否覆盖基础设施和人力成本的增加？可以写成如下形式：

开店成本的账其实很清晰：先算清楚 ROI，再决定是“先开小店再扩张”，还是“一步到位上智慧餐厅”。选型不是选最贵，而是选最合适。

ROI=Speedupquery×ValuebusinessCostinfra+Costteam\displaystyle \text{ROI} = \frac{\text{Speedup}_{\text{query}} \times \text{Value}_{\text{business}}}{\text{Cost}_{\text{infra}} + \text{Cost}_{\text{team}}}
ROI 大于 1，说明升级架构划算；小于 1，说明当前场景还没必要折腾。
  1. 查询加速倍数Speedup_{\text{query}} 是相比旧架构，核心查询快了多少倍。
    Speedupquery\text{Speedup}_{\text{query}}
  2. 业务价值系数Value_{\text{business}} 是加速带来的业务收益，比如风控挽回的损失。
    Valuebusiness\text{Value}_{\text{business}}
  3. 基础设施成本Cost_{\text{infra}} 是机器、存储、带宽等云资源成本。
    Costinfra\text{Cost}_{\text{infra}}
  4. 团队人力成本Cost_{\text{team}} 是学习、迁移、运维付出的精力。
    Costteam\text{Cost}_{\text{team}}
  5. 产出比评估分子分母相除，算出每一块钱成本换来了多少业务价值。
    ROI=Speedupquery×ValuebusinessCostinfra+Costteam\text{ROI} = \frac{\text{Speedup}_{\text{query}} \times \text{Value}_{\text{business}}}{\text{Cost}_{\text{infra}} + \text{Cost}_{\text{team}}}

7. 实践案例

把时间拨回现在。银行、电商、互联网大厂，就像三类不同菜系的餐厅，各自用 NewSQL 或 HTAP 解决了自己的痛点。

金融支付是典型的强一致场景：一笔转账要同时扣减两个账户，任何一步失败都不能允许部分成功。传统架构用存储过程加锁来硬扛，在分布式环境下越来越吃力。采用 NewSQL 后，自动分片和分布式事务让核心账务系统具备横向扩展能力，同时依然保证“要么都成功，要么都失败”。

电商大促面临的则是流量洪峰。平时 1000 QPS，双 11 峰值瞬间冲到几十倍。如果还是单机主从架构，扩容要提前几天准备。NewSQL 的存储计算分离让计算节点像“临时工”一样随时上岗，配合容器编排，在分钟级完成扩容，大促结束后缩容，成本可控。

实时风控则更需要 HTAP。过去风控规则依赖 T+1 的离线数据，欺诈已经发生很久才被发现。HTAP 让每笔交易在写入事务系统的同时，立即可以被分析引擎扫描，毫秒级完成黑名单、额度、行为特征等判断。这些系统的可用性目标通常极高：

从路边小摊到连锁总店，再到智能餐厅，数据库的进化路径从来不是“哪个名词最火就用哪个”，而是让每一笔交易更快、更稳，让每一个决策更实时、更聪明。

A=1−TdowntimeTtotal\displaystyle A = 1 - \frac{T_{\text{downtime}}}{T_{\text{total}}}
99.99% 的可用性意味着一年停机时间不超过约 52.6 分钟，这是金融、电商场景的常见底线。
  1. 统计不可用时间T_{\text{downtime}} 是统计周期内系统不可用的总时长。
    TdowntimeT_{\text{downtime}}
  2. 统计周期总长T_{\text{total}} 是一年或一个月的总时间。
    TtotalT_{\text{total}}
  3. 相减得可用率1 减去不可用占比，得到可用性指标 A。
    A=1−TdowntimeTtotalA = 1 - \frac{T_{\text{downtime}}}{T_{\text{total}}}

AI 应用场景

实时风控系统

阶段：特征存储与实时推理

解决的问题：传统风控依赖 T+1 批处理，欺诈交易被发现时资金已流出；HTAP 让交易事务与分析查询共用一套数据，风控模型可在毫秒级拿到最新特征，实现“边交易边拦截”。

具体案例：某支付平台每秒处理数万笔交易，每笔交易触发黑名单、额度、设备指纹等十余项实时风控规则。采用 HTAP 架构后，风控决策延迟从分钟级降到百毫秒级，欺诈损失下降 60%。

电商大促弹性扩容

阶段：在线推理服务的数据写入

解决的问题：大促流量是平时的几十倍，传统数据库扩容周期以天计；NewSQL 的存储计算分离与自动分片让计算节点分钟级弹性伸缩，同时强一致事务避免超卖。

具体案例：某电商平台在双 11 核心链路采用 NewSQL，订单创建与库存扣减在同一强一致事务内完成，峰值 QPS 提升 20 倍，扩容时间从天级缩短到分钟级。

实时经营分析大屏

阶段：数据分析与可视化

解决的问题：连锁企业经营数据散落在交易库和数仓，报表 T+1 滞后；HTAP 统一入口直接查实时数据，管理层无需等待 ETL。

具体案例：某连锁餐饮集团上线 HTAP 后，总部大屏以秒级刷新各门店实时营业额、食材库存与毛利，发现异常门店可立即远程干预。

Python 演示

python24 行
import random def simulate(requests=200, batch_size=20):    """对比 NewSQL(批处理可见) 与 HTAP(实时可见) 的分析延迟"""    newsql_latencies = []    htap_latencies = []    for i in range(1, requests + 1):        write_time = i * 0.01  # 模拟时间轴, 单位秒        # HTAP: 每次写入都实时同步, 分析立刻可见        htap_latencies.append(0.005)        # NewSQL: 攒够 batch_size 条才跑一次批处理        if i % batch_size == 0:            invisible_time = write_time - (i - batch_size) * 0.01            newsql_latencies.append(invisible_time)    ns_avg = sum(newsql_latencies) / max(len(newsql_latencies), 1)    ht_avg = sum(htap_latencies) / len(htap_latencies)    print("NewSQL 平均分析延迟(秒): %.3f" % ns_avg)    print("HTAP 平均分析延迟(秒): %.3f" % ht_avg)    print("HTAP 实时性倍数: %.0fx" % (ns_avg / ht_avg))    return ns_avg, ht_avg if __name__ == "__main__":    random.seed(1)    simulate()
目的：用 200 笔模拟写入，对比 NewSQL 攒批处理与 HTAP 实时同步的分析数据可见延迟。
  1. htap_latencies.append(0.005)HTAP 每次写入后同步延迟极小，分析几乎立即可见
  2. if i % batch_size == 0:NewSQL 必须攒满一批才触发批处理，数据可见被延迟
  3. invisible_time = write_time - (i - batch_size) * 0.01计算这批数据从第一条写入到批处理触发之间的“不可见窗口”
  4. ns_avg / ht_avg算出 HTAP 相对 NewSQL 的实时性倍数，通常高达几十倍

常见误区

误区NewSQL 不就是一个“加强版 MySQL”吗？既然兼容 MySQL 协议，那它底层肯定还是 InnoDB 引擎，只是加了个集群外壳。

正解NewSQL 的差异是系统级的。它使用分布式事务、共识协议、自动分片和 MVCC 机制重新设计了存储与事务层，内核与单机 MySQL 完全不同。兼容 SQL 协议只是为了让开发者零成本迁移，就像“挂着老招牌的全新中央厨房”。

为何常见：很多 NewSQL 产品宣传“兼容 MySQL 生态”，用户顺着惯性就把同类项合并了。

误区HTAP 嘛，我一边放一个行存 MySQL，一边放一个列存 ClickHouse，中间写个同步任务，这不就是 HTAP 吗？

正解HTAP 的难点在于“混合”：统一的 SQL 入口、事务与分析的强一致性可见、列存数据的实时增量同步、查询路由自动选择引擎。第三方同步通常有秒级到分钟级延迟且难以保证一致性，属于“伪 HTAP”。

为何常见：产品架构图看起来都是“两个引擎 + 一条同步链路”，于是误以为拼装就能复刻。

误区HTAP 又能跑事务又能做分析，那还买什么 NewSQL、什么数仓，一个库全干完。

正解HTAP 适合实时性要求高、数据量中等的场景。超大规模离线分析利用列存数仓更便宜；极限高并发短事务用 NewSQL 更极致。数据库选型是光谱，不是单点。

为何常见：厂商宣传总爱强调“一个顶俩”，容易让人忘记每种架构都有舒适区。

误区我们公司把自建 MySQL 迁到了云主机，又买了云数据库 RDS，所以我们已经是云原生架构了。

正解云原生的标志是存储计算分离、容器化编排、弹性伸缩、故障自愈。只是把数据库跑在云虚拟机上，本质还是“带轮子的老厨房”，并没有获得云的弹性红利。

为何常见：“云数据库”被当作营销词，部署位置被误认为架构本质。

面试题

Q1. NewSQL 最核心的特征是？

单选题 · easy

  • A.分布式事务与强一致← 正确答案
  • B.纯键值存储与 API
  • C.只能运行在单机
  • D.不支持 SQL 查询

答案：A。NewSQL 的代表特征正是分布式事务与强一致性（A）。B 描述的是 NoSQL；C 和 D 与 NewSQL 的目标相反——它恰恰要突破单机限制并提供 SQL 能力。就像连锁餐厅不只是多了几张桌子的小饭馆，而是整套对账体系都重写了。

Q2. HTAP 中的“T“和”A”分别指什么？

单选题 · easy

  • A.事务处理与分析处理← 正确答案
  • B.数据表与数据聚合
  • C.时间戳与异步复制
  • D.线程池与自动分区

答案：A。HTAP 是 Hybrid Transactional/Analytical Processing 的缩写，T 是事务（Transactional），A 是分析（Analytical）。B、C、D 都是对字母 T/A 的错误臆测，不符合数据库界通用定义。

Q3. NewSQL 分布式事务常用哪个协议？

单选题 · mid

  • A.两阶段提交协议 2PC← 正确答案
  • B.超文本传输协议
  • C.动态主机配置协议
  • D.简单邮件传输协议

答案：A。两阶段提交（2PC）是 NewSQL 分布式事务的经典协议，先 prepare 再 commit，保证全局原子性。HTTP、DHCP、SMTP 都是网络协议，与分布式事务无关。就像总部先问所有分店“菜备齐了吗”，再统一下令上菜。

Q4. HTAP 行列混合存储的主要收益是？

单选题 · mid

  • A.点查与聚合分析兼顾← 正确答案
  • B.彻底取消所有索引
  • C.完全省掉事务日志
  • D.不再需要任何副本

答案：A。行列混合存储让行存快速点查、列存快速聚合，二者兼顾。B、C、D 都是不可能实现的承诺——存储引擎永远需要索引来加速、日志来恢复、副本来容灾。

Q5. 分库分表后定位数据通常会用到？

单选题 · mid

  • A.一致性哈希取模路由← 正确答案
  • B.全表扫描加内存过滤
  • C.随机选择一个数据库
  • D.按服务器启动顺序

答案：A。一致性哈希把数据映射到哈希环，节点变化时只需迁移少量相邻数据，是分库分表友好的路由方案。全表扫描成本高，随机选择不均衡，按启动顺序无法应对动态扩缩容。

Q6. 存储与计算分离的主要好处是？

单选题 · hard

  • A.计算节点可独立弹性伸缩← 正确答案
  • B.存储越慢性能反而越好
  • C.彻底消除网络传输开销
  • D.事务日志从此不再需要

答案：A。存储与计算分离让两者独立伸缩：计算节点成倍增加，存储按容量扩容。B 反常识，C 不现实，D 不可能——事务日志永远需要持久性来保证恢复能力。

Q7. 以下哪个场景最适合使用 HTAP？

单选题 · easy

  • A.实时风控与交易分析← 正确答案
  • B.只读归档历史冷数据
  • C.存放海量图片和视频
  • D.简单静态官网页面

答案：A。HTAP 适合“边交易边分析”的场景，如实时风控。只读归档更适用冷存储，图片视频归对象存储，静态官网用传统数据库即可，都不需要 HTAP。

Q8. 以下哪些属于 NewSQL 的典型技术？

多选题 · mid

  • A.自动分片与再平衡← 正确答案
  • B.事务的分布式协调← 正确答案
  • C.拒绝 SQL 访问接口
  • D.强制单机运行模式

答案：AB。自动分片与分布式协调是 NewSQL 的核心技术。C 和 D 恰恰是 NewSQL 要解决的问题——它必须提供 SQL 接口，也必须分布到多机运行，所以这两项明显错误。

Q9. HTAP 相比"OLTP + ETL + OLAP"的优势有哪些？

多选题 · hard

  • A.减少数据搬运与等待← 正确答案
  • B.分析查询接近实时← 正确答案
  • C.无需任何数据副本
  • D.一套入口统一访问← 正确答案

答案：ABD。HTAP 的三个典型优势：省去 ETL 搬运、分析近实时、统一入口。C 错误：HTAP 依然需要多副本和列副本，不可能“无需任何副本”，那是违背存储安全常识的。

Q10. 关于 CAP 与数据库选型，正确说法有？

多选题 · hard

  • A.网络分区时只可选一致或可用← 正确答案
  • B.NewSQL 通常更偏一致性← 正确答案
  • C.三个要素可以同时完美满足
  • D.HTAP 对齐一致性不作要求

答案：AB。CAP 指出网络分区时只能在一致性和可用性中二选一（A 对）。NewSQL 通常偏 CP（B 对）。C 违背 CAP 不可能三角。D 错误：HTAP 也强调一致性可见，否则实时分析会读到脏数据。