ClickHouse をキー・バリューストレージとして使えますか？

短く答えると 「いいえ」 です。キー・バリューのワークロードは、ClickHouse を 使うべきではない ケースの上位に入ります。結局のところ、これは OLAP システムであり、世の中には優れたキー・バリューストレージシステムが数多く存在します。ただし、キー・バリュー的なクエリに ClickHouse を使うことに意味がある場合もあります。通常は、主なワークロードが分析中心で ClickHouse によく適している低予算のプロダクトで、加えて、リクエストのスループットがそれほど高くなく、厳しいレイテンシ要件もないキー・バリューパターンを必要とする副次的な処理がある、というケースです。予算が無制限なら、この副次的なワークロードのために別のキー・バリューデータベースを導入していたでしょう。しかし現実には、ストレージシステムをもう 1 つ維持するには追加コスト (監視、バックアップなど) がかかるため、それを避けたいこともあります。推奨に反して ClickHouse に対してキー・バリュー的なクエリを実行するのであれば、次のヒントを参考にしてください。

ClickHouse でポイントクエリのコストが高い主な理由は、主要な MergeTree テーブルエンジンファミリーのスパースプライマリインデックスにあります。この索引はデータの各行を個別に指し示すことはできず、代わりに N 行ごとを指します。そのためシステムは、目的の行に到達するまで近くの N 番目の行からスキャンする必要があり、その過程で余分なデータも読み込むことになります。キー・バリューのシナリオでは、index_granularity 設定で N の値を小さくすると有効な場合があります。
ClickHouse は各カラムを別々のファイル群に保持するため、完全な 1 行を組み立てるにはそれぞれのファイルをたどる必要があります。ファイル数はカラム数に比例して増えるため、キー・バリューのシナリオでは、多数のカラムを使うのを避け、ペイロード全体を JSON や Protobuf など適切なシリアライゼーションフォーマットでエンコードした 1 つの String カラムに格納するのが有効な場合があります。
通常の MergeTree テーブルの代わりに Join テーブルエンジンと、データ取得に joinGet 関数を使う別のアプローチもあります。こちらはより高いクエリ性能を得られる可能性がありますが、使い勝手や信頼性の面で問題が生じるかもしれません。こちらに使用例があります。