Loading [MathJax]/jax/output/CommonHTML/config.js
首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
MCP广场
社区首页 >专栏 >TiFlash:并非另一个 T + 1 列存数据库

TiFlash:并非另一个 T + 1 列存数据库

原创
作者头像
PingCAP
修改于 2020-03-24 02:08:27
修改于 2020-03-24 02:08:27
1.6K0
举报
文章被收录于专栏:PingCAP的专栏PingCAP的专栏

上篇关于 TiFlash 的文章 发布后,我们收到了很多伙伴们的反馈,大家有各种各样的疑问,包括 TiFlash 是不是 T + 1 列存数据库?为啥实时写入也很快?读压力大怎么办?节点挂了怎么办?业务怎么接入?……今天我们就来详细回复一下大家的问题,希望能对大家理解和实践 TiFlash 有所帮助。

并非「另一个 T + 1 列存数据库」

首先,它并不是独立的列存数据库:TiFlash 是配合 TiDB 体系的列存引擎,它和 TiDB 无缝结合,在线 DDL、无缝扩容、自动容错等等方便运维的特点也在 TiFlash 中得到继承。

其次,TiFlash 可以实时与行存保持同步。

T + 1 问题

「为何要列和 MySQL 的对比呢?这样是否太无聊?」

由于 TiFlash 具备实时高频实时更新能力,因此我们在 上一篇 介绍中单机对单机比较了交易型数据库例如 MySQL,因为这些特点一般是行存引擎具备的优势。TiFlash 与大多数列存不同的是,它支持实时更新,并且与行存数据保持同步。

「为何说其他列存数据库无法更新?我看到 XX 支持 Update 呀?」

多数列存引擎并不是绝对不支持更新,而是不支持主键或唯一性约束,因此无法像交易型数据库那样快速定位单条记录并进行一致性更新,这也是你无法向它们实时同步交易库数据的原因。针对这样的设计,常用的更新方式是使用 ETL 去重和融合新老数据,然后批量导入列存,这就使得数据无法实时分析而需等待数小时甚至一天。

TiFlash 是为实时场景设计,因此我们必须支持实时更新。在这个前提下,通过良好的设计和工程实现,也借助 ClickHouse 极速的向量化引擎,TiFlash 仍然拥有不亚于甚至超出其他列存引擎的优异性能。大家可以参考 上一篇文章中的 Benchmark

为什么实时写入也很快

「TiFlash 是列存,大家都说列存的实时写入很慢,TiFlash 呢?」

经过业界验证的实时更新列存方案是 Delta Main 设计。简单说,就是将需要更新数据与整理好的不可变列存块分开存放,读时归并,定期 Compact,而 TiFlash 也采取了类似设计思路。TiFlash 并非是拍脑袋发明了一种可更新列存结构,而是参考了其他成熟系统设计,如 Apache Kudu,CWI 的 Positional Delta Tree 等的设计思路,TiFlash 的设计也兼具了 B+ 树和 LSM 的优势,在读写两端都有优异的性能(但牺牲了对 TiFlash 场景无用的点查性能)。由于无需考虑点查,因此 TiFlash 可以以进行惰性数据整理加速写入;由于引入了读时排序索引回写,因此哪怕 Compact 不那么频繁仍可以保持扫描高效,进一步减小写放大加速写入。

「TiFlash 进行 OLAP 读取的时候会影响 OLTP 性能吗?」

上篇文章 中已经展示过 TiFlash 的读取性能:

注:为了不影响比例,上图忽略了 MySQL 和 Oracle 数据。

下面带大家看看更新写入速度,这里做了个简单的写入测试:

  • 测试配置 3 节点 6 TiKV(3 副本)+ 2 节点 TiFlash(2 副本)。
  • sysbench write-only 测试。
  • 以 60954.39 的 QPS 进行混合写入更新和删除。
  • 同时 TiFlash 不断进行全表聚合计算。

