OLTP新贵G家F1的替代者TiDB

2023-10-25 11:00
文章标签 tidb f1 oltp 新贵 替代者

本文主要是介绍OLTP新贵G家F1的替代者TiDB,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

HBase 简介

众所周知,在 SQL 方面处于顶级的有两个公司,一个是 Oracle,他们已经积累了大量的经验,另一个是谷歌,谷歌 F1 在2012年发布了一篇论文,个人认为它是全球最优秀的 SQL OLTP 数据库。

1978年左右,数据库刚刚发展时出现了SQL RDBMS。2000年左右,国内开始流行互联网,互联网对 Oracle 数据库也产生较大的冲击。现在,传统的数据库大部分是集中在传统领域,互联网方面用得比较多的是 MySQL ,其次 HBase 等 NoSQL 也吸引了大量的用户。

为什么会出现 NoSQL?最开始所有人都用 SQL Database,那时比较高端有 Oracle,开源的还有 MySQL、PostgreSQL。可是随着业务的迅速发展,数据库成为了瓶颈,于是促使了 NoSQL 的诞生,NoSQL 将 Scale 放在第一位。如果业务快速发展,扩容会成为亟待解决的首要问题。这时,大多数人会选择放弃事务一致性。什么是一致性?比如使用微信时,如果我加你为好友,这是一个双向关系,对应到数据库中至少是两个操作,第一是在好友列表里把你加进来,第二个是你的好友列表里把我加进去。如果这两个列表的数据库放在不同的机器上,就需要保证一致性。否则可能会出现我是你的好友,但你的好友中却找不到我的这种情况。但这中间可能会出现多种情况,比如我把你加为好友,然后修改数据的时候 Crush 掉了,这个时候传统方案是会引入一个消息队列,有的还需要做一些补偿,这些问题在 NoSQL 里处理起来相对麻烦。

国内最大的 HBase 使用者是小米公司,有几个 HBase 的 Committer ,所以经过一些修改后可以支持分布式事务,于是能够解决之前的问题。为什么在面临诸多选择时,小米会选择 HBase 呢?就目前情况来说,主要还是技术选型和人才储备上的考虑。 MongoDB 大家应该不陌生,但用到一定程度后,总会出现各种问题,甚至有文章呼吁大家放弃 MongoDB 。但所有数据库都不是“十全十美”的,没有最好,选择最适合的尤为重要。

很多时候产品都有其特性,在满足其特性或者规格的情况下,使用起来可能非常顺手,否则十之八九都遇到各种麻烦。比如小米使用 HBase 就非常顺手,但其他的公司则不一定。道理很简单,如果不熟悉其使用场景,也不知道在相应场景下配什么参数,所以会出现各种各样的问题。

TiDB:支持 MySQL 协议的分布式数据库解决方案 技术分享 第1张 事实上,HBase 有非常好的特性,目前在小米公司可以每秒跑一百万 OPS ,最近 Pinterest 公布他们的 HBase 每秒可以跑三百万个 OPS ,这个数量级可以远超很多互联网公司。 HBase 在读写一致性方面非常出色,有很好的自动 Scale 的能力,通过Block Cache 和 Bloom Filters可以很好的解决查询问题,是否在磁盘上也可以通过Bloom Filters来判定。

另一方面,Oracle 把一部分逻辑会放在 CPU/硬件里,对应的 HBase 也会把一部分逻辑下推到对应的 RegionServer 上。对于一个分布系统来说,如果需要查询一个条件,可以直接把这个简单调节推到对应的 RegionServer 上执行。再比如求和运算,现在有一百亿数据,甚至一千亿条数据,分布在10个节点上,最快的求和方法是让所有节点同时运算,将这个条件下推得到所有对应数据的和,最后收集到10个数据的和即可。其实还可以继续往下推,这是比较复杂的数据库优化技术,实际情况还会更复杂。这在 HBase 里面依赖 Coprocessor 来实现。

大家应该对 MVCC 比较熟悉,也就是多版本,它的优点在于可以多次读取而不会 block。然后还有一个很好的特性,假设你用的 Database ,MVCC 在你没有做 compaction 之前可以回到任何时间的数据。现在云服务上也可以每隔半小时做一次快照,实际上如果使用 MVCC 回到任意一秒的话,可以完全不需要快照。

TiDB的优势

下面再介绍一下我们的产品 TiDB,Ti 是元素周期表里的元素。大家如果了解我们团队的程序员,就知道他们都比较 Geek,取名字要么在希腊神话里选一个神的名字,或者在数学里找一个希腊字母, 但是看了一圈,好坑都已经被占上了。于是,我们在化学元素周期表里找了一个金属作为项目名称,对于 Database 而言,它必须是高速稳定的,刚好钛金属有很强的防腐蚀性,所以选择了钛(Ti)。

