ClickHouse Cloud で Memoryテーブルエンジンを使用する場合、データはすべてのノード間でレプリカされません (これは仕様です) 。すべてのクエリが同じノードにルーティングされ、Memoryテーブルエンジンが期待どおりに動作するようにするには、次のいずれかを行います。
- すべての操作を同じセッションで実行する
- clickhouse-client など、TCP またはネイティブインターフェイス (スティッキー接続をサポート) を使用するクライアントを使う
PREWHERE をサポートしており、optimize_move_to_prewhere 設定によって制御される WHERE 条件の自動移動にも対応しています。まず条件に含まれるカラムのみが読み取られ、残りのカラムは条件を満たす行が存在するブロックについてのみ、かつ条件を満たす行についてのみ読み取られます。複数の条件を論理積で組み合わせた場合、enable_multiple_prewhere_read_steps 設定を使用した MergeTree と同様に、条件が段階的に評価されます。次の条件に含まれるカラムは、それまでの条件を満たした行についてのみ読み取られます。これは compress = true と組み合わせた場合に特に効果的です。選択性の高い条件では、ほとんどのカラムが一度も解凍されないためです。フィルタなしの SELECT count() FROM table は、データを読み取ることなくメタデータから結果が返されます。
単純なクエリでは、非常に高いスループット (10 GB/秒超) を実現できます。これは、ディスクからの読み取りや、データの解凍、デシリアライズが不要なためです。 (多くの場合、MergeTreeエンジンのスループットもほぼ同程度に高いことは付記しておきます。)
サーバーを再起動すると、テーブル内のデータは失われ、テーブルは空になります。
通常、このテーブルエンジンを使う妥当な理由はあまりありません。ただし、テストや、比較的少ない行数 (約100,000,000行まで) に対して最大速度が必要なタスクには使用できます。
Memoryエンジンは、システムによって、外部クエリデータ用の一時テーブル (“クエリ処理用の外部データ” の節を参照) や、GLOBAL IN の実装 (“IN 演算子” の節を参照) に使用されます。
Memoryエンジンのテーブルサイズを制限するために上限と下限を指定でき、これにより実質的に循環バッファとして動作させることができます (エンジンパラメータ を参照) 。
エンジンパラメータ
min_bytes_to_keep— メモリテーブルにサイズ上限が設定されている場合に保持する最小バイト数。- デフォルト値:
0 max_bytes_to_keepが必要
- デフォルト値:
max_bytes_to_keep— メモリテーブル内で保持する最大バイト数。各 insert 時に最も古い行が削除されます (つまり循環バッファ) 。大きな ブロック を追加する際、削除対象となる最も古い行のまとまりを削除するとmin_bytes_to_keepの制限を下回る場合、最大バイト数は指定した上限を超えることがあります。- デフォルト値:
0
- デフォルト値:
min_rows_to_keep— メモリテーブルにサイズ上限が設定されている場合に保持する最小行数。- デフォルト値:
0 max_rows_to_keepが必要
- デフォルト値:
max_rows_to_keep— メモリテーブル内で保持する最大行数。各 insert 時に最も古い行が削除されます (つまり循環バッファ) 。大きな ブロック を追加する際、削除対象となる最も古い行のまとまりを削除するとmin_rows_to_keepの制限を下回る場合、最大行数は指定した上限を超えることがあります。- デフォルト値:
0
- デフォルト値:
compress- メモリ内のデータを圧縮するかどうか。- デフォルト値:
false
- デフォルト値:
使用方法
設定の初期化bytes と 行 の上限指定パラメータは同時に設定できますが、実際に適用されるのは max と min のうち低い方の制限値です。