Puntos clave de ClickHouse

Acerca de los fragmentos, las réplicas y los nodos

ck tiene restricciones estrictas. Si es una sola copia, la desactivación de un fragmento hará que la tabla distribuida no esté disponible
La copia de 4 fragmentos 1 requiere 4 nodos ck y la copia de 3 fragmentos 2 requiere 6 nodos CK. El número de nodos CK es el número de fragmentos multiplicado por el número de copias. No se recomienda tener dos copias en un nodo. Si una Se requieren un nodo y dos copias Cree dos bases de datos nuevas y pase dinámicamente los valores de la base
La expansión del nodo no sincronizará automáticamente los datos antiguos. Hay dos formas de resolverlo. Los dos métodos siguientes necesitan volver a crear la tabla en el nuevo nodo
(1) Crear un nuevo clúster, seleccionar la función remota () para consultar el clúster A e insértelo en el clúster B. Cambie el nombre de la tabla original, cree una nueva tabla con el mismo esquema que la tabla original en todos los nodos, escriba datos en tiempo real en la nueva tabla y use la herramienta clickhouse-copiadora para migrar los datos históricos a la nueva tabla como un todo y luego elimine la tabla original. Por supuesto, durante la migración, la tabla reequilibrada no puede proporcionar servicios y todavía no es tan elegante.
(2) Ajuste el peso para que los datos se almacenen primero en el nuevo nodo y luego el peso se reajuste más tarde. Pero esto causará problemas obvios, y solo es efectivo para escribir directamente en la tabla distribuida, lo cual no es deseable.
2021.2.22
58 recién agregados usan copias múltiples de un solo fragmento , el motivo es el siguiente: https://xie.infoq.cn/article/ebfe0a6b0d6bdbbb4eae642ff
- El acoplamiento de BI con los datos de la capa de aplicación de almacenamiento de datos es generalmente de pequeña magnitud. Al mismo tiempo, clickhouse tiene una tasa de compresión de datos eficiente. Un solo nodo puede almacenar la cantidad total de datos de BI actuales y puede satisfacer las necesidades de almacenamiento de datos en el próximo pocos años.
- El número de simultaneidad predeterminado de Clickhouse es 100, usando un solo fragmento, cada nodo tiene la cantidad total de datos, cuando el qps es demasiado alto, puede aumentar el número de nodos horizontalmente para aumentar el número de simultaneidad.
- El soporte de unión de Clickhouse para tablas distribuidas es deficiente y los fragmentos individuales no utilizan la red, lo que puede mejorar la velocidad de consulta de unión.

Acerca de las particiones

Solo se fusionarán aquellos fragmentos de datos con el mismo valor de expresión de partición. Esto significa que no debe utilizar esquemas de particiones demasiado elaborados (más de mil particiones). De lo contrario, debido a que hay demasiados archivos en el sistema de archivos y demasiados descriptores de archivos que deben abrirse, la eficiencia de la consulta SELECT no es buena.

Acerca del mecanismo de sincronización de copia

La replicación es asincrónica multimaestro.
La instrucción INSERT (y ALTER) se puede ejecutar en cualquier servidor disponible. Los datos se insertan primero en el servidor local (es decir, el servidor que ejecuta la consulta) y luego se replican en otros servidores.

Dado que la replicación es asincrónica, habrá un cierto retraso para que los datos insertados recientemente aparezcan en otras réplicas.

Si algunas copias no están disponibles, escriba los datos cuando estén disponibles.

Si la copia está disponible, el tiempo de espera es el tiempo que se tarda en transmitir el bloque de datos comprimidos a través de la red.

De forma predeterminada, la operación INSERT solo necesita esperar a que se escriba correctamente una copia y luego regresar. Si los datos se escriben correctamente en una sola copia y el servidor para esa copia ya no existe, los datos almacenados se perderán. Para activar el mecanismo de confirmación de escritura de varias copias, use la opción insert_quorum.

insert_quorum: Habilite la escritura de arbitraje, cuántas copias se escriben para que se consideren exitosas. El valor predeterminado es 0. insert_quorum <2, la escritura de arbitraje está deshabilitada; insert_quorum> = 2, la escritura de arbitraje está habilitada.
Cuando los datos se escriben correctamente en insert_quorum de la copia durante el período insert_quorum_timeout, INSERT puede tener éxito. Si el número de copias escritas con éxito no alcanza el insert_quorum por algún motivo, se considera que la escritura ha fallado y el bloque insertado se eliminará de todas las copias de los datos escritos. Al leer datos escritos desde insert_quorum, puede usar la opción select_sequential_consistency. Cuando el número de copias disponibles de la consulta es menor que insert_quorum, se informará un error.
insert_quorum_timeout: Tiempo de espera de escritura de arbitraje (segundos), el valor predeterminado es 60 segundos. Si la escritura no se completa dentro del período de tiempo de espera, se generará una excepción y el cliente debe consultar repetidamente para escribir el mismo bloque en la misma copia o en cualquier otra.

