ClickHouse 知识库 | ClickHouse 文档中文

如何使用字符串类型键和值创建字典

2023 年 7 月 10 日 ·阅读时间：1 分钟

问题

如何使用来自 MergeTree 表源的字符串键和字符串值创建 ClickHouse 字典

答案

为字典创建源表

CREATE TABLE db1.table1_dict_source
(
  id UInt32,
  email String,
  name String
)
ENGINE = MergeTree()
ORDER BY id;

插入行

INSERT INTO db1.table1_dict_source
(id, email, name)
VALUES
(1, '[email protected]', 'me'),
(2, '[email protected]', 'you');

创建键/值都为字符串的字典

CREATE DICTIONARY db1.table1_dict
(
    email String,
    name String
)
PRIMARY KEY email
SOURCE(
CLICKHOUSE(
TABLE 'table1_dict_source'
USER 'default'
PASSWORD 'ClickHouse123!'))
LAYOUT(COMPLEX_KEY_HASHED())
LIFETIME(MIN 0 MAX 1000);

测试字典

clickhouse-cloud :) SELECT * from db1.table1_dict;

SELECT *
FROM db1.table1_dict

Query id: 098396ce-11dd-4c71-a0e1-40723dd67ddc

┌─email──────────┬─name─┐
│ [email protected]  │ me   │
│ [email protected] │ you  │
└────────────────┴──────┘

2 rows in set. Elapsed: 0.001 sec. 

您也可以使用 dictGet 函数从字典中检索值，例如

SELECT dictGet('db1.table1_dict', 'name', '[email protected]');

响应

┌─dictGet('db1.table1_dict', 'name', '[email protected]')─┐
│ me                                                  │
└─────────────────────────────────────────────────────┘

官方 ClickHouse 构建与第三方构建之间有什么区别？

2023 年 6 月 26 日 ·阅读时间：2 分钟

问题

我看到其他供应商提供他们自己的 ClickHouse 构建。官方 ClickHouse 构建与这些第三方构建之间有什么区别？

答案

以下是一些我们观察到的与其他构建的区别

字符串 “官方” 被供应商的名称替换
它们在几个月后才出现，并且 不包含最新的错误修复，这意味着这些构建可能包含已在官方版本中修复的漏洞
构建并不完全相同，代码中的地址也不同。因此，无法分析来自这些构建的堆栈跟踪，ClickHouse 团队也无法回答有关这些构建的问题
构建不可审计或不可重现 - 没有公开可用的 CI 系统具有相同的构建日志
ClickHouse 测试套件没有在这些构建上运行，因此它们没有经过测试套件的验证
它们可能不适用于所有架构（例如 ARM 等）
有时它们会包含针对特定客户的补丁，这些补丁可能会破坏兼容性并带来额外的风险

我们建议按照文档中的安装说明使用官方构建运行 ClickHouse 的最新版本

我们每月发布一个 稳定版本，并且支持三个最新的稳定版本，包括诊断和错误修复的反向移植。
我们还每年发布两次 长期支持 (LTS) 版本，该版本在其首次发布后的一年内提供支持，实际上只适用于不允许频繁升级或使用非 LTS 软件的公司。（我们非常喜欢每月发布的稳定版本！）

我们在文档中详细介绍了稳定版本与 LTS 版本之间的区别。

如何检查查询缓存是否在查询中使用？

2023 年 6 月 7 日 ·阅读时间：7 分钟

查看使用 clickhouse 客户端和 ClickHouse Cloud 服务的示例。

创建一个 query_cache_test 表

使用 clickhouse 客户端

clickhouse-cloud :) CREATE TABLE query_cache_test (name String, age UInt8) ENGINE =MergeTree ORDER BY name

CREATE TABLE query_cache_test
(
    `name` String,
    `age` UInt8
)
ENGINE = MergeTree
ORDER BY name

Query id: 81c54f09-7de4-48ec-916f-c7c304a46931

Ok.

0 rows in set. Elapsed: 0.343 sec.

用一些数据填充表

