ClickHouse多级磁盘和冷热数据分离实践

这篇具有很好参考价值的文章主要介绍了ClickHouse多级磁盘和冷热数据分离实践。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

特别注意

  • ck可以大小写区分也可以不区分
  • ck 配置文件中的各个卷的是有顺序的。
开启远程访问

 vim /etc/clickhouse-server/config.xml

<listen_host>0.0.0.0</listen_host>

前言

ClickHouse 的冷热数据分离和ES的类似,可以选择冷数据跑在哪个数据目录上。

总的来说 ClickHouse 冷热存储架构的整体设计思想是:本地 SSD 存储查询热数据,远端Nas存储查询相对不那么频繁的数据,从而节约存储成本,支持更多的数据存储需求。

操作命令
-- 查看存储策略
select * from system.storage_policies

-- 查看磁盘
 select * from system.disks
官网文档
## ttl值
https://ClickHouse.com/docs/en/engines/table-engines/mergetree-family/mergetree#mergetree-table-ttl
参考文档
###  多级磁盘
https://blog.csdn.net/weixin_37692493/article/details/114118400

### 
https://blog.csdn.net/SmartCodeTech/article/details/127513358

### 不错
https://blog.csdn.net/weixin_47388410/article/details/120885690


线上配置

    <storage_configuration>
        <disks>
            <disk0>
                <path>/opt/data/clickhouse/</path>
                <keep_free_space_bytes>1024000000</keep_free_space_bytes>
            </disk0>
            <fast_ssd>
                <path>/opt/data/clickhouse_fast/</path>
                <keep_free_space_bytes>1024000000</keep_free_space_bytes>
            </fast_ssd>
        </disks>

        <policies>
            <single>
                <volumes>
                    <single>
                        <disk>disk0</disk>
                    </single>
                </volumes>
            </single>

            <moving_from_ssd_to_hdd>
                <volumes>
                    <hot>
                        <disk>fast_ssd</disk>
                        <max_data_part_size_bytes>1073741824</max_data_part_size_bytes>
                    </hot>
                    <cold>
                        <disk>disk0</disk>
                    </cold>
                </volumes>
                <move_factor>0.2</move_factor>
            </moving_from_ssd_to_hdd>
        </policies>
        
    </storage_configuration>
示例:
<!-- 为了便于查找,我们建议在默认的存储路径下方添加存储策略 -->
<path>/data1/ClickHouse/data/</path> 
    <storage_configuration>
            <disks>
                <hot>
                <!-- 这里注意,使用存储策略后,建议任何数据路径之间不要有子集关系 -->
                    <path>/data1/ClickHouse/hot/</path>  
                </hot>
                <cold>
                    <path>/data2/ClickHouse/cold/</path>
                </cold>
            </disks>
            <policies>
                <ttl>
                    <volumes>
                        <hot>
                           <disk>hot</disk>
                        </hot>
                        <cold>
                           <disk>cold</disk>
                        </cold>
                    </volumes>
                </ttl>
            </policies>
    </storage_configuration>
语法格式
  • < path> 为ClickHouse默认的存储路径,找到该标签后在下方添加存储策略标签<storage_configuration>。
  • <storage_configuration>:固定标签,定义存储策略。
  • < dicks> 固定标签,下面会定义磁盘名称,以及磁盘绝对路径。
  • < hot>、< cold>:自定义标签,用来标记该路径,可按照此名称定义便于区分。
  • < policies>:固定标签,定义具体存储策略名称。
  • < ttl>:自定义标签,定义具体存储策略的名称,用于表级TTL,可按照此名称定义便于区分。
  • < volumes>:固定标签,定义卷组。
  • < hot>、< cold>:卷组名称,每个卷组下可以包括一个或多个disk标签,disk标签取值为< disks >标签下定义的磁盘名称。
检查
vm-01 :) select * from system.storage_policies;

SELECT *
FROM system.storage_policies

