<keeper_map_path_prefix> 設定を使用して、テーブルの保存先となる ZooKeeper パスを定義する必要があります。
例:
テーブルの作成
root_path-table_nameが格納される ZooKeeper パス。 プレフィックスはroot_pathに自動的に付加されるため、このパスには<keeper_map_path_prefix>config で定義されたプレフィックスを含めないでください。 また、auxiliary_zookeeper_cluster_name:/some/path形式もサポートされています。ここでauxiliary_zookeeper_clusterは<auxiliary_zookeepers>config 内で定義された ZooKeeper クラスターです。 デフォルトでは、<zookeeper>config 内で定義された ZooKeeper クラスターが使用されます。keys_limit- テーブル内で許可されるキーの数。 この制限はソフトリミットであるため、エッジケースによってはテーブル内のキー数がこれを超える場合があります。primary_key_name– カラム一覧内の任意のカラム名。primary keyの指定は必須で、主キーとして指定できるのは 1 つのカラムのみです。主キーは ZooKeeper 内でnode nameとしてバイナリ形式にシリアライズされます。- 主キー以外のカラムは、対応する順序でバイナリ形式にシリアライズされ、シリアライズされたキーによって定義されるノードの値として保存されます。
- キーに対する
equalsまたはinフィルタリングを含むクエリは、Keeperからの複数キーのルックアップに最適化されます。それ以外の場合は、すべての値が取得されます。
(v1, v2, v3) をバイナリシリアライズしたもので、Keeper 内の /keeper_map_tables/keeper_map_table/data/serialized_key に格納されます。
さらに、キー数のソフトリミットは 4 です。
同じ ZooKeeper パス上に複数のテーブルが作成された場合、それを使用するテーブルが 1 つでも存在する限り、値は保持されます。
そのため、テーブルの作成時に ON CLUSTER 句を使用して、複数の ClickHouse インスタンスからデータを共有できます。
もちろん、関連のない ClickHouse インスタンスで同じパスを指定して CREATE TABLE を手動で実行し、同様のデータ共有効果を得ることもできます。
対応している操作
挿入
KeeperMapに挿入する際、キーが存在しない場合は、そのキーに対応する新しいエントリが作成されます。
キーが存在し、設定keeper_map_strict_modeがtrueの場合は例外がスローされ、それ以外の場合はそのキーの値が上書きされます。
例:
削除
DELETE クエリまたは TRUNCATE を使用して削除できます。
キーが存在し、かつ設定 keeper_map_strict_mode が true に設定されている場合、データのフェッチと削除は、アトミックに実行できる場合にのみ成功します。
更新
ALTER TABLE クエリを使用して値を更新できます。主キーは更新できません。
設定 keeper_map_strict_mode が true の場合、データの取得と更新はアトミックに実行された場合にのみ成功します。