TiDB:支持 MySQL 协议的分布式数据库解决方案 技术分享 第2张

因为 TiDB 的目标是谷歌 F1,所以自然会满足以上特性。首先是可以满足分布式一致,也就是说对于应用来说,不用关心后面分成多少个机器,事务的一致性是必须保证的,比如我们之前提到的 A 关注 B,两个互相加好友或者转帐,可以直接利用一条 SQL 搞定,而无需担心中间过程。另外一个特性是兼容 MySQL 协议,国内大概有70% 的互联网公司都在使用 MySQL,为了考虑大家的迁移成本,我们会兼容 MySQL 协议。同时,由于已经很多 APP 在 MySQL 上运行,为我们提供了充足的测试样本。 TiDB 的测试有五百多万个,每次提交一行代码时,后面大概有6个机器并行地跑 Test ,五百多万 Test 所需时间大约是十分钟。为了照顾各种引擎爱好者,我们还支持了 LevelDB 、RocksDB、LMDB、BoltDB 等。TiDB 主要是采用 Go 语言开发的,其代码简单、易于理解,而且性能非常高。

系统架构 TiDB:支持 MySQL 协议的分布式数据库解决方案 技术分享 第3张

任何用 MySQL 协议写的程序都可以直接使用 TiDB ,其中间是 MySQL 协议相关的内容,再往下是 SQL Layer。其次是事务 KV 层,这正是 F1 和 Spanner 构造得最为精密的地方。最底层的构造是从 KV 开始,在 KV 基础上架一个分布式的 KV 层用于支持事务,然后再让 SQL 语句直接映射到 KV 层上。 TiDB:支持 MySQL 协议的分布式数据库解决方案 技术分享 第4张

接下来,向大家介绍 现阶段 TiDB 使用的分布式事务是如何在 HBase 上实现的,早期版本中,我们参考的是 Google 的 Percolator 的模型。首先假设有一个 Client,先为其分配一个 Timestamp,在 Google 论文中叫做Time Oracle,用来分配时间戳。分配之后可以做读写操作,根据时间戳进行快照读。最后提交之前要先 Prepare ,Prepare的时候会检测是否冲突,最后提交时会得到 Commit ,如果整个过程没有任何冲突就可以提交。 TiDB:支持 MySQL 协议的分布式数据库解决方案 技术分享 第5张上图代表了一个实例,最初帐户情况是 Bob 有10美金,而 Joe 有5美金。前面的数字代表其版本,当前是第6个版本,指向的是第5个版本,为10美金,Joe 是2美金。 TiDB:支持 MySQL 协议的分布式数据库解决方案 技术分享 第6张

假设Bob要转4美金给 Joe。第一步,要先转出去4美金,10美金变成6美金,由于被扣掉4美金,然后会标注一下自己是主锁。

TiDB:支持 MySQL 协议的分布式数据库解决方案 技术分享 第7张Joe当前是第7个版本,因为他得到了4美金,所以余额变成了6美金,同时标记自己指向另外一个主锁 Bob。 
TiDB:支持 MySQL 协议的分布式数据库解决方案 技术分享 第8张

到第八个版本时,主锁会指向现在的7,这时可以把主锁删掉。如果访问的时候发现主锁被删除,那么主锁冲突已不存在,可以进行提交。同时,它会把自己的锁删掉,中间还有一些其它的清理过程。

整个事务模型中会有单点,从 Time Oracle 分配一个时间戳,单点决定了整个系统的性能。Google 论文里有一个对应描述,可以跑到两百万每秒。因为事务开始和结束的时候都需要取一个 Timestamp ,所以他们最快读写事务的速度是一百万每秒,他们已经在论文中实现。实际上,现在有更好的方式可以提高速度,如 HLC 和一些 Time Oracle的改进算法。 TiDB:支持 MySQL 协议的分布式数据库解决方案 技术分享 第9张关于 Spanner ,我们重点参考对象是谷歌 Spanner 和 F1 。由于 Spanner 高度依赖于时钟,所以谷歌有一套原子钟和 GPS 时钟,GPS 信号可以给出地理位置和时间。为什么需要原子钟呢?由于 GPS 时钟特别容易受到干扰,比如天气恶劣时 GPS 时钟就不能运行,而原子钟仍然适用。 TiDB:支持 MySQL 协议的分布式数据库解决方案 技术分享 第10张TiDB:支持 MySQL 协议的分布式数据库解决方案 技术分享 第11张

