首页天道酬勤分布式数据库开发,开源分布式数据库 Hadoop

分布式数据库开发,开源分布式数据库 Hadoop

admin 05-12 14:39 155次浏览

当前,随着硬件性价比越来越高,网络传输速度越来越快,数据库分层趋势逐渐显现,人们不再强求用一种解决方案解决所有存储问题,而是通过分层,实现缓存和日期

TiDB作为HTAP数据库,除了实现高性能的OLTP特性之外,还提供基于实时交易数据的实时业务分析需求。

什么是 TiDB 数据库?

TiDB是数据库。 我知道市场上有很多类似MySQL和Oracle的数据库。为什么还需要一个新的数据库?

我想你们90%的人都用过MySQL。 但是,如果MySQL数据量很大或无法同时支持,有什么选择?

其实没有多少选择。 一种是完全不使用MySQL,使用NoSQL。 例如,假设HBase或Cassandra创建数据库。

但是,其代价是失去了SQL复杂查询的能力和整个MySQL的EcoSystem。

NoSQL提供横向水平展开能力,但面临整个业务代码的重写。 这在很多场合不太现实。

所以还是很多时候必须使用MySQL,但是MySQL在数量上有很多限制。 所以,过去我们能做的就是Sharding、水平分区和库别表。

但是很多时候虽然你做了水平切分,分库分表,但是 Scale 还是一个非常大的问题。

另一种可能是使用了读写分离,或者最终使用了Cassandra这样一致的系统,但对开发者来说这种心理负担比较大。

如果你没有一个强一致的、持久化的存储系统,你的业务层的代码是很难写的,特别是对一些金融场景或者说对一致性要求比较高的业务。

此外,我们的数据仓库、大数据分析解决方案和数据库解决方案之间基本上存在完全隔离。 过去两年中经常使用的流水线系统,如RabbitMQ和Kafka,是试图在数据库和数据仓库之间建立桥梁。 是否有直接在数据库级别进行实时OLAP的方法?

或者现在你要用MySQL的Sharding进行简单的业务间连接分析,都要把这个数据通过ETL引导到Hadoop或者数据仓库,然后再进行分析。

维持ETL的过程是比较麻烦的事情。 另一个问题是,数据分析师可能不是技术人员,也可能不是技术过硬的人,因此在技术选型上存在各种限制。

能不能就直接在数据库上去做一些 in-place 的查询呢,这是一个问题。

另一个是大趋势,考虑如何将类似数据库的业务与现有云体系结构集成。

例如,MySQL实例不能直接放入容器中。 因为如果容器锁定,数据就会消失。

怎么去面向一个云环境或者一个可以弹性伸缩的容器环境,设计一个可以弹性伸缩的数据库,这其实是个很大的问题。

另一个沉重的打击是,在实现高可用性时人会犯错。

我们现在建立数据库碰到这些问题的理由是什么呢?

我个人认为关系数据库类似于MySQL,而类似于Oracle的数据库本身不是为分布式而设计的。 此外,强制执行此库分类表等操作,本质上只是再次复制了MySQL,而不是针对它是分布式系统而优化存储和计算。

这就是问题所在。 所以,我觉得我们在进行业务间的咨询,物理间的这台机器间的咨询和写入。

但是终于这个情况在发生变化, 因为在 2000 年以后,分布式系统理论开始变为主流。

这有历史发展背景:过去硬件价格高,网络环境差。 所以,请尽量把计算放在当地做。

固态硬盘的出现基本减少了磁盘IO的问题,但Intel很快就会释放持久化内存。 这样的技术基本上解决了数据库IO层的问题。

目前,在谷歌内部,在同一数据中心读取远程磁盘与读取本地磁盘的吞吐量和延迟几乎一致。

在这种情况下,可以将整个数据中心视为计算机。 重新设计数据库时,它本质上是分布式系统。

第三,大家的思维都在改变。 大家都不梦想有完美的解决方案来解决所有存储问题。

易维护

TiDB这个项目是三年前开始的。 项目是在上面介绍的背景下,我过去在豆荚里维护MySQL集群。

然后,由于关系数据库很难维护,我们经常考虑MySQL和NoSQL组合的数据库是否有优势。

所以这就是最开始的初心,我们要去做一个功能完备的 SQL,百分之百去兼容现有的,至少是这些常用的复杂查询、子查询业务。

>

然后同时要以一个 MySQL 的协议和用法去面向客户,或者用户。这一点很重要,它可以极大地降低用户去试你产品的成本。

 

事务

第二点就是事务,事务是绝对不能少的。我觉得过去这十年 NoSQL 的社区有一个特别大的问题就是追求可扩展性,但是放弃了强一致事务的支持,这是不对的。

过去不实现这个功能的理由是这个功能会导致系统延迟,性能下降。但是我觉得以牺牲数据准确性为代价去实现这个功能是不现实的。

这就相当于本来这个事情应该数据库来做,这些 NoSQL 系统却强行把这个事情交给业务层做。这会给写业务带来一个极大的问题。

另外一个就是扩展的易用性,就是能不能做到我这里用了一个词叫做 push-button scaling。