┌─policy_name────────────┬─volume_name─┬─volume_priority─┬─disks────────┬─volume_type─┬─max_data_part_size─┬─move_factor─┐
│ default                │ default     │               1 │ ['default']  │ JBOD        │                  0 │           0 │
│ moving_from_ssd_to_hdd │ hot         │               1 │ ['fast_ssd'] │ JBOD        │         1073741824 │         0.2 │
│ moving_from_ssd_to_hdd │ cold        │               2 │ ['disk0']    │ JBOD        │                  0 │         0.2 │
│ single                 │ single      │               1 │ ['disk0']    │ JBOD        │                  0 │         0.1 │
└────────────────────────┴─────────────┴─────────────────┴──────────────┴─────────────┴────────────────────┴─────────────┘

4 rows in set. Elapsed: 0.008 sec. 

vm-01 :)  select * from system.disks;

SELECT *
FROM system.disks

┌─name─────┬─path───────────────────────┬──free_space─┬─total_space─┬─keep_free_space─┬─type──┐
│ default  │ /var/lib/clickhouse/       │ 10822782976 │ 18238930944 │               0 │ local │
│ disk0    │ /opt/data/clickhouse/      │  9798782976 │ 17214930944 │      1024000000 │ local │
│ fast_ssd │ /opt/data/clickhouse_fast/ │  9798782976 │ 17214930944 │      1024000000 │ local │
└──────────┴────────────────────────────┴─────────────┴─────────────┴─────────────────┴───────┘

3 rows in set. Elapsed: 0.002 sec. 

-- 切换库
vm-01 :) use default;

--  检查
show create table t1;
创建表
-- 创建表

> create table t1(`id` Int32,`name` String) engine=MergeTree() order by id settings storage_policy='moving_from_ssd_to_hdd';



--  检查
SELECT name, data_paths, metadata_path, storage_policy from system.tables where name in ('t1','t2','t3')
模拟写入
-- 
insert into t1 values(1,'aa'),(2,'bb'),(3,'cc');

-- check
tree /opt/data/clickhouse_fast/
tree /opt/data/clickhouse/
查看表数据和分区存储信息
--  查看表数据和分区存储信息,可以看到按照分区将数据写入到了不同的磁盘目录下
SELECT name, data_paths, metadata_path, storage_policy from system.tables where name ='t1'

--  查看分区存储信息
select name, disk_name, path from system.parts where table = 't1';



多磁盘数据迁移

手动模拟分区合并

手动模拟分区合并,分区合并会自动将其他磁盘目录下数据进行合并,并存储在其中某一磁盘下

-- 
optimize table t1;

-- 
select name, disk_name, path from system.parts where table = 't1' and active;
多磁盘分区迁移
##
ALTER TABLE t1 MOVE PART 'all_2_2_0' TO VOLUME 'cold'

## 
vm-01 :) select name, disk_name, path from system.parts where table = 't1' and active;

SELECT 
    name,
    disk_name,
    path
FROM system.parts
WHERE (table = 't1') AND active

┌─name──────┬─disk_name─┬─path─────────────────────────────────────────────────┐
│ all_1_1_0 │ fast_ssd  │ /opt/data/clickhouse_fast/data/default/t1/all_1_1_0/ │
│ all_2_2_0 │ fast_ssd  │ /opt/data/clickhouse_fast/data/default/t1/all_2_2_0/ │
└───────────┴───────────┴──────────────────────────────────────────────────────┘

2 rows in set. Elapsed: 0.010 sec. 

vm-01 :) select * from system.storage_policies;

SELECT *
FROM system.storage_policies

┌─policy_name────────────┬─volume_name─┬─volume_priority─┬─disks────────┬─volume_type─┬─max_data_part_size─┬─move_factor─┐
│ default                │ default     │               1 │ ['default']  │ JBOD        │                  0 │           0 │
│ moving_from_ssd_to_hdd │ hot         │               1 │ ['fast_ssd'] │ JBOD        │         1073741824 │         0.2 │
│ moving_from_ssd_to_hdd │ cold        │               2 │ ['disk0']    │ JBOD        │                  0 │         0.2 │
│ single                 │ single      │               1 │ ['disk0']    │ JBOD        │                  0 │         0.1 │
└────────────────────────┴─────────────┴─────────────────┴──────────────┴─────────────┴────────────────────┴─────────────┘

4 rows in set. Elapsed: 0.006 sec. 

vm-01 :) ALTER TABLE t1 MOVE PART 'all_2_2_0' TO VOLUME 'cold'

