宽表、NoSQL 与多模查询

• Seastar 的无共享（shared-nothing）模型
• 无锁与异步设计的原理
• 与 Cassandra 的 JVM 实现对比

Seastar 是一种基于无共享（shared-nothing）模型的异步框架，每个 CPU 核独立运行一个"分片"（shard），每个分片拥有自己的内存、网络连接和数据结构，线程之间几乎不共享状态，因此避免了锁竞争和跨核缓存失效。每个核运行独立的异步事件循环，通过非阻塞（non-blocking）的 DMA 与批量 I/O 提交，配合自身的无锁队列与原子操作，将吞吐量推高。相比 Cassandra 依赖 JVM 的 GC 停顿和加锁的数据结构，ScyllaDB 通过 Seastar 实现了无 GC、可预测的低延迟和更高的单核吞吐。

锁竞争和 GC 停顿是分布式数据库延迟抖动的主要来源。ScyllaDB 用 Seastar 把每个核做成一个独立的"迷你数据库"，通过网络栈（如 OSV 的 TCP/IP 栈）分摊开销，从而在相同硬件上获得远高于 Cassandra 的性能。

• 宽表模型天然按主键查询的特性
• 二级索引的维护与查询开销
• 物化视图的存储放大与一致性

宽表数据库以主键（分区键+聚类键）为查询核心，天然只对主键扫描高效。二级索引需要额外维护一份索引表，写入时同步更新索引，导致写放大和更复杂的写入路径；查询时若索引列分布不均，可能退化为全表扫描。Cassandra 的物化视图需要在每个副本上维护多份数据副本，会引入存储放大、写入放大和一致性维护成本，且对视图的变更有限制（如不支持某些更新）。在宽表场景下，通常更推荐用"反范式化+冗余列"或"索引表"来替代索引。

宽表数据库的强项是分布式高可用写入，不擅长灵活的辅助查询。设计时应优先围绕主键规划查询路径，把多条件查询转化为主键查询或旁路索引表，避免盲目建索引带来的性能与一致性负担。

• 多模索引的类型差异
• 统一索引管理的抽象
• 索引与查询路由的协同

多模数据库通过统一的索引管理层为不同数据模型提供一致的索引能力，内置标量索引（B-Tree、哈希）、全文索引（倒排）、向量索引（HNSW、IVF）、图的属性/邻接索引等。用户通过统一的 DDL 声明索引，存储引擎按模型分派到对应索引实现，查询优化器根据模型与谓词选择合适索引。统一管理的价值在于：一份元数据管理所有索引、统一的备份/恢复/监控、以及跨模型查询时索引的协同使用。

索引的统一管理降低了多模型并存时的运维复杂度，让标量、全文、向量、图索引共享同一套生命周期与资源治理，同时也考验底层异构索引的抽象一致性。

• LSM 树的写入与合并机制
• 一致性级别（QUORUM、ONE、ALL）的设置
• 最终一致性与 NWR 模型

Cassandra 采用 LSM（Log-Structured Merge）存储结构，写入先追加到 MemTable，再批量 Flush 成不可变的 SSTable，后台通过 Compaction 合并排序，因而写入是顺序追加、读需要查询多个 SSTable。一致性可通过配置读写的一致性级别（CL=ONE/QUORUM/ALL 等）来调节，形成 NWR 模型：当 R+W>N 时读能读到最新写入。这种"可变一致性"让用户在一致性、可用性与延迟之间按需权衡，代价是系统默认是最终一致性，需配合读修复和反熵来收敛。

LSM 换来的是优秀写入吞吐与无锁追加，代价是读放大与合并开销；Tunable Consistency 让用户按场景决定读取强度，理解 NWR 与读修复是正确使用 Cassandra 一致性的关键。

• 分区键决定数据分布与访问局部性
• 热点产生的根源
• 热点规避的技术手段

分区键决定数据在集群中的分布位置，理想的分区键应使数据均匀分布到各节点，避免某几个分区键被高频访问。热点往往来自高基数的单点访问（如热门用户、热门商品）或分区键选择不当导致数据倾斜。规避手段包括：为分区键加盐（suffix）、对分区键做哈希、使用自然分布的键（如时间戳+随机后缀）、引入复合分区键以打散分布，同时对单分区内的数据量做约束（避免超大分区）。

