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

短い答えは**「いいえ」**です。キー・バリューのワークロードは、ClickHouseを使用しないべきケースのリストの中でもトップの位置にあります。結局のところ、ClickHouseはOLAPシステムであり、優れたキー・バリュー・ストレージシステムは他にも多く存在します。

しかし、キー・バリューのようなクエリにClickHouseを使用することが理にかなう状況もあるかもしれません。通常、これは主に分析的な性質のワークロードがあり、ClickHouseに適している低予算の製品の一部であり、しかしながらリクエストスループットがそれほど高くなく、厳しいレイテンシーの要件がないキー・バリューのパターンを必要とする二次プロセスがあります。もし予算が無限であったなら、その二次ワークロードのために別のキー・バリュー・データベースを設置していたでしょうが、実際には、もう一つのストレージシステム（監視、バックアップなど）を維持するための追加コストがあるため、それを避けたい場合があります。

推奨に反してClickHouseに対してキー・バリューのようなクエリを実行することを決めた場合、以下のヒントがあります：

• ClickHouseにおけるポイントクエリが高価である主要な理由は、その主なMergeTreeテーブルエンジンファミリーのスパース主インデックスです。このインデックスは、特定のデータ行を指し示すことができず、代わりに各N番目の行を指し示し、システムは隣接するN番目の行から目的の行にスキャンしなければならず、その過程で過剰なデータを読み込む必要があります。キー・バリューのシナリオでは、index_granularity設定を使用してNの値を減らすことが有用かもしれません。
• ClickHouseは各カラムを別々のファイルセットに保持するため、完全な1行を構成するためには各ファイルを通過する必要があります。カラムの数は、カラムの数に応じて線形に増加するため、キー・バリューのシナリオでは、多くのカラムの使用を避け、すべてのペイロードをJSON、Protobuf、またはそれが意味のあるものである何らかのシリアライズ形式でエンコードされた単一のStringカラムに置くことが価値があるかもしれません。
• 正常なMergeTreeテーブルの代わりにJoinテーブルエンジンを使用し、データを取得するためにjoinGet関数を使用する代替アプローチもあります。これにより、クエリのパフォーマンスが向上する可能性がありますが、一部の使いやすさや信頼性の問題があるかもしれません。こちらが使用例です。