clickhouse-cloud :) INSERT INTO query_cache_test SELECT * FROM generateRandom('name String, age UInt8',1,1) LIMIT 100000;

INSERT INTO query_cache_test SELECT *
FROM generateRandom('name String, age UInt8', 1, 1)
LIMIT 100000

Query id: 90369105-bd67-494c-bdaf-d90dbfb6def9

Ok.

0 rows in set. Elapsed: 0.173 sec. Processed 327.05 thousand rows, 3.43 MB (1.89 million rows/s., 19.86 MB/s.)

启用跟踪日志

clickhouse-cloud :) SET send_logs_level = 'trace'

SET send_logs_level = 'trace'

Query id: d65490b0-7960-4a85-a343-787e70e5e293

Ok.

0 rows in set. Elapsed: 0.134 sec.

运行一个查询，要求使用查询缓存（在查询中追加 SETTINGS use_query_cache=true）

clickhouse-cloud :) SELECT name FROM query_cache_test WHERE age > 1000 FORMAT Null SETTINGS use_query_cache=true;

SELECT name
FROM query_cache_test
WHERE age > 1000
FORMAT `Null`
SETTINGS use_query_cache = 1

Query id: 3754a7fd-b786-47c1-a258-dfbc75e35a04

[c-red-qc-36-server-0] 2023.05.29 12:06:10.542408 [ 454 ] {3754a7fd-b786-47c1-a258-dfbc75e35a04} \<Debug\> executeQuery: (from 151.53.3.113:50412, user: tony) SELECT name FROM query_cache_test  WHERE age > 1000 FORMAT Null SETTINGS use_query_cache=true; (stage: Complete)
[c-red-qc-36-server-0] 2023.05.29 12:06:10.542744 [ 454 ] {3754a7fd-b786-47c1-a258-dfbc75e35a04} \<Debug\> InterpreterSelectQuery: MergeTreeWhereOptimizer: condition "age > 1000" moved to PREWHERE
[c-red-qc-36-server-0] 2023.05.29 12:06:10.542900 [ 454 ] {3754a7fd-b786-47c1-a258-dfbc75e35a04} \<Debug\> InterpreterSelectQuery: MergeTreeWhereOptimizer: condition "age > 1000" moved to PREWHERE
[c-red-qc-36-server-0] 2023.05.29 12:06:10.543020 [ 454 ] {3754a7fd-b786-47c1-a258-dfbc75e35a04} \<Trace\> ContextAccess (tony): Access granted: SELECT(name, age) ON tony.test
[c-red-qc-36-server-0] 2023.05.29 12:06:10.543164 [ 454 ] {3754a7fd-b786-47c1-a258-dfbc75e35a04} \<Trace\> ContextAccess (tony): Access granted: SELECT(name, age) ON tony.test
[c-red-qc-36-server-0] 2023.05.29 12:06:10.543226 [ 454 ] {3754a7fd-b786-47c1-a258-dfbc75e35a04} \<Trace\> InterpreterSelectQuery: FetchColumns -> Complete
[c-red-qc-36-server-0] 2023.05.29 12:06:10.543337 [ 454 ] {3754a7fd-b786-47c1-a258-dfbc75e35a04} \<Debug\> tony.test (e61a107c-e7f8-4445-825f-88f85c72f7e9) (SelectExecutor): Key condition: unknown
[c-red-qc-36-server-0] 2023.05.29 12:06:10.543395 [ 454 ] {3754a7fd-b786-47c1-a258-dfbc75e35a04} \<Debug\> tony.test (e61a107c-e7f8-4445-825f-88f85c72f7e9) (SelectExecutor): Selected 1/1 parts by partition key, 1 parts by primary key, 12/12 marks by primary key, 12 marks to read from 1 ranges
[c-red-qc-36-server-0] 2023.05.29 12:06:10.543412 [ 454 ] {3754a7fd-b786-47c1-a258-dfbc75e35a04} \<Trace\> tony.test (e61a107c-e7f8-4445-825f-88f85c72f7e9) (SelectExecutor): Spreading mark ranges among streams (default reading)
[c-red-qc-36-server-0] 2023.05.29 12:06:10.543461 [ 454 ] {3754a7fd-b786-47c1-a258-dfbc75e35a04} \<Trace\> MergeTreeBaseSelectProcessor: PREWHERE condition was split into 1 steps: "greater(age, 1000)"
[c-red-qc-36-server-0] 2023.05.29 12:06:10.543484 [ 454 ] {3754a7fd-b786-47c1-a258-dfbc75e35a04} \<Trace\> MergeTreeInOrderSelectProcessor: Reading 1 ranges in order from part all_0_0_0, approx. 100000 rows starting from 0
[c-red-qc-36-server-0] 2023.05.29 12:06:10.543559 [ 454 ] {3754a7fd-b786-47c1-a258-dfbc75e35a04} \<Trace\> QueryCache: No entry found for query SELECT name FROM query_cache_test  WHERE age > 1000 FORMAT `Null` SETTINGS
[c-red-qc-36-server-0] 2023.05.29 12:06:10.547760 [ 454 ] {3754a7fd-b786-47c1-a258-dfbc75e35a04} \<Trace\> QueryCache: Stored result of query SELECT name FROM query_cache_test  WHERE age > 1000 FORMAT `Null` SETTINGS
[c-red-qc-36-server-0] 2023.05.29 12:06:10.547827 [ 454 ] {3754a7fd-b786-47c1-a258-dfbc75e35a04} \<Debug\> executeQuery: Read 100000 rows, 97.66 KiB in 0.005508 sec., 18155410.31227306 rows/sec., 17.31 MiB/sec.
[c-red-qc-36-server-0] 2023.05.29 12:06:10.547913 [ 454 ] {3754a7fd-b786-47c1-a258-dfbc75e35a04} \<Debug\> MemoryTracker: Peak memory usage (for query): 451.89 KiB.
[c-red-qc-36-server-0] 2023.05.29 12:06:10.547933 [ 454 ] {3754a7fd-b786-47c1-a258-dfbc75e35a04} \<Debug\> TCPHandler: Processed in 0.005911032 sec.
Ok.