分区键是 Cassandra 数据分布与查询路径的核心，设计不当会同时造成写入热点与读取热点。加盐与哈希能在分布均匀与查询局部性之间取得平衡，是规避热点的常用手段。

• 单调递增 RowKey 导致写热点与 Region 倾斜的原因
• 反转、加盐、哈希、组合键四种方案
• 各方案的查询局部性与分布均匀性取舍

HBase 按 RowKey 字典序分区存储，单调递增的 RowKey（如自增 ID、时间戳）会把所有新写入路由到最后一个 Region，形成写热点并导致 Region 不断分裂。反转（Reversed Key）把前缀反转使新数据分散到不同 Region，但破坏范围查询；加盐（Salting）在 RowKey 前加随机前缀，分布均匀但牺牲范围扫描；哈希（Hash）对 RowKey 做哈希保证均匀但完全失去有序性；组合键（Composite Key）用"类别+时间戳"等自然维度组合，在均匀分布与有序范围查询之间取得折中。实际常采用"加盐+时间戳"或"关联维度+时间戳"的组合。

写热点源于数据分布与 Region 划分的不匹配。设计 RowKey 的本质是在"分布均匀"与"查询局部性/有序扫描"之间权衡，需结合具体访问模式选择，而非单一方案。

• 预分区的原理与作用
• Region 分裂的触发与代价
• 预分区键的规划方法

预分区（Pre-splitting）是在建表时按 RowKey 区间预先划分多个 Region，并指定每个 Region 的 StartKey/EndKey，使数据一开始就均匀分布到多个 Region，避免初始集中写入单个 Region 引发的热点与频繁分裂。Region 分裂（Split）是数据超限时 Region 自动一分为二的过程，频繁分裂会带来 StoreFile 重写与 Region 迁移开销。规划时需根据 RowKey 分布预估数据量，按合理区间切分，并针对高基数字段（如加盐前缀）设计分区键，使各 Region 负载均衡。

预分区把"先写满再分裂"改为"提前划分"，显著减少运行期分裂抖动。关键是预估数据规模与 RowKey 分布，把分区键设计成在预定义区间内均匀落点。

• 协议兼容的范围
• 驱动兼容性
• 兼容带来的迁移便利

ScyllaDB 公开兼容 Cassandra 的 CQL 协议与驱动（Java/Python/Go 等），使得使用 Cassandra 客户端的应用无需修改即可连接 ScyllaDB。两者均支持 CQL 语法、一致性级别、数据模型与复制因子配置，ScyllaDB 在协议层面实现了高度兼容，同时在底层存储与执行引擎上采用自研的 Seastar 实现。这种兼容性降低了从 Cassandra 迁移到 ScyllaDB 的成本。

协议兼容是 ScyllaDB 作为 Cassandra 高性能替代品的关键，让用户沿用现有工具链与代码，把精力放在性能与运维优化上。

• 统一 API 的抽象层次
• 模型映射与查询语言
• 统一访问的价值

多模数据库通过统一的查询 API 或语言（如 SQL 扩展、Cypher、文档查询）让用户用一套接口访问键值、文档、图、时序等不同模型。底层把不同模型映射到统一的存储引擎与数据类型上，通过查询解析器把统一语言分派到对应模型的执行引擎。例如支持 SQL 访问 JSON 文档、用 Cypher 查询图、用向量函数做相似度检索。统一 API 降低了多模型并存时的学习与运维成本，但需要抽象层处理各模型的语义差异。

统一 API 的价值在于"一套语言、多种模型"，但抽象层必须妥善处理不同模型在模式、事务与查询语义上的差异，才能避免接口统一的"表面化"。

• 多模数据库的集成优势
• 单一专用库的性能优势
• 取舍的权衡因素

多模数据库把多种数据模型集成在一个引擎中，带来数据一致性管理统一、运维简单（一套集群、备份、监控）与跨模型查询便利；但其通用抽象相较专用库可能在某些极端场景下性能不及。单一专用库（如专用图库、专用时序库）针对单一模型深度优化，性能与特性更强，但需要维护多套系统、处理跨系统数据同步与一致性问题。取舍的关键在于业务复杂度、数据规模、性能敏感度与团队运维能力。

