大数据-136 - ClickHouse 集群 表引擎详解1 - 日志、Log、Memory、Merge

简介: 大数据-136 - ClickHouse 集群 表引擎详解1 - 日志、Log、Memory、Merge

点一下关注吧!!!非常感谢!!持续更新!!!

目前已经更新到了:

Hadoop(已更完)

HDFS(已更完)

MapReduce(已更完)

Hive(已更完)

Flume(已更完)

Sqoop(已更完)

Zookeeper(已更完)

HBase(已更完)

Redis (已更完)

Kafka(已更完)

Spark(已更完)

Flink(已更完)

ClickHouse(正在更新···)

章节内容

上节我们完成了如下的内容:


测试连接集群

数据类型学习

整型 浮点型 Decimal 等等

简单介绍

表引擎(即表的类型)决定了:


数据的存储方式和位置,写到哪里以及从哪里读取数据

支持哪些查询以及如何支持

并发数据访问

索引的使用(如果存在)

是否可以执行多线程请求

数据复制参数

ClickHouse 是一个列式数据库管理系统,支持多种表引擎,每种表引擎都有其特定的功能和用途。以下是一些常用的 ClickHouse 表引擎:


MergeTree 系列

MergeTree:最常用的表引擎,支持高效的分区、排序、索引等功能,适合处理大量写入和查询场景。支持主键和索引。

ReplicatedMergeTree:基于 MergeTree,但增加了复制功能,适用于分布式集群环境。

ReplacingMergeTree:允许以最新的记录覆盖旧的记录,对于需要根据特定列去重的场景非常适用。

SummingMergeTree:支持对数值列的聚合,适用于需要进行聚合计算的场景。

AggregatingMergeTree:支持更加复杂的聚合操作,适合需要预计算汇总的场景。

CollapsingMergeTree:用于处理日志式数据,通过将 “begin” 和 “end” 记录合并,以减少存储空间。

VersionedCollapsingMergeTree:在 CollapsingMergeTree 基础上,增加了版本号,用于更好地控制数据合并。

Log 系列

Log:简单的表引擎,不支持索引和分区,适合小数据量或日志式的存储场景。

TinyLog:适合嵌入式场景或测试,性能更简单,不能处理大规模数据。

StripeLog:适合 SSD 场景,按行写入,但会将数据按块组织,适合某些特定读写模式。

Memory:数据只存储在内存中,适用于需要快速读写但不需要持久化的场景。

Distributed:在分布式集群中使用,将查询分发到多个节点,适合大规模数据和高并发查询场景。

Merge:将多个表作为一个虚拟表进行查询,适合需要联合多个表进行读取的场景。

Join:预加载并存储 Join 表,用于提高连接操作的效率。

View 系列

MaterializedView:物化视图,允许通过预计算来加速查询。

View:普通视图,不会存储数据,只是查询的定义。

Buffer:将数据暂时存储在内存中,并定期批量写入到基础表中,适合需要优化写入性能的场景。

Null:将数据写入时直接丢弃,适合测试场景。

日志

TinyLog

最简单的表引擎,用于将数据存储在磁盘上,每列都存储在单独的压缩文件上,写入时,数据将附加到文件末尾。该引擎没有并发控制。


如果同时从表中读取或者写入数据,则读取操作将抛出异常

如果同时写入多个查询中的表,则数据将被破坏

这种表的引擎的典型用法 write-once:首先只写入一次数据,然后根据需要多次读取。此引擎适用于相对较小的表(建议最多1,000,000行)。如果有许多小表,则使用此表引擎是适合的,因为它需要打开的文件更少,当拥有大量小表时,可能会导致性能低下,不支持索引。


测试1

创建一个TinyLog引擎的表并插入一条数据

CREATE table t (a UInt16, b String) ENGINE = TinyLog;
INSERT INTO t (a, b) VALUES (1, 'abc');

运行结果如下所示:

此时我们去保存数据的目录下查看:

cd /var/lib/clickhouse/data/default/t
ls

运行结果如下图:

文件列表的解释:

  • a.bin 和 b.bin 是压缩过的对应列的数据
  • sizes.json 中记录了 每个 bin 的大小

Log

Log 与 TinyLog 不同的是,标记的小文件与列文件存在一起,这些标记写在每个数据块上,并且包含偏移量,这些偏移量指示从哪里开始读取文件以便跳过指定的行数。这使得可以在多个线程中读取表数据,对于并发数据访问,可以同时执行读取操作,而写入操作则阻塞读取和其他写入。

