Una alternativa recomendada al motor de tabla Buffer es habilitar las inserciones asíncronas.
Parámetros del motor
database
database – Nombre de la base de datos. Puede usar currentDatabase() u otra expresión constante que devuelva una cadena.
table
table – Tabla en la que se vacían los datos.
num_layers
num_layers – Capa de paralelismo. Físicamente, la tabla se representará en num_layers búferes independientes.
min_time, max_time, min_rows, max_rows, min_bytes, and max_bytes
Parámetros opcionales del motor
flush_time, flush_rows, y flush_bytes
flush*).
Los datos se vacían del búfer y se escriben en la tabla de destino si se cumplen todas las condiciones min* o al menos una de las condiciones max*.
Además, si se cumple al menos una condición flush*, se inicia un vaciado en segundo plano. Esto difiere de max*, ya que flush* permite configurar por separado los vaciados en segundo plano para evitar añadir latencia a las consultas INSERT en tablas Buffer.
min_time, max_time y flush_time
min_rows, max_rows, y flush_rows
min_bytes, max_bytes, and flush_bytes
num_layers). O bien, si la parte de datos que se va a insertar es lo suficientemente grande (mayor que max_rows o max_bytes), se escribe directamente en la tabla de destino, omitiendo el búfer.
Las condiciones para vaciar los datos se calculan por separado para cada uno de los búferes de num_layers. Por ejemplo, si num_layers = 16 y max_bytes = 100000000, el consumo máximo de RAM es de 1.6 GB.
Ejemplo:
merge.hits_buffer con la misma estructura que merge.hits y usando el motor Buffer. Al escribir en esta tabla, los datos se almacenan en búfer en RAM y más tarde se escriben en la tabla ‘merge.hits’. Se crea un único búfer y los datos se vacían si se cumple cualquiera de estas condiciones:
- Han pasado 100 segundos desde el último vaciado (
max_time) o - Se han escrito 1 millón de filas (
max_rows) o - Se han escrito 100 MB de datos (
max_bytes) o - Han pasado 10 segundos (
min_time) y se han escrito 10.000 filas (min_rows) y 10 MB (min_bytes) de datos
DROP TABLE o DETACH TABLE, los datos almacenados en búfer también se vacían en la tabla de destino.
Puede establecer cadenas vacías entre comillas simples para la base de datos y el nombre de la tabla. Esto indica que no hay una tabla de destino. En este caso, cuando se cumplen las condiciones de vaciado, el búfer simplemente se borra. Esto puede ser útil para mantener una ventana de datos en memoria.
Al leer desde una tabla Buffer, los datos se procesan tanto desde el búfer como desde la tabla de destino (si existe).
Tenga en cuenta que la tabla Buffer no admite un índice. En otras palabras, los datos del búfer se escanean por completo, lo que puede ser lento para búferes grandes. (Para los datos de una tabla subyacente, se usará el índice que esta admita).
Si el conjunto de columnas de la tabla Buffer no coincide con el conjunto de columnas de una tabla subyacente, se inserta el subconjunto de columnas que existe en ambas tablas.
Si los tipos no coinciden en alguna de las columnas de la tabla Buffer y una tabla subyacente, se registra un mensaje de error en el registro del servidor y el búfer se borra.
Lo mismo ocurre si la tabla subyacente no existe cuando se vacía el búfer.
Ejecutar ALTER en la tabla Buffer en versiones anteriores al 26 Oct 2021 provocará un error
Block structure mismatch (consulte #15117 y #30565), por lo que eliminar la tabla Buffer y volver a crearla es la única opción. Verifique que este error esté corregido en su versión antes de intentar ejecutar ALTER en la tabla Buffer.FINAL y SAMPLE no funcionan correctamente con las tablas Buffer. Estas condiciones se pasan a la tabla de destino, pero no se usan para procesar los datos del búfer. Si necesita estas características, recomendamos usar la tabla Buffer solo para escritura y leer desde la tabla de destino.
Al añadir datos a una tabla Buffer, uno de los búferes se bloquea. Esto provoca retrasos si al mismo tiempo se está realizando una operación de lectura desde la tabla.
Los datos que se insertan en una tabla Buffer pueden acabar en la tabla subyacente en un orden distinto y en bloques diferentes. Por eso, es difícil usar correctamente una tabla Buffer para escribir en una CollapsingMergeTree. Para evitar problemas, puede establecer num_layers en 1.
Si la tabla de destino está replicada, al escribir en una tabla Buffer se pierden algunas características esperadas de las tablas replicadas. Los cambios aleatorios en el orden de las filas y en los tamaños de las partes de datos hacen que la deduplicación de datos deje de funcionar, lo que significa que no es posible tener una escritura fiable ‘exactly once’ en tablas replicadas.
Debido a estas desventajas, solo podemos recomendar el uso de una tabla Buffer en casos excepcionales.
Se usa una tabla Buffer cuando se reciben demasiados INSERTs desde un gran número de servidores en un periodo de tiempo, y los datos no pueden almacenarse en búfer antes de la inserción, lo que significa que los INSERTs no pueden ejecutarse con suficiente rapidez.
Tenga en cuenta que no tiene sentido insertar datos de una fila en una, incluso en las tablas Buffer. Esto solo ofrece una velocidad de unos pocos miles de filas por segundo, mientras que insertar bloques de datos más grandes puede superar el millón de filas por segundo.