关于数据库:多点基于-Databend-的-TiDB-数据归档实践-Data-Infra-分享第-4-期总结

本周末 Data Infra 社区分享中邀请到多点 DMALL 数据库负责人：冯光普分享了《基于 Databend 的 TiDB 数据归档实际》

本次分享的次要内容：

TiDB 在多点 DMALL 应用的十分好。能够实现通明扩大，研发无感，数据减少，架构不变；TiDB 在应用中给人的感觉是没有容量限度，反对更多的数据；在 TiDB 中扩容更便捷，加节点即扩容，主动 Rebalance。基于以上长处，TiDB 越用越难受，但老本也就越来越高。

上图多点 DMALL TiDB 某集群当初跑在腾讯云上总共 24 个节点，每个节点近 3 T+ 空间（NVME 磁盘 )，当初总数据量 60 T 了，QPS 靠近 10 万。数据还在一直的回升中，所以思考须要对 TiDB 进行归档存储。

在抉择归档时，分 4 个方面做了比照：

存储老本：对象存储和 HDD, SSD 的老本，其中对象存储是 HDD 的 1 /10, 是 SSD 的 1/30,
在线查问能力：但数据又不能间接放到对象存储中，还须要提供对外的查问能力，
反对大表继续备份：这块也调研了 MariaDB on S3，须要先写入 InnoDB，而后在转成只读的 s3 engine , 这样备份 10 TB 的表，本地也要有 10 TB 的空间，Databend 是间接写入对象存储。
兼容 MySQL 协定：能够放弃 TiDB 的应用习惯。

基于以上条件的比照，最终多点 DMALL 抉择了 Databend。多点 Databend 的部署架构如下：

其中 Databend-query 有点相似于 MySQL server 间接连贯对象存储，对于用户治理，权限，meta 信息存储在 Databend-meta 中，这个节点能够单点部署，生产中也能够部署成集群模式。

DMALL 研发一个新的归档工具，工作流程如下：

归档工作，由开发人员发动，DBA 审核，自动化归档，数据永恒保留。基于下面的办法，能够实现开发人员，查问 2,3 年前的数据，也能够自助实现。

多点采纳的单表按 10 M 每个 Batch 写入，评估一天单表能够归档 1.3 T 数据，单集群对于表没有限度，能够依据工作去并发写 Databend 集群，这样一天的量根本十分可观。另外这块，多点 DMALL 也比照了 MySQL，TiDB，Databend 数据压缩能力：

在 MySQL 中占用 150 G 数据，导入 TiDB 中占用：25 G，在 Databend 中占用：18 G（只有一个正本，数据可用性靠对象存储保障 )。

基于老本方面的考查：数据从 TiDB 到 Databend 从 3 正本到 1 份数据（对象存储帮搞定正本），对象存储不须要预留，按理论付费，单价仅是 HDD，SSD 老本的 1/10-1/30。DMALL 这边应用 Databend 做 TiDB 的归档后，存储老本仅仅是原来存储老本的 2%。

在归档场景下 Databend 劣势：

最初冯光普提出心愿 Databend 生态方面更加的欠缺，例如，能够更加欠缺 TP 到 Databend 的数据同步据，进一步的交融 TP + AP 的能力。

Data Infra 社区是 Databend 开发者邀请数据工作者一起交换数据架构及相干技术的一个社区。关注微信公众号，继续理解 Data Infra 社区。

Databend 是一款开源、弹性、低成本，基于对象存储也能够做实时剖析的旧式数仓。期待您的关注，一起摸索云原生数仓解决方案，打造新一代开源 Data Cloud。

文章首发于公众号：Databend

为什么抉择 Databend 归档 TiDB