ClickHouse性能调优——压缩和编码算法

这篇具有很好参考价值的文章主要介绍了ClickHouse性能调优——压缩和编码算法。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

随着数据库数据越来越多,给数据存储、网络访问造成成本和负担。压缩技术节约存储空间、加速网络访问的常用解决方案,本文主要介绍压缩算法和ClickHouse编码技术。

压缩类型

ClickHouse协议支持LZ4和ZSTD 压缩算法,两者都是基于字典使用校验和的压缩算法,LZ4较快、但压缩率比ZSTD较低。你可以选择合适算法,缺省为LZ4,当不确定选择哪种算法时建议使用LZ4。对于MergeTree引擎表,数据压缩设置可以在config.xml文件中设置:

<?xml version="1.0" ?>
<clickhouse>
  <compression incl="clickhouse_compression">
    <case>
      <min_part_size>104857600</min_part_size>
      <min_part_size_ratio>0.01</min_part_size_ratio>
      <method>zstd</method>
      <level>3</level>
    </case>
  </compression>
</clickhouse>

我们可以查看表的压缩率,对比压缩效果:这里使用Cell Towers数据集,包括43百万数据。相同数据使用不同压缩算法,对比结果如下:

Table Name Compressed Table Size(GB) Uncompressed Table Size(GB) Compression Ratio
cell_towers_LZ4 1,07 2,06 1,92
cell_towers_zstd 0,84 2,06 2,45

现在让我们看下每列压缩率,下表使用LZ4压缩算法,基数和数据类型是影响压缩比的主要因素。