"多模"换运维便利与一致性，可能牺牲单项性能；"专用"换极致的单项性能，却要承担多系统的集成与一致性成本。应根据业务实际需求权衡，而非绝对优劣。

• 文档模型与宽表模型的存储差异
• 读写路径与更新方式
• 查询能力差异

MongoDB 以 JSON 文档为单位存储，支持嵌套结构、就地更新（in-place update）与丰富的查询（范围、聚合、地理、文本），写入更新可局部修改字段。Cassandra 以宽表（行+列）存储，按分区键分布，写入是追加式 LSM、更新与删除本质是写入新版本（tombstone），查询以主键为核心，聚合与复杂查询能力较弱。两者都具备分布式扩展能力，但 MongoDB 更面向灵活多变的数据与查询，Cassandra 更面向高写入吞吐与可靠可用性。

两者模型差异决定了适用场景：MongoDB 灵活、查询丰富但写放大与锁竞争更明显；Cassandra 写入高效、读以主键为主但聚合能力弱。选型应看负载是写多还是查询复杂。

• 敏捷 schema 的灵活性
• 多模下的查询与一致性约束
• 数据质量与迁移成本

文档库的敏捷 schema 允许不同文档拥有不同结构，便于快速迭代与灵活建模，但也会带来字段缺失、类型不一致、查询语义不明确与数据质量难以约束的问题。在多模数据库下，文档与其他模型（如关系、图）并存时，敏捷 schema 的灵活性需与多模型间的关联、约束与事务一致性要求平衡，否则会造成跨模型数据不一致与查询困难。因此多模场景常引入 schema 校验（如 JSON Schema）与迁移工具来约束灵活性。

敏捷 schema 是双刃剑：灵活性降低开发成本，却增加数据治理与查询稳定性风险。多模环境下，灵活性与跨模型约束之间的平衡需要架构师审慎设计。

• Ring 拓扑与虚拟节点
• 一致性哈希的数据分布
• 环上的数据与副本定位

Cassandra 将哈希空间（默认 Murmur3 分区器为 -2^63 到 2^63-1，旧版 RandomPartitioner 为 0 到 2^127-1）按环状组织，每个节点（或虚拟节点 vnode）通过 token 划分一段区间，数据按分区键哈希后落到对应区间节点。为提高数据分布均衡与扩容灵活性，使用虚拟节点（vnode）让每个物理节点承担多个 token 区间，简化负载均衡。复制时按复制因子在环上顺时针取相邻节点存放副本。定位数据时，客户端根据分区键哈希计算 token，在环上找到负责该 token 区间的节点，再从该节点按复制因子顺时针定位副本节点，从而完成读写路由。一致性哈希使节点增减时只影响相邻区间的数据重映射，配合虚拟节点实现平滑的负载均衡与扩容。

Ring 拓扑与一致性哈希把数据分布、副本定位与扩容均衡统一到环上，虚拟节点（vnode）则是解决物理节点负载不均与扩容重分布的关键优化，理解 token 区间与副本定位是掌握 Cassandra 集群布局的基础。

• 分区键与聚类键的职责划分
• 数据物理存储的有序性
• 局部性对查询与写入的影响

宽表模型中，分区键（RowKey/Partition Key）决定数据落点与副本分布，聚类列（Clustering Key）决定同一分区内数据的排序与物理相邻性。由于同分区数据按聚类键字典序连续存储，把关联数据（如同一用户的时间序列）设计为相同分区键并叠加聚类列，可让这类数据在物理存储上相邻，提升范围查询与扫描的局部性。正确设计聚类键可让常用查询按顺序扫描局部数据，减少跨分区/跨节点访问。

数据局部性源于"同分区+有序聚类"的物理编排，把访问模式与聚类键对齐，是宽表建模提升查询性能的关键，也是宽表模型"反范式冗余"的核心依据。

• 统一存储层与多模型映射
• 各模型的数据组织方式
• 模型间关联与查询

多模数据库底层通常采用统一的存储或访问层，通过不同的存取与查询接口暴露键值、文档、图、关系等多种模型。键值模型直接以键值存储，文档模型以 JSON 等文档存储并支持嵌套查询，图模型以节点/边存储并提供图遍历与图算法，各模型共享一份元数据与存储资源。模型间通过引用或关联（如外键、图边）实现跨模型查询，用户可用统一或混合语言同时访问多个模型。

