8.0 KiB
| slug | sidebar_position | sidebar_label |
|---|---|---|
| /ja/engines/table-engines/special/buffer | 120 | Buffer |
Buffer テーブルエンジン
データをRAMにバッファし、定期的に別のテーブルにフラッシュして書き込みます。読み取り操作中は、データはバッファともう一方のテーブルから同時に読み取られます。
:::note Buffer テーブルエンジンの推奨される代替手段は、非同期インサートを有効にすることです。 :::
Buffer(database, table, num_layers, min_time, max_time, min_rows, max_rows, min_bytes, max_bytes [,flush_time [,flush_rows [,flush_bytes]]])
エンジンパラメータ:
database
database - データベース名。currentDatabase() または文字列を返す他の定数式を使用できます。
table
table - データを書き込むテーブル。
num_layers
num_layers - パラレル層。物理的には、テーブルは独立したバッファの num_layers によって表されます。
min_time, max_time, min_rows, max_rows, min_bytes, and max_bytes
バッファからデータをフラッシュする条件。
オプションのエンジンパラメータ:
flush_time, flush_rows, and flush_bytes
バックグラウンドでバッファからデータをフラッシュする条件（省略またはゼロは flush* パラメータがないことを意味します）。
バッファからデータがフラッシュされ、すべての min* 条件または少なくとも1つの max* 条件が満たされると、宛先テーブルに書き込まれます。
また、少なくとも1つの flush* 条件が満たされると、バックグラウンドでフラッシュが開始されます。これは max* とは異なり、flush* により、INSERT クエリへの遅延を避けてバッファテーブルへのバックグラウンドフラッシュを個別に設定できます。
min_time, max_time, and flush_time
バッファへの最初の書き込みからの秒数条件。
min_rows, max_rows, and flush_rows
バッファ内の行数条件。
min_bytes, max_bytes, and flush_bytes
バッファ内のバイト数条件。
書き込み操作中、データは1つ以上のランダムなバッファに挿入されます（num_layers で設定）。または、挿入するデータ部分が大きすぎる場合（max_rows または max_bytes より大きい場合）、バッファを省略して宛先テーブルに直接書き込まれます。
データをフラッシュする条件は、それぞれの num_layers バッファに対して個別に計算されます。たとえば、num_layers = 16 および max_bytes = 100000000 の場合、最大RAM消費量は1.6 GBです。
例:
CREATE TABLE merge.hits_buffer AS merge.hits ENGINE = Buffer(merge, hits, 1, 10, 100, 10000, 1000000, 10000000, 100000000)
merge.hits_buffer テーブルを作成し、その構造は merge.hits と同じで、Buffer エンジンを使用します。このテーブルに書き込むと、データはRAMにバッファされ、その後 merge.hits テーブルに書き込まれます。単一のバッファが作成され、データは以下の場合にフラッシュされます:
- 最後のフラッシュから100秒が経過した場合（
max_time）または - 100万行が書き込まれた場合（
max_rows）または - 100 MBのデータが書き込まれた場合（
max_bytes）または - 10秒が経過した場合（
min_time）かつ10,000行（min_rows）と10 MB（min_bytes）のデータが書き込まれた場合
たとえば、1行だけが書き込まれた場合であっても、100秒後には必ずフラッシュされます。しかし、多くの行が書き込まれた場合、データはより早くフラッシュされます。
サーバが停止された場合、DROP TABLE または DETACH TABLE により、バッファされたデータも宛先テーブルにフラッシュされます。
データベース名とテーブル名にシングルクォートで空文字列を設定できます。これは、宛先テーブルがないことを示します。この場合、データフラッシュ条件が満たされると、バッファは単にクリアされます。これは、メモリ内にデータのウィンドウを保持するのに役立つ場合があります。
Buffer テーブルから読み取るとき、データはバッファからと、もしあれば宛先テーブルから処理されます。 Buffer テーブルはインデックスをサポートしていないことに注意してください。つまり、バッファ内のデータは完全にスキャンされます。これにより、大規模なバッファには時間がかかる可能性があります。（サブテーブル内のデータについては、サポートするインデックスが使用されます。）
Buffer テーブルのカラムセットがサブテーブルのカラムセットと一致しない場合、両方のテーブルに存在するカラムのサブセットが挿入されます。
Buffer テーブルのカラムとサブテーブルとの間で型が一致しない場合、エラーメッセージがサーバーログに記録され、バッファがクリアされます。バッファがフラッシュされるときにサブテーブルが存在しない場合も同様です。
:::note
2021年10月26日以前のリリースで Buffer テーブルにALTERを実行すると Block structure mismatch エラーが発生します（#15117 および #30565を参照）。Buffer テーブルを削除し、再作成することが唯一の選択です。ALTERをBufferテーブルに実行する前に、リリースでこのエラーが修正されていることを確認してください。
:::
サーバが異常終了すると、バッファ内のデータは失われます。
FINAL および SAMPLE は Buffer テーブルでは正しく動作しません。これらの条件は宛先テーブルには渡されますが、バッファ内のデータ処理には使用されません。これらの機能が必要な場合は、Buffer テーブルは書き込み専用にし、読み取りは宛先テーブルから行うことをお勧めします。
Buffer テーブルにデータを追加すると、一部のバッファはロックされます。これにより、同時にテーブルから読み取り操作が行われている場合に遅延が発生します。
Buffer テーブルに挿入されたデータは、サブテーブルに異なる順番で異なるブロックに収まる可能性があります。このため、Buffer テーブルは正しく CollapsingMergeTree に書き込むには困難です。問題を避けるには、num_layers を1に設定することができます。
宛先テーブルがレプリケートされている場合、Buffer テーブルに書き込むとレプリケートテーブルの予期した特徴が失われます。行の順番やデータ部分のサイズがランダムに変わるため、データの重複除去が動作しなくなり、レプリケートテーブルへの確実な「正確に一度」書き込みができなくなります。
これらの欠点から、Buffer テーブルを使用するのは稀なケースに限定することをお勧めします。
Buffer テーブルは、短時間に多くのサーバから非常に多くのINSERTを受信し、データを挿入前にバッファできず、INSERTが十分高速に実行できない場合に使用されます。
Buffer テーブルでも、1行ずつデータを挿入することは意味がありません。これにより、1秒あたり数千行の速度しか出せませんが、より大きなデータブロックを挿入することで、1秒あたり100万行以上の速度が期待できます。