バッファテーブルエンジン
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_bufferテーブルを作成し、merge.hitsと同じ構造を持ち、バッファエンジンを使用します。このテーブルに書き込むと、データは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に設定することができます。
宛先テーブルがレプリケートされている場合、バッファテーブルへの書き込み時にレプリケートテーブルのいくつかの期待される特性が失われます。行の順序やデータ部分のサイズのランダムな変更が原因で、データの重複排除が機能しなくなり、レプリケートテーブルに対して信頼性のある「ちょうど1回」の書き込みが不可能になります。
これらの欠点のため、バッファテーブルの使用は稀なケースでのみ推奨されます。
バッファテーブルは、時間単位で多数のサーバーから多くのINSERTが受信され、挿入前にデータをバッファリングできないために、INSERTが十分に速く実行できない場合に使用されます。
バッファテーブルに対して1行ずつデータを挿入することは意味がないことに注意してください。これは、数千行/秒の速度しか生み出さず、大きなデータブロックを挿入することで100万行/秒を超える速度を実現できます。
