clickhouse
前言最近一直在搞监控方面的事情，随着监控数据越来越多，之前使用的influxdb感觉有点要扛不住的感觉，查询时间范围选择稍长，查询速度就变得特别慢。正好发现了clickhouse数据库，测试后觉得不错，目前监控已经全面切换至clickhouse，今天就来简单分享下clickhouse如何实现多磁盘存储，实现冷热数据分离。
Clickhouse简介ClickHouse是一款OLAP的数据库产品，由俄罗斯yandex公司开发，专为在线数据分析而设计，能够使用SQL查询生成实时数据报告，在2016年开源。
ClickHouse足够轻量，不依赖Hadoop生态。ClickHouse有如下特点：
真正的面向列的DBMS数据高效压缩磁盘存储的数据多核并行处理在多个服务器上进行分布式处理SQL语法支持向量化引擎实时数据更新索引适合在线查询支持近似预估计算支持嵌套的数据结构支持数组作为数据类型支持限制查询复杂性以及配额复制数据复制和对数据完整性的支持详情参考官方文档：/
Clickhouse多磁盘存储策略
clickhouse storage
在Clickhouse 19.15版本之前，MergeTree 只支持单路径存储，所有的数据都会被写入config.xml配置中path指定的路径下，即使服务器挂载了多块磁盘，也无法有效利用这些存储空间。
为了解决这种问题 在19.15版本开始支持MergeTree自定义存储策略的功能，支持以数据分区为最小移动单元将分区目录写入多块磁盘目录。
根据配置策略的不同，目前大致有三类存储策略：
1.默认策略（default）：MergeTree原本的存储策略，无须任何配置，所有分区会自动保存到config.xml 配置中的path指定的路径。
1.JBOD策略：这种策略适用于服务器挂载了多块磁盘，但是没有RAID的场景。JBOD （Just a Bunch Of Disks），是一种Round-robin 轮询策略，每执行一次INSERT或者Merge 所产生的新分区会轮询写入各个磁盘。这种策略的效果类似于RAID 0，可以降低单块磁盘的负载，在一定条件下能增加数据并行读写的性能。若单块磁盘发生故障，则会丢掉应用JBOD策略写入的这部分数据。
3.HOT/COLD策略：（冷热分离）这种策略适合服务器挂载了不同类型磁盘的场景。将存储磁盘分为HOT和COLD。
HOT使用SSD，注重性能；
COLD区域使用HDD这类高容量存储媒介，注重存取的经济性。
数据在写入的MergeTree之初，首先会在HOT区域创建分区目录保存数据，当分区数据大小达到阈值数据会自动移动到COLD区域。
而在每个区域的内部也支持定义多个磁盘，所以在单个区域写入的过程，也能使用JBOD策略。
Clickhouse多磁盘存储配置Clickhouse安装也非常简单，本文不做概述，官方文档已经写得很详细了。
磁盘、卷和存储策略应当在主配置文件 config.xml 或 config.d 目录中的独立文件中的 <storage_configuration> 标签内定义。
disk配置示例：
<storage_configuration> <disks> <disk_name_1> <!-- disk name --> <path>/mnt/fast_ssd/clickhouse/</path> </disk_name_1> <disk_name_2> <path>/mnt/hdd1/clickhouse/</path> <keep_free_space_bytes>10485760</keep_free_space_bytes> </disk_name_2> <disk_name_3> <path>/mnt/hdd2/clickhouse/</path> <keep_free_space_bytes>10485760</keep_free_space_bytes> </disk_name_3> ... </disks> ...</storage_configuration>示例解释：
<disk_name_*> 必填项，必须全局唯一，表示磁盘的自定义名称
<path> 必填项，服务器将用来存储数据 (data 和 shadow 目录) 的路径, 应当以 ‘/’ 结尾
<keep_free_space_bytes> 选填项，用于指定指定磁盘的预留空间，单位字节bit
注意：磁盘的配置选项的先后顺序没有关系。
在policies 的配置中，需要引用先前定义的disks磁盘。policies 同样支持定义多个策略。
存储策略配置：
<storage_configuration> ... <policies> <hdd_in_order> <!-- policy name --> <volumes> <single> <!-- volume name --> <disk>disk1</disk> <disk>disk2</disk> </single> </volumes> </hdd_in_order> <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>disk1</disk> </cold> </volumes> <move_factor>0.2</move_factor> </moving_from_ssd_to_hdd> </policies> ...</storage_configuration>示例解释：
<hdd_in_order>必填项，必须全局唯一，表示策略的自定义名称
<volume_name_x>必填项，必须全局唯一，表示卷的自定义名称
<disk> 必填项，用于关联<disks>配置内的磁盘，可以声明多个disk，MergeTree会按照定义的顺序选择disk
<max_data_part_size_bytes> 选填，字节为单位 默认1G，表示在这个卷的单个disk磁盘中，一个数据分区的最大磁盘存储阈值，若当前分区的数据大小超过阈值，则之后的分区会写入下一个disk磁盘。
<move_factor> 选填项，默认值为0.1,；若当前卷的可用空间大小小于factor因子，并且定义多个卷，则数据会自动移动到下一个卷。
在示例中，hdd_in_order 策略实现了 循环制 方法。因此这个策略只定义了一个卷（single），数据片段会以循环的顺序全部存储到它的磁盘上。当有多个类似的磁盘挂载到系统上，但没有配置 RAID 时，这种策略非常有用。
如果在系统中有不同类型的磁盘可用，可以使用 moving_from_ssd_to_hdd。hot 卷由 SSD 磁盘（fast_ssd）组成，这个卷上可以存储的数据片段的最大大小为 1GB。所有大于 1GB 的数据片段都会被直接存储到 cold 卷上，cold 卷包含一个名为 disk1 的 HDD 磁盘。
同样，一旦 fast_ssd 被填充超过 80%，数据会通过后台进程向 disk1 进行转移。
创建数据表，将配置的策略应用到表即可：
CREATE TABLE table_with_non_default_policy ( EventDate Date, OrderID UInt64, BannerID UInt64, SearchPhrase String) ENGINE = MergeTreeORDER BY (OrderID, BannerID)PARTITION BY toYYYYMM(EventDate)SETTINGS storage_policy = 'moving_from_ssd_to_hdd'default 存储策略意味着只使用一个卷，这个卷只包含一个在 <path> 中定义的磁盘。表创建后，它的存储策略就不能改变了。
后记本文简单介绍了Clickhouse多磁盘存储的策略以及简单的配置。由于磁盘价格比较贵，笔者公司其实没有挂多快盘来进行存储，而是使用了oss以及s3来进行冷数据存储的，下一篇我将来详细介绍下clickhouse如何将冷数据存储到oss和s3上。