多模数据库的关键在"统一存储+多接口"，既要让各模型呈现各自原生的语义，又要能在共享基础设施上相互关联，这考验存储抽象与查询优化器的跨模型能力。

• 时序数据的写入特征
• 宽表建模（时间戳+设备ID）
• 压缩与 TTL 处理

时序/物联网数据有高写入、按时间离散、单设备数据可聚合处理的特征。宽表库可用"设备ID+时间戳"作为分区键/聚类键，把同一设备的数据聚在同一分区内按时间有序存储，便于按设备做时间范围查询与聚合。宽表库的追加式写入（LSM）天然适合高吞吐时序写入，配合 TTL 自动过期旧数据、压缩（Compaction）合并与压缩存储，可有效控制存储成本。但也需注意单分区过大与分区热点问题。

宽表库与时序场景高度契合：写入模式吻合、时间有序便于范围扫描、TTL 与压缩控制成本。适配重点是合理设计分区键以避免单设备极端数据量造成存储倾斜。

• SQL 扩展对 JSON/图/向量的支持
• 跨模型查询的解析与执行
• 统一查询的局限

多模数据库通过扩展 SQL 支持跨模型检索，例如在 SQL 中加入 JSON 查询函数（JSON_EXTRACT、path 表达式）、图查询扩展（返回节点/边结果）、向量相似度函数（如欧氏距离、余弦相似度）等。查询优化器把统一的 SQL 语句解析后分派到对应模型的执行引擎，并支持跨模型的结果关联（如把 JSON 文档向量化的结果与图遍历结果拼接）。统一 SQL 让用户用一套语言完成跨模检索，但各扩展的语义差异与执行计划融合需要精细处理。

统一查询语言的价值是"一套语法跨多模型"，其难点在于优化器如何融合不同模型的执行计划并保证结果语义一致，这种扩展能力是多模数据库的竞争力所在。

• 多模型某一天然场景的建模
• 模型的互补作用
• 融合查询的价值

典型的融合场景如社交/风控/物联网平台：用文档存实体与灵活配置（如用户资料、订单明细），用图存实体关联（如好友关系、资金流向），用时序存监控与事件流（如设备指标、访问日志）。各模型各司其职：文档负责灵活记录、图负责关系分析、时序负责连续变化数据，通过统一数据库可在一个系统内完成跨模型关联查询（如从图找到用户关系，再拉取其时序行为特征）。

融合场景的本质是"一个业务域内多种数据形态"，用多模数据库统一管理可避免多套系统间的同步与一致性问题，同时保留每种模型的原生能力。

• 事务的模型范围与边界
• 跨模型事务的支持程度
• 一致性语义的差异

多模数据库的事务边界通常由底层存储引擎决定，多数支持单模型内事务（如单文档、单图事务），跨模型事务的支持取决于架构：部分采用统一事务引擎的多模库支持跨模型强一致事务，而基于多引擎组合的多模库跨模型操作往往只能弱一致或依赖补偿。跨模型操作的限制包括：不同模型对原子性、隔离级别的支持不一，跨模型索引与约束难以统一，以及图/文档的嵌套结构与关系表的约束模型差异导致事务语义难对齐。

"多模"不等于"多模型强一致事务"。界定事务边界需明确底层引擎能力，跨模型事务的强一致支持是架构与成本的权衡，需在需求驱动下合理设计。

• 向量与嵌入数据的存储
• 结构化数据与 AI 特征融合
• 统一查询支撑 AI 应用

在 AI 原生场景中，多模数据库可同时存储结构化业务数据、文档、图谱与向量嵌入，并支持向量相似度检索（如 RAG、语义搜索、推荐）。它把向量检索与传统/图查询统一在同一个引擎中，让 AI 应用能基于结构化事实、关系与语义向量做混合推理与召回，例如先向量召回候选再按结构化条件过滤、或结合图路径丰富上下文。统一管理还便于数据一致性、特征更新与权限治理。

AI 应用往往需要"语义+结构化+关系"混合数据，多模数据库恰好把向量、文档、图、关系统一管理，减少多系统拼接与数据同步，是 AI 原生数据底座的重要趋势。

• 存储共享与隔离的两种模式
• 资源隔离的手段
• 两者的权衡