0 rows in set. Elapsed: 0.006 sec. Processed 100.00 thousand rows, 100.00 KB (17.56 million rows/s., 17.56 MB/s.)

再次运行相同的查询

clickhouse-cloud :) SELECT name FROM query_cache_test WHERE age > 1000 FORMAT Null SETTINGS use_query_cache=true;

SELECT name
FROM query_cache_test
WHERE age > 1000
FORMAT `Null`
SETTINGS use_query_cache = 1

Query id: a047527c-9d55-4e6b-9747-0ccad8787515

[c-red-qc-36-server-0] 2023.05.29 12:06:17.931007 [ 454 ] {a047527c-9d55-4e6b-9747-0ccad8787515} \<Debug\> executeQuery: (from 151.53.3.113:50412, user: tony) SELECT name FROM query_cache_test  WHERE age > 1000 FORMAT Null SETTINGS use_query_cache=true; (stage: Complete)
[c-red-qc-36-server-0] 2023.05.29 12:06:17.931331 [ 454 ] {a047527c-9d55-4e6b-9747-0ccad8787515} \<Debug\> InterpreterSelectQuery: MergeTreeWhereOptimizer: condition "age > 1000" moved to PREWHERE
[c-red-qc-36-server-0] 2023.05.29 12:06:17.931468 [ 454 ] {a047527c-9d55-4e6b-9747-0ccad8787515} \<Debug\> InterpreterSelectQuery: MergeTreeWhereOptimizer: condition "age > 1000" moved to PREWHERE
[c-red-qc-36-server-0] 2023.05.29 12:06:17.931585 [ 454 ] {a047527c-9d55-4e6b-9747-0ccad8787515} \<Trace\> ContextAccess (tony): Access granted: SELECT(name, age) ON tony.test
[c-red-qc-36-server-0] 2023.05.29 12:06:17.931696 [ 454 ] {a047527c-9d55-4e6b-9747-0ccad8787515} \<Trace\> ContextAccess (tony): Access granted: SELECT(name, age) ON tony.test
[c-red-qc-36-server-0] 2023.05.29 12:06:17.931749 [ 454 ] {a047527c-9d55-4e6b-9747-0ccad8787515} \<Trace\> InterpreterSelectQuery: FetchColumns -> Complete
[c-red-qc-36-server-0] 2023.05.29 12:06:17.931857 [ 454 ] {a047527c-9d55-4e6b-9747-0ccad8787515} \<Debug\> tony.test (e61a107c-e7f8-4445-825f-88f85c72f7e9) (SelectExecutor): Key condition: unknown
[c-red-qc-36-server-0] 2023.05.29 12:06:17.931891 [ 454 ] {a047527c-9d55-4e6b-9747-0ccad8787515} \<Debug\> tony.test (e61a107c-e7f8-4445-825f-88f85c72f7e9) (SelectExecutor): Selected 1/1 parts by partition key, 1 parts by primary key, 12/12 marks by primary key, 12 marks to read from 1 ranges
[c-red-qc-36-server-0] 2023.05.29 12:06:17.931913 [ 454 ] {a047527c-9d55-4e6b-9747-0ccad8787515} \<Trace\> tony.test (e61a107c-e7f8-4445-825f-88f85c72f7e9) (SelectExecutor): Spreading mark ranges among streams (default reading)
[c-red-qc-36-server-0] 2023.05.29 12:06:17.931952 [ 454 ] {a047527c-9d55-4e6b-9747-0ccad8787515} \<Trace\> MergeTreeBaseSelectProcessor: PREWHERE condition was split into 1 steps: "greater(age, 1000)"
[c-red-qc-36-server-0] 2023.05.29 12:06:17.931975 [ 454 ] {a047527c-9d55-4e6b-9747-0ccad8787515} \<Trace\> MergeTreeInOrderSelectProcessor: Reading 1 ranges in order from part all_0_0_0, approx. 100000 rows starting from 0
[c-red-qc-36-server-0] 2023.05.29 12:06:17.932043 [ 454 ] {a047527c-9d55-4e6b-9747-0ccad8787515} \<Trace\> QueryCache: Entry found for query SELECT name FROM query_cache_test  WHERE age > 1000 FORMAT `Null` SETTINGS
[c-red-qc-36-server-0] 2023.05.29 12:06:17.932551 [ 454 ] {a047527c-9d55-4e6b-9747-0ccad8787515} \<Debug\> MemoryTracker: Peak memory usage (for query): 5.19 KiB.
[c-red-qc-36-server-0] 2023.05.29 12:06:17.932581 [ 454 ] {a047527c-9d55-4e6b-9747-0ccad8787515} \<Debug\> TCPHandler: Processed in 0.001961411 sec.
Ok.

