ClickHouse 能否用作键值存储？

简短的回答是 **“否”**。键值工作负载是 ClickHouse **不**应使用的情况中的首要位置之一。它毕竟是一个 OLAP 系统，而市场上有很多优秀的键值存储系统。

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

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

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