上图是谷歌 F1 的一些信息,其中单独标记了谷歌 F1 的这篇论文,大家有兴趣的话不妨细读一番,目前整个 TiDB 所做的都是在实现这篇论文。假设有一千亿数据,你现在要给某一列加索引时,在传统数据库上应该如何操作?比如说在分布式环境下,你用MySQL 给一列添加一个索引,这几乎很难实现,而且还必须保证 index 的一致性。更多细节请参考论文。 TiDB:支持 MySQL 协议的分布式数据库解决方案 技术分享 第12张

TiDB 是如何从 SQL 迁移到 KV 上的呢?由基础知识可知,传统的 RDBMS 数据库底下一般是一个 B-Tree。对于分布式关系型数据库,站在更上层一点看,比如谷歌的F1,数据库底层都是 KV 层,都在 KV 层逻辑下操作。如果有一个 User Table,在 TiDB 里假设你的Table的结构是由 uid、name和 email 构成。在 TiDB 里有一个隐藏列叫做 RowID ,所有的操作包括行锁都是锁的 RowID 。假设 RowID 是1, uid 是XX,Name 是 Bob,Email 是 bob@Email.com,这都属于元信息。即便你的 Column name 很长,但最后在数据库里存储的是原信息。在 TiDB 中, 每一列都有唯一的UID。

假设 Table 的 ID 是1,uid 的 ID 是2,name 的ID是3,email 的 ID 是4。在数据库中存储为一个 KV 结构,然后对 TableID、RowID 、ColumnID 进行重新编码,直接将这个表的一行切成4个 KV 。这时候如果进行 select , Email 等于某一个值的话,于是可以直接取出来相应的值,速度非常快。

兼容 MySQL

TiDB 对 MySQL 协议有很好的兼容性。有一些比较知名的 MySQL 应用和管理工具,比如WordPress、PhpMyAdmin, MySQL Workbench,都可以直接基于 TiDB 运行。而且数据可以无限扩展,不再是单机数据库。其次,TiDB 还兼容各种 ORM ,比如 XORM 、Beego ORM 等,能够支持很多 MySQL 的应用。每一次代码更新,这些 ORM Test 会自动运行一次,从而保证与 MySQL 的兼容性,虽然还有一些比较细微的特性暂时没有支持。现在已经支持异步的 Schema 变更,对于 DDL 操作,不会阻塞线上的业务。

关于社区

目前 TiDB 完全开源在 Github 上面。开源和开放的概念是两回事,很多大公司,所谓的开源只是把代码上传一下,国内比较知名的案例也挺多的,大家知道很多项目都已经放弃了维护。但是我们是打算完全以一个开放的心态来做整个事情,全部的代码,全部的讨论, Code Review,Bug Tracking,Roadmap 都是开源的,毕竟通用的分布式 OLTP 关系型数据库是一个非常前沿而且极端重要的领域,未来是云上的 DBaaS 的重要组成部分,但是在这块目前整个技术社区,即使全球来看都没有一个太成熟开源解决方案,TiDB也目前也处于早期,从架构上来看,我们将 SQL 层和 KV 层做了很彻底的分离,这也是我们希望更多开发者能根据自己的需要更方便的进行定制,我们也想得很清楚,依靠某一家公司,或者某几个人的力量是不够的,我们 PingCAP 只是将这一把火点起来,将框架搭好,制定好透明和公平的规则,吸引更多的合作公司和独立开发者,一起将 TiDB 做成中国第一个世界顶级的开源项目,实现共赢。

好的项目可以由社区进行推动,就比如 HBase,HBase 不属于任何一个公司,但是社区一直推动它进步。目前我们在 GitHub 状态是有 3200+的 Star,有 32个 Contributors,算是开了一个好头,非常感谢大家,希望大家都能参与进来。

这篇关于OLTP新贵G家F1的替代者TiDB的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/282113

相关文章

DB、DW、DM、ODS、OLAP、OLTP和BI的概念理解

今天特地查了一些官方解释和很多优秀的博客文章,将关于数仓方面的一些名词理解记了下来,先将这些简称做一个解释: 1、DB(DataBase):数据库,一般指的就是OLTP数据库,在线事物数据库,用来支持生产的。DB保留的是数据信息的最新状态,只有一个状态! 2、DW(Data Warehouse):数据仓库,保存的是数据在不同时间点的状态,对同一个数据信息,保留不同时间点的状态,便于我们做统计

delphi如何给按钮添加单键快捷键(F1~F12)