多模数据库既可在统一存储引擎上共享底层存储（数据文件、缓存、IO），也可为不同模型配置隔离的存储资源。共享存储能提高资源利用率、简化运维并支持跨模型事务，但可能出现模型间资源争用与相互影响；隔离存储（如为向量/图模型分配独立存储与计算资源）能保证稳定性与故障隔离，但增加资源与运维成本。实践中常采用"共享元数据+按模型/租户分区隔离"的混合策略。

存储隔离与共享是对资源利用率与故障隔离的权衡，多模数据库需在统一管理的同时提供按模型/租户的隔离能力，以满足不同业务的 SLA 与安全要求。

• LSM 的追加式写入
• 文档的就地更新机制
• 读写放大与性能特征

宽表（LSM）本质是追加写：更新/删除通过写入新版本与 tombstone 实现，数据先进 MemTable 再批量落盘，靠 Compaction 合并，牺牲一定读放大换取高写入吞吐。文档库（如 MongoDB）通常支持就地更新：在数据页上直接修改字段，更新延迟低、读放大小，但并发写与页分裂/锁竞争更明显。二者在写入模式、磁盘占用与读写优化方向上截然不同。

追加写换来高吞吐与顺序 IO，代价是读放大与空间放大；就地更新读路径高效但写路径易受锁与页竞争影响。选型取决于写多还是读多的负载特征。

• 模型转换的映射成本
• 查询与约束的改写
• 迁移风险与验证

从单一模型迁移到多模数据库，或在不同模型间转换，会带来显著成本：关系模型转文档/图需要重构范式与关联、宽表需要重新设计分键与聚类、查询语句与事务边界需按新模型改写、原有约束与校验需重新实现。数据迁移还涉及字段映射、清洗、去重与一致性校验，以及双写/回滚等上线策略。因此迁移前需评估多模带来的收益是否覆盖建模重构与迁移风险。

多模数据库虽降低"多系统"运维成本，却引入"模型转换"的建模成本。迁移决策应权衡建模重构、查询改写与数据一致性风险，而非仅看运行指标。

• 反范式与宽行设计
• 热点行的成因与规避
• 列族（Column Family）设计

宽表库采用反范式设计，把关联数据冗余进同一行以减少跨表/跨节点关联，用宽行（一行包含大量列：如设备+时间戳+多个指标列）提升单次读取的数据密度。热点行源于某行被高频读写或单行过大，应通过合理分键、控制单行大小、拆分热点列来避免。列族设计上，应据访问频率与大小把高频列、低频列、大对象分到不同列族，因为列族是独立存储与压缩单位，列族过多会带来额外开销，列族过少则无法按访问模式隔离存储。

宽表库性能的核心是"围绕主键做反范式宽行"，列族则是存储与 IO 的物理边界，合理划分列族可优化压缩、缓存与读写分离，是宽表建模的关键手段。

• 各组件职责划分
• 写路径（WAL→MemStore→Flush）
• 读路径（BlockCache+Bloom Filter）

HBase 中 HMaster 负责 Region 分配、负载均衡与表管理，RegionServer 管理多个 Region 并服务读写。写入时先写 WAL（Write-Ahead Log）保证持久化，再写入 MemStore（内存缓存），MemStore 达到阈值后 Flush 成 HFile 落盘；读取时先查 BlockCache（DataBlock 缓存）与 MemStore，再通过 Bloom Filter 判断 HFile 是否可能包含目标行，减少无效磁盘扫描。HFile 为有序文件，后台 Compaction 合并小文件。

HBase 的读写路径围绕"内存加速+磁盘日志+有序文件"展开，理解 WAL/MemStore/BlockCache/Bloom Filter 的协作是定位读写性能与故障恢复问题的关键。

• 列族数量与存储开销
• VERSIONS 与版本管理
• TTL 与数据过期

HBase 列族是独立存储单位，列族数量过多会带来大量小文件、增大 MemStore 与 Flush 开销，通常建议列族少而精。列限定符（Column Qualifier）应尽量精简，避免冗余信息。VERSIONS 控制每个单元格保留的历史版本数，版本越多存储放大越大，读取时若不指定版本会读最新版本，过多版本增加扫描成本。TTL 让数据到期自动删除，能控制存储增长，但需注意 TTL 与版本、Compaction 的交互，避免删除不及时造成的空间浪费。