┌─Column Name───┬─Column Type─┬─compressed─┬─uncompressed─┬─Compression Ratio─┬─compression_codec─┐
│ changeable    │ UInt8       │ 188.32 KiB │ 41.27 MiB    │            224.41 │                   │
│ averageSignal │ UInt8       │ 188.32 KiB │ 41.27 MiB    │            224.41 │                   │
│ radio         │ Enum8(''    │ 188.38 KiB │ 41.27 MiB    │            224.35 │                   │
│ mcc           │ UInt16      │ 384.88 KiB │ 82.54 MiB    │            219.61 │                   │
│ net           │ UInt16      │ 410.99 KiB │ 82.54 MiB    │            205.66 │                   │
│ unit          │ Int16       │ 2.12 MiB   │ 82.54 MiB    │             38.86 │                   │
│ range         │ UInt32      │ 48.27 MiB  │ 165.09 MiB   │              3.42 │                   │
│ samples       │ UInt32      │ 77.14 MiB  │ 165.09 MiB   │              2.14 │                   │
│ created       │ DateTime    │ 87.37 MiB  │ 165.09 MiB   │              1.89 │                   │
│ cell          │ UInt64      │ 178.76 MiB │ 330.17 MiB   │              1.85 │                   │
│ area          │ UInt16      │ 48.29 MiB  │ 82.54 MiB    │              1.71 │                   │
│ lat           │ Float64     │ 259.85 MiB │ 330.17 MiB   │              1.27 │                   │
│ lon           │ Float64     │ 261.98 MiB │ 330.17 MiB   │              1.26 │                   │
│ updated       │ DateTime    │ 130.71 MiB │ 165.09 MiB   │              1.26 │                   │
└───────────────┴─────────────┴────────────┴──────────────┴───────────────────┴───────────────────┘

使用ZSTD压缩压缩率如下表,压缩效果明显优于LZ4:

┌─Column Name───┬─Column Type─┬─compressed─┬─uncompressed─┬─Compression Ratio─┬─compression_codec─┐
│ changeable    │ UInt8       │ 29.05 KiB  │ 41.27 MiB    │           1454.95 │                   │
│ averageSignal │ UInt8       │ 29.05 KiB  │ 41.27 MiB    │           1454.95 │                   │
│ radio         │ Enum8(''    │ 29.08 KiB  │ 41.27 MiB    │           1453.44 │                   │
│ mcc           │ UInt16      │ 62.84 KiB  │ 82.54 MiB    │           1344.98 │                   │
│ net           │ UInt16      │ 80.79 KiB  │ 82.54 MiB    │           1046.21 │                   │
│ unit          │ Int16       │ 1.19 MiB   │ 82.54 MiB    │             69.18 │                   │
│ samples       │ UInt32      │ 31.46 MiB  │ 165.09 MiB   │              5.25 │                   │
│ range         │ UInt32      │ 31.51 MiB  │ 165.09 MiB   │              5.24 │                   │
│ cell          │ UInt64      │ 113.25 MiB │ 330.17 MiB   │              2.92 │                   │
│ created       │ DateTime    │ 70.06 MiB  │ 165.09 MiB   │              2.36 │                   │
│ area          │ UInt16      │ 38.65 MiB  │ 82.54 MiB    │              2.14 │                   │
│ lat           │ Float64     │ 225.17 MiB │ 330.17 MiB   │              1.47 │                   │
│ lon           │ Float64     │ 229.93 MiB │ 330.17 MiB   │              1.44 │                   │
│ updated       │ DateTime    │ 119.08 MiB │ 165.09 MiB   │              1.39 │                   │
└───────────────┴─────────────┴────────────┴──────────────┴───────────────────┴───────────────────┘

列压缩编码

在ClickHouse中,还可以在支持的表引擎中压缩单个列。支持压缩的表引擎如下表所示:

Table Engine Column Compression Default Compression
Merge Tree Family Yes Yes, Change with “compression” settings
Log Family Yes Yes, only LZ4 by default
Set No Yes, only default compression
Join No Yes, only default compression

可以在创建表语句或修改列中使用CODEC关键字定义列的压缩方法。

CREATE TABLE <database>.<table>
(
    column1 DateTime CODEC(<Codec>),
    .
    .
    .
)
ENGINE = <EngineType>
. . .


--------------------------------

ALTER TABLE <database>.<table> MODIFY COLUMN column1 CODEC(<Codec>);

ClickHouse支持通用目的编码和特定编码,通用编解码器更像默认编解码器(LZ4, ZTSD)及其修改版本。特定编解码器是为了利用数据的特定特征使压缩更有效而设计的。

通用编码

  • NONE : No Compression.
  • LZ4 : Applies LZ4 fast compression.
  • LZ4HC[(level)] : LZ4 HC (high compression) algorithm with configurable level.
  • ZSTD[(level)] : ZSTD compression algorithm with configurable level.

特定编码算法

​ 这些编解码器旨在通过使用数据的特定特征使压缩更有效。有些编解码器本身不压缩数据。相反,它们为通用的编解码器准备数据,编解码器比不准备编解码器更好地压缩数据。

  • Delta : This approach stores the difference between 2 neighbor values. It can be combined with LZ4 and ZSTD.
  • DoubleDelta : This approach stores the difference between 2 neighbor delta values (delta of deltas). Suitable for time series data.
  • Gorilla : Calculates XOR between current and previous value. Suitable for slowly changing floating numbers.
  • T64 : It crops unused high bits of values in integer data types(include Enum, Date, DateTime) and puts them into a 64×64 bit matrix.
  • FPC : Used in floating point values. XOR between the actual value and the predicted value.

我选择不同类型列,对比不同编码的压缩率。首先时ENUM8(radio列的数据类型),共有五个值,统计如下:

┌──count()─┬─radio─┐
│      867 │ NR    │
│   556344 │ CDMA  │
│  9931312 │ GSM   │
│ 12101148 │ LTE   │
│ 20686487 │ UMTS  │
└──────────┴───────┘

不同压缩率对比图如下。显然ZSTD性能好于其他。

ClickHouse性能调优——压缩和编码算法

再看看Uint16(area字段类型),该字段基数为57512,压缩率对比图如下:

ClickHouse性能调优——压缩和编码算法

最后是Datetime(updated字段类型),该列有1千7百万缓慢变化时间序列数据。使用DoubleDelta和zstd组合性能最好。
ClickHouse性能调优——压缩和编码算法

总结

本文主要介绍了ClickHouse的压缩类型及编码方法,并测试数据进行压缩率对比分析。根据分析结果,压缩率不仅和压缩算法和编码相关,也和数据类型,基数,数据特征有关。简单总结如下:

ClickHouse性能调优——压缩和编码算法

参考资料:

ClickHouse Compression Algorithms - ClickHouse Performance (chistadata.com)文章来源地址https://www.toymoban.com/news/detail-466150.html

到了这里,关于ClickHouse性能调优——压缩和编码算法的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

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

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

相关文章

  • clickhouse调优配置

    clickhouse的配置项主要在 config.xml 或 users.xml 中, 基本上都在 users.xml 里 config.xml https://clickhouse.tech/docs/en/operations/server-configuration-parameters/settings/ users.xml https://clickhouse.tech/docs/en/operations/settings/settings/ 时间字段 使用DateTime类型,不要用字符串,clickhouse底层将DateTIme存为时间戳

    2024年02月09日
    浏览(42)
  • 如何让ES低成本、高性能?滴滴落地ZSTD压缩算法的实践分享

    前文分别介绍了滴滴自研的ES强一致性多活是如何实现的、以及如何提升ES的性能潜力。由于滴滴ES日志场景每天写入量在5PB-10PB量级,写入压力和业务成本压力大,为了提升ES的写入性能,我们让ES支持ZSTD压缩算法,本篇文章详细展开滴滴在落地ZSTD压缩算法上的思考和实践。

    2024年02月13日
    浏览(50)
  • 【云计算与大数据技术】数据编码LZSS算法、Snappy压缩库及分布式通信系统的讲解(图文解释 超详细)

    数据编码概述 - 在分布式系统中需要处理大量的网络数据,为了加快网络数据的传输速度,通常需 要对传输数据进行编码压缩 数据压缩是以尽可能少的数码来表示信源所发出的信号,减少容纳给定的消息集合或数据采样集合的信号空间,这里讲的信号空间就是被压缩的对象,是

    2024年02月16日
    浏览(114)
  • IDEA调优-四大基础配置-编码纵享丝滑

    1.JVM虚拟机选项配置 1.-Xms128m: 设置 JVM 初始堆栈大小为 128MB。 初始堆栈大小用于存储线程运行时的局部变量和方法调用栈。 较小的初始堆栈可以减少内存占用,但可能导致频繁的垃圾回收。 较大的初始堆栈可以减少垃圾回收的频率,但可能导致内存浪费。 2. -Xmx8192m: 设置

    2024年03月26日
    浏览(42)
  • Mysql中如果建立了索引,索引所占的空间随着数据量增长而变大,这样无论写入还是查询,性能都会有所下降,怎么处理?

    索引所占空间的增长确实会对MySQL数据库的写入性能和查询性能造成影响,这主要是由于索引数据过多时会导致磁盘I/O操作变得非常频繁,从而使性能下降。为此,可以采取以下几种方式来减缓这种影响:   1. 限制索引的大小:可以考虑为索引指定大小限制,在存储时仅存储

    2023年04月23日
    浏览(52)
  • Spark(30):Spark性能调优之常规性能调优

    目录 0. 相关文章链接 1. 最优资源配置 2. RDD优化 2.1. RDD复用 2.2. RDD持久化 2.3. RDD尽可能早的 filter 操作 3. 并行度调节 4. 广播大变量 5. Kryo序列化 6. 调节本地化等待时长  Spark文章汇总          Spark 性能调优的第一步,就是为任务分配更多的资源,在一定范围内,增

    2024年02月16日
    浏览(60)
  • 视频编码压缩基础

    视频编码基础 视频图像的质量评价 采用有损压缩的技术能显著降低码率,但是也会降低视频图像的质量,因此对于有损压缩算法,需要建立一套评价准则,对编码质量进行评价。 可以分为 主观质量 和 客观质量评价 客观质量评价方法 1.均方误差(mean square error,MSE) 原始参考帧

    2024年02月12日
    浏览(32)
  • ES 性能调优,这可能是全网最详细的 Elasticsearch 性能调优指南

    性能调优是一件大而细的活儿。技术开发没有银弹,也就是本质上是没有所谓可应对任何场景的通用\\\"最优配置\\\"的。如果有,那么出厂何必不直接给出呢?所以理解每一项优化配置的含义很重。在当前情况下为最优配置,但是换一种场景就未必了。 废话不多说,直接上干货!

    2024年02月03日
    浏览(56)
  • Go性能调优及相关工具使用(四)——性能调优工具pprof的使用

    本堂课的知识要点有哪些? 1、性能发现工具pprof 2、性能调优案例 1、性能调优简介 性能调优原则: 要依靠数据不是猜测 要 定位最大瓶颈 而不是细枝末节 不要过早优化 不要过度优化 2、性能发现工具pprof 说明: 1、希望知道应用在什么地方耗费了多少CPU、Memory 2、pprof是用于

    2024年02月08日
    浏览(44)
  • openGauss学习笔记-271 openGauss性能调优-TPCC性能调优测试指导-测试MOT-TPCC性能

    本章节主要介绍openGauss数据库内核基于鲲鹏服务器和openEuler操作系统,为了达到最佳TPMC性能所依赖的关键系统级调优。 271.1 TPC-C简介 TPC-C基准是衡量联机事务处理(OLTP)系统性能的行业标准基准。它基于一个复杂的数据库和许多不同的事务类型。这些事务类型在此基准上执

    2024年04月26日
    浏览(42)

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

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

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

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

二维码1

领取红包

二维码2

领红包