如何对我的查询强制执行时间限制？

答案

您可以使用 max_execution_time 设置

clickhouse-cloud :) SELECT 1 SETTINGS max_execution_time=0.0001

SELECT 1
SETTINGS max_execution_time = 0.0001

Query id: 3db752a7-b94f-4456-b3b9-ccbf290d1394


0 rows in set. Elapsed: 0.113 sec.

Received exception from server (version 23.5.1):
Code: 159. DB::Exception: Received from service.aws.clickhouse.cloud:9440. DB::Exception: Timeout exceeded: elapsed 0.000557862 seconds, maximum: 0.0001. (TIMEOUT_EXCEEDED)

简短的回答是“是”。但是，我们建议将所有区域/数据中心之间的延迟保持在两位数范围内，否则写入性能会因经过分布式共识协议而下降。例如，美国海岸之间的复制可能会正常工作，但美国和欧洲之间的复制则不会。

在配置方面，与单区域复制相比没有区别，只需对副本使用位于不同位置的主机即可。

有关更多信息，请参阅 有关数据复制的完整文章。

如果您通过 Oracle ODBC 驱动程序使用 Oracle 作为 ClickHouse 外部字典的来源，您需要在 /etc/default/clickhouse 中为 NLS_LANG 环境变量设置正确的值。有关更多信息，请参阅 Oracle NLS_LANG 常见问题解答。

示例

NLS_LANG=RUSSIAN_RUSSIA.UTF8

列式数据库独立存储每列的数据。这样，您只需读取任何给定查询中使用的那些列的数据。成本在于影响整行的操作会成比例地变得更加昂贵。列式数据库的同义词是面向列的数据库管理系统。ClickHouse 是这种系统的典型例子。

列式数据库的主要优势是

• 仅使用少数几列（而非所有列）的查询。
• 针对大量数据的聚合查询。
• 面向列的数据压缩。

以下是构建报表时传统面向行的系统与列式数据库之间差异的说明

传统面向行

列式

列式数据库是分析应用程序的首选，因为它允许在表中包含许多列以备不时之需，但不会在读取查询执行时间（传统的 OLTP 数据库在查询期间读取所有数据，因为数据存储在行中，而不是列中）上为未使用的列支付成本。面向列的数据库专为大数据处理和数据仓库而设计，它们通常使用低成本硬件的分布式集群进行本机扩展以提高吞吐量。ClickHouse 通过结合 分布式 和 复制 表来实现这一点。

它是“Clickstream”和“Data wareHouse”的组合。它来自 Yandex.Metrica 的原始用例，ClickHouse 应该保留来自互联网上所有人的所有点击记录，它至今仍能完成这项任务。您可以在 ClickHouse 历史 页面上阅读有关此用例的更多信息。

这种双重含义有两个后果

• 书写 ClickHouse 的唯一正确方式是大写 H。
• 如果您需要缩写它，请使用 CH。出于一些历史原因，在国内（尤其是中国）使用 CK 缩写也很流行，主要是因为第一个关于 ClickHouse 的中文演讲使用了这种形式。

ClickHouse 是一个开源项目，在 GitHub 上开发。

按照惯例，贡献说明已发布在源代码仓库根目录下的CONTRIBUTING文件中。

如果您想建议对 ClickHouse 进行重大更改，请考虑创建一个 GitHub 问题，解释您想做什么，以便首先与维护者和社区进行讨论。此类 RFC 问题的示例。

如果您的贡献与安全相关，请查看我们的安全策略。

这只是一个简短的示例，用于说明如何使用JSONExtract 函数。

创建一个表

CREATE TABLE default.json_extract_example
(
    `rawJSON` String EPHEMERAL,
    `a1` String DEFAULT JSONExtractString(rawJSON, 'a1'),
    `a2` Boolean DEFAULT JSONExtractBool(rawJSON, 'a2'),
    `a3.aa1` Float DEFAULT JSONExtractFloat(JSONExtractRaw(rawJSON, 'a3'), 'aa1'),
    `a3.aa2` UInt8 DEFAULT JSONExtractUInt(JSONExtractRaw(rawJSON, 'a3'), 'aa2')
)
ENGINE = MergeTree
ORDER BY (a1, a2)

添加您的 JSON 原始字符串

INSERT INTO default.json_extract_example (rawJSON) VALUES ('{"a1": "XX", "a2": true, "a3":{"aa1":23.11,"aa2":12}}');

查询您的数据