0 rows in set. Elapsed: 0.002 sec.

现在观察 TRACE 日志中与 QueryCache 相关的差异，

第一次执行

[c-red-qc-36-server-0] 2023.05.29 12:06:10.543559 [ 454 ] {3754a7fd-b786-47c1-a258-dfbc75e35a04} \<Trace\> QueryCache: No entry found for query SELECT name FROM query_cache_test  WHERE age > 1000 FORMAT `Null` SETTINGS
[c-red-qc-36-server-0] 2023.05.29 12:06:10.547760 [ 454 ] {3754a7fd-b786-47c1-a258-dfbc75e35a04} \<Trace\> QueryCache: Stored result of query SELECT name FROM query_cache_test  WHERE age > 1000 FORMAT `Null` SETTINGS

在第二次执行时

[c-red-qc-36-server-0] 2023.05.29 12:06:17.932043 [ 454 ] {a047527c-9d55-4e6b-9747-0ccad8787515} \<Trace\> QueryCache: Entry found for query SELECT name FROM query_cache_test  WHERE age > 1000 FORMAT `Null` SETTINGS

在第一次执行中，显然没有找到条目 (No entry found for query SELECT...)，因此 ClickHouse 为我们存储了 (Stored result of query SELECT...) 该条目。

在第二次执行中，查询使用了查询缓存，因为它已经找到了已存储的条目 (Entry found for query SELECT...)。