Acerca de la copia de llamada de equilibrio de carga de consulta de tabla distribuida

执行分布式查询时，首先计算分片的每个副本的错误数，然后将查询发送至最少错误的副本。如果没有错误或者错误数相同，则按如下的策略查询数据：
1.random(默认) ：将查询发送至任意一个副本。
2.nearest_hostname : 将查询发送至主机名最相似的副本。
3.in_order : 将查询按配置文件中的配置顺序发送至副本。
4.first_or_random : 选择第一个副本，如果第一个副本不可用，随机选择一个可用的副本。

关于建表

建表时添加on cluster 可以只操作一次在多个节点上同时新建本地表

关于分布式表

直接在分布式表中插入数据数据落地规则：建分布式表时会有一个参数选择分片，一般是rand或者是hash，根据这个参数，还有weight权重这两个属性，决定数据落地那个分片
写数据到分布式表
优点：clickhouse控制数据到分片的路由
缺点：
（1）数据是先写到一个分布式表的实例中并缓存起来，再逐渐分发到各个分片上去，实际是双写了数据（写入放大），浪费资源
（2）数据写入默认是异步的，短时间内可能造成不一致
（3）目标表中会产生较多的小parts，使merge（即compaction）过程压力增大
相对而言，直接写本地表是同步操作，更快，parts的大小也比较合适，但是就要求应用层额外实现sharding和路由逻辑，如轮询或者随机等，在生产环境中推荐写本地表、读分布式表，可以引入第三方负载均衡工具，由第三方工具决定插入到那个表中，例如chproxy，或者Flink-ClickHouse Sink中实现随机路由，此处只是简单的随机分配，并未考虑集群负载占用的情况。https://www.jianshu.com/p/ab811cceb856
2021.2.22新增
- 负载均衡可以采用BalancedClickhouseDataSource轮询多个节点，druid已经有对应支持https://github.com/alibaba/druid/issues/3984使用简单；但是内部随机方式，可能会导致负载不均匀，虽然有定时检测机制，但是经测试，节点挂掉，请求直接报错；这种无法实现故障转移
- nginx实现SLB，既可以轮询，也可以做故障转移，国内大厂采用此方案
  
  （1）没有配置副本，非复制表（MergeTree），每个节点为一个shard的情况：数据只被插入到一个本地表中。当一个节点挂了之后查询分布表会报错。
  （2）配置副本，非复制表（MergeTree）：数据只被插入到一个本地表中，虽然做了副本，但是MergeTree 引擎的表并不会自动复制数据，所有数据还是只在一个节点上。当一个节点挂了之后查询分布表不会报错，但是挂了的节点的数据会丢失。
  （3）配置副本，复制表（ReplicatedMergeTree）：插入到分布式表中的数据仅插入到其中一个本地表中，但通过复制机制传输到另一个节点的表中，因此两个本地表上的数据保持同步。一个节点挂了之后可以正常提供服务，查询分布式表不会报错，数据未丢失。

private Request buildRequest(ClickhouseRequestBlank requestBlank) {
       
       
        String resultCSV = String.join(" , ", requestBlank.getValues());
        String query = String.format("INSERT INTO %s VALUES %s", requestBlank.getTargetTable(), resultCSV);
        String host = sinkSettings.getClickhouseClusterSettings().getRandomHostUrl();

        BoundRequestBuilder builder = asyncHttpClient
                .preparePost(host)
                .setHeader(HttpHeaders.Names.CONTENT_TYPE, "text/plain; charset=utf-8")
                .setBody(query);

        if (sinkSettings.getClickhouseClusterSettings().isAuthorizationRequired()) {
       
       
            builder.setHeader(HttpHeaders.Names.AUTHORIZATION, "Basic " + sinkSettings.getClickhouseClusterSettings().getCredentials());
        }

        return builder.build();
    }

    public String getRandomHostUrl() {
       
       
        currentHostId = ThreadLocalRandom.current().nextInt(hostsWithPorts.size());
        return hostsWithPorts.get(currentHostId);
    }