我简单地扔一台机器进去,不做任何的 resharding,不做任何的修改配置,这个系统自己就扩大了,自己去做 rebalancing,这跟传统的 Sharding 方案有本质的区别。

 

高可用

然后 HA 是什么?HA 就是高可用,这个问题是传统方案很难解决的。就是一切都是需要人工去做这个数据校验和流量的切换。

有没有办法能做到真正的 HA,这个数据库能不能自动地自己去运维、自己去修复自己,自己去保证这个系统的可用性。

在这块我们也做了一些工作,就是我们在底下的整个数据模型完全放弃掉了主从的模型,完全基于 Raft 跟 Paxos 这样的一种分布式选举算法来做。

这个还比较重要,因为如果一个系统你不能保证它的可用性,谈再多的性能都是没有意义的,特别是对于 OLTP 系统来说。

我的这个系统能不能既在上面去支持 ACID 事务,同时又可以利用 Spark 或者 Hadoop 去用整个机群的计算资源和能力,再去做一些复杂的 SQL 查询的时候能加速。这个其实是可以做到的。

 

开源

最后一点就是一定是百分之百开源,通用的技术软件不开源是绝对没有未来的。

因为现在时代已经变了,过去那种闭门造车,然后招一大堆销售,挨家敲门说你要不要试一下的搞法是不对的,特别是平台性质的软件。

而且开源会更加有利于去做软件推广,你的用户越多,用户给你的反馈就越多。

这会比自己在内部去做软件速度快得多。这也是为什么这个项目才开始三年,我们的客户就超过了 2000 多家。

 

TiDB 数据库的四大“杀手锏”

现在我来总结一下 TiDB 数据库有哪些应用场景可以在你自己的业务里面去使用。

 

用例 1:MySQL 分片与合并

 

第一种场景就是 MySQL,比如已有的业务使用了 MySQL Sharding,没问题。现在 TiDB 因为在业务层实时兼容 MySQL 的这个访问协议。

而且我们做了一个工具 Syncer,它能够把 TiDB 作为一个 MySQL Master 的 Slave,在业务层前端可以是一个主库 MySQL,而作为从库的 TiDB 可以看做一个大的 MySQL。

过去我们有一个说法叫一主多从, 但现在有了 TiDB 以后,可以反过来说多主一从。

你可以把这多个 MySQL 组的不同的表、不同的业务、不同的库,实时的 Binlog 的数据全都同步、汇总到一个大的分布式的 MySQL 上。

这个分布式 MySQL 就是 TiDB。在这个 MySQL 之上,你可以去用一些比较复杂的 Query,比如 join,groupby 全都可以。所以这个是一种用户场景。

Syncer 是什么?我刚才简单提了下,Syncer 是可以把自己伪装成一个 MySQL 的 Slave 去做数据的同步的工具。

它本质上是一个 Binlog Listener,会去监听 MySQL 的 Binlog,然后把它变成数据库的语句。

 

用例 2:直接替换 MySQL

 

另外一个应用场景就非常简单粗暴,最简单的情况是业务在快速地增长,但是原来业务就是 MySQL 写的,也没考虑什么分库分表,架构这样的事情。

摩拜早期的时候就用 MySQL。后来发现业务开始快速增长,公司在 30 人团队规模的时候开始使用 TiDB。然后一年之内整个公司人数增长到 800 人,数据从很小的数据集到后来在 TiDB 上有几十 T 的数据,不需要再去做分库分表。

所以在业务快速增长的场景下 TiDB 是个很好的选择。

然后对于 OLTP 的业务来说,TiDB 也是一个很好的选择。对吞吐来说,TiDB 基本上可以做到线型扩张,机器越多,性能越好。而对于延迟来说,TiDB 也有非常出色的表现。

 

用例 3:数据仓库

 

还有一类使用场景是直接把 TiDB 作为数据仓库用。 TiDB 在 OLAP 的性能测评方面表现非常出众。

如果有一些特别复杂的 SQL,TiDB 的 SQL 层还是搞不定,我这边也做了一个开源的项目,叫 TiSpark 。它其实是一个 Spark 的插件,能够让用户直接用 Spark SQL 来实时地在  TiKV 上做大数据分析。

第三个应用场景,TiDB 本身是一个存储跟计算分开的一个项目。它底下 Key-Value 的那一层也可以单独拿出来用,你可以把它当作一个 Hbase 的替代品, 同时支持跨行的事务。

TiDB 的项目其实是受到了 Google Spanner 这个系统的启发,是通过 NoSQL 这一层支持 transaction 的。

TiKV 提供了两层 API,一层是支持跨行事物 transaction 的 API。第二层 API 叫弱 API,主要用来做单行的事务,不提供跨行事务的 ACID 的支持,但是换取的是整个性能和延迟的进一步提升。

所以如果有需要,事务可以用 transaction 的 API,如果需要性能,但是没有强一致事务的跨行事务的需求,就用弱 API。弱 API 跟 Hbase 的一致性级别是一样的。

 

用例 4:作为其他系统的基石

 