仅使用 SQL

即使只通过发出 SQL 命令而不检查 clickhouse client 跟踪日志，

也可以通过检查相关的 system 表来验证是否使用了查询缓存。

clickhouse-cloud :) SELECT 1 SETTINGS use_query_cache=true;

SELECT 1
SETTINGS use_query_cache = 1

Query id: a5a078c7-61e5-4036-a6f0-4d602d5b72d2

┌─1─┐
│ 1 │
└───┘

1 row in set. Elapsed: 0.001 sec.

clickhouse-cloud :) SELECT 1 SETTINGS use_query_cache=true;

SELECT 1
SETTINGS use_query_cache = 1

Query id: 322ae001-b1ab-463f-ac8d-dc5ba346f3f9

┌─1─┐
│ 1 │
└───┘

1 row in set. Elapsed: 0.001 sec.

clickhouse-cloud :) SELECT * FROM clusterAllReplicas(default,system.query_cache);

SELECT *
FROM clusterAllReplicas(default, system.query_cache)

Query id: c9b57eac-ba64-430e-8d51-8f865a13cc25

┌─query──────────────┬─result_size─┬─stale─┬─shared─┬─compressed─┬──────────expires_at─┬─────────────key_hash─┐
│ SELECT 1 SETTINGS  │         136 │     0 │      1 │          1 │ 2023-08-02 15:08:23 │ 12188185624808016954 │
└────────────────────┴─────────────┴───────┴────────┴────────────┴─────────────────────┴──────────────────────┘

1 row in set. Elapsed: 0.005 sec.

clickhouse-cloud :) SELECT * FROM clusterAllReplicas(default,system.events) WHERE event LIKE 'QueryCache%'

SELECT *
FROM clusterAllReplicas(default, system.events)
WHERE event LIKE 'QueryCache%'

Query id: d536555e-b8ab-4cd4-9741-c04e95612bec

┌─event────────────┬─value─┬─description────────────────────────────────────────────────────────────────────────────────────────────┐
│ QueryCacheHits   │     1 │ Number of times a query result has been found in the query cache (and query computation was avoided).  │
│ QueryCacheMisses │     1 │ Number of times a query result has not been found in the query cache (and required query computation). │
└──────────────────┴───────┴────────────────────────────────────────────────────────────────────────────────────────────────────────┘

2 rows in set. Elapsed: 0.006 sec.

在最后的结果中，我们看到第一次执行查询 SELECT 1 SETTINGS use_query_cache=true; 时出现 1 次 QueryCacheMisses，以及与第二次执行查询相关的 QueryCacheHits 事件。

还要记住，默认的最大缓存条目大小为 1048576 字节（= 1 MiB），并且默认情况下结果仅在缓存中存储 60 秒（例如，您可以在 SETTINGS 中使用 query_cache_ttl=300 将查询缓存结果存储 5 分钟）。

您可以在此处找到有关 ClickHouse 查询缓存的更多详细信息。

如何在不返回任何行的情况下确定查询的处理时间

2023 年 6 月 7 日 ·阅读时间：1 分钟

问题

我的查询返回了许多行，但我只对查询处理时间感兴趣。如何省略查询输出并检查查询处理时间？

答案

将 FORMAT Null 附加到您的查询中，以将输出格式配置为 Null。这将阻止数据传输到客户端。

例如

SELECT
    customer_id,
    count() AS total,
    any(review_headline)
FROM amazon_reviews
GROUP BY customer_id
ORDER BY total DESC
FORMAT Null

响应将返回处理的行数和经过的时间，但不会返回任何行。

0 rows in set. Elapsed: 25.288 sec. Processed 222.04 million rows, 13.50 GB (8.78 million rows/s., 533.77 MB/s.)

如何使用 ClickHouse API 和 cURL 启动、停止和恢复云服务

