大宽表场景调研：六类访问模式、产品解决方案与 Lindorm "宽表+搜索" 深度解析1. 背景 大宽表的核心问题是：访问模式是否与底层存储结构和架构设计相匹配。 同一张宽表，在不同访问模式下会呈现为完全不同的问题域：点查低频更新、搜索、交互式 OLAP、批处理、特征存取/向量检索。因此，选型的关键不是"列数"，而是"访问模式与存储/架构的匹配度"。 📌 本次调研重点：点查低频更新、搜索、交互式 OLAP、批处理、稀疏/动态 schema、半结构化/JSON 等访问模式。向量检索不在本次深度调研范围内。 本文目标：拆解大宽表的六类访问模式分析各产品的存储结构与架构深度解析 Lindorm "宽表+搜索" 解决了什么问题核心概念速览 ⏭️ 熟悉这些概念的读者可跳过本节。 | 概念 | 一句话解释 | |------|-----------| | RowKey | 行的唯一标识（类似主键）；HBase 的存储顺序以 RowKey 为首（并进一步按 ColumnFamily/Qualifier/Timestamp 排序），点查/范围查可快速定位（来源：HBase Sort Order） | | Wide-Column 存储 | 更接近“按 RowKey 聚集”的行式：同一 RowKey 的 cell 在同一 Column Family 内按 qualifier 排列，适合“按行取多列/按列族读”；与列存（Column Store）不同（来源：HBase Data Model） | | LSM-Tree | Log-Structured Merge Tree，写入先进内存（MemTable），再批量刷盘合并，适合高吞吐写入 | | 倒排索引 | 从"词 → 文档列表"的映射，适合"任意字段过滤"（如 WHERE tag = 'vip'） | | DocValues | 从"文档 → 字段值"的列式存储，适合排序/聚合（如 ORDER BY score DESC）（来源：ES doc_values） | | 列存（Column Store） | 同一列的值在物理上相邻存储，适合"扫描少量列 + 聚合"；与 Wide-Column 不同 |2. 大宽表的六类访问模式 六类访问模式（与"六类场景"一一对应）：点查 + 低频更新型：RowKey -> 一行(很宽)，高 QPS、低延迟、偶尔更新低延迟分析/检索型（交互式）：多行 + 少量列 + 多维过滤/排序/TopN/部分聚合，秒级内返回离线聚合型（批处理）：PB 级 scan + 大聚合/JOIN，分钟~小时级，重点是"稳定跑完"稀疏/动态 schema 型：列集合持续增长、90% 为空，按需索引、可回放历史半结构化/JSON 型：日志/事件属性，字段嵌套、全文 + 数值混合过滤特征向量/高维型：dense 数值、SIMD/ANN，偏"数值计算/向量检索" 适配矩阵（分级：主场 / 可用 / 边缘 / 不适合；"可用"通常意味着需要明确建模或与其它系统组合）： | 访问模式 | Rockset | HBase | Elasticsearch | ClickHouse | Lindorm | | ------------------- | ------------------ | ------------------------- | ------------------------------- | ---------------------------- | --------------------------- | | 1. 点查 + 低频更新 | 可用（成本偏高） | 主场 | 可用（按 _id 可点查） | 不适合 | 主场 | | 2. 低延迟分析/检索 | 主场 | 不适合（需外挂索引/计算） | 主场（检索/过滤/排序强） | 主场（结构化聚合强） | 主场（索引裁剪+回表型） | | 3. 离线聚合（PB） | 不适合 | 作为数据源可用 | 不适合 | 边缘/可用（更偏交互式 OLAP） | 作为数据源可用 | | 4. 稀疏/动态 schema | 主场 | 主场 | 边缘（mapping 风险） | 边缘 | 主场 | | 5. 半结构化/JSON | 主场 | 边缘 | 主场 | 可用（日志分析强，全文需补） | 主场 | | 6. 特征向量/高维 | 边缘（需核实能力） | 可用（按 id 取向量） | 可用（向量检索/过滤） | 边缘 | 可用（按 id 取向量） | 下面逐一展开：每个访问模式都用“物理结构匹配点”解释为什么，并把典型产品放进来说明“快的原因”和“退化的原因”。2.1 访问模式 1：点查 + 低频更新型（RowKey -> Wide Row）…