测试结果是:

  1. sysbench 运行 QPS 非常平稳,不会因为 AP 查询而抖动。从上图可以看到,黄色线段代表 AP 查询(开启和关闭),开启和关闭并不会对查询产生抖动,哪怕 999 分位。
  2. TiFlash 可以很好匹配 TiKV 的实时写入(包含增删改而非仅仅插入)同时提供查询。
  3. 另外,我们也观测到,以大压力写入同时进行查询,通过对 5000 个 TiFlash Region 副本采样:读取时,进行一致性校对 + 追赶 + 写入的时间平均 27.31 毫秒,95分位在 73 毫秒,99分位是 609 毫秒,对于分析类查询,这个延迟稳定性是可以接受的。

实际上,在都只写 1 副本的情况下,TiFlash 的写入性能大致可以追上 2-3 个同规格 TiKV 节点,这确保了 TiFlash 在更少的资源配比下,也可以匹配 TiKV 的写入压力。

为何如此?

由于 TiFlash 引擎针对 AP 场景无需点查的不同设计,它相对 LSM 引擎减小了写放大比率:TiFlash 的写放大大约在 3-7 倍之间。且在写入约繁忙情况下,由于攒批效果反而越接近更小的三倍放大比率。而 LSM 结构下,RocksDB 的写放大在 10 倍左右。这个对比优势大大提高了 TiFlash 磁盘实际能承载的业务吞吐量。

方便敏捷的运维

灵活扩容

「如果读压力也很大,你光写得够快有啥用啊?」

虽然我们展示了 TiFlash 的写入性能,其实哪怕它的写入速度不如 TiKV,我们仍然可以单独对 TiFlash 进行扩容。不管 TiFlash 的写入性能多优秀,仍然有可能因为用户的查询读取压力过大而造成写入速度下降,这时候是否就会产生严重的复制延迟呢?

会。但是 TiFlash 却可以依靠 TiDB 的体系单独扩容,如果业务压力过大,多上线几台 TiFlash 节点就可以自然分担数据和压力,用户完全无需操心扩容过程,这些都是透明且自动的。相对于同节点的行列混合设计,这样的架构无疑更灵活,且仍然保持了一致性。

自动恢复

「节点挂了怎么办?」

当 TiFlash 节点损坏下线,TiDB 体系可以保证 TiFlash 的数据自动从行存恢复副本,而补副本的过程也会考虑不对 TiKV 产生冲击。在 TiFlash 多副本的情况下,这个过程对用户也是完全透明无感知的:你只需要将补充的服务器启动上线就行。

无阻塞 DDL

「TiFlash 支持 DDL 吗?」

TiFlash 继承了 TiDB 体系的在线 DDL,尤其是它支持了更改列类型。与传统列存系统需要完全重写列格式不同,TiFlash 支持混合表结构,每个列数据块可以有独立的表结构,这使得 TiFlash 更改列类型是完全实时且无负担的:没有数据需要被立刻重写。这种设计,使得 TiFlash 可以很容易被用于数据集成场合,任何上游数据源的表结构变更可以无阻塞地被同步。

快速的业务接入

上述所有这些特性,使得 TiFlash 体系可以非常便捷地承载实时分析业务。考虑一下如果你有一个新业务上线,你需要将在线业务接入分析平台例如 Hadoop,你也许需要做如下事情:

  1. 修改业务逻辑,在表结构中添加变更时间标记以便增量抽取。
  2. 编写定时任务,从源数据库中抽取增量数据。
  3. 将数据写入 Staging 表,通过和 Hive 目标表进行 JOIN 并回写以处理增量更新。
  4. 很可能你还需要编写数据校验代码定期检查一致性。
  5. 那么也意味着你需要编写不一致时的修复代码。

这个过程可能需要耗费数天,甚至更久,而你还需要维护整个传输链路。

在 TiDB + TiFlash 体系下,你只需要一条命令:

