バッファテーブルエンジン
データをRAMに書き込むためにバッファし、定期的に別のテーブルにフラッシュします。読み取り操作中は、バッファと別のテーブルから同時にデータが読み込まれます。
バッファテーブルエンジンの推奨代替は、非同期挿入を有効にすることです。
エンジンパラメータ:
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
バックグラウンドでバッファからデータをフラッシュする条件（省略するかゼロの場合はflush*パラメータはありません）。
すべてのmin*条件を満たすか、少なくとも1つのmax*条件を満たすと、データがバッファからフラッシュされて宛先テーブルに書き込まれます。
また、少なくとも1つのflush*条件が満たされる場合、バックグラウンドでフラッシュが開始されます。これはmax*とは異なり、flush*はバックグラウンドフラッシュを別々に構成できるため、バッファテーブルに対する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.6GBになります。
例:
merge.hitsと同じ構造のmerge.hits_bufferテーブルを作成し、バッファエンジンを使用します。このテーブルに書き込むと、データはRAMにバッファされ、後で「merge.hits」テーブルに書き込まれます。単一のバッファが作成され、フラッシュは次のいずれかの条件を満たす場合に行われます：
- 最後のフラッシュから100秒が経過した（
max_time）または - 100万行が書き込まれた（
max_rows）または - 100MBのデータが書き込まれた（
max_bytes）または - 10秒が経過し（
min_time）、10,000行（min_rows）、および10MB（min_bytes）のデータが書き込まれた
たとえば、1行だけが書き込まれた場合、100秒後にフラッシュされます。多くの行が書き込まれた場合、データはより早くフラッシュされます。
サーバーが停止されると、DROP TABLEまたはDETACH TABLEにより、バッファされたデータも宛先テーブルにフラッシュされます。
データベース名やテーブル名に空の文字列をシングルクォートで指定することができます。これは宛先テーブルが存在しないことを示します。この場合、データフラッシュ条件が満たされると、バッファは単純にクリアされます。これにより、メモリ内のデータウィンドウを保持するのが便利です。
バッファテーブルから読み取る際、データはバッファと宛先テーブル（存在する場合）から両方処理されます。
バッファテーブルはインデックスをサポートしていないことに注意してください。言い換えれば、バッファ内のデータは完全にスキャンされるため、大きなバッファの場合は遅くなる可能性があります。（従属テーブルのデータについては、サポートされているインデックスが使用されます。）
バッファテーブルのカラムのセットが従属テーブルのカラムのセットと一致しない場合、両方のテーブルに存在するカラムのサブセットが挿入されます。
バッファテーブルと従属テーブルのいずれかのカラムの型が一致しない場合、エラーメッセージがサーバーログに記録され、バッファはクリアされます。
バッファがフラッシュされるときに従属テーブルが存在しない場合も同様のことが発生します。
サーバーが異常に再起動された場合、バッファ内のデータは失われます。
FINALおよびSAMPLEはバッファテーブルに対して正しく機能しません。これらの条件は宛先テーブルに渡されますが、バッファ内のデータの処理には使用されません。これらの機能が必要な場合は、バッファテーブルは書き込み専用に使用し、宛先テーブルから読み取ることをお勧めします。
バッファテーブルにデータを追加する際、1つのバッファがロックされます。これにより、テーブルから同時に読み取り操作が実行されると、遅延が発生します。
バッファテーブルに挿入されたデータは、従属テーブルに異なる順序や異なるブロックで格納される場合があります。このため、バッファテーブルはCollapsingMergeTreeへの書き込みに正しく使用するのが難しいです。問題を回避するために、num_layersを1に設定することができます。
宛先テーブルがレプリケートされている場合、バッファテーブルに書き込むと、レプリケートテーブルの予期される特性のいくつかが失われます。行の順序やデータパートのサイズのランダムな変更により、データの重複排除が機能しなくなり、「正確に一度」書き込みをすることができなくなります。
これらの欠点により、バッファテーブルは稀な場合にのみ使用することを推奨します。
バッファテーブルは、大量のサーバーから単位時間あたりに多くのINSERTを受け取る場合に使用され、挿入前にデータをバッファできないため、INSERTが十分に高速に実行できない場合です。
バッファテーブルであっても、1行ずつデータを挿入することは無意味です。これは、1秒あたり数千行の速度を生むだけであり、大きなデータブロックを挿入すると1秒あたり100万行以上の速度を生むことができます。