ALTER TABLE t1
    MOVE PART 'all_2_2_0' TO VOLUME 'cold'


Ok.

0 rows in set. Elapsed: 0.005 sec. 

vm-01 :) select name, disk_name, path from system.parts where table = 't1' and active;

SELECT 
    name,
    disk_name,
    path
FROM system.parts
WHERE (table = 't1') AND active

┌─name──────┬─disk_name─┬─path─────────────────────────────────────────────────┐
│ all_1_1_0 │ fast_ssd  │ /opt/data/clickhouse_fast/data/default/t1/all_1_1_0/ │
│ all_2_2_0 │ disk0     │ /opt/data/clickhouse/data/default/t1/all_2_2_0/      │
└───────────┴───────────┴──────────────────────────────────────────────────────┘

2 rows in set. Elapsed: 0.003 sec. 

策略下沉并应用

通过设置表的TTL值将表的历史的数据下沉到 moving_from_ssd_to_hdd 冷标签(历史元的存储盘)中。

新创建的表将冷数据迁移到 moving_from_ssd_to_hdd 标签磁盘中。
-- 创建新表并应用某个存储策略
create table t1(`id` Int32,`name` String) engine=MergeTree() order by id settings storage_policy='moving_from_ssd_to_hdd';


-- 修改表的 TTL
ALTER TABLE example_table MODIFY TTL d + INTERVAL 1 DAY ;

修改原有的表应用某个存储策略
-- 查看storage_policies
SELECT 
    policy_name,
    volume_name,
    volume_priority,
    disks,
    formatReadableSize(max_data_part_size) AS max_data_part_size,
    move_factor
FROM system.storage_policies

-- 修改原有的表应用相应的存储策略
alter table  test02 modify setting storage_policy='moving_from_ssd_to_hdd';

冷热数据分离

上面说的磁盘多级磁盘的配置,修改表的存储策略,可以应用到不同的磁盘中。如果通过表的TTL值,自动去对历史数据分到网络存储盘。新数据到本地磁盘了?

基于move factor的数据移动策略
vm-01 :)  select * from system.storage_policies;

SELECT *
FROM system.storage_policies

┌─policy_name────────────┬─volume_name─┬─volume_priority─┬─disks────────┬─volume_type─┬─max_data_part_size─┬─move_factor─┐
│ default                │ default     │               1 │ ['default']  │ JBOD        │                  0 │           0 │
│ moving_from_ssd_to_hdd │ hot         │               1 │ ['fast_ssd'] │ JBOD        │         1073741824 │         0.2 │
│ moving_from_ssd_to_hdd │ cold        │               2 │ ['disk0']    │ JBOD        │                  0 │         0.2 │
│ single                 │ single      │               1 │ ['disk0']    │ JBOD        │                  0 │         0.1 │
└────────────────────────┴─────────────┴─────────────────┴──────────────┴─────────────┴────────────────────┴─────────────┘

4 rows in set. Elapsed: 0.004 sec. 

vm-01 :) select * from system.disks;

SELECT *
FROM system.disks

┌─name─────┬─path───────────────────────┬──free_space─┬─total_space─┬─keep_free_space─┬─type──┐
│ default  │ /var/lib/clickhouse/       │ 10813464576 │ 18238930944 │               0 │ local │
│ disk0    │ /opt/data/clickhouse/      │  9789464576 │ 17214930944 │      1024000000 │ local │
│ fast_ssd │ /opt/data/clickhouse_fast/ │  9789464576 │ 17214930944 │      1024000000 │ local │
└──────────┴────────────────────────────┴─────────────┴─────────────┴─────────────────┴───────┘

3 rows in set. Elapsed: 0.005 sec. 

在上面的例子中,我们配置了一个存储策略:

  • 包含了2个卷(volume)。数据默认写入到default磁盘。
  • move factor 设置为0.2。当default磁盘空间小于20%时,将数据迁移到磁盘data2。
  • 默认卷max_data_part_size_bytes设置为xx G,大于xx G的part数据,不会写入到默认卷。

注意: 配置文件中的各个卷的顺序非常重要。当CK有新数据写入的时候,数据会优先写到第一个卷。再依次写道后面的卷。move_factor 也是从前面的卷移动到后面的卷。

