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