列族、列限定符、VERSIONS 与 TTL 共同决定 HBase 的存储放大与查询效率，设计时应以"精简列族、控制版本、合理 TTL"为原则权衡存储与性能。

• 缺少二级索引的局限
• Phoenix 二级索引方案
• 组合 RowKey 与自建索引表

HBase 只支持按 RowKey 高效查询，多条件查询需扫描全表。解决方案有：用 Phoenix 提供 SQL 与二级索引（覆盖索引、可变索引），把常用查询列建立索引表；用组合 RowKey 把多条件合并进主键实现单表定位；或自建索引表，把"条件值→主键"映射写入独立表，查询时先查索引表再回查主表。各方案在一致性、写放大与查询局部性上各有取舍，需按查询模式选择。

多条件查询是宽表模型的短板，二级索引会带来写放大与一致性问题，组合 RowKey 牺牲灵活性换取局部性，自建索引表灵活但需自行维护一致性，需权衡。

• 数据模型差异
• 一致性模型差异
• 运维复杂度与选型

数据模型上，HBase 依赖 HDFS/ZooKeeper，以 RowKey+列族组织，适合与 Hadoop 生态集成；Cassandra 独立部署，以分区键+聚类键组织，虚拟化节点更易扩展。一致性上，HBase 依赖 HDFS 与 WAL 提供较强一致性，Cassandra 默认最终一致、提供可变一致性（Tunable Consistency）。运维上 HBase 需管理 HDFS、ZooKeeper、HMaster 等多组件，复杂度高；Cassandra 无中心节点、运维相对简单。选型依据：若需与 Hadoop 生态耦合、强一致读，选 HBase；若需高可用写入、多数据中心、无中心化，选 Cassandra。

两者同属宽表但生态与一致性取向不同，选型取决于对 Hadoop 生态依赖、一致性要求、多数据中心与运维能力的综合判断。

• TTL 的语义与触发
• 过期数据的删除方式
• TTL 与 Compaction 的交互

宽表库（如 Cassandra、HBase）通过 TTL 为数据设置过期时间，数据到期后逻辑上不可见，物理删除由读取时的 tombstone 过滤与后台 Compaction 完成。写入时记录过期时间戳，读取时过滤已过期数据，Compaction 合并时真正清除过期数据。合理设置 TTL 可控制存储增长、符合数据合规要求，但需注意：短时间内大量数据集中过期会造成 Compaction 压力与删除风暴，且 tombstone 过多会影响读性能。

TTL 是宽表库管理数据生命周期的重要手段，但过期删除的物理过程依赖 Compaction，设计 TTL 时应考虑过期节奏与删除风暴，避免性能抖动。

• 各模型默认一致性语义
• 统一查询跨模型的一致性
• 一致性权衡

不同数据模型封装的一致性语义不同：关系模型通常提供强一致与事务隔离，文档模型提供单文档事务与可调一致性，图模型提供事务性图遍历，宽表/键值模型默认最终一致。多模统一查询跨模型时，各模型的一致性语义差异会显现：跨模型事务可能涉及不同引擎，难以保证强一致，只能退化为弱一致或靠应用层补偿。因此统一查询需明确各模型一致性边界，并据此设计跨模型操作。

多模查询的易用性背后隐藏着一致性语义的差异，统一访问层必须清晰暴露各模型的一致性强弱，避免用户误以为跨模型操作天然强一致。

• 文档库的聚合管道
• 宽表库的聚合限制
• 典型场景的聚合支持

MongoDB 等文档库提供完善的聚合管道（Aggregation Pipeline），支持分组、排序、投影、unwind、累加器函数等，能在分布式引擎上执行复杂聚合。宽表库（Cassandra、HBase）缺乏通用聚合能力，只支持极简的计数/聚合（如 Cassandra 的 COUNT、SUM），复杂聚合需在应用层或借助外部引擎（如 Spark、Phoenix）完成。这源于宽表以主键查询为核心、避免分布式扫描的架构取向。

聚合能力差异源于架构定位：文档库面向查询与分析，宽表库面向高吞吐主键读写。选择时需评估业务聚合需求，必要时为宽表接入分析引擎。

• 扩缩容的分片迁移
• 再平衡机制
• 对服务的影响与流量控制