## 以上参考文章如下
https://yunche.pro/blog/?id=64

基于TTL的数据移动策略
-- 创建时指定 TTL
CREATE TABLE ttl_test_tbl
(
    `f1` String,
    `f2` String,
    `f3` Int64,
    `f4` Float64,
    `date` Date
)
ENGINE = MergeTree()
PARTITION BY date
ORDER BY f1
TTL date + INTERVAL 90 DAY TO DISK 'disk0'
SETTINGS storage_policy = 'moving_from_ssd_to_hdd';


-- 修改表的 TTL
ALTER TABLE example_table
    MODIFY TTL d + INTERVAL 1 DAY ;
检查
vm-01 :) show tables;

SHOW TABLES

┌─name─────────┐
│ enum         │
│ student      │
│ tt           │
│ ttl_test_tbl │
└──────────────┘

4 rows in set. Elapsed: 0.005 sec. 

vm-01 :) desc ttl_test_tbl;

DESCRIBE TABLE ttl_test_tbl

┌─name─┬─type────┬─default_type─┬─default_expression─┬─comment─┬─codec_expression─┬─ttl_expression─┐
│ f1   │ String  │              │                    │         │                  │                │
│ f2   │ String  │              │                    │         │                  │                │
│ f3   │ Int64   │              │                    │         │                  │                │
│ f4   │ Float64 │              │                    │         │                  │                │
│ date │ Date    │              │                    │         │                  │                │
└──────┴─────────┴──────────────┴────────────────────┴─────────┴──────────────────┴────────────────┘

5 rows in set. Elapsed: 0.002 sec. 

vm-01 :) show create table ttl_test_tbl;

SHOW CREATE TABLE ttl_test_tbl

┌─statement──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ CREATE TABLE db_devops.ttl_test_tbl
(
    `f1` String,
    `f2` String,
    `f3` Int64,
    `f4` Float64,
    `date` Date
)
ENGINE = MergeTree()
PARTITION BY date
ORDER BY f1
TTL date + toIntervalDay(90) TO DISK 'disk0'
SETTINGS storage_policy = 'moving_from_ssd_to_hdd', index_granularity = 8192 │
└────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘

1 rows in set. Elapsed: 0.002 sec. 

参考文档:

## 腾讯云
https://cloud.tencent.com/document/product/1299/63662

修改已有的表的存储策略实践

vm-01 :) alter table  knight modify setting storage_policy='moving_from_ssd_to_hdd';

ALTER TABLE knight
    MODIFY SETTING storage_policy = 'moving_from_ssd_to_hdd'



Received exception from server (version 20.8.3):
Code: 36. DB::Exception: Received from 127.0.0.1:9000. DB::Exception: New storage policy shall contain volumes of old one. 

0 rows in set. Elapsed: 0.004 sec. 

报错需要修改如下:

报错的意思是 新的存储策略需要包含旧的磁盘卷。文章来源地址https://www.toymoban.com/news/detail-695776.html

            <moving_from_ssd_to_hdd>
                <volumes>
                 <!-- 增加的部分 -->
                  <default>
                      <disk>default</disk>
                  </default>

                  </default>

                    <hot>
                        <disk>fast_ssd</disk>
                        <max_data_part_size_bytes>1073741824</max_data_part_size_bytes>
                    </hot>

                    <cold>
                        <disk>disk0</disk>
                    </cold>
                </volumes>
                <move_factor>0.2</move_factor>
            </moving_from_ssd_to_hdd>