2023 年 6 月 7 日 ·阅读时间：1 分钟

问题

如何使用 API 终结点启动、停止和恢复 ClickHouse 云服务？

答案

要从空闲状态唤醒/恢复云服务，您可以 ping 该实例。

curl -X GET https://abc123.us-west-2.aws.clickhouse.cloud:8443/ping

要停止云服务，请使用 /state 终结点以及 stop 命令。语法如下所示

curl -X PATCH https://api.clickhouse.cloud/v1/organizations/<org_uuid>/services/<service_uuid>/state -u <key_id>:<key_secret> -H "Content-Type: application/json" -d ''{"command": "<stop|start>"}''

例如，以下命令停止 2e2124ca-c5ac-459d-a6f2-abc123549d2a 服务

curl -X PATCH https://api.clickhouse.cloud/v1/organizations/123abcd0-e9b5-4f55-9e42-0fb04392445c/services/2e2124ca-c5ac-459d-a6f2-abc123549d2a/state -u abc123:ABC123 -H "Content-Type: application/json" -d '{"command": "stop"}'

输出如下所示

{"result":{"id":"2e2124ca-c5ac-459d-a6f2-abc123549d2a","name":"mars-s3","provider":"aws","regionId":"us-west-2","state":"stopping","endpoints":[{"protocol":"nativesecure","host":"abc123.us-west-2.aws.clickhouse.cloud","port":9440},{"protocol":"https","host":"abc123ntrb.us-west-2.aws.clickhouse.cloud","port":8443}],"tier":"production","idleScaling":true,"idleTimeoutMinutes":5,"minTotalMemoryGb":24,"maxTotalMemoryGb":48,"ipAccessList":[{"source":"[0.0.0.0/0](http://0.0.0.0/0)","description":"Anywhere"}],"createdAt":"2022-10-21T18:46:31Z"},"status":200}%

要再次启动服务，请使用 start 命令。

curl -X PATCH https://api.clickhouse.cloud/v1/organizations/123abcd0-e9b5-4f55-9e42-0fb04392445c/services/2e2124ca-c5ac-459d-a6f2-abc123549d2a/state -u abc123:ABC123 -H "Content-Type: application/json" -d '{"command": "start"}'

注意

以下是服务可能处于的各种状态

"state":"stopping"
"state":"stopped"
"state":"starting"
"state":"running"
"state":"idle"

注意

处于 “空闲” 状态的云服务被认为已启动，因此 start 命令不会恢复/唤醒它。使用步骤 1 中显示的 ping 终结点唤醒服务。

如何在 Docker 中配置 cap_ipc_lock 和 cap_sys_nice 功能

2023 年 6 月 7 日 ·阅读时间：2 分钟

问题

在 Docker 中运行 ClickHouse 时，Docker 正在抱怨系统中缺少 CAP_IPC_LOCK 和 CAP_SYS_NICE 功能。如何解决它？

以下是缺少 CAP_SYS_NICE 或 CAP_SYS_NICE 功能的日志消息的示例

docker run -d --name clickhouse-server \
    --ulimit nofile=262144:262144 \
    --network clickhouse-net \
    -p 8123:8123 -p 9000:9000 -p 9009:9009 -p 9363:9363 \
    clickhouse/clickhouse-server:23.2

04.19 08:04:10.022720 [ 1 ] {} <Information> Application: It looks like the process has no CAP_IPC_LOCK capability, binary mlock will be disabled. It could happen due to incorrect ClickHouse package installation. You could resolve the problem manually with 'sudo setcap cap_ipc_lock=+ep /usr/bin/clickhouse'. Note that it will not work on 'nosuid' mounted filesystems.

04.19 08:04:10.065860 [ 1 ] {} <Information> Application: It looks like the process has no CAP_SYS_NICE capability, the setting 'os_thread_priority' will have no effect. It could happen due to incorrect ClickHouse package installation. You could resolve the problem manually with 'sudo setcap cap_sys_nice=+ep /usr/bin/clickhouse'. Note that it will not work on 'nosuid' mounted filesystems.