Log引擎不支持索引。

同样,如果写入表事变,则该表会被破坏,并且从该表中读取将会返回错误。Log引擎适合于临时数据,write-once表以及测试或演示目的。


StripeLog

该引擎属于日志引擎系列,在你需要写入许多小数据量(小于100百万行)的表的场景下使用这个引擎。


写数据

StripeLog引擎将所有的列存储在一个文件中,对每一个INSERT请求,ClickHouse将数据块追加在表文件的末尾,逐列写入。

ClickHouse为每张表写入如下文件:


data.bin 数据文件

index.mrk 标记文件,标记包含了已插入的每个数据块中每列的偏移量。

StripeLog引擎不支持 ALTER、UPDATE、ALTER DELETE操作。


读数据

带标记文件使得ClickHouse可以并行的读取数据,这意味着SELECT请求返回行的顺序是不可预测的,使用ORDER BY子句对行进行排练。

新增表

CREATE TABLE stripe_log_table (
  timestamp DateTime,
  message_type String,
  message String
) ENGINE = StripeLog;

执行结果如下图所示:

插入数据

INSERT INTO stripe_log_table VALUES (now(), 'REGULAR', 'The first reqular message');
INSERT INTO stripe_log_table VALUES 
(now(), 'REGULAR', 'The second regular message'),
(now(), 'WARNING', 'The first warning message');

我们使用两次 INSERT 请求从而在 data.bin 文件中创建两个数据块。

查询数据

ClickHouse 在查询数据时使用多线程,每个线程读取单独的数据并在完成后独立的返回结果行,这样

的结果是,大多数情况下,输出中的块的顺序和输入时相应块的顺序是不同的,例如:

SELECT * FROM stripe_log_table;
# 对结果排序(默认增序)
SELECT * FROM stripe_log_table ORDER BY timestamp;

执行的结果如下图:

Memory

内存引擎,数据以未压缩的原始形式直接保存在内存中,服务器重启数据就会丢失。

读写操作不会互相阻塞,不支持索引。

简单查询下有非常高的性能表现:超过10G/s

一般用到的地方不多,除了用来测试,就是需要非常高的性能,但是数据量又不能太大(上限大概1亿行)的场景。


Merge

Merge引擎(不要与MergeTree搞混)本身不存储数据,但可以用于同时从任意多个其他的表中读取数据,读是自动并行的,不支持写入。

读取时,那些被真正读取到数据的表的引擎(如果有的话)会被使用。


Merge参数:


数据库名

匹配表名的正则表达式

创建新标

CREATE table t1 (id UInt16, name String) ENGINE = TinyLog;
CREATE table t2 (id UInt16, name String) ENGINE = TinyLog;
CREATE table t3 (id UInt16, name String) ENGINE = TinyLog;

执行结果如下图所示:

插入数据

INSERT INTO t1 (id, name) VALUES (1, 'first');
INSERT INTO t2 (id, name) VALUES (2, 'second');
INSERT INTO t3 (id, name) VALUES (3, 'i am in t3');

执行结果如下图:

建立链接

CREATE TABLE t (id UInt16, name String) ENGINE = Merge(currentDatabase(), '^t');

执行结果如下图所示:

相关实践学习
【涂鸦即艺术】基于云应用开发平台CAP部署AI实时生图绘板
【涂鸦即艺术】基于云应用开发平台CAP部署AI实时生图绘板
目录
相关文章
|
负载均衡 算法 关系型数据库
大数据大厂之MySQL数据库课程设计:揭秘MySQL集群架构负载均衡核心算法:从理论到Java代码实战,让你的数据库性能飙升!
本文聚焦 MySQL 集群架构中的负载均衡算法,阐述其重要性。详细介绍轮询、加权轮询、最少连接、加权最少连接、随机、源地址哈希等常用算法,分析各自优缺点及适用场景。并提供 Java 语言代码实现示例,助力直观理解。文章结构清晰,语言通俗易懂,对理解和应用负载均衡算法具有实用价值和参考价值。
大数据大厂之MySQL数据库课程设计:揭秘MySQL集群架构负载均衡核心算法:从理论到Java代码实战,让你的数据库性能飙升!
|
负载均衡 算法 关系型数据库
大数据新视界--大数据大厂之MySQL数据库课程设计:MySQL集群架构负载均衡故障排除与解决方案
本文深入探讨 MySQL 集群架构负载均衡的常见故障及排除方法。涵盖请求分配不均、节点无法响应、负载均衡器故障等现象,介绍多种负载均衡算法及故障排除步骤,包括检查负载均衡器状态、调整算法、诊断修复节点故障等。还阐述了预防措施与确保系统稳定性的方法,如定期监控维护、备份恢复策略、团队协作与知识管理等。为确保 MySQL 数据库系统高可用性提供全面指导。
zdl
|
消息中间件 运维 大数据
大数据实时计算产品的对比测评:实时计算Flink版 VS 自建Flink集群
本文介绍了实时计算Flink版与自建Flink集群的对比,涵盖部署成本、性能表现、易用性和企业级能力等方面。实时计算Flink版作为全托管服务,显著降低了运维成本,提供了强大的集成能力和弹性扩展,特别适合中小型团队和业务波动大的场景。文中还提出了改进建议,并探讨了与其他产品的联动可能性。总结指出,实时计算Flink版在简化运维、降低成本和提升易用性方面表现出色,是大数据实时计算的优选方案。
zdl
775 56
|
存储 数据采集 监控
阿里云DTS踩坑经验分享系列|SLS同步至ClickHouse集群
作为强大的日志服务引擎,SLS 积累了用户海量的数据。为了实现数据的自由流通,DTS 开发了以 SLS 为源的数据同步插件。目前,该插件已经支持将数据从 SLS 同步到 ClickHouse。通过这条高效的同步链路,客户不仅能够利用 SLS 卓越的数据采集和处理能力,还能够充分发挥 ClickHouse 在数据分析和查询性能方面的优势,帮助企业显著提高数据查询速度,同时有效降低存储成本,从而在数据驱动决策和资源优化配置上取得更大成效。
897 9
|
SQL 存储 大数据
单机顶集群的大数据技术来了
大数据时代,分布式数仓如MPP成为热门技术,但其高昂的成本让人望而却步。对于多数任务,数据量并未达到PB级,单体数据库即可胜任。然而,由于SQL语法的局限性和计算任务的复杂性,分布式解决方案显得更为必要。esProc SPL作为一种开源轻量级计算引擎,通过高效的算法和存储机制,实现了单机性能超越集群的效果,为低成本、高效能的数据处理提供了新选择。
|
存储 负载均衡 监控
揭秘 Elasticsearch 集群架构,解锁大数据处理神器
Elasticsearch 是一个强大的分布式搜索和分析引擎,广泛应用于大数据处理、实时搜索和分析。本文深入探讨了 Elasticsearch 集群的架构和特性,包括高可用性和负载均衡,以及主节点、数据节点、协调节点和 Ingest 节点的角色和功能。
905 0
|
存储 Prometheus 监控
构建高可用性ClickHouse集群:从理论到实践
【10月更文挑战第27天】在数据驱动的时代,构建一个稳定、高效的数据库系统对于企业的业务发展至关重要。作为一名数据工程师,我深知数据库系统的高可用性和可扩展性对于支撑企业应用的重要性。在这篇文章中,我将分享如何构建一个高可用性的ClickHouse集群,从分布式表的设计到数据复制与分片,再到故障恢复机制,确保系统在大规模数据处理中的稳定性和可靠性。
702 0
|
存储 监控 大数据
构建高可用性ClickHouse集群:从单节点到分布式
【10月更文挑战第26天】随着业务的不断增长,单一的数据存储解决方案可能无法满足日益增加的数据处理需求。在大数据时代,数据库的性能、可扩展性和稳定性成为企业关注的重点。ClickHouse 是一个用于联机分析处理(OLAP)的列式数据库管理系统(DBMS),以其卓越的查询性能和高吞吐量而闻名。本文将从我的个人角度出发,分享如何将单节点 ClickHouse 扩展为高可用性的分布式集群,以提升系统的稳定性和可靠性。
1604 0
|
监控 安全 Apache
什么是Apache日志?为什么Apache日志分析很重要?
Apache是全球广泛使用的Web服务器软件,支持超过30%的活跃网站。它通过接收和处理HTTP请求,与后端服务器通信,返回响应并记录日志,确保网页请求的快速准确处理。Apache日志分为访问日志和错误日志,对提升用户体验、保障安全及优化性能至关重要。EventLog Analyzer等工具可有效管理和分析这些日志,增强Web服务的安全性和可靠性。
600 9

推荐镜像

更多