clickhouse分析：zookeeper数据存储

安装clickhouse

安装全新的clickhouse，暂无数据。

开启debug级别的日志

在config.xml中，开启<level>debug</level>模式，便于查看日志内容。

创建复制表

建表语句：

create table test_test
(Id               Int32,YearMonth        Int32,DeviceType       String
) engine = ReplicatedMergeTree('/clickhouse/tables/{layer}-{shard}/default_test',
'{replica}') PARTITION BY YearMonth ORDER BY (YearMonth, DeviceType) SETTINGS index_granularity = 8192;

以下为zookeeper存储的内容：

主要存储了一些建表的数据和数据块等信息。

查看zookeeper存储的内容

插入一条数据到复制表中：

insert into test_test(Id,YearMonth,DeviceType) values (1,202001,'D1-2');

zookeeper显示的内容：

在分区中多出了内容，出现了202001_0_0_0的文件夹，该文件夹为我们导入的分区的文件夹，存储的内容如下：

再次写入同分区的数据：

insert into test_test(Id,YearMonth,DeviceType) values (2,202001,'D1-3');

zookeeper显示：

本地磁盘：

此时同分区的数据还未merge，官方文档提示merge将在接下来的十几分钟内完成，我们也可以手动执行：

OPTIMIZE TABLE test_test PARTITION 202001;

此时磁盘的显示：

zookeeper的显示：

不仅没有删除，还多了一个，我们通过查询语句：

select * from system.parts where table='test_test';

显示：

active中只有一个为活跃状态1，rows也为2，证明该数据块已经是merge后的，只是剩下的这两个暂时还没有被删除。

过个几分钟可以发现之前的数据块已经被删除，同时zookeeper也保持着最新的数据块状态：

查询在zookeeper中的存储

目前观察，在存储中还未发现有查询在zookeeper中的存储数据，在config.xml中有一个配置：

 <!-- Allow to execute distributed DDL queries (CREATE, DROP, ALTER, RENAME) on cluster.Works only if ZooKeeper is enabled. Comment it if such functionality isn't required. --><distributed_ddl><!-- Path in ZooKeeper to queue with DDL queries --><path>/clickhouse/task_queue/ddl</path><!-- Settings from this profile will be used to execute DDL queries --><!-- <profile>default</profile> --></distributed_ddl>

在上述的截图中也看到了这个目录：

我们来执行ddl的语句看下存储的内容：

drop table test_test on cluster 'cluster01';

这其中cluster01为我们集群的名字，在metrika.xml中配置，metrika.xml是通过config.xml中的<include_from>/etc/clickhouse-server/metrika.xml</include_from>导入的。

在ddl中显示出了我们的刚刚查询的语句，该语句会被分发到所有的节点执行，目前我们只有一个节点，该部分的数据也会随着执行语句的增多而增加。

其它的注意事项

若你的集群中有多个节点，会出现如下节点：

其中01-01为layer-shard，在具体的节点内，还有replica，该部分包含的节点互为副本，也即是zookeeper会将这些副本的数据进行同步。这些也跟我们的建表语句有关，不同的建表语句可能出现不同的目录。

<macros>
<layer>01</layer>
<shard>01</shard>
<replica>cluster01-01-01</replica>
</macros>

log文件夹中记录了每次insert的一些简单信息，该部分的数据也会随着数据块的增加而增多：

format version: 4
create_time: 2020-01-21 11:09:42
source replica: cluster01-01-01
block_id: 202001_18140686589791493295_2460127323285304296
get
202001_0_0_0

执行完OPTIMIZE的merge命令后，新增了一条log显示如下：

format version: 4
create_time: 2020-01-21 11:14:28
source replica: cluster01-01-01
block_id:
merge
202001_0_0_0
202001_1_1_0
202001_2_2_0
into
202001_0_2_1
deduplicate: 0

当merge完成后parts中当块数据会同样被删除，log文件不删除，会一直增加。若将表删除，则该表的所有记录都会从zookeeper中删除掉。

附录：clickhouse安装等实例教程：

https://blog.csdn.net/zhangpeterx/article/details/95091335

clickhouse分析：zookeeper数据存储相关推荐

爬虫mysql数据清洗_爬虫分析之数据存储——基于MySQL,Scrapy
配置MySql 关于MySQL在Ubuntu的Pycharm上的配置,可以参考这篇文章中的第三部分如果上面的步骤处理完毕后找不到你新建的数据库, 可以参照下图配置勾选要显示的Schemas(数据库 ...
Clickhouse的数据存储原理、二进制文件内容分析与索引详解
Clickhouse的数据存储原理.二进制文件内容分析与索引详解 Clickhouse以其强大的性能著称,已经被越来越多的使用在OLAP分析查询等场景中.Clickhouse是一个列式存储的数据库,而 ...
表格存储TableStore全新升级，打造统一的在线数据存储平台！
表格存储TableStore是阿里云自研的面向海量结构化和半结构化数据存储的Serverless NoSQL多模型数据库,被广泛用于社交.物联网.人工智能.元数据和大数据等业务场景.表格存储Table ...
Tablestore Timestream：为海量时序数据存储设计的全新数据模型...
引言随着近几年物联网的发展,时序数据迎来了一个不小的爆发.为了存储这些时序数据,各大企业纷纷推出自己的时序数据库. Tablestore作为阿里云自研的NoSQL多模型数据库,能够提供海量结构化数据 ...
ClickHouse数据库和数据表
文章目录 ClickHouse数据库和数据表大小写敏感数据库数据库操作 ClickHouse数据库引擎数据存储目录数据表数据表操作创建数据表复制表结构复制表结构和数据 ClickHo ...
布局数据存储，中国电子云意在何为？
数据存储市场的未来在哪里? 答案毋庸置疑是:云端.著名咨询机构Wikibon曾经做过一项统计,将全球三大云服务商的数据存储营收与传统存储厂商的营收进行对比,发现云服务商的数据存储业务规模已然赶上传统存 ...
以太坊EVM智能合约中的数据存储
目录 EVM基本信息数据管理 Stack Args Memory Storage 固定长度的值动态长度数组 Mappings 复杂类型的组合总结 EVM基本信息以太坊是一种基于栈的虚拟机,基于 ...
BigData NoSQL —— ApsaraDB HBase数据存储与分析平台概览
一.引言时间到了2019年,数据库也发展到了一个新的拐点,有三个明显的趋势: 越来越多的数据库会做云原生(CloudNative),会不断利用新的硬件及云本身的优势打造CloudNative数据库, ...
Spark Stream整合flum和kafka，数据存储在HBASE上，分析后存入数据库
开发环境:Hadoop+HBASE+Phoenix+flum+kafka+spark+MySQL 默认配置好了Hadoop的开发环境,并且已经安装好HBASE等组件. 下面通过一个简单的案例进行整合: ...

clickhouse分析：zookeeper数据存储

clickhouse分析：zookeeper数据存储相关推荐

最新文章

热门文章