ClickHouse DBA 的 SQL
会话
数据库使用的第一个概述是当前和活动连接的列表。从操作系统看，连接到数据库的会话是不可见的，因为 ClickHouse 对每个连接只使用一个进程和一个线程。所以 DBA 需要一条 SQL 语句！
以下是获取数据库中活动会话列表的方法：
SHOW PROCESSLIST;
SELECT query_id, user, address, elapsed, query FROM system.processes ORDER BY query_id;第一个命令是最简单的命令，非常类似于 MySQL 命令。第二个 SQL 命令允许您放置额外的 WHERE 条件并对结果进行排序。这两个命令仅提取当前正在运行的查询，而不是与服务器的所有连接。
为了得到总连接数，查询是：
SELECT * FROM system.metrics WHERE metric LIKE '%Connection';此查询返回不同类型的连接数，而不是先前查询的列表。
有经验的 DBA 应该注意到最后两个查询使用了系统数据库。它是 DBA 最重要的数据库，因为它包含许多 ClickHouse 内部的视图。
锁
好消息——ClickHouse 没有锁！好吧，至少没有用户可见的锁。
ClickHouse 异步执行 INSERT：MergeTree Engine 收集数据并将其插入到稍后在后台合并的部分中。一旦 INSERT 完成，新数据立即对查询可见。UPDATE 和 DELETE 不是 ClickHouse 中的 DML 子句。这种特殊行为使锁不频繁且短暂。
无论如何，仍然可能有长时间运行的查询。这些可以使用上述 SHOW PROCESSLIST 命令检查，并且可以使用 KILL 命令中断：
SHOW PROCESSLIST;
KILL QUERY WHERE query_id='query_id';ClickHouse UPDATE 和 DELETE 命令是 DDL。它们被称为突变并异步执行。无法回滚突变，但如果其中一些挂起，则可以中断它们。命令与前面的命令类似：
SELECT * FROM system.mutations;
KILL MUTATION mutation_id = 'trx_id';重要说明：在杀死进程之前，确保您知道自己在做什么很重要！
磁盘空间使用
ClickHouse 磁盘空间管理非常重要。典型的数据仓库数据库非常大。即使 ClickHouse 使用复杂的数据压缩算法，对于 ClickHouse DBA 来说，密切关注占用和空闲的磁盘空间也很重要。
让我们从数据库中的已用空间开始：
SELECT database, table, partition, name part_name, active, bytes_on_disk FROM system.parts ORDER BY database, table, partition, name;前面的查询非常详细，因为它报告了每个 Part、Partition、Table 等，但是您可以使用 GROUP BY 按数据库、按表或按分区获取汇总值。例如，以下查询显示数据库的磁盘使用情况：
SELECT database, sum(bytes_on_disk) FROM system.parts GROUP BY database;Altinity 的注意事项：对于多磁盘配置，查看特定磁盘或卷的已用空间也很有用：SELECT * FROM system.disks
在数据输入期间，部件不会立即通过合并步骤合并到分区中。要强制合并，可以使用以下命令：
OPTIMIZE TABLE table [PARTITION partition] [FINAL]压缩因子非常重要，并且对于每一列都是不同的。这是检查每列空间使用情况的查询：
SELECT database, table, column, any(type),
sum(column_data_compressed_bytes) compressed,
sum(column_data_uncompressed_bytes) uncompressed,
uncompressed/compressed ratio,
compressed/sum(rows) bpr,
sum(rows)
FROM system.parts_columns
WHERE active AND database <> 'system'
GROUP BY database, table, column
ORDER BY database, table, column;性能
性能优化是每个 DBA 最喜欢的工作。
默认情况下，CH 不会跟踪执行的查询，但可以通过在会话级别或 users.xml 配置文件中设置参数log_queries = 1来实现。我强烈建议启用它。
Here's how to discover the longest running queries:SELECT user,
client_hostname AS host,
client_name AS client,
formatDateTime(query_start_time, '%T') AS started,
query_duration_ms / 1000 AS sec,
round(memory_usage / 1048576) AS MEM_MB,
result_rows AS RES_CNT,
round(result_bytes / 1048576, 6) AS RES_MB,
read_rows AS R_CNT,
round(read_bytes / 1048576) AS R_MB,
written_rows AS W_CNT,
round(written_bytes / 1048576) AS W_MB,
query
FROM system.query_log
WHERE type = 2
ORDER BY query_duration_ms DESC LIMIT 10一旦确定了长时间运行的查询，您就可以开始优化它们。主要技术是：正确选择 ORDER BY 列、编解码器和编码。请参阅Altinity 网络研讨会了解更多详情。
一个特别有用的性能特性是物化视图，它允许您定义数据的替代视图。物化视图可以整合数据或以不同的方式对其进行排序。分析最繁重和最经常出现的查询可以让您解决物化视图的设计问题。
如果您使用最新的 ClickHouse 版本（20.3.x），它会将日志存储在 system.metric_log 表中，这允许您使用 SQL 进入操作系统级别的数据：
SELECT toStartOfMinute(event_time) AS time,
sum(ProfileEvent_UserTimeMicroseconds) AS user_time,
bar(user_time, 0, 60000000, 80) AS bar
FROM system.metric_log
WHERE event_date = today()
GROUP BY time ORDER BY time;注意“bar”功能——数百个很酷的 ClickHouse 功能之一！
复制
可以在集群中配置更多连接的 ClickHouse 节点。
ClickHouse 集群允许复制以实现 HA（高可用性）和并发访问以及分片以实现分布式查询和高 INSERT 吞吐量。配置非常灵活，因为可以为单个表定义复制和分片。
ClickHouse 复制是异步的和多主机的（在内部它使用 ZooKeeper 进行 Quorum）。它的主要目标是 HA，但如果出现问题……以下是检查可能发生的各种“坏”事情的方法：
SELECT database,
table,
is_leader,
total_replicas,
active_replicas
FROM system.replicas
WHERE is_readonly
OR is_session_expired
OR future_parts > 20
OR parts_to_check > 10
OR queue_size > 20
OR inserts_in_queue > 10
OR log_max_index - log_pointer > 10
OR total_replicas < 2
OR active_replicas < total_replicas;
浙公网安备 33010602011771号