TiDB Serverless 与技术生态全景
发布时间:2023-02-22 08:39:15 所属栏目:云计算 来源:
导读: PingCAP 在 2022 年 11 月 1 日正式发布了 TiDB Cloud Serverless Tier,本次分享在介绍 Serverless Tier 的技术细节之余,全面解析 TiDB 的技术生态全景和在生态构建中所做的努力。阅读本文,了解有关 Server
PingCAP 在 2022 年 11 月 1 日正式发布了 TiDB Cloud Serverless Tier,本次分享在介绍 Serverless Tier 的技术细节之余,全面解析 TiDB 的技术生态全景和在生态构建中所做的努力。阅读本文,了解有关 Serverless 的更多信息,以及 PingCAP 在技术领域的最新进展。 如今云已经不是什么新鲜事,我们已经处于云时代,相较以往,云时代的开发者面临着与以往不一样的机会与挑战。在云时代,我们有着新的技术设施,我这里举几个例子,每个云厂商都会提供块存储服务、对象存储服务和弹性计算服务。块存储服务具有高吞吐、低时延和高持久的特性。对象存储服务,比如 AWS 的 S3、国内阿里云的 OSS,提供了低成本的海量存储空间,并且这些存储还有着超高的可用性,甚至可以跨地域复制来进行容灾。而弹性计算服务,可以给我们提供多种规格的计算实力,而且还提供了不同的计费模式,当然,根据用户的诉求进行弹性伸缩,也是一个基本的能力。 新世纪有了一系列新的基础设施,当然也一定会有许许多多新的不期而遇的挑战。云厂商给我们提供了许多的云服务,并且云的初衷之一,就是让使用者可以减少很多的运维工作。但是如果你现在深度地使用云,仍然需要运维大量的云上基础设施。这些运维工作使得我们开发者的精力被分散,没法完全专注于业务本身。除了运维工作之外,如何使用好云也是一门学问,前不久我刚刚参加了 AWS 的架构师培训,其实如何多快好省地用好云,不是一件简单的事儿。云服务的使用者,很容易就会造成云上资源的浪费,产生不必要的高额费用,特别是在现在许多的云服务,仍然是按时间来收费的情况下。对于有多套环境需求的场景,比如说公司内部有多个团队,不同的业务有各自的环境诉求,或者在 CICD 的场景下,我们可能会有 preview、stage、product 的多套环境需求,购买多套云服务会产生高额的费用,但是共享一套云服务则可能会产生资源的竞争,甚至出现测试环境影响生产业务的情况。云上的服务,比如说云上的数据库服务,现在的使用方式仍然是提前规划容量,然后始终按照购买的时候的容量进行工作和计费,如果后期需要调整,仍然需要人工介入,手动去进行扩缩容。 当然之前,我们还是先来看一下传统的TiDB集群。这是一个经典的 TiDB 集群架构,可以看到这是一个非常典型的分层架构,计算层是 TiDB Server,每个 TiDB Server 都是一个无状态的计算节点,可以非常容易的进行横向扩容,存储层是 TiKV 和 TiFlash。TiKV 是我们的分布式存储引擎,TiFlash 是列存储引擎,整个存储层通过分布式协议实现了一致分布式存储。在计算层和存储层之外,我们还有一个调度单元 PD,这里存储了整个 TiDB 集群的信息。在这样的一个架构下面, TiDB 已经有了很好的表现。比如 TiDB 有着非常好的扩展性,无论是计算还是存储能力都可以随节点线性扩展。 但是这样的一个经典架构在云的时代,面对着完全不同的基础设施,存在一些问题。第一,share-nothing,刚才我们提到云厂商提供的基础设施,无论是块存储,还是对象存储,天然就有着高可用,高持久的特性,云厂商已经帮我们做了数据复制,但是 TiKV,TiDB 的存储层,仍然做着自己的数据复制。这在云上其实是多余的,数据的复制不仅仅是存储资源的浪费,同时还需要消耗大量的带宽,在云上,网络也会造成非常高额的费用。第二,存储层状态重。这是因为每个存储节点,其实都存储着一些数据的副本,扩容转移一个故障节点都需要对这些副本进行同步,导致横向扩展的速度仍然不够快,也进一步导致难以利用厂商提供的竞价实例,从而能够进一步的降低成本。第三,TiDB 之前是一个非常经典的计算、存储、调度分离的架构。但是在云时代,这样划分的颗粒度仍然过大,每一个节点承担的责任过多,导致 TiDB 整体的弹性仍然不够,其实我们可以在云上,将更多的功能拆分出来形成单独的微服务,这些微服务可以独立的去进行扩容和部署,甚至这些微服务可以被多个集群去共享。如果拆分出更多的微服务,TiDB 集群整体的弹性会进一步上升。 在计算层我们进一步地拆分了 TiFlash[,TiFlash 现在它的计算存储已经可以去分离,TiFlash 的计算部分可以像 TiDB Server 一样,作为一个独立的组件去进行管理,去扩容。第二,我们引入了新的一层,叫做 Gateway。Gateway 代替了 TiDB Server 与用户进行交互,它负责诸如连接管理、唤醒节点这样的功能。它的出现使得我们所说的多租户成为一个可能。第三,我们优化了计算节点,在图上右边的部分,有多个 TiDB 和 TiFlash。我们将计算节点进行了优化,这样的设计进一步降低了计算层的成本,以及提升了计算节点唤醒的速度。计算层和存储层的改动,使得 TiDB Cloud Serverless Tier 支持了多租户。现在一套 TiDB Cloud Serverless Tier 集群,可以支持多个租户,每个租户都是完全隔离的。在用户看来,他们拥有的就是一套独立的 TiDB 集群。 做完相应的改进,新的架构解决了之前所说的传统架构在云上的问题,更好地适应了云上的基础设施。这边总结一下,一是推出了 Cloud Storage Engine,可以融合地使用块存储和对象存储,并且消除了多余的复制,解决了两类问题,一是冗余的复制,二是高额的网络费用。第二,拆分出了更多的微服务,更好地使用了云上的弹性算力。整体的改动使得 TiDB Cloud 可以支持多租户。 技术上的努力使得 TiDB Cloud Serverless Tier 拥有了非常新颖的能力。TiDB Cloud Serverless Tier 拥有全部的 TiDB 的 HTAP 能力,是世界上第一款 Serverless HTAP 数据库。我们优化了 TiFlash 的架构,使其更好地适应了云上多租户的场景。从刚才介绍的 TiDB Cloud Serverless Tier 的架构上可以看到,我们对计算节点进行了优化,多租户也共享了存储。所以,TiDB Cloud Serverless Tier 目前可以做到秒级创建一个 TiDB 集群,并且如果你长时间不使用,再次连接的时候也仅需数百毫秒的时间就可以恢复完整的集群。这个操作对于用户来说,是完全透明的,用户甚至感知不到。未来,我们会进一步优化这个时间,集群创建时间会持续缩短,唤醒时间也会从数百毫秒缩短到数十毫秒。 作为一款真正的 Serverless 云数据库,当然,TiDB Cloud Serverless Tier 是完全无需用户去运维的。在使用方式上,不需要像传统的数据库那样,提前去规划容量,在需要的时候进行缩容,TiDB Cloud Serverless Tier 会根据流量自动地进行伸缩,无需任何手动的操作。具备了这么强大的能力,TiDB Cloud Serverless Tier 的计费方式也是真正的按使用量付费,用户只需要为自己真正使用的资源进行付费,不使用,即使这些集群仍然在运行当中,你也无需支付任何的费用,这也是 TiDB Cloud Serverless Tier 区别于传统数据库甚至于其他 Serverless 数据库的不同之处,这些数据库即使你不使用,但只要集群被创建出来,仍然会按照创建时的规格进行收费,这其实会造成极大的资源浪费。 讲了这么多,接下来我们来展示一个 Demo[,这个 Demo 就是我们从无到有来创建一个 TiDB Cloud Serverless Tier 集群,这个其实也是基本上是所有用户唯一需要与 TiDB Cloud Serverless Tier 打交道的一个动作,因为刚才我们说了,一旦创建之后其实你不需要去运维,你也不需要去进行手动扩缩容,TiDB Cloud Serverless Tier 会根据你的流量自动进行扩缩容,我们开始看一下集群创建的过程。 希望经过我们的努力,TiDB Cloud Serverless Tier 可以成为一个服务于每个人的 HTAP 数据库,TiDB Cloud Serverless Tier 现在拥有了完整的 HTAP 能力,可以处理复杂的工作负载,并且真正地按使用量付费,对于任何人都只需要为自己使用的计算资源和存储资源付费,不存在资源浪费的情况,具有非常高的性价比。对于个人开发者,TiDB Cloud Serverless Tier 每个月其实都提供了一定量免费的 Quota,只要不超过这个 Quota,对于个人开发者而言,TiDB Cloud Serverless Tier 就是一个完全免费的触手可及的 HTAP 数据库,对于 Startup 来说,TiDB Cloud Serverless Tier 可以跟随业务增长自动进行扩容,而且这个扩容完全是自动的,不需要手动介入。Startup 可以专注于他的业务本身去发展自己的业务,不需要为数据基础设施去操心。对于大公司而言,因为 TiDB Cloud Serverless Tier 超高的性价比以及非常迅速的创建恢复时间,使得云上资源不再成为一个限制,每个部门、每个环境都可以拥有自己独立的数据库,未来我们还会推出 data branching 更好地帮助企业客户,当然如果公司有跨云部署的诉求,TiDB Cloud Serverless Tier 也是一个非常完美的选择。 当然,对于任何一个数据库的使用者不可能仅仅与数据库软件本身打交道,同时需要使用大量的数据库生态软件,TiDB Cloud Serverless Tier 拥有非常丰富的生态,接下来我们就来看一下 TiDB 的生态。数据库不是单一软件,而是一个生态体系,除了产品自身的能力,繁荣的技术生态体系也至关重要。TiDB 从出生起就非常重视生态,所以选择了与 MySQL 兼容,并且在这个上面做了许多努力。 在语言上,TiDB 还与基本上所有流行的 ORM 框架兼容,与语言的 driver 不同,除了协议层的兼容之外,ORM 往往在功能上对 MySQL 的兼容性有着更高的要求,TiDB 的一些扩展能力也需要去进行补齐。TiDB 在这个方面做了很多努力,首先针对一些 ORM 开发了自己的插件,比如对于 django 和HIBERNATE,我们开发了django-tidb 和 hibernate-tidb 插件。TiDB 也在产品本身的 MySQL 兼容性的能力上做了很多增强,比如,可能在应用中我们可以不用,但是对于许多 ORM 框架都非常重要的两个功能 savepoint 和外键。这两个功能对于很多ORM 框架来说都非常重要,很多 ORM 框架对他的依赖都非常重。在最近两个 TiDB 的版本中发布了savepoint 功能和实验版本的外键功能,这使得 TiDB 进一步提升了与许多 ORM 框架的兼容性。 除了语言的 driver 和 ORM 框架之外,TiDB 以及 TiDB Cloud 还可以集成许多流行的平台,我们这里罗列了一些主要的,比如在数据处理领域,TiDB 可以与 Spark、Flink、Databricks 这些流行的大数据处理框架以及平台结合使用,来构建企业的 ETL pipeline,形成统一的数据处理平台。同时除了传统的 ELT 平台,TiDB 还可以与海外非常流行的 modern data stack 体系进行集成,我们给 Airbyte 贡献了 tidb-source-connector 和 tidb-destination-connector,开发了 dbt-tidb adapter,使得 TiDB、TiDB cloud 可以完美地与 Airbyte、dbt 进行集成。 TiDB 和 TiDB Cloud 很早就支持使用 prometheus 和 grafana 作为监控平台,我们还支持将监控的 metrics 导出到 datadog 平台,还可以实现与 Serverless 部署平台 Vercel、Netlify 的集成,以及与 no-code workflow automation 平台,像 zapier、n8n 的集成,以及与 IaC 工具 Terraform 的集成等等。接下来深入到一些领域来仔细看一下。 首先来看 modern data stack 领域,也就是我们所说的 ELT pipeline,注意,这里不是传统的 ETL pipeline,是 ELT pipeline。首先介绍一下 Airbyte 和 dbt,Airbyte 是一个 data pipeline 平台,它可以连接数百种数据源和数据汇,将数据源中的数据导出到数据汇中,然后在数据汇中对数据进行整理。基于此,用户可以通过 Airbyte 实现任意的数据迁移,它的口号就是 data from any source to any destination。dbt 是一个 data transformation 工具,借助 dbt 用户可以非常灵活地在数据库或者数据仓库中操作数据,进行数据变换。结合使用 Airbyte、dbt 和 TiDB Cloud,用户可以将任意数据源中的数据,比如在 salesforce 中的 CRM 数据,google sheets 中的表格数据,甚至是像 Instagram 这样 2C 应用中的企业运营数据导入到 TiDB Cloud 中。有了数据,我们可以利用 BI 工具进行数据分析,因为 TiDB 以及 TiDB Cloud Serverless Tier 是一个 HTAP 数据库,在面对分析型负载的时候,有着更好的表现。甚至,如果说用户有数据归档的诉求,可以继续将 TiDB 作为 Airbyte 的数据源,将数据导入到像 Snowflake、Databricks、Google Big Query 这样的数据仓库或者说数据湖中去。 总的来说,用户如果结合使用 TiDB Cloud、Airbyte 和 dbt 建立一条 ELT data pipeline,一是可以使用自己的数据设施 all in Cloud,整条流水线都可以拥有非常好的弹性,可以满足业务增长的诉求。同时云上的基础设施拥有很高的性价比,可以降低数据基础设施的成本,而且因为 all in Cloud,你无需运维,降低了数据集成的技术、费用门槛。二是可以加速企业内业务数据的流动,Airbyte 拥有上百种的数据连接器,用户可以直接去使用,无需自己设计、开发,从而企业内的数据分析师可以更快地进行数据分析,帮助企业发现新的商业机会,而不是把精力浪费在基础设施的重复建设当中。 为了让用户更好地使用 Vercel 和 TiDB Cloud Serverless Tier,我们开发了 TiDB Cloud Vercel Integration ,你可以在 Vercel 的 Integration 市场中找到它,通过这个 integration,只需要简单的几次点击就可以连接 TiDB Cloud Serverless Tier 集群和 Vercel 项目。同时我们还开发了 TiDB Cloud Starter 模板,这个模板可以让用户通过几次点击和几分钟的等待,从无到有地构建一个全球可访问的 web 应用。以下是一个简单的 demo 让大家来体验这套 Fullstack Serverless Infrastructure。 我们进入下一个生态 Terraform,Terraform 是业界默认的跨云 IaC 工具,使用 Terraform 可以使用代码来管理云基础设施,将它集成到我们的 CICD 流程当中,我们在前不久开发了 TiDB Cloud Terraform Provider,使得用户可以通过 Terraform 来管理 TiDB Cloud 的资源。像图上展示的,我们可以通过这样的一个 Terraform 文件来创建一个 TiDB Cloud Serverless Tier 集群。Terraform Core 会解析这个文件,将 TiDB Cloud 资源的相关定义都发给我们开发的 TiDB Cloud Terraform Provider,TiDB Cloud Provider 会调用 TiDB Cloud Go SDK 来操作 TiDB Cloud 的资源。PingCAP 已经和 HashiCorp 成为了技术合作伙伴,TiDB Cloud Terraform Provider 也已经是 HashiCorp 认证的 Partner Provider,欢迎大家使用 Terraform 来操作 TiDB Cloud 的资源。操作tidbcloud的资源。terraform提供了一个简单的界面,用户可以通过这个界面快速找到自己需要的资源,并且可以直接访问资源。 (编辑:汽车网) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |