我可以使用 ClickHouse 作为键值存储吗？

简短的回答是 **“否”**。键值工作负载在 **不** 应该使用 ClickHouse 的案例列表中名列前茅。

简短的回答是“否”

简短的回答是 “否”。键值工作负载在 不 应该使用 ClickHouse 的案例列表中名列前茅。毕竟它是一个 OLAP 系统，而市面上有很多优秀的键值存储系统。

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

如果您决定违反建议，并针对 ClickHouse 运行一些类似键值查询的操作，以下是一些提示

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