Databend 特性系列（1）｜Databend 数据生命周期

2022-09-15 11:30:55 阅读：224 来源： 互联网

标签：default 生命周期 tb1 特性 Databend snapshot MySQL sec

Databend 是一个使用 Rust 研发、开源、完全面向云架构的新式数仓，提供极速的弹性扩展能力，致力于打造按需、按量的 Data Cloud 产品体验。具备以下特点：

开源 Cloud Data Warehouse 明星项目
Vectorized Execution 和 Pull&Push-Based Processor Model
真正的存储、计算分离架构，高性能、低成本，按需按量使用
完整的数据库支持，兼容 MySQL ，Clickhouse 协议
完善的事务性，支持 Time Travel, Database Clone， Data Share 等功能
支持基于同一份数据的多租户读写、共享操作

现在使用 Databend 的用户越来越多后，大家面临一个问题，使用 Databend 如何备份呢？是不是需要如同 MySQL 一样每天做一个物理备份或是逻辑备份呢？答案是：可能还有更好的办法。这篇文章和大家聊一下 Databend 中数据的生命周期，然后再来看 Databend 如何做备份管理。

首先我们来看一下 Databend 的架构

Databend 的写入操作是有事务性保证，基于事务隔离 RR 实现的，底层的数据存储是基于对象存储，实质上数据的持久化安全也是依赖于底层的对象存储，所以选择云厂商的 S3, OSS, COS 也是不错的选择，如果是自建的 minio, ceph 一定要做集群保证。因为是基于对象存储写入，所以任务的写入都可以理解为是一个增量操作，这也让 Databend 省掉了日志管理，更多的需要把表和对应的 snapshot 关联起来就可以让数据恢复到任意的时间点。接下来分 4 个方面看看 Databend 如何利用对象存储实现一个无须备份，但数据永远不丢失的方案。

Databend 数据生命周期核心：Snapshot

在讲 Databend snapshot 之前，抛出来一个问题：

如果想访问一个表 5 分钟前的数据怎么处理，
一个 delete from tb ; 没有 where 条件怎么恢复？

如果在别的数据库这两个需求，基本都是灾难。但在 Databend 中，这些是非常轻松可以完成的。演示如下：

MySQL [default]> create table d_tb1(c1 int, c2 varchar);

Query OK, 0 rows affected (0.011 sec)

MySQL [default]> insert into d_tb1 values(1,'databend');
Query OK, 0 rows affected (0.018 sec)

MySQL [default]> insert into d_tb1 values(2,'MySQL');

Query OK, 0 rows affected (0.016 sec)

MySQL [default]> insert into d_tb1 values(3,'Hive');

Query OK, 0 rows affected (0.016 sec)

MySQL [default]> insert into d_tb1 values(4,'Hbase');

Query OK, 0 rows affected (0.016 sec)
MySQL [default]> select * from d_tb1;
+------+----------+
| c1   | c2       |
+------+----------+
|    1 | databend |
|    3 | Hive     |
|    2 | MySQL    |
|    4 | Hbase    |
+------+----------+
4 rows in set (0.018 sec)

基于 snapshot 读取数据

总共写入了 4 行数据，我们来看一下对应的 snapshot 相关的数据：

MySQL [default]> select snapshot_id,previous_snapshot_id, timestamp from fuse_snapshot('default','d_tb1');
+----------------------------------+----------------------------------+----------------------------+
| snapshot_id                      | previous_snapshot_id             | timestamp                  |
+----------------------------------+----------------------------------+----------------------------+
| b031e57aa06443cc9d3ffadb3023dec6 | 34b8df220edc4d8cb9e3e76118788686 | 2022-08-30 01:19:06.367120 |
| 34b8df220edc4d8cb9e3e76118788686 | 4bb479751b7144d8aa2b53e5b281453f | 2022-08-30 01:18:53.202724 |
| 4bb479751b7144d8aa2b53e5b281453f | a2801ed9656d42c9812f2921214f0795 | 2022-08-30 01:18:35.597615 |
| a2801ed9656d42c9812f2921214f0795 | NULL                             | 2022-08-30 01:18:21.750208 |
+----------------------------------+----------------------------------+----------------------------+
4 rows in set (0.007 sec)