答案

添加两个 --cap-add 参数，为容器提供 IPC_LOCK 和 SYS_NICE 功能。

docker run -d --name clickhouse-server \
   --cap-add=SYS_NICE \
   --cap-add=IPC_LOCK \
   --ulimit nofile=262144:262144 \
   --network clickhouse-net \
   -p 8123:8123 -p 9000:9000 -p 9009:9009 -p 9363:9363 \
   clickhouse/clickhouse-server:23.2

使用以下命令检查功能是否在容器中可见。

apt-get update > /dev/null && apt-get install -y libcap2-bin > /dev/null && capsh --print

响应类似于

debconf: delaying package configuration, since apt-utils is not installed
WARNING: libcap needs an update (cap=40 should have a name).
Current: = cap_chown,cap_dac_override,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_net_bind_service,cap_net_raw,cap_ipc_lock,cap_sys_chroot,cap_sys_nice,cap_mknod,cap_audit_write,cap_setfcap+ep
Bounding set =cap_chown,cap_dac_override,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_net_bind_service,cap_net_raw,cap_ipc_lock,cap_sys_chroot,cap_sys_nice,cap_mknod,cap_audit_write,cap_setfcap
Ambient set =
Securebits: 00/0x0/1'b0
 secure-noroot: no (unlocked)
 secure-no-suid-fixup: no (unlocked)
 secure-keep-caps: no (unlocked)
 secure-no-ambient-raise: no (unlocked)
uid=0(root) euid=0(root)
gid=0(root)
groups=0(root)
Guessed mode: UNCERTAIN (0)

手动为 ClickHouse 设置这两个功能。

setcap "cap_ipc_lock=+ep cap_sys_nice=+ep" /usr/bin/clickhouse

检查功能是否已应用。

getcap -v /usr/bin/clickhouse

您应该看到以下内容

/usr/bin/clickhouse = cap_ipc_lock,cap_sys_nice+ep

重新启动 ClickHouse 服务器，日志消息将不再显示。

有关更多详细信息，请查看有关 Linux 功能的这篇文章。

按内存使用量查看昂贵的查询

2023 年 6 月 7 日 ·阅读时间：2 分钟

以下有用的查询显示哪些执行的查询使用了最多的内存。关于此查询的一些评论

结果是从过去一天（now() - toIntervalDay(1))）计算的，但您可以轻松地修改时间间隔。
它假设您有一个名为 default 的集群，这是您在 ClickHouse Cloud 中的集群的名称。将 default 更改为您集群的名称。
如果您没有集群，请参见本文末尾列出的查询。

SELECT
    count() as nb_query,
    user,
    query,
    sum(memory_usage) AS memory,
    normalized_query_hash
FROM
    clusterAllReplicas(default, system.query_log)
WHERE
    (event_time >= (now() - toIntervalDay(1)))
    AND query_kind = 'Select'
    AND type = 'QueryFinish'
    and user != 'monitoring-internal'
GROUP BY
    normalized_query_hash,
    query,
    user
ORDER BY
    memory DESC;

响应如下所示

┌─nb_query─┬─user────┬─query─────────────────────────────────────────────────────────┬───memory─┬─normalized_query_hash─┐
│       11 │ default │ select version()                                              │ 46178924 │   7202516440347714159 │
│        2 │ default │ SELECT * FROM "system"."table_functions" LIMIT 31 OFFSET 0    │  8391544 │  12830067173062987695 │
└──────────┴─────────┴───────────────────────────────────────────────────────────────┴──────────┴───────────────────────┘

注意

如果您没有 system.query_log 表，那么您可能没有启用查询日志记录。查看有关 query_log 设置的详细信息，了解如何启用它。

如果您没有集群，可以使用以下命令直接查询您的一个 system.query_log 表。

SELECT
    count() as nb_query,
    user,
    query,
    sum(memory_usage) AS memory,
    normalized_query_hash
FROM
    system.query_log
