ClickHouseをキー値ストレージとして使用できますか？

短い答えは**「いいえ」**です。キー値ワークロードは、絶対に ClickHouseを使用しないべきケースのリストの中で上位に位置しています。結局のところ、ClickHouseはOLAPシステムであり、優れたキー値ストレージシステムが多数存在します。

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

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

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