> ## Documentation Index
> Fetch the complete documentation index at: https://clickhouse.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# Otros ajustes de tabla de MergeTree
> Ajustes de tabla de MergeTree de ClickHouse en el grupo generado Other.
export const SettingsInfoBlock = ({type, default_value, changeable_without_restart}) => {
return
Tipo
{type}
Predeterminado
{default_value}
{changeable_without_restart &&
Modificable sin reiniciar
}
{changeable_without_restart &&
{changeable_without_restart}
}
;
};
export const ExperimentalBadge = () => {
return ;
};
Estos ajustes están disponibles en [system.merge\_tree\_settings](/docs/es/reference/system-tables/merge_tree_settings) y se autogeneran a partir del código fuente de ClickHouse.
## adaptive\_write\_buffer\_initial\_size
Tamaño inicial del búfer de escritura adaptativo
## add\_implicit\_sign\_column\_constraint\_for\_collapsing\_engine
Si es true, añade una restricción implícita a la columna `sign` de una tabla CollapsingMergeTree
o VersionedCollapsingMergeTree para permitir únicamente valores válidos (`1` y `-1`).
## alter\_column\_secondary\_index\_mode
Configura si se permiten los comandos `ALTER` que modifican columnas cubiertas por índices secundarios y qué acción debe realizarse si se permiten. De forma predeterminada, estos comandos `ALTER` están permitidos y los índices se reconstruyen.
Valores posibles:
* `rebuild` (predeterminado): Reconstruye cualquier índice secundario afectado por la columna en el comando `ALTER`.
* `throw`: Impide cualquier `ALTER` de columnas cubiertas por índices secundarios **explícitos** lanzando una excepción. Los índices implícitos quedan excluidos de esta restricción y se reconstruirán.
* `drop`: Elimina los índices secundarios dependientes. Las nuevas partes no tendrán los índices, por lo que será necesario ejecutar `MATERIALIZE INDEX` para recrearlos.
* `compatibility`: Mantiene el comportamiento original: `throw` en `ALTER ... MODIFY COLUMN` y `rebuild` en `ALTER ... UPDATE/DELETE`.
* `ignore`: Pensado para uso experto. Dejará los índices en un estado incoherente, lo que puede dar lugar a resultados de consulta incorrectos.
## apply\_patches\_on\_merge
Si es true, las partes de parche se aplican durante las fusiones
## assign\_part\_uuids
Cuando está habilitada, se asignará un identificador único a cada parte nueva.
Antes de habilitarla, compruebe que todas las réplicas sean compatibles con UUID versión 4.
## auto\_statistics\_types
Lista separada por comas de los tipos de estadísticas que se calcularán automáticamente en todas las columnas compatibles.
Tipos de estadísticas compatibles: basic, tdigest, countmin, uniq, uniq\_v2.
El tipo de estadísticas `minmax` está obsoleto: es un subconjunto de `basic`, que debe usarse en su lugar.
## background\_task\_preferred\_step\_execution\_time\_ms
Tiempo objetivo para ejecutar un paso de fusión o mutation. Puede superarse si
un paso tarda más
## clean\_deleted\_rows
Configuración obsoleta, no tiene ningún efecto.
## clone\_replica\_zookeeper\_create\_get\_part\_batch\_size
Tamaño del lote de las solicitudes get-part multi-create de ZooKeeper al clonar una réplica.
## compatibility\_allow\_sampling\_expression\_not\_in\_primary\_key
Permite crear una tabla con una expresión de muestreo que no forme parte de la clave primaria. Esto
solo es necesario para permitir temporalmente ejecutar el servidor con tablas incorrectas por
compatibilidad con versiones anteriores.
## compute\_exact\_num\_defaults\_for\_sparse\_columns
Calcula el recuento exacto de valores predeterminados por columna durante las inserciones y
fusiones, en lugar de la estimación más barata por muestreo que se usa para decidir la
serialización dispersa. Lo requiere `optimize_trivial_count_with_sparsity_filter`,
que consume el contador persistido `num_defaults` (las columnas Nullable
además necesitan `nullable_serialization_version = 'allow_sparse'`).
Dejarlo deshabilitado mantiene las inserciones/fusiones tan rápidas como antes; al habilitarlo
se añade una pasada O(rows) por cada columna apta para dispersión.
## deduplicate\_merge\_projection\_mode
Indica si se permite crear una proyección para una tabla con un MergeTree no clásico,
es decir, que no sea un MergeTree (Replicated, Shared). La opción `ignore` es solo para
compatibilidad y puede dar lugar a respuestas incorrectas. En caso contrario, si se permite,
define qué acción realizar al fusionar proyecciones: `drop` o `rebuild`. Por lo tanto, el
MergeTree clásico ignorará esta configuración. También controla `OPTIMIZE DEDUPLICATE`,
pero afecta a todos los miembros de la familia MergeTree. Al igual que la
opción `lightweight_mutation_projection_mode`, también es a nivel de parte.
Posibles valores:
* `ignore`
* `throw`
* `drop`
* `rebuild`
## deduplication\_hashes\_cache\_update\_wait\_ms
Cuánto tiempo espera cada iteración de inserción a que la caché en memoria `deduplication_hashes` se actualice a una
versión más reciente antes de volver a comprobar si ya contiene bloques insertados. La caché replica el
directorio `deduplication_hashes` en ClickHouse Keeper para que las inserciones puedan detectar duplicados sin una
ida y vuelta a Keeper.
## default\_compression\_codec
Especifica el códec de compresión predeterminado que se utilizará si no se ha definido ninguno para una columna concreta en la declaración de la tabla.
Orden de selección del códec de compresión para una columna:
1. Códec de compresión definido para la columna en la declaración de la tabla
2. Códec de compresión definido en `default_compression_codec` (esta configuración)
3. Códec de compresión predeterminado definido en la configuración `compression`
Valor predeterminado: una cadena vacía (no definido).
## disco
Nombre del disco de almacenamiento. Se puede especificar en lugar de la política de almacenamiento.
## dynamic\_serialization\_version
Versión de serialización para el tipo de datos Dynamic. Necesaria para la compatibilidad.
Valores posibles:
* `v1`
* `v2`
* `v3`
## enforce\_index\_structure\_match\_on\_partition\_manipulation
Si esta configuración está habilitada en la tabla de destino de una consulta
de manipulación de particiones (`ATTACH/MOVE/REPLACE PARTITION`), los índices y las proyecciones deben ser
idénticos entre las tablas de origen y destino. De lo contrario, la tabla de destino
puede tener un superconjunto de los índices y proyecciones de la tabla de origen.
## execute\_merges\_on\_single\_replica\_time\_threshold
Cuando esta configuración tiene un valor mayor que cero, solo una réplica inicia
la fusión de inmediato, y las demás réplicas esperan hasta ese tiempo para
descargar el resultado en lugar de realizar fusiones localmente. Si la réplica elegida
no termina la fusión dentro de ese tiempo, se vuelve al comportamiento
estándar.
Posibles valores:
* Cualquier entero positivo.
## finished\_mutations\_to\_keep
Cuántos registros sobre mutaciones finalizadas se deben conservar. Si es cero, se conservan
todos.
## force\_read\_through\_cache\_for\_merges
Forzar la lectura a través de la caché del sistema de archivos para las fusiones
## initialization\_retry\_period
Período de reintento para inicializar la tabla, en segundos.
## kill\_threads
Configuración obsoleta, no tiene ningún efecto.
## lightweight\_mutation\_projection\_mode
De forma predeterminada, la eliminación ligera `DELETE` no funciona en tablas con
proyecciones. Esto se debe a que una operación `DELETE` puede afectar a las filas de una
proyección. Por tanto, el valor predeterminado es `throw`. Sin embargo, esta
opción puede cambiar ese comportamiento. Con el valor `drop` o `rebuild`,
las eliminaciones funcionarán con proyecciones. `drop` eliminaría la proyección, por lo que
podría ser rápido para la consulta actual, ya que la proyección se elimina, pero lento en
consultas futuras, al no haber ninguna proyección disponible. `rebuild` reconstruiría la
proyección, lo que podría afectar al rendimiento de la consulta actual, pero
podría acelerar las consultas futuras. Lo bueno es que estas opciones
solo funcionarían a nivel de parte, lo que significa que las proyecciones de la parte que no
se vea afectada permanecerán intactas en lugar de desencadenar acciones como
drop o rebuild.
Valores posibles:
* `throw`
* `drop`
* `rebuild`
## load\_existing\_rows\_count\_for\_old\_parts
Si se habilita junto con la configuración [exclude\_deleted\_rows\_for\_part\_size\_in\_merge](/docs/es/reference/settings/merge-tree-settings/exclude#exclude_deleted_rows_for_part_size_in_merge),
el recuento de filas eliminadas de las partes de datos existentes se calculará durante el
arranque de la tabla. Tenga en cuenta que esto puede ralentizar la carga de la tabla al arrancar.
Valores posibles:
* `true`
* `false`
**Véase también**
* la configuración [exclude\_deleted\_rows\_for\_part\_size\_in\_merge](/docs/es/reference/settings/merge-tree-settings/exclude#exclude_deleted_rows_for_part_size_in_merge)
## lock\_acquire\_timeout\_for\_background\_operations
Para operaciones en segundo plano como fusiones, mutaciones, etc. Número de segundos antes de que falle la adquisición de bloqueos de la tabla.
## mutation\_workload
Se utiliza para regular cómo se usan y comparten los recursos entre las mutaciones y
otras cargas de trabajo. El valor especificado se usa como valor de la configuración `workload` para las
mutaciones en segundo plano de esta tabla. Si no se especifica (cadena vacía), se usa en su lugar la
configuración del servidor `mutation_workload`.
**Véase también**
* [Planificación de cargas de trabajo](/docs/es/concepts/features/configuration/server-config/workload-scheduling)
## non\_replicated\_deduplication\_window
El número de los bloques insertados más recientemente en la tabla
[MergeTree](/docs/es/reference/engines/table-engines/mergetree-family/mergetree) no replicada
cuyas sumas hash se almacenan para comprobar duplicados.
Posibles valores:
* Cualquier entero positivo.
* `0` (desactiva la deduplicación).
Se utiliza un mecanismo de deduplicación similar al de las tablas replicadas (consulte la
configuración [replicated\_deduplication\_window](/docs/es/reference/settings/merge-tree-settings/replicated-deduplication-window#replicated_deduplication_window)): la suma hash de deduplicación
cubre todo el bloque insertado. Las sumas hash se escriben en
un archivo local en un disco, en lugar de en ClickHouse Keeper.
## notify\_newest\_block\_number
Notifica el número del bloque más reciente a SharedJoin o SharedSet. Solo en ClickHouse Cloud.
## nullable\_serialization\_version
Controla el método de serialización que se utiliza para las columnas `Nullable(T)`.
Valores posibles:
* basic — Usa la serialización estándar para `Nullable(T)`.
* allow\_sparse — Permite que `Nullable(T)` use codificación dispersa.
## object\_serialization\_version
Versión de serialización del tipo de dato JSON. Necesaria para la compatibilidad.
Valores posibles:
* `v1`
* `v2`
* `v3`
Solo la versión `v3` permite cambiar la versión de serialización de los datos compartidos.
## old\_parts\_lifetime
El tiempo (en segundos) durante el que se almacenan las partes inactivas para proteger contra la pérdida de datos
durante reinicios inesperados del servidor.
Posibles valores:
* Cualquier entero positivo.
Después de fusionar varias partes en una nueva parte, ClickHouse marca las
partes originales como inactivas y las elimina solo después de que transcurran `old_parts_lifetime` segundos.
Las partes inactivas se eliminan si no están siendo utilizadas por las consultas actuales, es decir, si
el `refcount` de la parte es 1.
No se llama a `fsync` para las partes nuevas, por lo que durante cierto tiempo las partes nuevas existen solo
en la RAM del servidor (caché del SO). Si el servidor se reinicia inesperadamente, las partes nuevas
pueden perderse o dañarse. Para proteger los datos, las partes inactivas no se eliminan
de inmediato.
Durante el inicio, ClickHouse comprueba la integridad de las partes. Si la parte fusionada
está dañada, ClickHouse devuelve las partes inactivas a la lista de partes activas
y más tarde las vuelve a fusionar. Entonces, la parte dañada se renombra (se añade el prefijo `broken_`)
y se mueve a la carpeta `detached`. Si la parte fusionada no está
dañada, las partes inactivas originales se renombran (se añade el prefijo `ignored_`)
y se mueven a la carpeta `detached`.
El valor predeterminado de `dirty_expire_centisecs` (un ajuste del kernel de Linux) es de 30
segundos (el tiempo máximo durante el que los datos escritos se almacenan solo en RAM), pero con
cargas elevadas en el sistema de disco, los datos pueden escribirse mucho más tarde. Según pruebas realizadas,
se eligió un valor de 480 segundos para `old_parts_lifetime`, intervalo durante el cual se
garantiza que una parte nueva se escriba en disco.
## optimize\_row\_order
Controla si el orden de las filas debe optimizarse durante las inserciones para mejorar la
compresibilidad de la parte de tabla recién insertada.
Solo tiene efecto en las tablas ordinarias con motor MergeTree. No hace nada en
tablas especializadas con motor MergeTree (p. ej., CollapsingMergeTree).
Las tablas MergeTree se comprimen (opcionalmente) usando [códecs de compresión](/docs/es/reference/statements/create/table#column_compression_codec).
Los códecs de compresión genéricos como LZ4 y ZSTD logran tasas máximas de compresión
si los datos presentan patrones. Las secuencias largas del mismo valor suelen
comprimirse muy bien.
Si esta configuración está habilitada, ClickHouse intenta almacenar los datos en las partes
recién insertadas en un orden de filas que minimice el número de secuencias de valores iguales
en las columnas de la nueva parte de tabla.
En otras palabras, un número pequeño de secuencias de valores iguales significa que las secuencias
individuales son largas y se comprimen bien.
Encontrar el orden óptimo de las filas es computacionalmente inviable (NP-hard).
Por ello, ClickHouse usa una heurística para encontrar rápidamente un orden de filas que,
aun así, mejore las tasas de compresión con respecto al orden original de las filas.
Heurística para encontrar un orden de filas
Por lo general, es posible reorganizar libremente las filas de una tabla (o parte de tabla),
ya que SQL considera equivalente la misma tabla (parte de tabla) con un orden de filas distinto.
Esta libertad para reorganizar filas se restringe cuando se define una clave primaria
para la tabla. En ClickHouse, una clave primaria `C1, C2, ..., CN` impone que
las filas de la tabla se ordenen por las columnas `C1`, `C2`, ... `Cn` ([clustered index](https://en.wikipedia.org/wiki/Database_index#Clustered)).
Como resultado, las filas solo pueden reorganizarse dentro de "clases de equivalencia" de filas,
es decir, filas que tienen los mismos valores en sus columnas de clave primaria.
La idea es que las claves primarias de alta cardinalidad, por ejemplo, las que
incluyen una columna de timestamp `DateTime64`, dan lugar a muchas clases de equivalencia
pequeñas. Del mismo modo, las tablas con una clave primaria de baja cardinalidad crean pocas
clases de equivalencia y de gran tamaño. Una tabla sin clave primaria representa el caso extremo
de una única clase de equivalencia que abarca todas las filas.
Cuanto menos numerosas y más grandes sean las clases de equivalencia, mayor será el grado
de libertad al reorganizar las filas.
La heurística aplicada para encontrar el mejor orden de filas dentro de cada clase de equivalencia
fue propuesta por D. Lemire y O. Kaser en
[Reordering columns for smaller indexes](https://doi.org/10.1016/j.ins.2011.02.002)
y se basa en ordenar las filas dentro de cada clase de equivalencia por cardinalidad
ascendente de las columnas que no forman parte de la clave primaria.
Realiza tres pasos:
1. Encontrar todas las clases de equivalencia basadas en los valores de fila de las columnas de clave primaria.
2. Para cada clase de equivalencia, calcular (normalmente estimar) las cardinalidades
de las columnas que no forman parte de la clave primaria.
3. Para cada clase de equivalencia, ordenar las filas en orden ascendente de
cardinalidad de las columnas que no forman parte de la clave primaria.
Si está habilitada, las operaciones de inserción implican costos adicionales de CPU para analizar y
optimizar el orden de las filas de los datos nuevos. Se espera que los INSERTs tarden entre un 30 y un 50 %
más, según las características de los datos.
Las tasas de compresión de LZ4 o ZSTD mejoran en promedio entre un 20 y un 40 %.
Esta configuración funciona mejor para tablas sin clave primaria o con una clave primaria de
baja cardinalidad, es decir, una tabla con solo unos pocos valores distintos de clave primaria.
No se espera que las claves primarias de alta cardinalidad, por ejemplo las que incluyen columnas de timestamp de tipo
`DateTime64`, se beneficien de esta configuración.
## packed\_skip\_index\_max\_bytes
.idx2 \/ .mrk2. La decisión se toma por subflujo en el momento de la escritura."}]}]} />
Umbral (bytes serializados en disco, es decir, después de la compresión y la cadena de
hash del subflujo) por debajo del cual un subflujo de índice de omisión se empaqueta en un
único archivo `skp_idx.packed` por parte, en lugar de escribirse como un archivo
independiente `skp_idx_.idx2` / `.mrk2`. Los subflujos más grandes permanecen en el
formato heredado por archivo. La decisión se toma de forma independiente para cada subflujo
en el momento de la escritura, por lo que una sola parte puede tener índices pequeños
(por ejemplo, `minmax`) empaquetados e índices grandes (por ejemplo, un `bloom_filter`
pesado) por archivo. Establézcalo en 0 para desactivar por completo el empaquetado (valor predeterminado).
Cada subflujo de índice de omisión consta en realidad de un archivo de datos y un archivo
de marcas; ambos se almacenan en búfer en memoria hasta el umbral antes de tomar la
decisión de volcado a disco. Por tanto, el pico de memoria durante la escritura escala con
`2 * packed_skip_index_max_bytes * (number of substreams that stay
below the threshold)`.
Los índices de texto completo no son compatibles con esta configuración y nunca se empaquetan.
El empaquetado reduce la presión sobre los inodos cuando hay muchos índices de omisión
definidos en una tabla (por ejemplo, con `add_minmax_index_for_numeric_columns`).
El formato en disco es autodescriptivo: los lectores detectan `skp_idx.packed` y atienden
de forma transparente los subflujos empaquetados desde su interior. Cambiar esta
configuración afecta solo a las partes nuevas que se escriban; las partes existentes conservan el
formato que tenían en el momento de la escritura.
## part\_minmax\_index\_columns
Selecciona qué columnas abarca el índice min-max de cada parte. Cada valor habilita un grupo adicional de columnas con respecto al anterior.
Valores posibles:
* `partition_key_only` — solo se rastrean las columnas de la clave de partición.
* `with_block_number_offset` — columnas de la clave de partición, además de las columnas virtuales persistidas `_block_number` y `_block_offset`. Habilita la poda a nivel de parte mediante estas columnas.
## propagate\_types\_serialization\_versions\_to\_nested\_types
Si está establecido en true, las versiones de serialización como string\_serialization\_version se propagarán dentro de tipos anidados como Array/Map/Nullable/JSON/etc. Si se desactiva, la versión de serialización se aplicará solo a las columnas de nivel superior de este tipo y Tuple el
## ratio\_of\_defaults\_for\_sparse\_serialization
Relación mínima entre el número de valores *por defecto* y el número de *todos* los valores
de una columna. Al establecer este valor, la columna se almacena usando
serializaciones dispersas.
Si una columna es dispersa (contiene principalmente ceros), ClickHouse puede codificarla en
un formato disperso y optimizar automáticamente los cálculos: los datos no
requieren una descompresión completa durante las consultas. Para habilitar esta
serialización dispersa, defina la configuración `ratio_of_defaults_for_sparse_serialization`
con un valor inferior a 1.0. Si el valor es mayor o igual que 1.0,
las columnas siempre se escribirán usando la serialización completa normal.
Valores posibles:
* Float entre `0` y `1` para habilitar la serialización dispersa
* `1.0` (o superior) si no desea usar la serialización dispersa
**Ejemplo**
Observe que la columna `s` de la siguiente tabla es una cadena vacía en el 95 % de
las filas. En `my_regular_table` no usamos serialización dispersa, y en
`my_sparse_table` establecemos `ratio_of_defaults_for_sparse_serialization` en
0.95:
```sql theme={null}
CREATE TABLE my_regular_table
(
`id` UInt64,
`s` String
)
ENGINE = MergeTree
ORDER BY id;
INSERT INTO my_regular_table
SELECT
number AS id,
number % 20 = 0 ? toString(number): '' AS s
FROM
numbers(10000000);
CREATE TABLE my_sparse_table
(
`id` UInt64,
`s` String
)
ENGINE = MergeTree
ORDER BY id
SETTINGS ratio_of_defaults_for_sparse_serialization = 0.95;
INSERT INTO my_sparse_table
SELECT
number,
number % 20 = 0 ? toString(number): ''
FROM
numbers(10000000);
```
Observe que la columna `s` de `my_sparse_table` ocupa menos espacio de almacenamiento en disco:
```sql theme={null}
SELECT table, name, data_compressed_bytes, data_uncompressed_bytes FROM system.columns
WHERE table LIKE 'my_%_table';
```
```response theme={null}
┌─table────────────┬─name─┬─data_compressed_bytes─┬─data_uncompressed_bytes─┐
│ my_regular_table │ id │ 37790741 │ 75488328 │
│ my_regular_table │ s │ 2451377 │ 12683106 │
│ my_sparse_table │ id │ 37790741 │ 75488328 │
│ my_sparse_table │ s │ 2283454 │ 9855751 │
└──────────────────┴──────┴───────────────────────┴─────────────────────────┘
```
Puede verificar si una columna usa la codificación dispersa consultando la
columna `serialization_kind` de la tabla `system.parts_columns`:
```sql theme={null}
SELECT column, serialization_kind FROM system.parts_columns
WHERE table LIKE 'my_sparse_table';
```
Puede ver qué partes de `s` se almacenaron con la serialización dispersa:
```response theme={null}
┌─column─┬─serialization_kind─┐
│ id │ Default │
│ s │ Default │
│ id │ Default │
│ s │ Default │
│ id │ Default │
│ s │ Sparse │
│ id │ Default │
│ s │ Sparse │
│ id │ Default │
│ s │ Sparse │
│ id │ Default │
│ s │ Sparse │
│ id │ Default │
│ s │ Sparse │
│ id │ Default │
│ s │ Sparse │
│ id │ Default │
│ s │ Sparse │
│ id │ Default │
│ s │ Sparse │
│ id │ Default │
│ s │ Sparse │
└────────┴────────────────────┘
```
## reduce\_blocking\_parts\_sleep\_ms
Solo disponible en ClickHouse Cloud. Tiempo mínimo de espera antes de volver a
intentar reducir las partes bloqueantes después de que no se haya descartado ni reemplazado ningún rango. Un valor más bajo de esta
configuración activará tareas en background\_schedule\_pool con frecuencia, lo que
genera una gran cantidad de solicitudes a ZooKeeper en clústeres a gran escala
## replace\_long\_file\_name\_to\_hash
Si el nombre de archivo de una columna es demasiado largo (más de 'max\_file\_name\_length'
bytes), se reemplaza por SipHash128
## replicated\_can\_become\_leader
Si es `true`, las réplicas de las tablas replicadas de este nodo intentarán asumir
el liderazgo.
Valores posibles:
* `true`
* `false`
## search\_orphaned\_parts\_disks
ClickHouse examina todos los discos en busca de partes huérfanas al ejecutar cualquier operación ATTACH o CREATE sobre una tabla,
para evitar que se pasen por alto partes de datos en discos no definidos (no incluidos en la política).
Las partes huérfanas pueden originarse por una reconfiguración del almacenamiento potencialmente insegura; por ejemplo, si se excluyó un disco de la política de almacenamiento.
Esta configuración limita el alcance de los discos que se buscarán según sus características.
Valores posibles:
* any - el alcance no está limitado.
* local - el alcance se limita a los discos locales.
* none - alcance vacío, no buscar
## serialization\_info\_version
Versión de la información de serialización que se usa al escribir `serialization.json`.
Esta configuración es necesaria para garantizar la compatibilidad durante las actualizaciones del clúster.
Valores posibles:
* `basic` - Formato básico.
* `with_types` - Formato con el campo adicional `types_serialization_versions`, que permite versiones de serialización por tipo.
Esto hace que configuraciones como `string_serialization_version` tengan efecto.
Durante las actualizaciones progresivas, configúralo como `basic` para que los servidores nuevos produzcan
partes de datos compatibles con los servidores antiguos. Cuando la actualización se complete,
cámbialo a `WITH_TYPES` para habilitar versiones de serialización por tipo.
## share\_nested\_offsets
Cuando está habilitado (valor predeterminado), las columnas Array con nombres con puntos que comparten un prefijo común (p. ej., n.a y n.b)
se tratan como parte de una estructura Nested: comparten un único archivo de desplazamiento en disco (p. ej., n.size0),
y se valida que sus tamaños de array sean iguales durante INSERT.
Cuando está deshabilitado, cada columna Array tiene su propio archivo de desplazamiento independiente, los nombres con puntos no tienen ninguna semántica
especial, y una columna escalar puede coexistir con columnas Array con puntos que comparten el mismo prefijo
(p. ej., n UInt32 junto con n.a Array(String)). Esta configuración es inmutable después de crear la tabla.
## simultaneous\_parts\_removal\_limit
Si hay muchas partes obsoletas, el hilo de limpieza intentará eliminar hasta
`simultaneous_parts_removal_limit` partes en una sola iteración.
Si `simultaneous_parts_removal_limit` se establece en `0`, significa que no hay límite.
## storage\_policy
Nombre de la política de discos de almacenamiento
## string\_serialization\_version
Controla el formato de serialización de las columnas `String` de nivel superior.
Esta configuración solo surte efecto cuando `serialization_info_version` está configurado como "with\_types".
Cuando se configura como `with_size_stream`, las columnas `String` de nivel superior se serializan con una
subcolumna `.size` independiente que almacena las longitudes de las cadenas, en lugar de incluirlas en línea. Esto permite subcolumnas
`.size` reales y puede mejorar la eficiencia de compresión.
Los tipos `String` anidados (por ejemplo, dentro de `Nullable`, `LowCardinality`, `Array` o `Map`)
no se ven afectados, excepto cuando aparecen en una `Tuple`.
Valores posibles:
* `single_stream` — Usa el formato de serialización estándar con tamaños en línea.
* `with_size_stream` — Usa un flujo de tamaños independiente para las columnas `String` de nivel superior.
## temporary\_directories\_lifetime
Cuántos segundos se deben conservar los directorios tmp\_. No debería reducir este valor,
porque es posible que las fusiones y mutaciones no puedan funcionar con un valor bajo de este
ajuste.
## try\_fetch\_recompressed\_part\_timeout
Tiempo de espera (en segundos) antes de iniciar la fusión con recompresión. Durante este
tiempo, ClickHouse intenta recuperar la parte recomprimida de la réplica a la que se asignó
esta fusión con recompresión.
La recompresión suele ser lenta en la mayoría de los casos, por lo que no iniciamos la fusión con
recompresión hasta que transcurre este tiempo de espera e intentamos recuperar la parte recomprimida de la
réplica a la que se asignó esta fusión con recompresión.
Valores posibles:
* Cualquier entero positivo.
## ttl\_only\_drop\_parts
Controla si las partes de datos se eliminan por completo en las tablas MergeTree cuando todas las
filas de esa parte han caducado según su configuración de `TTL`.
Cuando `ttl_only_drop_parts` está deshabilitado (de forma predeterminada), solo se eliminan las filas que han
caducado según su configuración de `TTL`.
Cuando `ttl_only_drop_parts` está habilitado, se elimina la parte completa si todas las
filas de esa parte han caducado según su configuración de `TTL`.
## wait\_for\_unique\_parts\_send\_before\_shutdown\_ms
Antes de apagarse, la tabla esperará el tiempo requerido para que otras réplicas obtengan las partes únicas
(que existen solo en la réplica actual) (0 significa
deshabilitado).
## zookeeper\_session\_expiration\_check\_period
Período de comprobación de la expiración de la sesión de ZooKeeper, en segundos.
Valores posibles:
* Cualquier entero positivo.