mirror of
https://github.com/ClickHouse/ClickHouse.git
synced 2024-12-18 20:32:43 +00:00
107 lines
8.0 KiB
Markdown
107 lines
8.0 KiB
Markdown
---
|
||
slug: /ja/engines/table-engines/special/buffer
|
||
sidebar_position: 120
|
||
sidebar_label: Buffer
|
||
---
|
||
|
||
# Buffer テーブルエンジン
|
||
|
||
データをRAMにバッファし、定期的に別のテーブルにフラッシュして書き込みます。読み取り操作中は、データはバッファともう一方のテーブルから同時に読み取られます。
|
||
|
||
:::note
|
||
Buffer テーブルエンジンの推奨される代替手段は、[非同期インサート](/docs/ja/guides/best-practices/asyncinserts.md)を有効にすることです。
|
||
:::
|
||
|
||
``` sql
|
||
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です。
|
||
|
||
例:
|
||
|
||
``` sql
|
||
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](https://github.com/ClickHouse/ClickHouse/issues/15117) および [#30565](https://github.com/ClickHouse/ClickHouse/pull/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万行以上の速度が期待できます。
|