Motor de tabla SharedMergeTree

Describe el motor de tabla SharedMergeTree

La familia de motores de tabla SharedMergeTree es un reemplazo nativo de la nube para los motores ReplicatedMergeTree, optimizado para funcionar sobre almacenamiento compartido (p. ej., Amazon S3, Google Cloud Storage, MinIO, Azure Blob Storage). Existe un equivalente de SharedMergeTree para cada tipo específico de motor MergeTree; es decir, SharedReplacingMergeTree sustituye a ReplicatedReplacingMergeTree.

La familia de motores de tabla SharedMergeTree es la base de ClickHouse Cloud. Para el usuario final, no hace falta cambiar nada para empezar a usar la familia de motores SharedMergeTree en lugar de los motores basados en ReplicatedMergeTree. Ofrece las siguientes ventajas adicionales:

• Mayor rendimiento de inserción
• Mayor rendimiento de las fusiones en segundo plano
• Mayor rendimiento de las mutaciones
• Operaciones de escalado y reducción de escala más rápidas
• Consistencia fuerte con menor sobrecarga para las consultas SELECT

Una mejora significativa que aporta SharedMergeTree es que proporciona una separación más marcada entre cómputo y almacenamiento en comparación con ReplicatedMergeTree. A continuación puede ver cómo ReplicatedMergeTree separa el cómputo y el almacenamiento:

Como puede ver, aunque los datos almacenados en ReplicatedMergeTree están en almacenamiento de objetos, los metadatos siguen residiendo en cada uno de los clickhouse-servers. Esto significa que, para cada operación replicada, los metadatos también deben replicarse en todas las réplicas.

A diferencia de ReplicatedMergeTree, SharedMergeTree no requiere que las réplicas se comuniquen entre sí. En su lugar, toda la comunicación se realiza a través del almacenamiento compartido y clickhouse-keeper. SharedMergeTree implementa replicación asíncrona sin líder y utiliza clickhouse-keeper para la coordinación y el almacenamiento de metadatos. Esto significa que los metadatos no necesitan replicarse a medida que el servicio escala y reduce su tamaño. Esto se traduce en operaciones más rápidas de replicación, mutación, fusión y escalado. SharedMergeTree permite cientos de réplicas por tabla, lo que hace posible escalar dinámicamente sin segmentos. En ClickHouse Cloud se utiliza un enfoque de ejecución distribuida de consultas para aprovechar más recursos de cómputo en una consulta.

​

Introspección

La mayoría de las tablas del sistema usadas para la introspección de ReplicatedMergeTree también existen en SharedMergeTree, excepto system.replication_queue y system.replicated_fetches, ya que no se produce replicación de datos ni de metadatos. Sin embargo, SharedMergeTree tiene alternativas equivalentes para estas dos tablas.

system.virtual_parts

Esta tabla sirve como alternativa a system.replication_queue para SharedMergeTree. Almacena información sobre el conjunto más reciente de partes actuales, así como sobre partes futuras en proceso, como fusiones, mutaciones y particiones eliminadas.

system.shared_merge_tree_fetches

Esta tabla es la alternativa a system.replicated_fetches para SharedMergeTree. Contiene información sobre los fetches actualmente en curso de claves primarias y checksums en memoria.

​

Activación de SharedMergeTree

SharedMergeTree está habilitado de forma predeterminada.

En los servicios que admiten el motor de tabla SharedMergeTree, no necesita habilitar nada manualmente. Puede crear tablas de la misma forma que antes, y se utilizará automáticamente un motor de tabla basado en SharedMergeTree correspondiente al motor especificado en su consulta CREATE TABLE.

CREATE TABLE my_table(
 key UInt64,
 value String
)
ENGINE = MergeTree
ORDER BY key

Esto creará la tabla my_table con el motor de tabla SharedMergeTree.

No es necesario especificar ENGINE=MergeTree, ya que en ClickHouse Cloud default_table_engine=MergeTree. La siguiente consulta es idéntica a la anterior.

CREATE TABLE my_table(
 key UInt64,
 value String
)
ORDER BY key

