Fuente original: https://bohutang.me/2020/09/18/clickhouse-and-friends-compute-storage/
Última actualización: 2020-09-18
Si varios servidores de ClickHouse pueden montar la misma pieza de datos (almacenamiento distribuido, etc.) y cada servidor puede escribir, ¿cuáles son los beneficios?
En primer lugar, podemos entregar el mecanismo de copia al almacenamiento distribuido para garantizar que la arquitectura de la capa superior se vuelva simple y simple;
En segundo lugar, el servidor de clickhouse se puede aumentar o disminuir en cualquier máquina, de modo que las capacidades de almacenamiento y computación se puedan utilizar por completo.
Este artículo discutirá el esquema de separación de almacenamiento y cálculo de ClickHouse, que no es complicado de implementar.
1. Problema
Los datos en tiempo de ejecución de ClickHouse constan de dos partes: metadatos de memoria y datos de disco.
Primero miramos el proceso de escritura:
w1. 开始写入数据
w2. 生成内存part信息，并维护part metadata列表
w3. 把part数据写到磁盘
Veamos el proceso de lectura:
r1. 从part metadata定位需要读取的part
r2. 从磁盘读取part数据
r3. 返回给上层数据
De esta manera, si el servidor1 escribe una parte de los datos, solo actualizará los metadatos de la parte en su propia memoria, y otros servidores no lo conocerán, por lo que los datos que se acaban de escribir no se pueden consultar.
La separación de almacenamiento y cálculo, lo primero que hay que resolver es la sincronización de los datos del estado de la memoria.
En ClickHouse, lo que tenemos que resolver es el problema de sincronización de los metadatos de las piezas en la memoria.
2. Sincronización de datos de memoria
En el artículo anterior < ReplicatedMergeTree Table Engine and Synchronization Mechanism >, conocemos el mecanismo de sincronización de datos entre réplicas: primero sincronizar los metadatos y luego obtener los datos de la pieza correspondiente a través de los metadatos.
Aquí, tomamos prestado el canal de sincronización ReplicatedMergeTree y luego hacemos la resta. Después de sincronizar los metadatos, se omite la sincronización de los datos de la pieza, porque los datos del disco solo necesitan ser actualizados por un servidor (se requiere la semántica fsync).
Código del núcleo: MergeTreeData :: renameTempPartAndReplace
if (!share_storage)
part->renameTo(part_name, true);
3. Demostración de demostración
guión:
Primero, inicie 2 servidores clickhouse, todos montan los mismos datos
<path>/home/bohu/work/cluster/d1/datas/</path>Escriba un registro a través de clickhouse-server1 (puerto 9101): (111, 3333)
La consulta a través de clickhouse-server2 (puerto 9102) es normal
Truncar tabla a través de clickhouse-server2 (puerto 9102)
La consulta a través de clickhouse-server1 (puerto 9101) es normal
4. Implementación del código
Prototipo (https://github.com/BohuTANG/ClickHouse/commit/f67d98ef408fda1a359e4fb17848619ef1f6e59b) Cabe señalar que aquí solo se implementa la sincronización de datos de escritura, y es una forma muy complicada.
Dado que DDL no está implementado, el método de registro en zookeeper también es complicado: todas las réplicas de la demostración se registran manualmente.
5. Resumen
Este artículo proporciona una idea, que puede considerarse una introducción, pero también espera una realización de ingeniería más sistemática.
ClickHouse aún no es compatible con la función de consulta distribuida. Si se admite esta capacidad, la separación de almacenamiento y cálculo de ClickHouse es una pequeña bomba de hidrógeno extremadamente poderosa.
Se acabó el texto completo.
Disfruta ClickHouse :)
La clase "MySQL Core Optimization" de Teacher Ye se ha actualizado a MySQL 8.0, escanee el código para comenzar el viaje de la práctica de MySQL 8.0