我们看到 previouse_snapshot_id 为 NULL 是第一次写入的操作。对应的数据是：insert into d_tb1 values(1,'databend');如果想读取这个 snapshot 的数据方法：

MySQL [default]> select * from d_tb1 at(SNAPSHOT=>'a2801ed9656d42c9812f2921214f0795');
+------+----------+
| c1   | c2       |
+------+----------+
|    1 | databend |
+------+----------+
1 row in set (0.010 sec)

看到这里是不是觉得这里充满了魔法了。同样也可以使用时间来访问历史的数据：

MySQL [default]> select * from d_tb1 at(timestamp=>'2022-08-30 01:18:21.750208'::timestamp);
+------+----------+
| c1   | c2       |
+------+----------+
|    1 | databend |
+------+----------+
1 row in set (0.010 sec)

这个时间不用精确值，只用比当行对应的 timestamp 值大，小于上面一行的 timestamp 就可以获取对应的精确数据。

再来看一下 delete 没有 where 条件的操作:

MySQL [default]> delete from d_tb1;
Query OK, 0 rows affected (0.012 sec)

MySQL [default]> select * from d_tb1;
Empty set (0.010 sec)
MySQL [default]> select snapshot_id,previous_snapshot_id, timestamp from fuse_snapshot('default','d_tb1');
+----------------------------------+----------------------------------+----------------------------+
| snapshot_id                      | previous_snapshot_id             | timestamp                  |
+----------------------------------+----------------------------------+----------------------------+
| ec52197b4c344f8d8a353eff8a812de7 | b031e57aa06443cc9d3ffadb3023dec6 | 2022-08-30 01:32:03.227960 |
| b031e57aa06443cc9d3ffadb3023dec6 | 34b8df220edc4d8cb9e3e76118788686 | 2022-08-30 01:19:06.367120 |
| 34b8df220edc4d8cb9e3e76118788686 | 4bb479751b7144d8aa2b53e5b281453f | 2022-08-30 01:18:53.202724 |
| 4bb479751b7144d8aa2b53e5b281453f | a2801ed9656d42c9812f2921214f0795 | 2022-08-30 01:18:35.597615 |
| a2801ed9656d42c9812f2921214f0795 | NULL                             | 2022-08-30 01:18:21.750208 |
+----------------------------------+----------------------------------+----------------------------+
5 rows in set (0.007 sec)

从上面的 snapshot 来看，增加一个新的 snapshot，所以我们为了访问 delete 的数据，就可以利用 at 语句访问前一个 snapshot 就可以，如下：

MySQL [default]> select * from d_tb1 at(snapshot=>'ec52197b4c344f8d8a353eff8a812de7');
Empty set (0.010 sec)
MySQL [default]> select * from d_tb1 at(snapshot=>'b031e57aa06443cc9d3ffadb3023dec6');
+------+----------+
| c1   | c2       |
+------+----------+
|    3 | Hive     |
|    4 | Hbase    |
|    2 | MySQL    |
|    1 | databend |
+------+----------+
4 rows in set (0.011 sec)

恢复这个表，也可以考虑:

create table d_tb1_new as select * from d_tb1 at(snapshot=>'b031e57aa06443cc9d3ffadb3023dec6');

再进行 rename 操作即可。关于 at 语法参考：https://databend.rs/doc/reference/sql/query-syntax/dml-at这些特性也是依赖于 Databend 使用底层时使用的对象存储，所有的写入都是增量写入。例如：对于 Delete 也只是操作的 meta 并没有真正的删除数据。这也是 Databend 的一个特性：Time travle。

Snapshot 终极大招

在上面的演示中，我们看到利用 Databend 的 at 语句加上 snapshot 和 timestamp 实现对表任意时间点和操作前的访问。在最后恢复数据时，我们还需要借助于建一个新表，然后 Select 出来数据，然后对外访问。那有没有更快的方法呢？Databend 永远不会让你失望，当然更快的方法。接下来给你演示一下。首先我们来一下 d_tb1 和 snapshot_location 对应关系：