WHERE
    (event_time >= (now() - toIntervalDay(1)))
    AND query_kind = 'Select'
    AND type = 'QueryFinish'
    and user != 'monitoring-internal'
GROUP BY
    normalized_query_hash,
    query,
    user
ORDER BY
    memory DESC;

ClickHouse 的自动模式迁移工具

2023 年 6 月 7 日 ·阅读时间：1 分钟

我们经常被问到关于 ClickHouse 的良好模式迁移工具，以及在 ClickHouse 中管理数据库模式的最佳实践是什么，这些模式可能会随着时间的推移而发生变化？ClickHouse 没有标准的模式迁移工具，但我们已经编制了以下列表（无特定顺序）的自动模式迁移工具，我们知道这些工具支持 ClickHouse。

Goose
Atlas
Bytebase
Flyway
Liquibase
一个名为 clickhouse-migrations 的简单的社区工具
另一个用 Go 编写的社区工具

如何查看活动或排队的变异数量？

2023 年 6 月 7 日 ·阅读时间：1 分钟

问题

如何查看活动或排队的变异数量？

答案

如果您对表执行大量 ALTER 或 UPDATE 语句，监控活动或排队的突变数量非常重要。这些查询会重写数据部分，并且不是原子的——它们按创建部分的顺序排序，并按此顺序应用于每个部分。您可以在文档中找到有关突变的更多详细信息。

每个突变都会在 system.mutations 表中生成一个条目。当执行大量突变时，您可以使用以下命令监控运行和排队的突变计数。

SELECT
   hostname() AS host,
   count()
   FROM clusterAllReplicas('default', 'system.mutations') WHERE not is_done
   GROUP BY host;

注意

此查询假设您正在运行一个名为 default 的集群，这是您在 ClickHouse Cloud 中的集群的名称。将 default 替换为您的集群的名称。

如果您没有集群，请使用以下命令

SELECT
   hostname() AS host,
   count()
   FROM system.mutations WHERE not is_done
   GROUP BY host;

我们还建议您阅读这篇关于更新和删除的最新博客。

为什么推荐使用 ClickHouse Keeper 而不是 ZooKeeper？

2023 年 6 月 7 日 ·阅读时间：2 分钟

ClickHouse Keeper 为数据复制和分布式 DDL 查询执行提供协调系统。ClickHouse Keeper 与 ZooKeeper 兼容，但您可能不了解为什么要使用 ClickHouse Keeper 而不是 ZooKeeper。本文讨论了 Keeper 的一些优势。

答案

ClickHouse Cloud 在大规模多租户环境中为数千项服务使用 clickhouse-keeper。我们设计并构建了 Keeper，以便我们可以消除对基于 Java 的 ZooKeeper 实现的依赖。ClickHouse Keeper 解决了许多 ZooKeeper 的众所周知的缺点，并做出了额外的改进，包括

快照和日志由于更好的压缩而占用更少的磁盘空间
对默认数据包和节点数据大小没有限制（在 ZooKeeper 中为 1 MB）
没有 zxid 溢出问题（它迫使 ZooKeeper 每 2B 次事务重新启动一次）
由于使用更好的分布式共识协议，网络分区后的恢复速度更快
它为相同的数据量使用更少的内存
它更容易设置，并且不需要指定 JVM 堆大小或自定义垃圾收集实现
协议中的几个自定义命令可以在 ReplicatedMergeTree 表中实现更快的操作
Jepsen 测试覆盖范围更大

此外，ClickHouse 支持团队观察到，在使用 clickhouse-keeper 而不是 ZooKeeper 的站点中，集群问题大幅减少。

有关如何配置和运行 ClickHouse Keeper 的更多详细信息，请查看 Keeper 文档页面。

问题​

答案​

问题​

答案​

使用 clickhouse 客户端​

仅使用 SQL​

问题​

答案​

问题​

答案​

问题​

答案​

问题​

答案​

答案​

问题

答案

问题

答案

使用 clickhouse 客户端

仅使用 SQL

问题

答案

问题

答案

问题

答案

问题

答案

答案