TiDB Serverless 与技术生态全景介绍
发布时间:2023-12-13 22:01:00 所属栏目:云计算 来源:DaWei
导读: 数据库不是单一软件,而是一个生态体系。成为一款好用的数据库,除了产品自身的能力外,繁荣的技术生态体系也至关重要,既可以提升使用体验,又可以降低使用门槛。
这才有了数
这才有了数
数据库不是单一软件,而是一个生态体系。成为一款好用的数据库,除了产品自身的能力外,繁荣的技术生态体系也至关重要,既可以提升使用体验,又可以降低使用门槛。 这才有了数字化的新的基础设施,当然也注定有各式各样的数字化的挑战。云厂商给我们提供了许多的云服务,并且云的初衷之一,就是让使用者可以减少很多的运维工作。但是如果你现在深度地使用云,仍然需要运维大量的云上基础设施。这些运维工作使得我们开发者的精力被分散,没法完全专注于业务本身。除了运维工作之外,如何使用好云也是一门学问,前不久我刚刚参加了 AWS 的架构师培训,其实如何多快好省地用好云,不是一件简单的事儿。云服务的使用者,很容易就会造成云上资源的浪费,产生不必要的高额费用,特别是在现在许多的云服务,仍然是按时间来收费的情况下。对于有多套环境需求的场景,比如说公司内部有多个团队,不同的业务有各自的环境诉求,或者在 CICD 的场景下,我们可能会有 preview、stage、product 的多套环境需求,购买多套云服务会产生高额的费用,但是共享一套云服务则可能会产生资源的竞争,甚至出现测试环境影响生产业务的情况。云上的服务,比如说云上的数据库服务,现在的使用方式仍然是提前规划容量,然后始终按照购买的时候的容量进行工作和计费,如果后期需要调整,仍然需要人工介入,手动去进行扩缩容。 基于这些问题,其实 PingCAP 做了很多的努力,也都做了相应的改进,大家可以看到这是现在 TiDB Cloud Serverless Tier 的一个新架构。首先在存储层开发了 Cloud Storage Engine 一个新的存储引擎,图中 Shared Storage Layer 和 Shared Storage Pool 这两层组合起来就是新的 Cloud Storage Engine。现在新的存储引擎融合使用了云上的块存储和对象存储,并且消除了原来存储层冗余的数据复制,彻底的解决了之前所说的 share-nothing 和状态重复的问题。这样的做法可以极大地减少在存储层内进行节点扩充的费用,并且可以快速地实现。 在计算层我们进一步地拆分了 TiFlash[,TiFlash 现在它的计算存储已经可以去分离,TiFlash 的计算部分可以像 TiDB Server 一样,作为一个独立的组件去进行管理,去扩容。第二,我们引入了新的一层,叫做 Gateway。Gateway 代替了 TiDB Server 与用户进行交互,它负责诸如连接管理、唤醒节点,这样的功能。它的出现使得我们所说的多租户成为一个可能。第三,我们优化了计算节点,在图上右边的部分,有多个 TiDB 和 TiFlash。我们将计算节点进行了优化,这样的设计进一步降低了计算层的成本,以及提升了计算节点唤醒的速度。计算层和存储层的改动,使得 TiDB Cloud Serverless Tier 支持了多租户。现在一套 TiDB Cloud Serverless Tier 集群,可以支持多个租户,每个租户都是完全隔离的。在用户看来,他们拥有的就是一套独立的 TiDB 集群。 我们只需要点击创建,如果你需要可以选择名字以及供应商以及 region,这里我们都是使用默认的。然后就进入了创建的一个过程,可以看到大概在 20 秒的时候整个集群其实就已经从 creating 的状态变成了 avaliable 的状态,TiDB Cloud Serverless Tier 现在整个创建时间大概就是在 20 秒左右,可能会上下有一定波动,基本是在这样一个量级。只需要 20 秒你就可以拥有一个完全工作的 HTAP 云数据库,并且后续不需要你进行任何操作以及与它有任何运维上的交互。在HTAP上,你可以轻松实现数据库的备份、恢复、还原、查询等功能,同时还可以通过自定义脚本来实现各种复杂的应用程序。 (编辑:大连站长网) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |
推荐文章
站长推荐