SELECT *
FROM json_extract_example
FORMAT Pretty

结果

┏━━━━┳━━━━━━┳━━━━━━━━┳━━━━━━━━┓
┃ a1 ┃ a2   ┃ a3.aa1 ┃ a3.aa2 ┃
┡━━━━╇━━━━━━╇━━━━━━━━╇━━━━━━━━┩
│ XX │ true │  23.11 │     12 │
└────┴──────┴────────┴────────┘

每个都存储为原始 JSON 类型

SELECT
    toTypeName(a1),
    toTypeName(a2),
    toTypeName(a3.aa1),
    toTypeName(a3.aa2)
FROM default.json_extract_example
FORMAT Pretty

┏━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━┓
┃ toTypeName(a1) ┃ toTypeName(a2) ┃ toTypeName(a3.aa1) ┃ toTypeName(a3.aa2) ┃
┡━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━┩
│ String         │ Bool           │ Float32            │ UInt8              │
└────────────────┴────────────────┴────────────────────┴────────────────────┘

简短的答案是“否”。键值工作负载是不使用 ClickHouse 的情况列表中的前列。它毕竟是一个OLAP 系统，而市场上有很多优秀的键值存储系统。

但是，在某些情况下，使用 ClickHouse 进行类似键值的查询仍然有意义。通常，它是一些低成本产品，其主要工作负载本质上是分析性的，并且适合 ClickHouse，但还有一些辅助进程需要类似键值的模式，并且请求吞吐量不高且没有严格的延迟要求。如果您有无限的预算，您将为这个辅助工作负载安装一个辅助的键值数据库，但实际上，维护另一个存储系统（监控、备份等）会产生额外的成本，而这可能是值得避免的。

如果您决定违反建议并对 ClickHouse 运行一些类似键值的查询，以下是一些技巧

• ClickHouse 中点查询昂贵的主要原因是它对主 MergeTree 表引擎系列 的稀疏主索引。此索引不能指向数据的每个特定行，而是指向每第 N 行，系统必须从相邻的第 N 行扫描到所需的行，在此过程中读取过多数据。在键值场景中，通过 index_granularity 设置降低 N 的值可能很有用。
• ClickHouse 将每一列保存在一组单独的文件中，因此要组装一个完整的行，它需要遍历所有这些文件。它们的计数随着列数线性增加，因此在键值场景中，可能值得避免使用太多列，并将所有有效负载放在一个使用 JSON、Protobuf 或任何有意义的序列化格式编码的 String 列中。
• 有一种替代方法，使用Join 表引擎而不是普通的 MergeTree 表，并使用joinGet 函数检索数据。它可以提供更好的查询性能，但可能存在一些可用性和可靠性问题。这里有一个使用示例。

我们可以将 MapReduce 之类的系统称为分布式计算系统，其中 reduce 操作基于分布式排序。此类中最常见的开源解决方案是Apache Hadoop。

由于延迟高，这些系统不适合在线查询。换句话说，它们不能用作 Web 界面后端。这些类型的系统不适用于实时数据更新。如果操作结果和所有中间结果（如果有）都位于单个服务器的 RAM 中，那么分布式排序不是执行 reduce 操作的最佳方式，这种情况通常发生在线查询中。在这种情况下，哈希表是执行 reduce 操作的最佳方式。优化 map-reduce 任务的一种常见方法是使用 RAM 中的哈希表进行预聚合（部分 reduce）。用户手动执行此优化。分布式排序是运行简单的 map-reduce 任务时性能降低的主要原因之一。

大多数 MapReduce 实现允许您在集群上执行任意代码。但声明性查询语言更适合 OLAP，以便快速运行实验。例如，Hadoop 有 Hive 和 Pig。还可以考虑 Cloudera Impala 或 Shark（已过时）用于 Spark，以及 Spark SQL、Presto 和 Apache Drill。运行此类任务时的性能与专用系统相比非常低，但相对较高的延迟使得将这些系统用作 Web 界面后端变得不现实。

我们建议服务的最大数据库数为 1000 个，最大表数为 5000 个，最大分区数为 50000 个，最大部分数为 100000 个。ClickHouse 中的数据库更像是一个命名空间，对性能没有影响；1000 个数据库是一个宽松的指导方针。但是，表的数量会影响服务启动时间，因此我们建议限制表的数量或分区。如果达到这些阈值，ClickHouse 会发出警告。

这些限制也适用于 ClickHouse Cloud。