基于通用的 KV 层,我们是可以做到很多我们想做的事情。TiDB 并不只是一个简单的数据库项目,它应该是其他的分布式系统的 building block,可以作为其他系统构建的基石。

TiDB 本身对外提供的是 MySQL 的接口,但是社区里面的小伙伴直接去给 TiKV 层去封装一个 Redis 的协议层。然后能让用户直接用 Redis 的协议去做 TiKV。这样就变成了可持久化的 Scalable 的 Redis。

然后另外一个 Case,是在今日头条用的,就是对外提供一个 S3,你想造自己的 S3 没有问题。但是造 S3 最难的部分是在源信息管理这块,并不是它的 data nodes,所以如果你已经有了一个支持跨事务的一个源信息存储系统,你可以做到自己去建造 S3。

我知道已经有一些社区的同学构建一整套新的分布式存储的服务,现在 API 还没有开源,但我觉得不久的未来会开源。

 

如何从 MySQL 迁移到 TiDB?

既然 TiDB 这么好,那现在怎么把 MySQL 迁移到 TiDB 上呢?因为 TiDB 其实是基于 MySQL 生态的,当然可以用 MySQLDump。

我们自己做了一个数据的导入导出工具叫 Lightning。为什么要做这个呢?

比如说过去我们如果直接是用 MySQL 的协议,用 MyDumper、Myloader,就是简单粗暴的导出导入。

那 TiDB 想要做什么事情呢?

因为大家知道 MyDumper Dump 出来的就是 MySQL 一条条的语句。然后在 TiDB 这边要从 SQL,到它的 parser 到执行计划、指导事务、到 KV,最后才写到单机的 RocksDB 上面。

这个过程一遍遍重复执行是一个很慢的过程,如下图:

我们就想,有没有办法能够直接绕过中间所有的东西,直接利用 MyDumper Dump 出来的这个 SQL 语句直接生成底下的 RocksDB 的数据的格式呢?当然可以。

所以这就是 Lightning 在做的事情。你可以认为这是一个升级版的 MySQLDumper,直接 Dump 出 SQL 语句。

然后我们在 TiDB Lightning 这个项目内部直接去做了这个 Record to KV,就是直接生成底层的 key-value pairs。然后同时在内部去做数据分片,提前分好。

第三个就是直接去绕过中间所有的这些 SQL,直接去生成 RocksDB 的 SSD 文件,相当于存储的格式文件发送给不同的机器。然后这个机器直接去把文件 Load 到数据库里面就完成了,中间其实是很快的。

部署 TiDB,我们选的技术方案是 Ansible,所有的部署都是可以一键完成。然后包括性能调优什么的完全是开源的。

另外,TiKV 这个项目已经捐给了 CNCF 基金会, TiDB 与 Kubernetes 整合的项目—— TiDB Operator 也已经开源了。

当然,如果你说想在本地自己去玩一玩,但是 TiDB 这么多组件,我能不能用一条命令就能在本地搭建一个完整的 TiDB Cluster 去做测试呢?当然可以。

我们这边是有 Docker Compose,是两条路径,一条是 git clone,然后第二条是启动。

它会启动包括 Dashboard,数据的迁移、可视化,TiDB MySQL 的 Service endpoint、TiSpark 全都会在你的 Docker Container 去创建。

另外这还不够,我们把一些核心算法通过数学的方式去形式化地证明它是正确的。这个 TLA+ 的源码文件开源了,大家如果想在自己的分布式系统里面去用 TLA+ 做数学上的证明,你可以去参考我们写的文档。所以我觉得测试反而是这个公司最重要的一块资产。

 

总结

 

最后,有几个大的问题也是这段时间我思考得比较多的,比如说你整个集群云化了以后,在数据库的层面上 Multi—tenancy 该怎么做?就是如何能去做到更有效的资源隔离和复用?

现在并没有太好的解决方案,因为整个 IO 的隔离还是比较大的问题。

第二个就是自治,这个数据库能不能拥有智能,就是我再不需要人工去做运维。

这个数据库能够自己部署,自己维护,自己更新。然后数据出现问题,自己修复;性能出现问题,自己调优。

我们也在尝试去把一些我们运营时的 Metric 往 Tensorflow 里面去导,自动地去做调优。这个工作正在做,然后应该 CMU 是一些比较有意思的工作。

还有就是软硬件的结合,就是说怎么去利用这些新时代的硬件来提升你的整个数据库的稳定性能。

java实现构造无限层级树形菜单从使用React和Webpack构建的网站的URL中删除.html扩展名汇总在vue中写jsx的方式产品与大数据中的“少即是多”roofts和us到基本操作怎么用VSCode调试React Vue代码Java Map按Key值进行排序浅析JavaMail发送邮件后再通过JavaMail接收格式问题vue中的el-tree @node-click传自定义参数怎么用eclipse输出Hello World的实现方法香港云服务器这几天网络有没有丢包严重Java实现导出ZIP压缩包的方法Qt专栏之模态与非模态对话框的实现jquery find方法如何获取第一个子元素iOS设置View阴影效果深入理解C#中的枚举
分布式存储集群,分布式存储部署 redis集群三种方式,fastoredis
相关内容