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