代码语言:txt
AI代码解释
复制
ALTER TABLE your_table SET TIFLASH REPLICA 1;

你就可以自动获得一份实时保持一致的列存数据镜像,进行实时分析。

5秒(取决于你的手速) vs 数天

即便你已经有完整的 Hadoop 数仓建设,TiFlash 配合 TiSpark,也可以轻松衔接两个平台的同时,为离线数仓提供实时分析能力。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

评论
登录后参与评论
暂无评论
推荐阅读
编辑精选文章
换一批
TiFlash 源码阅读(一) TiFlash 存储层概览
本系列会聚焦在 TiFlash 自身,读者需要有一些对 TiDB 基本的知识。可以通过这三篇文章了解 TiDB 体系里的一些概念《 说存储 》、《 说计算 》、《 谈调度 》。
PingCAP
2022/04/27
1K1
TiDB HTAP 深度解读
HTAP (Hybrid Transactional / Analytical Processing)是近些年需求不断受到关注的技术名词,它描述了一个数据库能够同时满足交易以及分析两种作业。TiDB 4.0 是一个针对 HTAP 进行了特别的设计和架构强化,这次给大家带来一篇 VLDB 2020 HTAP 主题的论文解读,比较特殊的是这篇论文是 PingCAP 写的,关于 TiDB HTAP 架构。所以这篇解读,是以作者团队(中的一部分)的视角来写的。原文在此,欢迎指正。
PingCAP
2020/09/18
1.2K0
TiDB HTAP 深度解读
TiDB + TiFlash : 朝着真 HTAP 平台演进
在互联网浪潮出现之前,企业的数据量普遍不大,特别是核心的业务数据,通常一个单机的数据库就可以保存。那时候的存储并不需要复杂的架构,所有的线上请求(OLTP, Online Transactional Processing) 和后台分析 (OLAP, Online Analytical Processing) 都跑在同一个数据库实例上。后来渐渐的业务越来越复杂,数据量越来越大,DBA 们再也优化不动 SQL 了。其中一个显著问题是:单机数据库支持线上的 TP 请求已经非常吃力,没办法再跑比较重的 AP 分析型任务。跑起来要么 OOM,要么影响线上业务,要么做了主从分离、分库分表之后很难实现业务需求。
PingCAP
2019/09/02
2.8K0
原创分享 TiDB 的列式存储引擎是如何实现的?
TiDB 是一款分布式 HTAP 数据库,它目前有两种存储节点,分别是 TiKV 和 TiFlash。TiKV 采用了行式存储,更适合 TP 类型的业务;而 TiFlash 采用列式存储,擅长 AP 类型的业务。TiFlash 通过 raft 协议从 TiKV 节点实时同步数据,拥有毫秒级别的延迟,以及非常优秀的数据分析性能。它支持实时同步 TiKV 的数据更新,以及支持在线 DDL。我们把 TiFlash 作为 Raft Learner 融合进 TiDB 的 raft 体系,将两种节点整合在一个数据库集群中,上层统一通过 TiDB 节点查询,使得 TiDB 成为一款真正的 HTAP 数据库。
PingCAP
2020/08/07
2.2K0
原创分享 TiDB 的列式存储引擎是如何实现的?
读论文 - F1 Lightning: HTAP as a Service
论文发布之后已经有一段时间了,之前提到的这篇文章由于种种原因也是欠了有些日子,抱歉了大家。
PingCAP
2020/10/15
1.4K0
TiDB HTAP 的架构演进及实践
在访问量和数据量急剧膨胀的今天,关系型数据库已经难以支撑庞大复杂的系统规模。在此背景下,备受关注的数据库新理念 HTAP,会是一条“正确”的路吗?在刚过去的 QCon 全球软件开发大会上,PingCAP 实时分析产品负责人马晓宇发表了《TiDB HTAP 的架构演进及实践》的主题演讲,它从 HTAP 的历史入手,详述了 HTAP 的技术挑战以及 TiDB 的应对方案。本文为其演讲整理文,enjoy~ 大家好,今天为大家分享以下几方面内容。首先是分享 HTAP 的历史,其次是 TP 和 AP 之间存储和计算的
深度学习与Python
2023/04/01
1K0
TiDB HTAP 的架构演进及实践
【赵渝强老师】TiDB的列存引擎:TiFlash
TiDB的TiFlash提供列式存储,且拥有借助ClickHouse高效实现的协处理器层。除此以外,它与TiKV非常类似,依赖同样的Multi-Raft体系,以Region为单位进行数据复制和分散。TiFlash以低消耗不阻塞TiKV写入的方式,实时复制TiKV集群中的数据,并同时提供与TiKV一样的一致性读取,且可以保证读取到最新的数据。TiFlash中的Region副本与TiKV中完全对应,且会跟随TiKV中的Leader副本同时进行分裂与合并。下图为TiDB HTAP形态架构,其中包含TiFlash节点。
赵渝强老师
2025/04/16
840
【赵渝强老师】TiDB的列存引擎:TiFlash
PingCAP 开源分布式数据库 TiDB 论文入选 VLDB
8 月 31 日 - 9 月 4 日,第 46 届 VLDB 会议以线上直播的方式举行(原定于日本东京召开),PingCAP 团队的论文《TiDB: A Raft-based HTAP Database 》入选 VLDB 2020 ,成为业界第一篇 Real-time HTAP 分布式数据库工业实现的论文。PingCAP 联合创始人、CTO 黄东旭获邀在会上进行演讲,分享关于论文的深度解读及在线答疑。
PingCAP
2020/09/04
1.4K0
PingCAP 开源分布式数据库 TiDB 论文入选 VLDB
Why HTAP Matters
说到 Why HTAP Matters,其实包含两部分,一部分是说为什么我们叫 HTAP,另外一部分是说 TiDB 怎样在 HTAP 架构下发挥它的优势。
PingCAP
2020/08/03
1K0
Why HTAP Matters
初探TiDB-TiFlash
TiFlash是TiDB生态组件之一,专门解决OLAP场景。借助ClickHouse实现高效的列式计算。
田帅萌
2020/04/15
1.7K0
初探TiDB-TiFlash
为了证明它的速度,我们一口气对比了 Oracle、MySQL、MariaDB、Greenplum ...
为了更直观回答这个问题,我们用最新版本的 TiFlash 进行了一次全新的对比测试。测试选取了传统交易型数据库(及其列存扩展),分析型数据库和大数据计算引擎进行对比,分别是 Oracle、MySQL、MariaDB ColumnStore、Greenplum 和 Apache Spark。
PingCAP
2020/02/13
3.5K3
理想汽车 HTAP 读流量优化指南
郑赫扬(艺名:潜龙),理想汽车 DBA。负责公司分布式数据库的技术探索和业务场景落地,热爱开源。就职于金融、互联网教育、电商、新能源汽车等领域。
PingCAP
2021/11/05
6230
第四代HTAP数据库的亮点是什么 ?
OLTP + 实时OLAP两种Store并行,从客户端进来的请求智能选择,TiDB 可以自动选择使用 TiFlash 列存或 TiKV 行存,甚至在同一查询内混合使用提供最佳查询速度。(这个选择机制与 TiDB 选取不同索引提供查询类似:根据统计信息判断读取代价并作出合理选择)。
杨漆
2021/01/19
6160
第四代HTAP数据库的亮点是什么 ?
TiFlash 源码阅读(三)TiFlash DeltaTree 存储引擎设计及实现分析 - Part 1
TiFlash 是 TiDB 的分析引擎,是 TiDB HTAP 形态的关键组件。TiFlash 源码阅读系列文章将从源码层面介绍 TiFlash 的内部实现。希望读者在阅读这一系列文章后,能够对 TiFlash 内部原理有一个清晰的理解,更熟悉 TiFlash 各个流程及概念,甚至能对 TiFlash 进行源码级别的编程开发。在 上一期源码阅读 中,我们介绍了 TiFlash 的计算层。从本文开始,我们将对 TiFlash 各个组件的设计及实现进行详细分析。
PingCAP
2022/06/07
6230
TiFlash 源码阅读(三)TiFlash DeltaTree 存储引擎设计及实现分析 - Part 1
分布式数据库的HTAP能统一OLTP和 OLAP吗?
OLAP和OLTP通过ETL衔接。为提升OLAP性能,需在ETL过程进行大量预计算,包括:
JavaEdge
2023/08/13
5730
分布式数据库的HTAP能统一OLTP和 OLAP吗?
[学习笔记] TiDB学习笔记(三)
本文是《极客时间》-《TiDb极简入门》的学习笔记。传送门:https://time.geekbang.org/opencourse/videointro/100089601
菜刀兔
2022/01/02
1.1K2
​国产数据库梳理
网上对这些数据库介绍有些误导,流传各种说法,比如:流传OB基于MySQL、GaussDB 200/300 和openGauss有啥区别,没办法谁让当前国产数据库太多...
donghy
2022/09/17
2.6K0
构建实时数仓 - 当 TiDB 偶遇 Pravega
数据仓库是公司数据发展到一定规模后必然需要提供的一种基础服务,也是“数据智能”建设的基础环节。早期数仓多为离线模式,主要处理的是 T+1 的数据,随着互联网时代的到来,实时数据处理的场景日益增多,离线数仓已无法满足业务发展的实时性需求。为更好的解决业务场景的实时化需求,实时数仓建设已成必然趋势,这也是 HTAP 数据库的重要能力之一。
PingCAP
2021/06/09
8990
干货 | 分布式数据库TiDB在携程的实践
携程自2014年左右开始全面使用MySQL数据库,随着业务增长、数据量激增,单机实例逐渐出现瓶颈,如单表行数过大导致历史数据查询耗时升高,单库容量过大导致磁盘空间不足等。为应对这些问题,我们采取了诸多措施如分库分表的水平拆分、一主多从读写分离、硬件SSD升级、增加前端Redis缓存等,但同时也使得整个业务层架构更加复杂,且无法做到透明的弹性,因此开始将目光转移到分布式数据库以解决这些痛点。
携程技术
2021/12/13
9290
干货 | 分布式数据库TiDB在携程的实践
成为一栈式数据服务生态: TiDB 5.0 HTAP 架构设计与成为场景解
数字化转型浪潮是现在进行时,在企业数字化转型的过程中,我们看到一个普遍的趋势,企业对“海量、实时、在线”的数据需求变得更加迫切。数字化转型并不是互联网公司的专利,人工智能、大数据、物联网这些技术也不仅仅是互联网公司才会使用。事实证明,越来越多的传统企业正在应用这些新兴技术进行业务的创新。每一项新技术的应用都需要一定的技术积累,互联网公司也许会配备很多工程师来支持一个数据体系架构。但对于传统公司来说也许不具备这样的实力,他们会发现自己很难驾驭大数据技术栈。此外,传统大技术栈已经慢慢开始难以应对日新月异的业务需求和爆炸性的数据增长。企业的很多业务对数据实时性的要求越来越高,比如风控、反欺诈等,更早地识别和阻断风险可以让企业减少损失;在物流行业,更实时的数据让物流企业可以更实时地调配行车路线和各类资源,以达到更好的运营效率;公共服务也会对实时数据产生要求,如果去柜台办理一个业务,需要等很久才能查到刚刚办的上一个流程的数据,这对于用户体验来说是非常糟糕的。
PingCAP
2021/05/08
5920
成为一栈式数据服务生态: TiDB 5.0 HTAP 架构设计与成为场景解
推荐阅读
相关推荐
TiFlash 源码阅读(一) TiFlash 存储层概览
更多 >
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档