MySQL [default]> select snapshot_id, snapshot_location from fuse_snapshot('default','d_tb1');
+----------------------------------+------------------------------------------------------+
| snapshot_id                      | snapshot_location                                    |
+----------------------------------+------------------------------------------------------+
| ec52197b4c344f8d8a353eff8a812de7 | 1/15967/_ss/ec52197b4c344f8d8a353eff8a812de7_v1.json |
| b031e57aa06443cc9d3ffadb3023dec6 | 1/15967/_ss/b031e57aa06443cc9d3ffadb3023dec6_v1.json |
| 34b8df220edc4d8cb9e3e76118788686 | 1/15967/_ss/34b8df220edc4d8cb9e3e76118788686_v1.json |
| 4bb479751b7144d8aa2b53e5b281453f | 1/15967/_ss/4bb479751b7144d8aa2b53e5b281453f_v1.json |
| a2801ed9656d42c9812f2921214f0795 | 1/15967/_ss/a2801ed9656d42c9812f2921214f0795_v1.json |
+----------------------------------+------------------------------------------------------+
5 rows in set (0.007 sec)

MySQL [default]> show create table d_tb1;
+-------+------------------------------------------------------------------------------------------------------------------------------------------+
| Table | Create Table                                                                                                                             |
+-------+------------------------------------------------------------------------------------------------------------------------------------------+
| d_tb1 | CREATE TABLE `d_tb1` (
  `c1` INT,
  `c2` VARCHAR
) ENGINE=FUSE SNAPSHOT_LOCATION='1/15967/_ss/ec52197b4c344f8d8a353eff8a812de7_v1.json' |
+-------+------------------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.006 sec)

从上面的信息中可以看来，每个表后面通过 SNAPSHOT_LOCATION 的对应的版本对应起来。那么如果我们创建一个基于前面 snapshot_id 对应的 snapshot_location 对应的位置，会怎么样呢？来操作一下：

MySQL [default]> CREATE TABLE `d_tb2` (
    ->   `c1` INT,
    ->   `c2` VARCHAR
    -> ) ENGINE=FUSE SNAPSHOT_LOCATION='1/15967/_ss/b031e57aa06443cc9d3ffadb3023dec6_v1.json';
Query OK, 0 rows affected (0.013 sec)

MySQL [default]> select * from d_tb2;
+------+----------+
| c1   | c2       |
+------+----------+
|    3 | Hive     |
|    1 | databend |
|    2 | MySQL    |
|    4 | Hbase    |
+------+----------+
4 rows in set (0.010 sec)

可以看到数据又回来了。这样也可以通过 rename 的方式直接对外，提供服务。是不是感觉到更神奇。基于 Snapshot 的引用创建表，也是我们 Databend 数据 Share 的一个核心。Snapshot 方式的数据管理，也让 Databend 天然具备了 RR 事务隔离级的读写操作。

总结

在上面的文章中我们演示了 snapshot 在 Databend 对于数据生命周期的访问控制。这里有一个核心就是云对象存储不能炸了。在这个前题下，如果备份 Databend 的数据可以有以下几种方法：

每天备份一下对应的表结构。
每天备份一下对应表的 fuse_snapshot 对应输出。
如果是自建的存储可以增加副本数来增加安全性。

关于 Databend

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

Databend 文档：https://databend.rs/
Twitter：https://twitter.com/Datafuse_Labs
Slack：https://datafusecloud.slack.com/
Wechat：Databend
GitHub ：https://github.com/datafuselabs/databend

标签：default,生命周期,tb1,特性,Databend,snapshot,MySQL,sec
来源： https://www.cnblogs.com/databend/p/16695955.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。

ICode9

Databend 特性系列（1）｜Databend 数据生命周期

Databend 数据生命周期核心：Snapshot

基于 snapshot 读取数据

Snapshot 终极大招

总结

关于 Databend