Si utiliza las tablas Replacing, Collapsing, Aggregating, Summing, VersionedCollapsing o Graphite MergeTree, se convertirán automáticamente al correspondiente motor de tabla basado en SharedMergeTree.

CREATE TABLE myFirstReplacingMT
(
    `key` Int64,
    `someCol` String,
    `eventTime` DateTime
)
ENGINE = ReplacingMergeTree
ORDER BY key;

Para una tabla determinada, puede comprobar qué motor de tabla se utilizó en la sentencia CREATE TABLE con SHOW CREATE TABLE:

SHOW CREATE TABLE myFirstReplacingMT;

CREATE TABLE default.myFirstReplacingMT
( `key` Int64, `someCol` String, `eventTime` DateTime )
ENGINE = SharedReplacingMergeTree('/clickhouse/tables/{uuid}/{shard}', '{replica}')
ORDER BY key

​

Configuración

El comportamiento de algunas opciones de configuración cambia de forma significativa:

• insert_quorum — todas las inserciones en SharedMergeTree son inserciones con cuórum (se escriben en almacenamiento compartido), por lo que esta configuración no es necesaria al usar el motor de tabla SharedMergeTree.
• insert_quorum_parallel — todas las inserciones en SharedMergeTree son inserciones con cuórum (se escriben en almacenamiento compartido), por lo que esta configuración no es necesaria al usar el motor de tabla SharedMergeTree.
• select_sequential_consistency — no requiere inserciones con cuórum y generará carga adicional en clickhouse-keeper en las consultas SELECT

​

Consistencia

SharedMergeTree proporciona una consistencia ligera mejor que ReplicatedMergeTree. Al insertar en SharedMergeTree, no es necesario especificar ajustes como insert_quorum o insert_quorum_parallel. Las inserciones se realizan con cuórum, lo que significa que los metadatos se almacenan en ClickHouse-Keeper y se replican al menos al cuórum de nodos de ClickHouse-Keeper. Cada réplica del clúster recuperará de forma asíncrona la información nueva desde ClickHouse-Keeper.

La mayoría de las veces, no debería usar select_sequential_consistency ni SYSTEM SYNC REPLICA LIGHTWEIGHT. La replicación asíncrona debería cubrir la mayoría de los escenarios y tiene una latencia muy baja. En el caso poco frecuente de que necesite evitar por completo las lecturas obsoletas, siga estas recomendaciones en este orden de preferencia:

1. Si ejecuta sus consultas en la misma sesión o en el mismo nodo para las lecturas y escrituras, no es necesario usar select_sequential_consistency, porque su réplica ya tendrá los metadatos más recientes.

2. Si escribe en una réplica y lee desde otra, puede usar SYSTEM SYNC REPLICA LIGHTWEIGHT para forzar a la réplica a recuperar los metadatos desde ClickHouse-Keeper.

3. Use select_sequential_consistency como ajuste de la consulta.

​

Visibilidad de ALTER y de las mutaciones

SharedMergeTree coordina los cambios de metadata a través de ClickHouse Keeper. Las réplicas obtienen la metadata modificada de forma asíncrona, por lo que un cambio de metadata no tiene por qué ser visible de inmediato en todas las réplicas. Las lecturas realizadas en la misma sesión y en el mismo nodo ya utilizan la metadata actualizada. Si una lectura debe ejecutarse en otra réplica justo después de un cambio de metadata, utilice SYSTEM SYNC REPLICA LIGHTWEIGHT para que esa réplica obtenga la metadata desde ClickHouse Keeper.

Las operaciones ALTER que generan mutaciones ejecutan en segundo plano un proceso que crea nuevas partes en el almacenamiento compartido y coordina su visibilidad a través de ClickHouse Keeper. No se trata de un proceso de reescritura o de transferencia de datos por réplica, como ocurre en ReplicatedMergeTree.

En ClickHouse Cloud, alter_sync tiene el valor predeterminado 0; configúrelo cuando un client deba esperar a que finalicen las operaciones de metadata o una reescritura MODIFY COLUMN que no afecte únicamente a la metadata. Para las operaciones UPDATE, DELETE y MATERIALIZE ..., utilice mutations_sync para controlar la espera y supervise el progreso en system.mutations.