用action 讲按钮窗体的Keypreview设为True,然后加如下代码 Delphi/Pascal code ? 1 2 3 4 5 6 procedure  TForm1 . FormKeyDown(Sender: TObject;  var  Key:  Word ;    Shift: TShiftState); begin    i

推荐系统-排序算法:常用评价指标:NDCG、MAP、MRR、HR、ILS、ROC、AUC、F1等

参考资料: 推荐算法常用评价指标:NDCG、MAP、MRR、HR、ILS、ROC、AUC、F1等 搜索评价指标——NDCG

命名实体识别(NER)-模型评估:词级别评估、实体级别评估【Precision、Recall、F1】

一、概述 命名实体识别的评判标准:实体的边界是否正确;实体的类型是否标注正确。主要错误类型包括: 文本正确,类型可能错误;反之,文本边界错误,而其包含的主要实体词和词类标记可能正确。 对于二分类的模型,预测结果与实际结果分别可以取0和1。我们用N和P代替0和1,T和F表示预测正确和错误。将他们两两组合,就形成了下图所示的混淆矩阵(注意:组合结果都是针对预测结果而言的)。 由于1和0是数字

分类问题的评价指标:多分类【Precision、 micro-P、macro-P】、【Recall、micro-R、macro-R】、【F1、 micro-F1、macro-F1】

一、混淆矩阵 对于二分类的模型,预测结果与实际结果分别可以取0和1。我们用N和P代替0和1,T和F表示预测正确和错误。将他们两两组合,就形成了下图所示的混淆矩阵(注意:组合结果都是针对预测结果而言的)。 由于1和0是数字,阅读性不好,所以我们分别用P和N表示1和0两种结果。变换之后为PP,PN,NP,NN,阅读性也很差,我并不能轻易地看出来预测的正确性与否。因此,为了能够更清楚地分辨各种预测情

等保2.0--安全计算环境--TiDB数据库

在使用本博客提供的学习笔记及相关内容时,请注意以下免责声明:信息准确性:本博客的内容是基于作者的个人理解和经验,尽力确保信息的准确性和时效性,但不保证所有信息都完全正确或最新。非专业建议:博客中的内容仅供参考,不能替代专业人士的意见和建议。在做出任何重要决定之前,请咨询相关领域的专业人士。个人责任:使用本博客内容的风险由用户自行承担。作者不对因使用本博客内容而导致的任何直接或间接损失承担责任。版权

【TiDB原理与实战详解】4、DM 迁移和TiCDC数据同步~学不会? 不存在的!

DM工具数据迁移 1、简介 DM全称TiDB Data Migration , 支持兼容mysql协议的数据库(MySQL、MariaDB、Aurora MySQL),将数据(异步)迁移到TiDB中。支持全量和增量数据传输。可以过滤数据,可以将分库分表的数据合并迁移到TiDB中。 2、DM集群安装配置 生产最低配置(可扩容) 组件数量DM-maste3DM-worker3G

【数据仓库/数据治理】探索数据处理的两大类:OLTP与OLAP及其核心技术

在现代数据处理的世界中,数据的管理和分析是商业和技术决策的关键。为满足不同的业务需求,数据处理大致分为两大类:联机事务处理(OLTP) 和 联机分析处理(OLAP)。这两者分别适用于日常事务处理和复杂的分析操作,在数据管理中扮演着不同但互补的角色。 联机事务处理(OLTP):日常事务的基石 OLTP系统主要用于处理基本的、日常的事务操作,典型的例子包括银行交易、订单处理和库存管理等。这类系

TiDB-从0到1-TiCDC数据同步工具

TiDB从0到1系列 TiDB-从0到1-体系结构TiDB-从0到1-分布式存储TiDB-从0到1-分布式事务TiDB-从0到1-MVCCTiDB-从0到1-部署篇TiDB-从0到1-配置篇TiDB-从0到1-集群扩缩容TiDB-从0到1-数据导出导入TiDB-从0到1-BR工具 一、TiCDC简介 每每介绍TiDB的组件都不得不感叹一下其强大的整体功能性。当使用MySQL还需要在下游挂

DataBase学习笔记 --- OLAP 与 OLTP区别

OLTP = > on-line transaction processing 链接事务处理 OLAP = > on-line Analytical processing 联机分析处理 OLTP是传统的关系型数据库主要应用,主要是基本的,日常的事务处理,例如银行交易。 OLAP是数据仓库系统的主要应用,支持复杂的分析操作,侧重决策支持,并且提供直观易懂的查询结果。 OLTP 系