多模数据库扩容时新增节点，通过分片（Region/Shard/Tablet）迁移把部分数据挪到新节点；缩容时回收数据并迁移离群分片。再平衡由元数据协调器（如 HBase HMaster、TiDB PD、Cassandra 的 vnode 机制）驱动，依据负载、存储与数据量决定分片迁移。迁移期间需控制迁移速率、进行限流与校验，保证服务可用与数据一致，同时对读写进行平滑切换。扩容后负载的均衡度取决于分片粒度与再平衡策略。

扩缩容与再平衡的难点是"迁移期间不中断服务且数据一致"，分片粒度越细迁移越平滑，但元数据与调度开销越大，需权衡。

• Minor/Major Compaction 的区别
• Region 均衡机制
• RegionServer 故障恢复与 HLog 回放

HBase 的 Minor Compaction 合并少量 HFile 减少文件数，Major Compaction 全量合并并清理过期/删除数据，二者都由后台触发，Major 更彻底但代价大。Region 均衡由 HMaster 依据 Region 大小与负载在 RegionServer 间迁移 Region，避免热点。RegionServer 故障时，HMaster 负责把其 Region 重新分配，并依靠 HLog（WAL）回放恢复未落盘数据，保证数据不丢失。

Compaction 控制文件数与存储大小，Region 均衡与 HLog 回放保证集群的负载均衡与故障恢复完整性，三者是 HBase 运维稳定性的关键机制。

• 全模型统一备份
• 跨模备份的一致性点
• 恢复与校验

多模数据库需要对所有模型提供统一备份，通常基于一致的快照或分布式快照机制，保证备份点跨模型数据一致。备份文件涵盖各模型的数据文件与元数据，恢复时可整体还原到一致时间点。跨模一致性依赖底层存储的一致性快照（如多分片原子快照），若引擎不支持原子快照，则需通过应用层协调或增量补偿实现逻辑一致。恢复后需校验各模型数据完整性。

多模备份的难点是"跨模型一致的时间点"，否则恢复后各模型数据会相互矛盾。验证备份可恢复性与一致性是灾难恢复的关键。

• 各模型差异化监控指标
• 统一监控的取舍
• 关键指标与告警

各模型的监控指标侧重不同：KV 关注吞吐、延迟、分区分布与热点；文档关注查询复杂度、索引命中、聚合耗时、文档大小分布；图关注遍历深度、边访问、图算法耗时、跨越度。统一监控需在"模型差异化指标"与"统一基座"之间取舍：保留通用资源指标（CPU/内存/IO/延迟/错误率）作为统一基线，同时为各模型暴露专属指标，通过统一监控平台聚合与告警。取舍的关键是既不遗漏模型特有风险，又避免指标过多造成噪音。

统一监控的平衡点在于"通用指标兜底 + 模型专属指标细化"，既保证全局可观测又避免指标爆炸，需按模型特性设计告警阈值。

• 不同模型的延迟特征
• SLO 差异化设计
• 场景驱动的延迟目标

不同模型与场景对延迟要求不同：在线交易/风控要求毫秒级低延迟，需强一致与高可用；分析/报表允许秒级延迟；向量检索与图查询的延迟取决于数据规模与索引。SLO 应差异化设计：按模型设定不同 P99/P95 延迟目标，按场景区分读写优先级，为关键路径配置更严格的 SLO 与资源隔离，为批处理场景放宽。设计时需结合压测基线、容量与资源预算，避免对所有模型一刀切。

SLO 差异化是资源与性能的精准匹配，把预算投入到关键模型与场景，避免"过度承诺"导致资源浪费或"欠承诺"导致风险。

• 混合架构的划分边界
• 数据同步机制
• 一致性保证

在混合架构中，多模数据库承担通用/多形态数据，专用数据库（如专用图库、专用时序库、数仓）承担对性能与功能要求极高的模型。划分边界依据：访问模式是否单一、性能要求是否极致、功能深度是否超出多模能力。数据同步通常用 CDC（变更数据捕获）、消息队列或 ETL 把多模库的变更同步到专用库，保证数据新鲜度。一致性上，跨系统难以强一致，需明确"源库为准"的最终一致或近实时一致，并设计故障补偿与对账机制。

混合架构在"多模集成便利"与"专用极致性能"之间取平衡，边界划分与数据同步的一致性设计是避免"两套数据互相矛盾"的关键。