一、业务中普遍存在的查询性能割裂问题日常开发做数据查询、统计时经常会遇到一个很矛盾的性能现象相同查询语句仅筛选条件的值不同响应速度天差地别严重影响用户体验。场景 1图书检索系统检索小众语种图书韩语库内仅 3 条数据带索引查询秒出结果检索英文图书表内 99% 数据均为英文书籍此时行存数据库优化器判定索引收益极低直接放弃索引走全表扫描大量无关字段加载带来巨大 IO 开销查询严重卡顿。场景 2广告投放数据统计中小广告主每日仅数千条业务记录按用户筛选明细走索引查询速度稳定头部广告主单日产生数千万条数据按维度汇总统计时纯行存全表扫描效率断崖式下跌。场景 3开源项目热度分析限定单语言筛选如 Javascript海量数据中筛选少量匹配记录索引查询高效全语言热度排行统计需要遍历全表聚合计算传统行存执行缓慢。传统架构独立行存 列存两套引擎的致命短板为解决明细查询与批量分析的矛盾很多系统会搭建行存、列存两套独立数据库依靠 ETL 工具同步数据行存MySQLInnoDB,Oracle,PostgreSQL,SQL Server适配索引点查、少量明细读取、频繁增改缺陷是全表扫描 IO 成本极高列存ClickHousem,Snowflake,Apache Druid,Google BigQuery按列压缩存储仅读取查询所需字段适合批量扫描、聚合统计缺陷是单行精准检索性能弱。但该架构存在无法根治的硬伤 应用层必须人工判断当前 SQL 适合路由到行存还是列存没有统一调度能力。一旦筛选条件发生变化小众值查询变为全量统计最优存储引擎随之切换代码无法自适应性能波动问题无法从根源解决。二、TiDB 一体化架构一份数据统一 SQL 引擎兼顾行存与列存OSS Inside 没有采用传统双库分离方案而是基于 TiDB 原生能力构建统一数据层核心设计底层双存储副本TiKV 作为行存版本TiFlash 作为列存版本全局统一 SQL 入口仅有一套 KV Server 作为 SQL 执行引擎数据同源同步TiKV、TiFlash 是同一份数据的两个副本两边数据实时一致无需额外 ETL 同步两套库内置智能优化器自动评估 SQL 执行计划无需业务代码干预路由逻辑。优化器自动路由规则场景 A海量数据筛选少量结果、存在有效索引 → 自动下发至 TiKV 行存执行利用索引快速定位匹配数据场景 B大范围全表扫描、全维度聚合统计 → 自动切换 TiFlash 列存执行依靠列式压缩降低磁盘 IO提升批量计算效率。三、OSS Inside 实战演示49 亿行数据表的两种查询验证我们以 TiDB 中数据规模最大的github_events表做实测整张表存储49 亿行开源事件数据。精准筛选场景统计编程语言为 Javascript 的事件总量 SQL 携带精准过滤条件匹配数据约 1 亿多行优化器识别为索引查询场景自动路由 TiKV 执行查询秒级返回全量统计场景不限制编程语言统计全部项目热度数据 该语句等价全表扫描优化器判断索引无收益直接下发至 TiFlash 列存扫描计算无需遍历完整行数据查询依旧高速返回。查看两条 SQL 的执行计划可以清晰区分精准过滤走 TiKV 行存全局聚合自动切换 TiFlash 列存全程无需开发手动指定存储引擎。四、方案价值总结回到最初图书检索系统的痛点做对比如果业务系统采用 TiDB 一体化架构一套 SQL 引擎统一接管所有查询底层自动切换 TiKV/TiFlash切换检索条件时不会出现性能骤降、用户体验变差的问题。OSS Inside 基于 TiDB 实现的一体化存储查询架构彻底解决了传统 “行存 列存双库” 需要人工适配数据源的尴尬统一 SQL 入口、自动路由执行计划兼顾明细点查与海量数据分析两种核心场景大幅降低业务开发适配成本提升研发敏捷度。
