精华内容
下载资源
问答
  • partial-htap-源码

    2021-03-19 15:56:59
    partial-htap
  • Why HTAP Matters

    2020-08-03 14:35:39
    说到 Why HTAP Matters,其实包含两部分,一部分是说为什么我们叫 HTAP,另外一部分是说 TiDB 怎样在 HTAP 架构下发挥它的优势。 什么是 HTAPHTAP,首先 HTAP 是 Gartner 提出的一个名词,它其实描述的概念很简单...

    说到 Why HTAP Matters,其实包含两部分,一部分是说为什么我们叫 HTAP,另外一部分是说 TiDB 怎样在 HTAP 架构下发挥它的优势。

    什么是 HTAP?

    HTAP,首先 HTAP 是 Gartner 提出的一个名词,它其实描述的概念很简单,就是一个数据库同时能具备 TP 和 AP 两种能力。TP 就是 Transactional Processing,也就是交易处理,这样的数据库是使用行存,支持实时更新,也可以有高并发,一般来说提供强一致的需求,每次 workload 基本上只触及比较少的数据。通常在数据库里面存的是当前数据。AP 则相反,全称为 Analytical Processing,即分析处理,大多数分析处理的场景是列存,它支持的只是批量更新支持的也是中低并发的 workload,基本上每个查询都会处理大量的数据。一般存放的是历史数据。

    所以大家可以看到 TP 和 AP 对于需求和技术侧其实是非常不一样的。因为这些不同,所以传统的数据架构其实是下图这样子的。

    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-RgAjCc2q-1596436139851)(media/why-tidb-matters/1-传统数据平台架构.png)]

    我的在线数据其实是在 online database 上,这部分是处理 TP 的数据,然后 TP 的数据需要通过一个 T+1 导到 AP 数据库,一般来说有很多种选择,比如说你是 Relational 的 Data Warehouse 或者也可以是 Hadoop 的 Data Lake,数据处理完之后有两种选项。一种选项是,数据处理完之后直接出报表或者导到一个 Data Serving 的 database 里面去,或者回馈到在线库。不管是其中哪一个环节都会增加数据的延迟,整个数据架构会比较复杂,其实如果你有一台 HTAP 数据库,它其实是可以给用户降低架构的复杂度,也降低运维成本的,顺便会提升业务的实时性,以及提升业务的敏捷性。敏捷性就是说你要开启一个业务或者要新建一个业务所需要的开发周期和架构周期。为什么呢?大家之前不是都是用这种老的架构,也跑的也好好的。现在其实 TP 和 AP 的边界会变得更加模糊化,AP 业务会变得 TP 化。比如说提供报表的同时也提供高并发的短查询,然后可能会对历史明细提供一些小范围的查询。或者 TP 也会变得更 AP 化,比如在交易的同时需要大规模的分析,或者回馈在线库,优化在线行为,或者要对实时的数据业务进行实时分析,或者要对跨业务线提供一个综合查询能力。

    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ZtWTPxet-1596436139853)(media/why-tidb-matters/2-销售业务平台.png)]

    举个具体的例子,比如说有一个很简单的业务叫销售业务平台(见上图),靠左边是偏 TP 的,最 TP 的是在线订单管理,要求的就是纯粹的 TP 能力,大家可以看右下角的注释:绿色的是使用行存索引做细粒度的查询,黑色是高并发,蓝色是实时更新。

    最左侧是最典型的 TP 业务,TP 业务来说需求的就是很明显的 TP 业务所有的一些技术特征。再往最右侧来看,最典型的 AP 业务是销售的历史报表,因为是历史报表,所以需要存大量的数据,要求的是可扩展性,一般来说使用列存,列存是用黄色的点。

    中间的一些其实是有点像 TP 也有点像 AP 的东西:历史明细查询,虽然数据量也很多,但是可能需要点查某一些数据,比如点查某一个人的明细订单或者点查某一批获批的明细订单;热销推荐,可能需要的是在交易发生的同时迅速的计算出现在卖的最好的是什么东西,它可能是对在线业务的一个多维聚合查询;订单联合仓储的明细查询或者说实时查询,它要求的不只是查询订单库的内容,还可能要求同时查询仓储库的内容;实时大屏就更好理解了,我一边卖的时候一边看哪些东西卖的比较好或者在什么城市卖了哪些东西;实时促销调价会稍微复杂一点,比如根据现在促销的情况,通过程序的方式实时进行调价。

    除了一左一右两边分别是 TP 和 AP,中间其实都是 TP 和 AP 混合的场景,因为它对整个技术侧来说需求是非常不一样的,大家可以看到下方标的那些能力的点都是有不同的需求的。

    同时满足这些需求其实不是很容易,为什么?比如说扩展性,TP 的扩展性其实是很难做的,虽然 AP 的扩展性,比如说像 AP 数据库或者 Hadoop 那些其实都已经很早就有了,但能做 TP 的数据库还能够扩展的,其实是近几年才有的,就是所谓的 NewSQL。TP 同时要兼具 AP 能力,就要求它同时能有行存和列存两种存储格式,光是这两者还不够,它还要能有机的把这两者统和起来,统和起来就会带来很多问题,比如说在互通数据的时候怎样保持高实时性,同时兼顾一致性。

    TiDB 4.0 HTAP 体系

    现在讲一下 TiDB。在 TiDB 4.0 之前,已经具备了一些能力。比如首先它立项的时候是为了一个交易型数据库来设计的,所以最早的时候就已经是一个比较完善的交易型数据库,同时兼容 MySQL 的特性,现在线上已经有万亿级的单库规模,能承载千万级的 QPS 业务,银行核心业务上已经稳定上线。但立项一开始并没有预计到的是,我们其实推出去之后它其实也是一个良好的数据中枢或者叫 data hub 或者是实时数仓的载体。这是以前 TiDB 已经有的两个大类的使用,就是 TP 和 AP。

    从 4.0 来说,TiDB 把 HTAP 体系更加完善了,主要是加入了实时更新的列存,就是 TiFlash。这套引擎整合在一起其实就是一个可扩展的行存和列存整合的架构,这套整合的架构在存储上是可以使用分离的不同的节点,可以确保两边互相之间没有干扰,它的实时性、一致性、可延展性都能得到很好的保证。复制本身这套体系是没有中间层的,所以复制是非常简便而且非常快的。就整个体系来说,它不光有列存,有全面支持行存的所有的索引的特性。另外添加了向量化引擎,列存本身和行存之间能通过智能的引擎选择。

    TiDB 本身其实没有办法做很详细的阐述,因为这是一个短 talk。我们在 VLDB 发了一个 paper,之后等这个 paper 可以公开的时候基本上我们会出一些更详细的说明,具体说整个 HTAP 这套体系在 TiDB 里面是怎么设计的。之所以提一下 paper,是想说这个东西并不是我们自嗨说它是 HTAP 或者说是一个很先进的架构,至少这个东西能通过一个顶刊的学术审核,能让研究者也觉得它是一个很有意思的东西。

    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-fDDv2O2G-1596436139854)(media/why-tidb-matters/3-HTAP架构.png)]

    上图是现在 TiDB 4.0 的 HTAP 架构,左侧是新增的 TiFlash 的节点,右侧是 TiKV,上面的计算层还是一样的,上面的计算层还是以 TiDB 或者说以 TiSpark 为主。

    可扩展的实时更新体系

    首先说可扩展的实时更新体系,这里包括几点:

    第一个是 TiDB 的 TiFlash 架构下还是使用 Mutli-Raft 的,也就是说 TiFlash 复制数据和存储数据的单元,比如说是以 region 为单元存储,这些和 TiKV 还是保持一致的,但是它是从一个行存到列存的复制。

    第二,这个复制的特点是无需中间介质的,也就是说所有的复制并不像普通的复制体系可能要通过一些分布式的管道,比如像 Kafka 或者其它的 MQ 系统,这样的话,复制其实会有比较大的延迟。在 TiDB 体系底下的行存和列存之间复制是以 region 点到点之间复制的,所以说你可以认为当中没有任何的中间介质,保证复制的实时性。

    第三,它兼顾复制和存储的伸缩性,也就是说整个体系来说,刚刚说过还是以 Multi-Raft 来做的,所以 Sharding 的单位也是以 region 为单位 Sharding,整个调度的模式还是符合原先的调度模式,所以他还是一样可以自然扩展。有意思的是行存和列存可以分别扩展,也就是说你有可能有一些用户行存可能需要用更多的机器,有一些用户可能列存需要用更多的机器,这相对于那些行存和列存放在同机的系统设计来说,要有很大的优势。

    第四也是最方便的是,以上这些,只需要一道命令来开启。

    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-3uvdv9AS-1596436139856)(media/why-tidb-matters/4-复制体系.png)]

    上图中,左边是我们复制体系,大家可以看到是以 region 为单位,region 到 region 直接复制,相对来说传统的如果是 T+1 的 ETL 的话要经过一个 Staging Area 或者哪怕实时复制,可能也需要经过 Kafka 那样的系统,复杂度和延时性都会上升。开启 TiFlash 同步其实只要一条命令:

    mysql> ALTER TABLE orders SET TIFLASH REPLICA 2;
    

    就是为 orders 表创建 2 个列存副本。

    异步却实时 + 一致的读取

    这其实是一个异步复制体系,并不是一个同步强制说两边都要写平才能提供服务的一套体系。所以说交易事务不会被列存 block,也就是说列存不管你是写的快还是写的慢,交易都不会被列存 block。哪怕说列存这边即使 down 了,行存这里还是可以继续工作。同时虽然是一个异步复制不等待的体系,Raft 整个共识协议会保证我读取的数据是最新的。

    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-4PNyvfGu-1596436139857)(media/why-tidb-matters/5-异步复制.png)]

    为什么在异步复制底下读取还是可以最新?说起来其实是一个非常简单的东西。可以看上图,我们在读取的同时会对行存的 leader 节点发起一个读取校对,这个校对其实就包含我现在复制的进度是多少,你只要告诉我一个进度号就行了,如果进度号不满足最新的数据要求,其实列存这边会等待。实际上测下来等待如果不是在 90% 到 100% 的满载系统里面,等待的时间其实是非常短的,是以毫秒来计算的。

    优化器智能选择

    比较有意思的一点是,这套系统并不是一个和行存之间割裂的系统。行列之间是一个有机整合,怎么整合?就是通过 TiDB 优化器,优化器会把列存当做一个特殊的索引,然后通过统计信息的方式,在不同的行存索引之间选择是一样的方式,就是基于统计信息和代价优化器去选择出现在最快的路径应该是选择行存还是列存或者说选择哪一条索引,所以说这套系统在同一个 TiDB 的入口就可以体现行存和列存两种不同的优势,用户也不需要在一个复杂的查询当中去考虑说我到底是使用行存还是列存,当然用户如果要保证完美的隔离,也可以手工开启只读行存或者只读列存,这样就会对应出 TP 和 AP 之间非常隔离的一种方式。

    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-QcIopo2d-1596436139859)(media/why-tidb-matters/6-性能测试-1.png)]

    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ti8Eyvu1-1596436139860)(media/why-tidb-matters/7-性能测试-2.png)]

    其实之前我们的 blog 上都写过,由上面两个图可见,这套系统的性能是非常不错的。当时是用 TiDB 加上 TiFlash,对比 Mariadb,对比 Spark 以及对比 Greenplum,当然也对比了 Oracle,但是 Oracle 没有开始它的列存。

    配合 TiSpark

    整套 HTAP 体系还有一个特色,就是配合 TiSpark 可以无缝衔接 Spark 上的生态,比如提供 AI 计算、Data Science 的 toolbox、BI 的对接,或者复杂的场景分析,这些都是可以由 Spark 体系加 TiSpark 来提供。它同时也可以 Hadoop Data Lake 当做同一套系统来查询。对于 TiDB 体系来说,则是提供一个重型复杂查询良好的分布式计算的性能。

    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-eW3HbLYd-1596436139861)(media/why-tidb-matters/8-性能对比.png)]

    上图是 TiSpark 加 TiFlash 对比 Greenplum 的性能,大家可以看到基本上是处于同一个量级,就是有一些 Greenplum 会更快一些,有一些 TiSpark 加 TiFlash 更快一些。

    TiDB HTAP 应用实践

    回到前面已经阐述过的观点,在 HTAP 场景底下 TiDB 能为用户提供一个简化架构,降低运维复杂度,更重要的是我们提升业务的实时性,提升业务的敏捷性。

    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-NRUvHCzP-1596436139863)(media/why-tidb-matters/9-实时数仓.png)]

    上图是 TiDB 其中 AP 场景当中一个比较主流的用法,就是做一个实时集成,也可以叫实时数仓,也就是说我用同一套 TiDB 可以做一个多源汇聚,不同的数据业务库从不同条线实时汇聚到 TiDB,因为 TiDB 是一个可持续更新的系统,所以它可以很方便的兼容从其它的 OLTP 库同步数据。同时在这套 TiDB 上也可以提供实时的查询,比如说可以提供报表,或者做一个客服系统,把各种不同库汇聚过来的信息给客户提供服务,或者做实时大屏,还可以做 AI。

    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-LNaGjjtJ-1596436139864)(media/why-tidb-matters/10-交易分析.png)]

    另外一种是更具体一点的用法(见上图),比如原本有很多用户是拿 MySQL 当在线库,然后他需要做 T+1 的同步到一个分析型数据库或者到 Hadoop,MySQL 提供的是在线的业务,BI 工具是连接到分析型数据库或者是连接到 Hadoop 上。对于这样的场景只需要一套 TiDB,原来 APP Server 对接的在线业务库就可以对接 TiDB 的行存,原来 BI 工具对接的报表类分析可以对接 TiDB 的列存。这样的话,对比先前,不光是架构简化还可以大大增加你的实时性能。

    有很多人可能会说你说的这么好,其实我不可能把所有业务都迁到 TiDB 上去,我现在也有我很成熟的 Data Warehouse 架构,我也在数仓做了很多建模,有很多方法论,对于这样的场景来说,是不是 TiDB 就没用了呢?

    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-f8A8ZAYc-1596436139865)(media/why-tidb-matters/11-结合现有数仓架构.png)]

    很多现在其实已经有 Hadoop 或者有数据仓库的用户其实是这样使用 TiDB 的 HTAP 体系的(见上图)。对于实施层来说,它会把数据汇聚到 TiDB 当中,TiDB 会提供一个 Real Time Layer,这个 Layer 会直接提供一些实时的查询,甚至直接提供对外的数据业务服务。同时也可以通过 Spark 把数据迁移到 Offline 的 Hadoop Layer,Hadoop Layer 同时可以把数据建完模或者清洗完,或者做一些聚合之后再回馈到 TiDB 层,这样 TiDB 会提供一个更方便的数据服务。因为一般来说不太可能把 Hadoop 直接当做 API 暴露到对外的层面,因为 Hadoop 承载不了这样比较高速实时的查询。所以这样的一套体系就会比较方便的为你整个现有的这套机构赋予一个 real time 的能力。

    目前这套系统已经被很多用户应用了,大家可以查看《TiDB HTAP 助力小红书业务升级》《TiDB 4.0 在 VIPKID 的应用实践》《海外直播软件 Bigo 的 TiDB 4.0 线上实践》《从 Exadata 到 TiDB,中通快递 HTAP 实践》,看看我们的用户现在怎么用以及现在这套他们用的好不好。

    作者简介:马晓宇,PingCAP 实时分析产品负责人。
    本文整理自马晓宇在 TiDB DevCon 2020 上的演讲,大会相关视频回顾可以关注官方 Bilibli 账号 TiDB_Robot 的更新。

    展开全文
  • TIDB——HTAP

    2021-08-04 14:54:35
    新一代HTAP数据库选型 HTAP概念的产生 传统数据库OLAP的技术:并行计算,partition,物化视图,列存,bitmap HTAP核心诉求数据服务的统一 TiDB应对HTAP 1.海量存储允许多数据汇聚,数据实时同步 2.支持多标准SQL,...

    新一代HTAP数据库选型
    HTAP概念的产生

    在这里插入图片描述
    在这里插入图片描述
    传统数据库OLAP的技术:并行计算,partition,物化视图,列存,bitmap
    HTAP核心诉求数据服务的统一
    TiDB应对HTAP
    1.海量存储允许多数据汇聚,数据实时同步
    2.支持多标准SQL,多表关联快速出结果
    3.透明多业务模块,支持分表聚合后可以任务维度查询
    4.TiDB最大下推机制、以及并行hash join 等算子,决定的TiDB在表关联上的优势
    适用于:后台运营系统、财务报表、大屏展现、用户画像

    引入Spark来缓解数据中台算力问题
    在这里插入图片描述
    Spark只能提供低并发的重量级查询,在从应用场景,很多中小规模的轻量AP查询,也需要高并发、相对低延迟技术能力,在这种场景下,Spark的技术模型重,资源消耗高的缺点就会暴露
    列示存储天然对OLAP友好,将数据放在列示引擎上。劣势(实时更新)
    在这里插入图片描述
    为解决实时更新的劣势引入Raft-Base最佳方案
    在这里插入图片描述
    引入MPP算力
    在这里插入图片描述
    HTAP下一步探索
    1.分布式数据库是在大数据规范下提供的HTAP的基础
    2.TiDB-Server 最大程度下推算法与Hash Join关键算子提供了基础AP能力
    3.借助生态,让Spark跑在TiKV上
    4.行列混合引擎,列式引擎提供实时写入能力
    5.行列引擎采取Raft-Base replication解决了数据同步效率
    6.TiDB-Server统一技术服务
    7.MPP解决了技术节点的扩展性与并行计算

    数据服务统一:产品内嵌功能的迭代,由一些具体的产品来完成HTAP。整合多个技术栈与产品,并进行数据的连同,形成服务的HTAP

    批处理(ETL)离线数仓
    批、流结合 Lambda架构
    流计算为主的kappa架构

    分区、列式存储、并行计算

    TiDB关键技术的创新
    1.三个分布式系统:分布式KV存储系统、分布式SQL计算系统、分布式的HTAP架构系统
    2.自动分片技术是更细维度弹性的基础
    全局有序的KV map
    按照等长大小策略自动分片(96M)
    每个分片是连续的KV,通过Start/End key 来寻址
    每个分片seek成本固定
    我们称该分片为region,它是复制调度的最小单位
    在这里插入图片描述
    3.Multi-Raft将复制组更离散
    在这里插入图片描述
    Region base Multi-raft的机制,实现了一个表可以同时有多个写入点TiKV的调度机制,可以识别单个节点的物理信息,比如IDC、REC、Host等(机房、机柜、宿主机等),并进行约束与绑定

    4.去中心化的分布式事务(两阶段提交)
    在这里插入图片描述
    在这里插入图片描述
    5.Local read and Geo-partition
    6.更大数据容量下的AP与TP的融合
    TiDB引入了实时更新的列式引擎,即解决了资源隔离,又提升了AP效率
    在列式上引入了MPP模型,实现了SQL join的下推与并行处理
    通过Raft-Base replication实现了更时效性
    融合了大数据生态,TiSpark
    7.数据服务的统一
    TiDB的CBO可以采集行列Cost模型进行配置,并同步收集不同引擎的统计信息,统一进行最佳路径选择

    TiDB典型应用场景
    OLTP Scale 高扩展联机 挑战(高并发,计算能力;大数据量,存储能力;高可用性,持续服务能力)
    强一致分布式事务
    悲观锁+乐观锁
    透明分布式
    多中心容灾多活
    SQL完整支持
    弹性扩展调度

    Mysql分表:单表性能问题,数据量超过一定大小,Btree高度增加一层IO增加响应时间增加
    MySQL分库:写入是昂贵资源,主从库的写入完全依赖于主库的硬件,如果写入超过了上限就要分库
    为什么需要中间件
    在这里插入图片描述
    在这里插入图片描述
    Reai-Time HTAP
    在这里插入图片描述
    在这里插入图片描述

    展开全文
  • TiDB as an HTAP Database

    2018-04-02 18:32:59
    TiDB as an HTAP Database 主讲人:PingCap CEO 刘奇 Hybrid Transactional / Analytical Processing ● ACID Transcation ● Real-time analysis ● SQL
  • TiDB HTAP 深度解读

    千次阅读 2020-09-18 18:43:43
    HTAP (Hybrid Transactional / Analytical Processing)是近些年需求不断受到关注的技术名词,它描述了一个数据库能够同时满足交易以及分析两种作业。TiDB 4.0 是一个针对 HTAP 进行了特别的设计和架构强化,这次给...

    HTAP (Hybrid Transactional / Analytical Processing)是近些年需求不断受到关注的技术名词,它描述了一个数据库能够同时满足交易以及分析两种作业。TiDB 4.0 是一个针对 HTAP 进行了特别的设计和架构强化,这次给大家带来一篇 VLDB 2020 HTAP 主题的论文解读,比较特殊的是这篇论文是 PingCAP 写的,关于 TiDB HTAP 架构。所以这篇解读,是以作者团队(中的一部分)的视角来写的。原文在此,欢迎指正。

    说重点

    论文整体介绍了一下 TiDB 的架构和设计,对 TiDB 有兴趣的同学推荐完整看下,会对理解架构有很大帮助。不过既然重点是 HTAP,那么在我看来比较重要的地方是这三点:

    1. 实时更新的列存
    2. Multi-Raft 的复制体系
    3. 根据业务 SQL 智能选择行/列存储

    后面我也会着重说一下这三部分。

    先说存储

    TP 和 AP 传统来说仰赖不同的存储格式:行存对应 OLTP,列存对应 OLAP。然而这两者的优劣差异在内存中会显得不那么明显,因此 SAP Hana 的作者 Hasso Plattner 提出使用 In-Memory + 列存技术同时处理 OLTP 和 OLAP。随后 2014 年 Gartner 提出的 HTAP 概念,也主要是针对内存计算。
    这里有个关键信息,列存不合适 TP 类场景。这也许已经是很多人的常识,不过也许并不是所有人都想过为何列存不合适 TP。

    数据快速访问需要仰赖 Locality,简单说就是希望根据你的访问模式,要读写的数据尽量放在一起。并不在一起的数据需要额外的 Seek 并且 Cache 效率更低。行存和列存,去除 encoding 和压缩这些因素,本质上是针对不同的访问模式提供了不同的数据 Locality。行存让同一行的数据放在一起,这样类似一次访问一整行数据就会得到很好的速度;列存将同一列的数据放在一起,那么每次只获取一部分列的读取就会得到加速;另一方面,列存在传统印象里更新很慢也部分是因为如果使用 Naive 的方式去将一行拆开成多列写入到应有的位置,将带来灾难性的写入速度。这些效应在磁盘上很明显,但是在内存中就会得以削弱,因此这些年以来我们提起 HTAP,首先想到的是内存数据库。

    虽然内存价格在不断下降,但是仍然成本高企。虽说分析机构宣传 HTAP 带来的架构简化可以降低总成本,但实际上内存数据库仍然只是在一些特殊领域得到应用:若非那些无可辩驳的超低延迟场景,架构师仍然需要说服老板,HTAP 带来的好处是否真的值得使用内存数据库。这样, HTAP 的使用领域就受到很大的限制。

    所以,我们还是以磁盘而非内存为设计前提。

    之前并不是没有人尝试使用行列混合的设计。这种行列混合可以是一种折中格式如 PAX,也可以是在同一存储引擎中通过聪明的算法糅合两种形态。但无论如何,上面说的 Locality 问题是无法绕过的,哪怕通过超强的工程能力去压榨性能,也很难同时逼近两侧的最优解,更不用提技术上这将会比单纯考虑单一场景复杂数倍。

    TiDB 并不想放弃 TP 和 AP 任何一侧,因此虽然也知道 Spanner 使用 PAX 格式做 HTAP,却没有贸然跟进。也许有更好的办法呢?

    TiDB 整体一直更相信以模块化来化解工程问题,包括 TiDB 和 TiKV 的分层和模块切割都体现了这种设计倾向。这次 HTAP 的构思也不例外。经过各种前期的的 Prototype 实验,包括并不限于通过类似 Binlog 之类的 CDC 方案将 TP 的更新同步到易构的 AP 侧,但是这些效果都不尽如人意,我们最终选了通过 Raft 来剥离 / 融合行存和列存,而非在同一套引擎中紧耦合两种格式。这种方式让我们能单独思考两个场景,也无需对现有的引擎做太大的改变,让产品成型和稳定周期大大缩短。另一方面,模块化也使得我们可以更
    好借助其他开源产品(ClickHouse)的力量,因为复杂的细节无需被封印在同一个盒子。

    市面上有其他设计采用了更紧密的耦合,例如 MemSQL 节点同时运行 TP 和 AP 两种业务,Spanner 选择 PAX 兼顾不同的读取模式,甚至传统数据库大多也在同一个引擎中添加了不同数据组织的支持。这样的架构会引入过于复杂的设计,也未必能在 TP 和 AP 任意一端取得好的收益。

    由于选择了松耦合的设计,我们只需要专心解决一个问题就可以搞定存储:如何设计一个可根据主键实时更新的列存系统。事实上,列存多少都支持更新,只是这种更新往往是通过整体覆盖一大段数据来达到的,这也就是为什么多数传统的 OLAP 数据库只能支持批量的数据更新,。如果无需考虑实时主键更新,那么存储可以完全无需考虑数据的去重和排序:存储按照主键顺序整理不止是为了快速读取定位,也是为了写入更新加速。如果需要更新一笔数据,引擎至少需要让同一笔数据的新老版本能以某种方式快速去重,无论是读时去重还是直接写入覆盖。传统意义上分析型数据库或者 Hadoop 列存都抛弃了实时更新能力,因此无需在读或者写的时候负担这个代价,这也是它们得以支持非常高速批量加载和读取的原因之一。但这样的设计无法满足我们场景。要达到 HTAP 的目标,TiDB 的列存引擎必须能够支持实时更新,而且这个更新的速率不能低于行存。

    事实上,我们肯定不是第一个在业界尝试实现列存更新的产品。业界对于列存更新,无论是何种变体,一个很通用的做法叫做 Delta Main。既然做列存更新效率不佳,那么我们何不使用写优化方式存储变更数据,然后逐步将更新部分归并到读优化的主列存区?只要我们保持足够的归并频率,那么整个数据的大部分比例都将以读优化的列存形态存在以保持性能。这是一个几乎从列存诞生起就有被想到的设计:你可以认为列存鼻祖 C-Store 就是某种意义上的 Delta Main 设计,它使用一个行存引擎做为写区,并不断将写区数据归并为列存。

    我们的可更新列存引擎 DeltaTree 的设计也是非常类似的思路。宏观上,DeltaTree 将数据按照主键序排序切分,类似 TiDB 的 Region 概念那样,每一个数据范围单独形成一个片段,每当片段的物理大小超过阈值就会分裂。微观上来说,每个片段就如上图一般,分成 Delta 和 Stable Space 两部分。其中 Delta 部分以优化写入为主,他们是以写入顺序攒批排列的小数据块,以写入顺序排列而非主键顺序能使得写入大大加速,因为数据写入只需要不断追加。每当积攒了足够多的 Delta 数据,引擎就会将他们归并到 Stable 区,Stable 区的设计类似 Parquet,也是以行组(Row-Group)再按列切割,并排序后压缩存储。Stable 区无疑是对读取优化的,如果只考虑 Stable,那么速度将会很快。但实际上在读取时,仍未归并到 Stable 的 Delta 数据可能需要覆盖 Stable 中的老数据,因此读取会是一个在线归并过程。为了加速这个归并,引擎为 Delta 部分添加了内存中的辅助 B+Tree 索引,这样 Delta 虽然并非物理有序(保持 Delta 物理有序将大大降低写入性能),但仍然保持逻辑有序,免去了归并前排序的代价。同时,由于宏观上数据区间的划分,使得每次归并无需重写所有数据减轻了归并的压力。

    回头说之前提到的 LSM 列存方案。实际上你可以认为 LSM 也可以近似认为是一种 Delta Main。当数据写入 MemTable 时,也是以写优化的追加形式写入。那是否 LSM 也可以成为一种支持列存更新的设计呢?我们也尝试过,并非不可能,只是性能对比 DeltaTree 尚有差距:进行范围读取时,LSM 需要进行非常重的多路归并,因为任何上层的新数据都可能会覆盖下层的老数据,而层和层之间存在交集,因此 N 层的 LSM 也许需要进行 N 路归并才能获取一段数据。我们曾经实现过基于 ClickHouse MergeTree 改造的 LSM 列存引擎,对比新的 DeltaTree 将近慢了一倍。

    至此为止,我们解决了可更新列存问题。

    再说复制

    既然选择了松耦合的存储引擎,行列存储并不在同一个模块内,那随之而来的问题必然是如何进行数据复制。对于传统的主从复制体系,我们往往使用比如 MySQL Binlog 这样的 High Level 层级进行复制。实际上,这种复制体系也是我们第一个原型迭代所使用的手段。基于 Binlog 的复制体系能很好封装不必要的细节,只要列存引擎 TiFlash 可以正常回放日志就可以,无需关心例如事务实现等等细节。这样我们很快得到了第一版 TiFlash,它通过 binlog 串联行存与列存,但是需要再往下实现容错,负载均衡等等一系列特性。更麻烦的是,TiDB 是一个分布式且多主的系统。每个 TiDB 服务器都会产生一份 binlog,如果要保持数据一致性,不会新老覆盖,binlog 实际上还需要经过一层汇聚和排序,这几乎将分布式降维打击成了单点吞吐,而排序管道也大大增加了数据到达的延迟。因此原型版的 TiFlash 是无法提供行列混合查询的:你只能单独查询行存或者列存,因为数据无法保证一致,在查询中混合两者会创造无穷无尽的不可知数据错误。

    于是我们转而从更低层级的日志进行复制,是的,我们选了在 Raft 层进行对接。从更底层进行对接的好处显而易见,Raft Log 保留了数据复制所需的一切细节,我们得以将 TiFlash 设计成一种特异的 TiKV 节点,从而能够直接获得 Multi-Raft 体系所赋予的一切好处:数据变得可以通过 PD 进行透明迁移扩容,容错本身也完全无需操心全部交由 Raft 体系来完成,当副本丢失时,存储层会自动发起恢复,而复制本身的复杂一致性保障也变得无需操心。从面临自己完善基于 ClickHouse 的副本体系,到坐享其成,一切都是如此美好。当然在实际的工程实现上也有代价,由高层准 SQL 级的 Binlog 改为完全底层的 Raft Log,代价也是相当巨大的。我们需要在 ClickHouse 上实现所有 Multi-Raft 体系所需的复杂操作,例如 Region 的分裂与合并,以及迁移和读取容错。

    新的设计是整个 HTAP 体系成立的关键,它给与 TiFlash 无缝接入整个存储层的能力。同一套复制体系,同一套调度体系,一样的事务模型,一样的一致性保障。它的复制设计是完全分布式,负载均衡且自动容错的。
    相比通过主从复制或者同机器行列双写,它的 AP 和 TP 部分可以完全独立地运转,自由扩容:如果你需要更多 AP 算力,那请增加 TiFlash 节点;如果你需要增加 TP 算力,请增加 TiKV 节点。互不干扰,以 Workload 而言或者计算资源扩展而言都是。

    与此同时,这种复制又是自动负载均衡且点对点直接链接的。每个 Region Leader 副本会单独与列存侧的副本进行沟通完全无需中间存储介质,当 Region 副本过大分裂时,列存副本也会跟着分裂;当副本因为热点打散进行迁移时,他们之间的复制管道也会跟着迁移。这对于 TiDB 的 Multi-Raft 体系来说都是已经实现的功能。

    另外 Raft 体系带来的最大好处却是一致性和异步复制的共存。

    传统意义上,如果需要复制保持副本一致,就必须采用同步复制。这样,无论是列存节点的高压,还是网路延迟加大,都会对 TP 业务带来巨大冲击:为了保持数据一致性,行存事务必须等待列存确实完成写入才能返回,否则期间的故障将会带来数据丢失和不一致。另外新增任何列存节点也会加大遭遇网络延迟的概率。虽然诸多 HTAP 产品并不会态度考虑 AP 和 TP 互相影响的问题,我们仍然希望娇弱的 TP 能收到更大程度的保护。

    这,恰恰可以通过 Raft 解决。TiFlash 通过 Learner 角色接入 Raft 体系,这允许列存以不投票只异步抄写的方式加入集群,这意味着它不会因为自身的稳定干扰正常 TP 业务的运转。当 TP 侧有事务写入,TiKV 无需等待 TiFlash 的数据同步,仅仅在完成正常的行存副本容错复制就可以返回客户端完成事务。那你也许要问了,这样是否数据无法保证一致性,是否行存和列存之间也许存在数据延迟?是也不是。物理上来说,确实存在,一个系统理论上并无可能做到异步复制仍然能同时物理上保持副本一致。但实际上我们也无需保证数据每时每刻在物理上一致,我们只需要提供一种一致的逻辑读取结果就行了。这也是 Raft 本身的核心特点之一,虽然多个副本并非全都每时每刻保持一致,但是只要读取的时候能得到最新的一致性数据即可。当实际读取发生时,列存副本会向行存的 Leader 发起校对请求,这个请求本身很简单:请告诉我在你收到请求的瞬间,最新日志序号是多少。而 TiFlash 会等待数据复制进度追上校对结果。仅此而已。这就使得 TiFlash 能够保证取得足够新鲜的数据,新鲜到保证囊括上一个瞬间写入的信息。是的,从 TiKV 写入的最新数据保证能从 TiFlash 被读取,这形成了读取的水位线。而通过时间戳和 MVCC 配合,TiFlash 的异步同步也可以提供与 TiKV 一样的强一致保证。这使得 TiFlash 列存表现得并不像一套异构复制体系,而更像是一种特殊的列存索引,也使得我们可以放心大胆地在同一个查询中混合两种不同引擎,而无需担心是否会由不一致带来微妙难以追查的错误。

    智能选择

    智能选择放在最后说,是因为它也的确是我们最后实现的。TiDB 的行列存智能选择就是通过代价优化自动选择行存或者列存。说起来这部分也很简单,犹如使用统计信息选择索引,我们也可以通过代价公式估算列存的使用代价。综合各个访问路径的开销,我们就能知道需要选择何种方式读取数据,而列存只是其中一种,并无特殊性。

    技术上来说,这并没有太多新意。但通过自动选择,TiDB 的 HTAP 体系从 TP + 报表的用况一下子拓展到了 HTAP 混合业务。一些边界模糊的业务系统,通过 TiFlash 加持,变得架构简单。例如物流系统,用户希望能够在同一套查询平台检索个别单号以及投递明细,又希望能统计某时间段不同货物类别的收发情况。明细查询对于 TiDB 来说并无任何障碍,但以往没有列存的时候,大数据集下的多维分析性能对比真的分析型产品仍有不小的差距。有了 TiFlash 之后,这样 AP 和 TP 边界模糊的业务就立马变得圆润完整起来。反倒是原始计划中的 TiSpark 读取,由于 TiDB 更贴近业务和 DBA 而非大数据的特点,相较之下显得并没有那么多。

    最后

    这篇文章并不完全讲述了我们论文的内容。缺失的部分是 TiDB 非 HTAP 部分的设计,有兴趣的同学可以点击原文在此。另外,也欢迎大家使用我们的产品,各位的使用和宝贵意见是 TiDB 发展最基本的推动力。

    展开全文
  • 浅谈“HTAP

    千次阅读 2020-09-01 16:46:59
    文章转载自: 浅谈“HTAPHTAP是近些年来比较火的一个概念,下面就聊聊其前世今生及技术特点。 1. 数据应用类别 根据数据的使用特征,可简单做如下划分。在选择技术平台之前,我们需要做好这样的定位。 1.1 OLTP...

    文章转载自: 浅谈“HTAP”,仅用于学习,如有侵权,请联系删除。

    HTAP是近些年来比较火的一个概念,下面就聊聊其前世今生及技术特点。

    1. 数据应用类别

    根据数据的使用特征,可简单做如下划分。在选择技术平台之前,我们需要做好这样的定位。
    在这里插入图片描述

    1.1 OLTP

    联机事务处理OLTP(On-Line Transaction Processing),OLTP是事件驱动、面向应用的,也称为面向交易的处理过程。其基本特征是前台接收的用户数据可以立即传送到计算中心进行处理,并在很短的时间内给出处理结果,是对用户操作的快速响应。例如银行类、电子商务类的交易系统就是典型的OLTP系统。其具备以下特点:

    • 直接面向应用,数据在系统中产生。
    • 基于交易的处理系统。
    • 每次交易牵涉的数据量很小;对响应时间要求非常高。
    • 用户数量非常庞大,其用户是操作人员,并发度很高。
    • 数据库的各种操作主要基于索引进行。
    • 以SQL作为交互载体。
    • 总体数据量相对较小。

    1.2 OLAP

    联机实时分析OLAP(On-Line Analytical Processing),OLAP是面向数据分析的,也称为面向信息分析处理过程。它使分析人员能够迅速、一致、交互地从各个方面观察信息,以达到深入理解数据的目的。其特征是应对海量数据,支持复杂的分析操作,侧重决策支持,并且提供直观易懂的查询结果。例如数据仓库是其典型的OLAP系统。其具备以下特点:

    • 本身不产生数据,其基础数据来源于生产系统中的操作数据
    • 基于查询的分析系统;复杂查询经常使用多表联结、全表扫描等,牵涉的数量往往十分庞大
    • 每次查询设计的数据量很大,响应时间与具体查询有很大关系
    • 用户数量相对较小,其用户主要是业务人员与管理人员
    • 由于业务问题不固定,数据库的各种操作不能完全基于索引进行
    • 以SQL为主要载体,也支持语言类交互
    • 总体数据量相对较大

    1.3 OTHER

    除了传统的OLTP、OLAP类,近些年来针对数据的使用又有些新特点,我将其归入了“其他”类。

    1) 多模

    随着业务“互联网化”和“智能化”的发展以及架构 “微服务”和“云化”的发展,应用系统对数据的存储管理提出了新的标准和要求,数据的多样性成为突出的问题。早期数据库主要面对结构化数据的处理场景。后面随着业务的发展,逐渐产生了对非结构化数据的处理需求。包括结构化数据、半结构化(JSON、XML等)数据、文本数据、地理空间数据、图数据、音视频数据等。多模,正是指单一数据库支持多种类型数据的存储与处理。

    2) 流式

    流式处理(实时计算),是来源于对数据加工时效性的需求。数据的业务价值随着时间的流失而迅速降低,因此在数据发生后必须尽快对其进行计算和处理。传统基于周期类的处理方式,显然无法满足需求。随着移动互联网、物联网和传感器的发展导致大量的流式数据产生。相应地出现了专有的流式数据处理平台,如Storm、Kafka等。近些年来,很多数据库开始支持流式数据处理,例如MemSQL、PipelineDB。有些专有流式数据处理平台开始提供SQL接口,例如KSQL基于Kafka提供了流式SQL处理引擎。

    3) 高阶

    随着对数据使用的深入,数据的使用不再仅仅以简单的增删改查或分组聚合类操作,而对于其更为高阶的使用也逐步引起大家的重视。例如使用机器学习、统计分析和模式识别等算法,对数据进行分析等。

    1.4 对比 — OLTP vs OLAP

    在这里插入图片描述

    2. 数据处理模式

    面对上述复杂多变的应用场景,数据应用的多种类别,是由单一平台处理,还是由不同平台来处理呢?一般来说,专有系统的性能将比通用系统性能高一到两个数量级,因而不同的业务应采用不同的系统。但正如古人说“天下大势、分久必合、合久必分”,在数据处理领域也有一种趋势,由单一平台来处理。这里选择的核心在于如何来辩证看待需求和技术。它们是一对矛盾体,当这对矛盾缓和时,数据处理领域将更趋向于整合;而当这对矛盾尖锐时,数据处理领域将趋于分散。就软硬件技术发展现状和当前需求来看,未来整合的趋势更为明显。集成数据平台将能满足绝大多数用户的场景,只有极少数企业需要使用专有系统来实现其特殊的需求。

    2.1 分散式(专有平台)

    目前比较常规的方式,是采用多个专有平台,来针对不同场景进行数据处理。因此是跨平台的,因此是有个数据传输的过程。这之中会带来两个问题:数据同步、数据冗余。数据同步的核心是数据时效性问题,过期的数据往往会丧失价值。常见的做法如下:
    在这里插入图片描述

    OLTP系统中的数据变化,通过日志的形式暴露出来;通过消息队列解耦传输;后端的ETL消费拉取,将数据同步到OLAP中。整个链条较长,对于时效性要求较高的场景是个考验。此外,数据在链条中流动,是存在多份的数据冗余保存。在常规的高可用环境下,数据会进一步保存多份。因此这里面隐藏了比较大的技术、人力成本以及数据同步成本。而且横跨如此之多的技术栈、数据库产品,每个技术栈背后又需要单独的团队支持和维护,如DBA、大数据、基础架构等。这些都蕴含着巨大的人力、技术、时间、运维成本。正是出于在满足各种业务需求的同时,提高时效性,减低数据冗余、缩短链条等,收敛技术栈就变得很重要。这也是通用类平台解决方案,诞生的出发点。

    2.2 集中式(通用平台)

    用户厌倦了为不同的数据处理采用不同的数据处理系统,更倾向于采用集成数据处理平台来处理企业的各种数据类型。对于融合了联机事务处理和联机实时分析的场景,也就是下面所谈到的HTAP。

    此类通用平台方案具备下面优点:

    • 通过数据整合避免信息孤岛,便于共享和统一数据管理。
    • 基于SQL的数据集成平台可提供良好的数据独立性,使应用能专注于业务逻辑,不用关心数据的底层操作细节。
    • 集成数据平台能提供更好的实时性和更全的数据,为业务提供更快更准的分析和决策。
    • 能够避免各种系统之间的胶合,企业总体技术架构简单,不需要复杂的数据导入/导出等,易于管理和维护。
    • 便于人才培养和知识共享,无须为各种专有系统培养开发、运维和管理人才。

    3. HTAP

    HTAP数据库(Hybrid Transaction and Analytical Process,混合事务和分析处理)。2014年Gartner的一份报告中使用混合事务分析处理(HTAP)一词描述新型的应用程序框架,以打破OLTP和OLAP之间的隔阂,既可以应用于事务型数据库场景,亦可以应用于分析型数据库场景。实现实时业务决策。这种架构具有显而易见的优势:不但避免了繁琐且昂贵的ETL操作,而且可以更快地对最新数据进行分析。这种快速分析数据的能力将成为未来企业的核心竞争力之一。
    在这里插入图片描述

    3.1 技术要点

    • 底层数据要么只有一份,要么可快速复制,并且同时满足高并发的实时更新。
    • 要满足海量数据的容量问题,在存储、计算都具有很好的线性扩展能力。
    • 具有很好的优化器,可满足事务类、分析类的语句需求。
    • 具备标准的SQL,并支持诸如二级索引、分区、列式存储、向量化计算等技术。

    3.2 重点技术 – 行列存储

    行存储(Row-based):对于传统的关系型数据库,比如甲骨文的OracleDB和MySQL,IBM的DB2、微软的SQL Server等,一般都是采用行存储(Row-based)行。在基于行式存储的数据库中,数据是按照行数据为基础逻辑存储单元进行存储的,一行中的数据在存储介质中以连续存储形式存在。
    在这里插入图片描述

    **列式存储(Column-based)**是相对于行式存储来说的,新兴的Hbase、HP Vertica、EMC Greenplum 等分布式数据库均采用列式存储。在基于列式存储的数据库中,数据是按照列为基础逻辑存储单元进行存储的,一列中的数据在存储介质中以连续存储形式存在。
    在这里插入图片描述

    传统的行式数据库,是按照行存储的,维护大量的索引和物化视图无论是在时间(处理)还是空间(存储)面成本都很高。而列式数据库恰恰相反,列式数据库的数据是按照列存储,每一列单独存放,数据即是索引。只访问查询涉及的列,大大降低了系统I/O,每一列由一个线来处理,而且由于数据类型一致,数据特征相似,极大方便压缩。

    3.3 重点技术 – MPP

    MPP (Massively Parallel Processing),即大规模并行处理,在数据库非共享集群中,每个节点都有独立的磁盘存储系统和内存系统,业务数据根据数据库模型和应用特点划分到各个节点上,每台数据节点通过专用网络或者商业通用网络互相连接,彼此协同计算,作为整体提供数据库服务。非共享数据库集群有完全的可伸缩性、高可用、高性能、优秀的性价比、资源共享等优势。简单来说,MPP是将任务并行的分散到多个服务器和节点上,在每个节点上计算完成后,将各自部分的结果汇总在一起得到最终的结果。下面以典型的MPP产品Greenplum架构为例。
    在这里插入图片描述

    3.4 重点技术 – 资源隔离

    OLTP、OLAP类两者对资源的使用特点不同,需要在资源层面做好隔离工作,避免相互影响。常见的通过定义资源队列的方式,指定用户分配队列,起到资源隔离的作用。

    3.5 HTAP产品

    下图是网站找到的数据库产品分类图,针对HTAP类的可参考对象线上的相关产品。当然这只是一家之言,仅供参考!
    在这里插入图片描述

    展开全文
  • BaikalDB:分布式HTAP数据库 BaikalDB支持PB级结构数据的顺序和随机实时读取/写入。 BaikalDB与MySQL协议兼容,并且支持MySQL样式SQL方言,通过该方言,用户可以将其数据存储从MySQL无缝迁移到BaikalDB。 BaikalDB...
  • HTAP数据库,即交易分析混合负载型DB,已经成为一种流行的新型数据库。不仅概念很火,并且也在逐渐成为除OLTP、OLAP之外,越来越多数据库用户新的选型规范。然而,同时又存在一些现象:一是一夜之间,所有的数据库都...
  • OLTP、OLAP与HTAP

    2020-07-22 09:27:12
    参考文章:OLTP、OLAP与HTAP OLTP On-Line Transaction Processing联机事务处理过程(OLTP) 也称为面向交易的处理过程,其基本特征是前台接收的用户数据可以立即传送到计算中心进行处理,并在很短的时间内给出处理...
  • OLTP VS OLAP VS HTAP

    2019-04-05 17:54:45
    https://blog.bcmeng.com/post/oltp-olap-htap.html OLTP是Online Transaction Processing的简称;...HTAP是Hybrid Transactional/Analytical Processing的简称。Transaction是指形成一个逻辑单元,不可...
  • TiDB(“ Ti”代表Titanium)是一个开源的NewSQL数据库,它支持混合事务处理和分析处理(HTAP)工作负载。 它与MySQL兼容,并具有水平可伸缩性,强一致性和高可用性。 水平可伸缩性 TiDB只需添加新节点即可扩展SQL...
  • Matlab集成的c代码住房技术评估平台(HTAPHTAP是自动化和扩展HOT2000住宅能源模拟工具的数据和工具的集合。 HOT2000软件套件可直接从处获得。 HTAP已用于: 优化零净能耗和零零零能耗房屋的设计,并进行深度能源...
  • TiDB 是一篇 Real-time HTAP 分布式数据库工业实现的论文。 ABSTRACT Hybrid Transactional and Analytical Processing(HTAP) 需要隔离处理事务性和分析性查询,以解决它们之间的冲突。为了实现这一点,有必要为...
  • 阿里云高级专家 王骞在2017杭州云栖大会中做了题为《如何支撑HTAP场景-HybridDB for MySQL系统架构和技术演进》的分享,就HybridDB for MySQL技术现状,产品定位,技术演进路线,当前限制和未来发展做了深入的分析。
  • 硬件两个近期的趋势表明htap这些旧的硬件设想(multi-socket multi-cores)将在未来变得无效为此,在这篇文章中,我们将介绍一种针对新型硬件,可以充分发挥新型硬件能力且专攻OLTP和OLAP事务的新型架构Heterogeneous...
  • HTAP作为一种新兴技术架构与能力,不仅可以带来某单一系统的功能与性能提升,更重要的是会驱动企业IT架构面向现代业务目标的整体转型升级。本文以典型银行IT架构为例,对HTAP驱动ITSP、应用架构、数据架构、技术架构...
  • 分布式 HTAP 数据库 ADB PG 架构解析

    千次阅读 2020-05-18 16:16:14
    分布式 HTAP 数据库 ADB PG 架构解析 转载自:https://yq.aliyun.com/users/d5whco4pewtmo 阿里云AnalyticDB for PostgreSQL(简称 ADB PG),为基于PostgreSQL内核构建的分布式数据库,支持ANSI SQL , 兼容部分...
  • 利用ProxySQL、MySQL、ClickHouse快速构建HTAP系统1. 关于ClickHouse企业里随着数据量的增加,以及日趋复杂的分析性业务需求,主要适用于OLTP场景的My...
  • HTAP 简介

    千次阅读 2019-03-28 20:00:00
    HTAP是混合 OLTP 和 OLAP 业务同时处理的系统,2014年Garnter公司给出了严格的定义:混合事务/分析处理(HTAP)是一种新兴的应用体系结构,它打破了事务处理和分析之间的“墙”。它支持更多的信息和“实时业务”的决策...
  • 那边厢OceanBase也紧跟着推出3.0版本,主攻方向亦是HTAP分布式数据库,在GitHub Oceanbase标注自己为“ The leading Scalable HTAP Database” , 并且又玩了一把TPC-H打榜第一的套路(后续:其成绩很快被超过)。...
  • 9张图告诉您 数据库的王者出现 HTAP 第一代: Rdbms型DB 第二代: Nosql型DB 第三代: 基于Paxos的分布式Rdbms DB 第四代: HTAP 王者出现 ???????????? 亲,对照一下 自己的技术落后了多少代 哈哈哈
  • HTAP会成为数据库的未来吗?

    千次阅读 2020-04-13 11:04:12
    在此背景下,备受关注的数据库新理念 HTAP,会是一条“正确”的路吗? 为什么是 HTAP? 在互联网浪潮出现之前,企业的数据量普遍不大,特别是核心的业务数据,通常一个单机的数据库就可以保存。那时候的存储并不...
  • 【SequoiaDB|巨杉数据库】HTAP混合负载① HTAP混合负载 一般来说,HTAP (Hybrid Transactional and Analytical Processing) 混合负载意味着数据库既可以运行 OLTP (Online Transactional Processing) 联机交易,也...
  • OceanBase再破纪录!核心成员陈萌萌:坚持HTAP就是坚持我们做数据库的初心.pdf
  • HTAP数据库Hubble Hubble是天云在多年大型银行大数据项目实施经验基础上,针对海量数据实时在线、即时分析场景抽象出来的最佳实践,支持上万用户并发实时查询、多源异构、支持ANSI99/2003 SQL标准。满足海量数据下...
  • 在此背景下,备受关注的数据库新理念 HTAP,会是一条“正确”的路吗? 为什么是 HTAP? 在互联网浪潮出现之前,企业的数据量普遍不大,特别是核心的业务数据,通常一个单机的数据库就可以保存。那时候的存储并不需要...
  • OLTP,OLAP以及HTAP的区别 本文链接:https://blog.csdn.net/ZG_24/article/details/87854982 收起 OLTP On-Line Transaction Processing联机事务处理过程(OLTP) 也称为面向交易的处理过程,其基本特征是前台...
  • TiDB + TiFlash : 朝着真 HTAP 平台演进

    千次阅读 2019-09-02 10:44:03
    一、为什么我们需要 HTAP 数据库? 在互联网浪潮出现之前,企业的数据量普遍不大,特别是核心的业务数据,通常一个单机的数据库就可以保存。那时候的存储并不需要复杂的架构,所有的线上请求(OLTP, Online ...
  • 随着企业应用的类型不断拓展,在海量数据、高并发、多类型数据的应用场景下,底层数据平台对于混合数据类型、混合业务场景处理能力的要求不断扩大,这就催生了 HTAP(混合事务和分析处理)的需求。 新一代分布式...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 2,825
精华内容 1,130
关键字:

htap