我能将 ClickHouse 用作键值存储吗？
简短的答案是 **“不可以”**。键值工作负载位于不适合使用 ClickHouse 的案例列表的前列。
简短的答案是“不能”
简短的答案是 “不能”。键值型工作负载位于不应使用 ClickHouse 的案例列表中靠前的位置。毕竟，它是一个 OLAP 系统，而市面上有很多优秀的键值存储系统。
然而，在某些情况下，使用 ClickHouse 进行类似键值查询仍然有意义。通常，这适用于主要工作负载是分析性质且适合 ClickHouse 的低成本产品，但也存在一些需要键值模式、请求吞吐量不高且对延迟要求不严格的辅助过程。如果预算无限，您会为这个辅助工作负载安装一个单独的键值数据库，但在现实中，维护另一个存储系统（监控、备份等）会增加额外的成本，这可能是不希望避免的。
如果您决定违背建议，并对 ClickHouse 运行一些类似键值查询，这里有一些技巧
- 点查询在 ClickHouse 中代价高昂的主要原因是其主 MergeTree 表引擎系列 的稀疏主索引。该索引无法指向数据的每个特定行，而是指向每 N 行，系统必须从相邻的 N 行扫描到所需行，沿途读取过多的数据。在键值场景中，使用
index_granularity设置减小 N 的值可能很有用。 - ClickHouse 将每个列保存在单独的文件集中，因此要组装一行完整的行，它需要遍历这些文件中的每一个。它们的数量随着列的数量线性增加，因此在键值场景中，避免使用许多列并将所有有效负载放在单个
String列中（以 JSON、Protobuf 或其他有意义的序列化格式编码）可能是值得的。 - 另一种方法是使用 Join 表引擎代替普通的
MergeTree表，并使用 joinGet 函数来检索数据。它可以提供更好的查询性能，但可能存在一些可用性和可靠性问题。这里有一个 用法示例。
·2 分钟阅读