到了这里,关于ClickHouse多级磁盘和冷热数据分离实践的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 万字长文详述ClickHouse在京喜达实时数据的探索与实践

    京喜达技术部在社区团购场景下采用JDQ+Flink+Elasticsearch架构来打造实时数据报表。随着业务的发展 Elasticsearch开始暴露出一些弊端,不适合大批量的数据查询,高频次深度分页导出导致ES宕机、不能精确去重统计,多个字段聚合计算时性能下降明显。所以引入ClickHouse来处理这些

    2024年02月06日
    浏览(36)
  • Clickhouse存算分离的思考

    Exploring storage and computing separation for ClickHouse - JuiceFS Blog ClickHouse 存算分离改造:小红书自研云原生数据仓库实践 唯品会翻牌ClickHouse后,实现百亿级数据自助分析_语言 开发_dbaplus社群_InfoQ精选文章 在思考如何实现存算分离,感觉可以像JuiceFS利用多盘存储隔离资源。 但是还有

    2024年02月07日
    浏览(35)
  • 【clickhouse笔记】 查询表或列的磁盘占用大小

    通过系统表 system.parts 我们可以查询MergeTree表的磁盘占用信息,而通过 system_part_columns 表可以查询具体字段的磁盘占用信息 示例:以下SQL 查询所有表的 磁盘压缩大小 和 原始未压缩磁盘占用、压缩比等信息 示例:以下SQL 查询所有表的所有字段的磁盘压缩大小 和 原始未压缩磁盘

    2024年02月21日
    浏览(53)
  • 数据库不应放在容器中?- B站Kubernetes有状态服务实践(Elasticsearch/Clickhouse)

    云原生时代下, Kubernetes已成为容器技术的事实标准, 使得基础设施领域应用下自动化运维管理与编排成为可能。对于无状态服务而言, 业界早已落地数套成熟且较完美的解决方案。可对于有状态的服务, 方案的复杂度就以几何倍数增长, 例如分布式应用多个实例间的依

    2024年03月18日
    浏览(55)
  • 数据库调优--冷热分离

    目录 业务场景: 数据库分区技术: 数据库分区的优点: 缺点: 冷热分离的简介: 热数据 冷数据 冷热分离 什么情况下我们可以使用冷热分离: 冷热分离的实现思路: 一、冷热数据都用mysql         需要考虑的问题: 二、冷数据存放到hbase Hbase: 什么是非关系型数据库

    2024年02月11日
    浏览(43)
  • ClickHouse主键索引最佳实践

    在本文中,我们将深入研究ClickHouse索引。我们将对此进行详细说明和讨论: ClickHouse的索引与传统的关系数据库有何不同 ClickHouse是怎样构建和使用主键稀疏索引的 ClickHouse索引的最佳实践 这篇文章主要关注稀疏索引,clickhouse主键使用的就是稀疏索引。 在本文中,我们将使用

    2024年02月01日
    浏览(38)
  • PySpark预计算ClickHouse Bitmap实践

    ClickHouse全称是Click Stream,Data WareHouse,是一款高性能的OLAP数据库,既使用了ROLAP模型,又拥有着比肩MOLAP的性能。我们可以用ClickHouse用来做分析平台快速出数。其中的bitmap结构方便我们对人群进行交并。Bitmap位图的每一位表示一个数据(比如说一个用户)。假设5亿用户(一个

    2024年04月17日
    浏览(106)
  • 【clickhouse实践】clickhouse如何在查询中对某字段空值设置默认值及对Nullable值的处理

    在ClickHouse中,我们可以使用一些函数来处理可空性(nullable)列。可空列是指允许包含空值(null)的列。在处理可空列时,我们需要考虑如何处理这些空值。以下是几个常用的ClickHouse函数,用于处理可空性列。 IFNULL 函数用于将一个可空性列中的空值替换为指定的默认值。它

    2024年02月12日
    浏览(40)
  • B站基于Clickhouse的下一代日志体系建设实践

    01 背景介绍 日志作为线上定位问题排障的重要手段,在可观测领域有着不可替代的作用。 稳定性、成本、易用性、可扩展性都是日志系统需要追求的关键点。 B站基于Elastic Stack的日志系统(Billions) 从2017建设以来, 已经服务了超过5年,目前规模超过500台机器,每日写入日

    2024年02月05日
    浏览(77)
  • 【数据库】详解数据库架构优化思路(两主架构、主从复制、冷热分离)

    对数据库架构进行优化是为了提高数据库系统的性能、可扩展性、稳定性和可维护性。MySQL官方说:单表2000万数据,性能就达到瓶颈了,为了保证查询效率需要让每张表的大小得到控制。 再来说,为什么要提高查询效率呢? 除了普通的用户查询操作,增、删、改操作都包含

    2024年02月11日
    浏览(43)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包