Buffer テーブルエンジン
書き込み対象のデータを RAM 上でバッファリングし、定期的に別のテーブルへフラッシュします。読み取り時には、バッファとその別のテーブルの両方から同時にデータを読み取ります。
Buffer テーブルエンジンの代替として推奨されるのは、非同期インサート を有効化することです。
エンジンパラメータ
database
database – データベース名。currentDatabase() もしくは文字列を返す他の定数式を使用できます。
table
table – データをフラッシュする対象のテーブル。
num_layers
num_layers – 並列レイヤー数。物理的には、テーブルは互いに独立したバッファが num_layers 個ある形で表現されます。
min_time, max_time, min_rows, max_rows, min_bytes, および max_bytes
バッファからデータをフラッシュするための条件。
オプションのエンジンパラメータ
flush_time, flush_rows, および flush_bytes
バックグラウンドでバッファからデータをフラッシュするための条件（省略または 0 の場合は、flush* パラメータは存在しないものとして扱われます）。
すべての min* 条件が満たされるか、少なくとも 1 つの max* 条件が満たされた場合、データはバッファからフラッシュされ、出力先テーブルに書き込まれます。
また、少なくとも 1 つの flush* 条件が満たされると、バックグラウンドでフラッシュが開始されます。これは max* とは異なり、flush* によって、Buffer テーブルへの INSERT クエリにレイテンシを追加しないように、バックグラウンドフラッシュを個別に構成できます。
min_time, max_time, および flush_time
最初の書き込み時点からの経過時間（秒）に関する条件。
min_rows, max_rows, および flush_rows
バッファ内の行数に関する条件。
min_bytes, max_bytes, および flush_bytes
バッファ内のバイト数に関する条件。
書き込み操作中、データは 1 つ以上のランダムなバッファ（num_layers で構成）に挿入されます。あるいは、挿入するデータのまとまりが十分に大きい場合（max_rows または max_bytes を超える場合）、バッファを経由せずに直接出力先テーブルに書き込まれます。
データをフラッシュする条件は、num_layers の各バッファごとに個別に評価されます。たとえば、num_layers = 16 かつ max_bytes = 100000000 の場合、RAM の最大使用量は 1.6 GB です。
例:
merge.hits と同じ構造を持ち、Buffer エンジンを使用する merge.hits_buffer テーブルを作成します。このテーブルに書き込むと、データは RAM 上にバッファされ、その後で 'merge.hits' テーブルに書き込まれます。1 つのバッファが作成され、以下のいずれかの条件を満たすとデータがフラッシュされます:
- 前回のフラッシュから 100 秒経過した場合（
max_time） - 100 万行が書き込まれた場合（
max_rows） - 100 MB のデータが書き込まれた場合（
max_bytes） - 10 秒が経過しており（
min_time）、かつ 1 万行（min_rows）および 10 MB（min_bytes）のデータが書き込まれた場合
たとえば、1 行だけが書き込まれた場合でも、100 秒後には必ずフラッシュされます。一方、多数の行が書き込まれている場合は、それより早くデータがフラッシュされます。
サーバーの停止時や DROP TABLE または DETACH TABLE が実行されたときは、バッファされたデータも宛先テーブルにフラッシュされます。
データベース名およびテーブル名には、シングルクォートで囲んだ空文字列を設定できます。これは、宛先テーブルが存在しないことを示します。この場合、データのフラッシュ条件に達すると、バッファは単にクリアされます。これは、メモリ上に一定期間分のデータだけを保持しておきたい場合に有用です。
Buffer テーブルから読み取る場合、データはバッファと宛先テーブル（存在する場合）の両方から処理されます。 なお、Buffer テーブルはインデックスをサポートしません。つまり、バッファ内のデータはフルスキャンされるため、大きなバッファでは低速になる可能性があります（下位テーブル内のデータについては、そのテーブルがサポートするインデックスが使用されます）。
Buffer テーブル内のカラム集合が下位テーブルのカラム集合と一致しない場合、両方のテーブルに共通するカラムのみが挿入されます。
Buffer テーブルと下位テーブルのいずれかのカラムで型が一致しない場合、エラーメッセージがサーバーログに出力され、バッファは消去されます。 バッファがフラッシュされる時点で下位テーブルが存在しない場合も同様です。
サーバーが異常終了した場合、バッファ内のデータは失われます。
FINAL と SAMPLE は Buffer テーブルでは正しく動作しません。これらの条件は宛先テーブルには渡されますが、バッファ内のデータ処理には使用されません。これらの機能が必要な場合は、Buffer テーブルは書き込み専用とし、読み取りは宛先テーブルからのみ行うことを推奨します。
Buffer テーブルにデータを追加する際は、バッファの 1 つがロックされます。そのため、同時にテーブルから読み取り操作が行われていると遅延が発生します。
Buffer テーブルに挿入されたデータは、下位テーブル内では異なる順序や異なるブロックに配置される場合があります。このため、Buffer テーブルを CollapsingMergeTree への正しい書き込みに用いるのは困難です。問題を避けるには、num_layers を 1 に設定できます。
宛先テーブルがレプリケートされている場合、Buffer テーブルに書き込むと、レプリケートされたテーブルに期待される特性の一部が失われます。行の順序やデータパーツのサイズがランダムに変化することで、データ重複排除が機能しなくなり、レプリケートされたテーブルに対して信頼できる「厳密に一度だけ」の書き込みを行うことが不可能になります。
これらの欠点により、Buffer テーブルの使用はごく限られたケースにのみ推奨されます。
Buffer テーブルは、単位時間あたりに多数のサーバーから大量の INSERT が送信され、挿入前にデータをバッファリングできないために INSERT が十分な速度で実行できない場合に使用されます。
なお、Buffer テーブルであっても、1 行ずつデータを挿入することには意味がありません。この方法では、スループットは毎秒数千行程度にとどまり、より大きなブロック単位でデータを挿入することで、毎秒 100 万行を超えるスループットを得ることができます。
