Resumen comparativo entre ClickHouse y Elasticsearch

Clickhouse es una base de datos analítica desarrollada por el gigante ruso de búsquedas Yandex con computación de almacenamiento de columnas completa. ClickHouse ha sido muy popular en el campo OLAP en los últimos dos años y las principales empresas nacionales de Internet lo utilizan a gran escala.

Elasticsearch es un motor de análisis de búsqueda distribuido casi en tiempo real cuyo almacenamiento subyacente está construido íntegramente en Lucene. En pocas palabras, amplía las capacidades de búsqueda independientes de Lucene para permitir capacidades de análisis y búsqueda distribuida. Elasticsearch generalmente proporciona funciones de análisis de búsqueda/registro de un extremo a otro junto con otros dos componentes de código abierto, Logstash (recopilación de registros) y Kibana (panel de control), y a menudo se lo denomina ELK.

Arquitectura distribuida

Elasticsearch y ClickHouse son productos de datos que admiten múltiples máquinas distribuidas . Lo primero que el autor debe comparar es la diferencia en la arquitectura distribuida entre los dos. El diseño de la estructura distribuida tiene un impacto muy importante en la facilidad de uso y la escalabilidad del producto. . En la arquitectura distribuida, varios problemas centrales que deben resolverse incluyen: descubrimiento de nodos, metasincronización y sincronización de datos de réplica. Como producto antiguo de código abierto, Elasticsearch es relativamente maduro en esta área. El descubrimiento de nodos nativos y el protocolo de sincronización Meta brindan a los usuarios una muy buena experiencia de usabilidad. Los problemas que el protocolo de sincronización Meta de Elasticsearch necesita resolver son en realidad muy similares al protocolo Raft de código abierto, pero Raft no existía cuando nació Elasticsearch, por lo que tuvimos que crear uno nosotros mismos. Después de tantos años de pulido, el protocolo de sincronización Meta de Elasticsearch también está bastante maduro. Basándose en esto, Elasticsearch tiene división de múltiples funciones, inferencia automática de esquemas y otras funciones muy fáciles de usar. Vale la pena mencionar que la sincronización de datos multicopia de Elasticsearch no reutiliza el protocolo de sincronización Meta, sino que utiliza el mecanismo tradicional de sincronización maestro-esclavo. El nodo maestro es responsable de sincronizar con el nodo de respaldo. Este método es más simple y eficiente. .

Las capacidades de la arquitectura distribuida de ClickHouse son relativamente simples, esto también se debe a que ClickHouse es todavía un producto de código abierto relativamente joven y aún se encuentra en la etapa de mejora iterativa continua en la facilidad de uso distribuido. ClickHouse presenta un clúster externo de ZooKeeper para emitir tareas DDL distribuidas (metacambios de nodo), tareas de sincronización activo-en espera y otras operaciones. La entrega de tareas de sincronización de datos (envío de datos) entre múltiples copias también depende del clúster ZooKeeper, pero al final la transmisión de datos entre múltiples copias es una copia de datos punto a punto a través del protocolo HTTP. Se puede escribir y la sincronización de datos es completamente multidireccional. En cuanto al descubrimiento de nodos, ClickHouse actualmente no tiene esta capacidad y debe resolverse configurando manualmente la dirección del nodo del clúster. La arquitectura distribuida andamiada actual de ClickHouse da como resultado que tenga capacidades de implementación flexibles extremadamente sólidas y capacidades de intervención de operación y mantenimiento. Es un poco menos utilizable para los usuarios y tiene un umbral de usuario relativamente alto. Sin embargo, en términos del límite superior de capacidades, la distribución de ClickHouse allí. No hay deficiencias en la escalabilidad de la implementación tradicional, y el límite superior del tamaño del clúster no es diferente del de Elasticsearch. ClickHouse tiene una arquitectura plana, sin distinción entre nodos front-end y nodos back-end, y puede implementar clústeres de cualquier tamaño. Al mismo tiempo, ClickHouse tiene capacidades de control más detalladas en la función de copia múltiple y puede configurar la cantidad de réplicas a nivel de tabla. El mismo clúster físico se puede dividir en múltiples clústeres lógicos y la cantidad de fragmentos y Las réplicas se pueden configurar arbitrariamente para cada máquina lógica.

Arquitectura de almacenamiento

Escribir diseño de enlace

búsqueda elástica

El rendimiento de escritura es un indicador central en escenarios de big data. Los requisitos de los usuarios para productos de big data no son solo almacenar datos rápidamente, sino también escribir rápidamente. Aquí primero presentamos el diseño del enlace de escritura en tiempo real de Elasticsearch: en cada fragmento de Elasticsearch, el proceso de escritura se divide en dos partes: primero escribir en Lucene y luego escribir en TransLog. Después de que la solicitud de escritura llega al Shard, primero se escribe el índice de memoria de Lucene. En este momento, los datos todavía están en la memoria y luego se escribe el TransLog. Después de escribir el TransLog, los datos del TransLog se actualizan en el disco. Después de escribir el TransLog, los datos del TransLog se actualizan en el disco. el disco se escribe correctamente, la solicitud se devuelve al usuario. Hay varios puntos clave aquí: uno es poner la escritura en Lucene al frente, principalmente para evitar que las solicitudes de escritura de los usuarios contengan datos "ilegales". En segundo lugar, después de escribir el índice de Lucene, no se puede buscar. Es necesario convertir el objeto de memoria en un segmento completo mediante una actualización y luego volver a abrirlo antes de que se pueda buscar. Este intervalo de tiempo de actualización es configurable por el usuario. Se puede ver que el índice Lucene no tiene la capacidad de escribir datos visibles en tiempo real, por lo que Elasticsearch es un sistema casi en tiempo real (Near Real Time). Finalmente, cada período de tiempo relativamente largo, como después de 30 minutos, Lucene actualizará el nuevo segmento generado en la memoria al disco. Después de la actualización, el archivo de índice ha persistido y el TransLog histórico será inútil y será borrado Antiguo TransLog.

Enlace de escritura de fragmento único de Elasticsearch

Enlace de escritura de fragmento único de ClickHouse

En comparación con el enlace de escritura de Elasticsearch, el método de escritura de ClickHouse es más "simple, directo" y extremo. Como se mencionó anteriormente, Elasticsearch es un sistema casi en tiempo real, y los datos recién escritos en el motor de almacenamiento de memoria deben vaciarse regularmente antes de ser visible. ClickHouse simplemente abandonó por completo la función del motor de almacenamiento de memoria, todos los datos se escribieron directamente en el disco y también se omitió la etapa tradicional de escritura del registro de rehacer. En escenarios con requisitos de rendimiento de escritura extremadamente altos, tanto Elasticsearch como ClickHouse deben renunciar a cierta visibilidad de escritura en tiempo real para mejorar el rendimiento. Es solo que el enfoque principal de ClickHouse es entregar la escritura de datos por lotes retrasada al cliente. Además, en términos de sincronización de copias múltiples, Elasticsearch requiere sincronización en tiempo real, es decir, las solicitudes de escritura deben escribirse en varias copias antes de devolverse, mientras que ClickHouse depende de ZooKeeper para la sincronización asincrónica de archivos de disco (envío de datos ) . En el combate real, el rendimiento de escritura de ClickHouse puede superar con creces el de Elasticsearch con las mismas especificaciones.

Segmento frente a parte de datos

Los diseños de almacenamiento de Elasticsearch y ClickHouse parecen muy similares por fuera, pero sus capacidades son completamente diferentes. El archivo de disco de Elasticsearch se compone de Segments . Segment es en realidad la unidad más pequeña del índice Lucene. El formato de almacenamiento interno de Segment no se discutirá aquí. Los segmentos se fusionarán de forma asincrónica en segundo plano. La fusión aquí resuelve principalmente dos problemas: 1) hacer que el índice secundario sea más ordenado; 2) completar el cambio de datos de la clave principal. El índice secundario es un índice ordenado "global". Construir todos los datos en un índice acelerará la consulta de manera más obvia que construirla en múltiples índices. Elasticsearch admite la eliminación y actualización de la clave principal, que se logra confiando en la función de eliminación del índice de Lucene. La operación de actualización se convertirá en una operación de eliminación más una operación de escritura. Cuando hay varios registros eliminados en el segmento de índice de Lucene, el sistema necesita eliminar estos registros mediante la fusión de segmentos. Cuando se combinan varios segmentos, los datos almacenados en el índice de Lucene muestran una combinación de solo anexos, de esta manera, la combinación del índice secundario no requiere "reordenamiento".

En comparación con Segment en Elasticsearch, la unidad más pequeña en el almacenamiento de ClickHouse es DataPart . Los datos escritos en lotes a la vez se colocarán en un DataPart. El almacenamiento de datos dentro de DataPart está en un estado completamente ordenado (ordenado según el orden por definición de tabla). Este almacenamiento ordenado es un índice agrupado predeterminado que se puede utilizar para acelerar el escaneo de datos. ClickHouse también realizará una fusión asincrónica de DataParts, y su fusión también se utiliza para resolver dos problemas: 1) hacer que el almacenamiento de datos sea más ordenado; 2) completar los cambios de datos de clave principal. DataPart se comporta de manera ordenada por fusión al fusionar y almacenar datos, y el DataPart generado después de la fusión todavía está en un estado completamente ordenado. Basándose en la configuración completamente ordenada del almacenamiento de DataPart, ClickHouse implementa actualizaciones de datos de clave primaria de una manera completamente diferente a Elasticsearch. Cuando Elasticsearch cambia la clave principal, adopta el método "primero verifique el registro original, genere un nuevo registro, elimine el registro original, escriba un nuevo registro". Este método limita por completo la eficiencia de la actualización de la clave principal. y agregar: La diferencia de eficiencia de escribir solo es muy grande. La actualización de la clave principal de ClickHouse es completamente asincrónica. Varios registros con la misma clave principal producirán los resultados de registro más recientes cuando se fusionen de forma asincrónica. Este método de actualización de clave primaria por lotes asincrónicos es más eficiente que Elasticsearch.

Finalmente, resumamos las diferencias en las capacidades de almacenamiento de archivos internos de Segment y DataPart. Segment es completamente el formato de almacenamiento del índice Lucene. El almacenamiento del índice Lucene en archivos invertidos es sin duda el mejor. El índice Lucene también proporciona almacenamiento en filas y columnas. Almacenamiento de datos brutos en diferentes formatos. Elasticsearch almacenará los datos originales en dos copias de forma predeterminada, una en el almacén de filas y otra en el almacén de columnas. Elasticsearch seleccionará el archivo de almacenamiento apropiado para escanear según el patrón de consulta. No hay un archivo de índice secundario en el DataPart de ClickHouse nativo y los datos se almacenan completamente en columnas. ClickHouse logra lo último en tasa de compresión de columnas y rendimiento de escaneo. En términos relativos, el almacenamiento en Elasticsearch es mediocre y cuesta al menos el doble.

Hablemos de Schemaless otra vez

Cuando se habla de las características de Elasticsearch, todos mencionarán la palabra Schemaless. Elasticsearch puede inferir automáticamente el esquema json de los datos escritos y ajustar la metaestructura de la tabla de almacenamiento de acuerdo con el esquema json de los datos escritos. Esto puede ayudar a los usuarios a ahorrar mucho tiempo creando tablas y Problemas con Gallie. Sin embargo, en opinión del autor, esta capacidad de Elasticsearch en realidad se llama más apropiadamente inferencia automática de esquemas, que se beneficia de las capacidades de metasincronización distribuida de Elasticsearch. El almacenamiento de Elasticsearch en realidad requiere un esquema, o incluso un esquema fuertemente vinculado, porque es un almacenamiento con índices secundarios como núcleo. ¿Cómo se puede construir un índice para campos sin tipos? El verdadero Schemaless debería ser la capacidad de cambiar los tipos de campos de manera flexible y eficiente, garantizando al mismo tiempo que el rendimiento de las consultas no disminuya significativamente. Hoy en día, si un usuario quiere cambiar un determinado tipo de campo en el índice de Elasticsearch, solo hay una forma: volver a indexar todos los datos. Por el contrario, el almacenamiento de ClickHouse no está fuertemente ligado al esquema, porque las capacidades de análisis de ClickHouse se basan en el escaneo del almacenamiento. Puede realizar una conversión de tipo dinámica durante el escaneo de datos y también puede ajustar los campos de manera lenta y asincrónica cuando se fusionan los DataParts. El cambio causado por el tipo de campo durante la consulta es el costo de aumentar el operador de transmisión durante el tiempo de ejecución, y los usuarios no experimentarán una fuerte caída en el rendimiento. El autor cree que Schemeless definitivamente no es la capacidad de foso de Elasticsearch, sino más bien su debilidad. En cuanto a la inferencia automática de esquemas, esta es una capacidad muy amigable para usuarios de pequeña escala, pero nunca podrá ayudar a los usuarios a crear el esquema de mejor rendimiento. En escenarios con grandes volúmenes de datos, aún es necesario crear esquemas basados en requisitos de consulta específicos. Al final, toda comodidad tiene un coste.

Esquema de consulta

motor de computación

Juntar ClickHouse y Elasticsearch aquí para hablar sobre motores informáticos es en realidad un poco ridículo, porque Elasticsearch solo implementa un motor de búsqueda general. La complejidad de las consultas que puede manejar un motor de búsqueda es cierta y tiene un límite superior. Todas las consultas de búsqueda pueden obtener resultados después de un cierto número de etapas, pero este no es el caso de los motores informáticos. Aunque Elasticsearch también tiene complementos compatibles con SQL, la lógica de implementación de este complemento es traducir consultas SQL simples en ciertos patrones de búsqueda. Para comportamientos de análisis de datos que los motores de búsqueda no admiten originalmente, Elasticsearch-SQL no resulta de ayuda. Además, las capacidades de traducción actuales de Elasticsearch-SQL no parecen ser muy completas e inteligentes. Para obtener el mayor rendimiento de búsqueda, los usuarios aún deben probar la API de consulta nativa de Elasticsearch. Para los usuarios que están acostumbrados a usar SQL, la API de consultas de Elasticsearch es un sistema completamente desconocido y las consultas complejas son muy difíciles de escribir.

El motor de búsqueda de Elasticsearch admite tres modos de búsqueda diferentes: query_and_fetch, query_then_fetch y dfs_query_then_fetch. El primer modo es muy simple: cada nodo distribuido busca de forma independiente y devuelve los resultados al cliente. El segundo modo es que cada nodo de almacenamiento distribuido primero busca su ID de registro TopN y su puntuación correspondiente, y luego los agrega en Después de consultar el nodo de solicitud , realice una reorganización para obtener los resultados finales de TopN y finalmente solicite al nodo de almacenamiento que extraiga datos detallados. El propósito de diseñar dos rondas de solicitudes aquí es minimizar la cantidad de detalles de extracción, es decir, la cantidad de escaneos del disco. El último método consiste en equilibrar los estándares de puntuación de cada nodo de almacenamiento, primero contar la TF (frecuencia de términos) y la DF (frecuencia de documentos) globales y luego realizar query_then_fetch. El motor de búsqueda de Elasticsearch no tiene las capacidades de procesamiento de transmisión de un motor informático de base de datos, sino que es un procesamiento de datos de solicitud-respuesta completamente por turnos. Cuando el usuario necesita devolver una gran cantidad de datos, es fácil que la consulta falle o active GC. En términos generales, el límite superior de las capacidades del motor de búsqueda de Elasticsearch es una consulta de dos etapas, y consultas como la asociación de múltiples tablas están completamente más allá de su límite superior.

El motor informático de ClickHouse se caracteriza por una vectorización extrema. Las funciones vectorizadas y los operadores de agregación completamente escritos a mano en plantillas C++ hacen que su rendimiento de procesamiento en consultas de agregación alcance el extremo. Junto con la última capacidad de escaneo paralelo del almacenamiento, los recursos de la máquina se pueden utilizar al máximo con facilidad. Las capacidades del motor informático de ClickHouse pueden cubrir completamente el motor de búsqueda Elasticsearch en términos de soporte de consultas de análisis. El motor informático con capacidades SQL completas puede permitir a los usuarios ser más flexibles y libres al procesar el análisis de datos.

Escaneo de datos

ClickHouse es un motor informático de almacenamiento completamente en columnas y se basa en el almacenamiento ordenado. En el proceso de consulta y escaneo de datos, primero inferirá la necesidad de escanear en función del orden del almacenamiento, las estadísticas del bloque de almacenamiento en columnas, las claves de partición y otra información. .Bloque de almacenamiento de columnas y luego realiza un escaneo de datos paralelo, como el cálculo de expresiones y los operadores de agregación, todos los cuales se procesan en un motor de cálculo normal. Desde el motor informático hasta el escaneo de datos, el flujo de datos se basa en bloques de almacenamiento de columnas y está altamente vectorizado . Como se mencionó en la sección anterior, el escaneo de datos de Elasticsearch ocurre principalmente en las etapas de consulta y recuperación. La fase de consulta escanea principalmente el archivo de índice de Lucene para obtener el DocId alcanzado por la consulta y también incluye escanear el archivo de almacenamiento de columnas para realizar cálculos de agregación. La etapa de recuperación verifica principalmente el archivo de almacenamiento de filas leyendo resultados detallados en el índice de Lucene. El cálculo de expresiones y el cálculo de agregación pueden ocurrir en ambas fases, y su lógica de cálculo se realiza en unidades de fila. En general, el escaneo y los cálculos de datos de Elasticsearch no tienen la capacidad de vectorizar y se basan en los resultados del índice secundario. Cuando el número de filas de resultados devueltas por el índice secundario es particularmente grande (consultas analíticas que involucran grandes cantidades de datos) , su motor de búsqueda expondrá sus deficiencias en capacidades insuficientes de procesamiento de datos.

Hablemos nuevamente de alta concurrencia

Muchos usuarios tendrán una imagen equivocada cuando hablen de ClickHouse. Las consultas de ClickHouse se ejecutan rápidamente, pero la concurrencia no es buena. Pero la razón detrás de esto es en realidad que el paralelismo de ClickHouse es tan asombroso . Esta es una de las principales fortalezas de ClickHouse. Una consulta puede maximizar completamente el rendimiento del disco. El paralelismo de las consultas no depende en absoluto de los fragmentos y se puede ajustar a voluntad. Es innegable que la capacidad de procesamiento de solicitudes concurrentes es el indicador definitivo de la eficiencia de un sistema de datos. No hay fallas naturales de concurrencia en la arquitectura de ClickHouse. Simplemente es un chico íntegro. La cantidad de datos y la complejidad computacional que deben escanearse en busca de consultas están ahí. ClickHouse simplemente lo calcula honestamente cada vez y las capacidades de hardware de la máquina determinan su límite superior de concurrencia.. La capacidad de concurrencia de ClickHouse es realmente buena, es un malentendido pensar que no es capaz de concurrencia. Pero de forma predeterminada, el objetivo de ClickHouse es garantizar que la latencia de una única consulta sea lo suficientemente baja; en algunos escenarios, los usuarios pueden mejorar las capacidades de concurrencia configurando los parámetros apropiados del sistema, como max_threads, etc. Por el contrario, aquí se ofrece una introducción de por qué las capacidades de concurrencia de Elasticsearch son muy buenas en algunos escenarios. En primer lugar, desde la perspectiva del diseño de la caché, la caché de Elasticsearch incluye la caché de consultas, la caché de solicitudes, la caché de datos y la caché de índice. La aceleración de la caché desde los resultados de la consulta hasta los resultados del análisis del índice se debe a que Elasticsearch cree que hay datos calientes en sus escenarios, lo que puede Fue consultado repetidamente. Por el contrario, ClickHouse solo tiene un UnCompressedBlockCache orientado a IO y un PageCache del sistema. Debido a que ClickHouse se basa en escenarios de análisis y consultas, los datos y las consultas en el escenario de análisis son modificables y los resultados de las consultas y otros cachés no son fáciles de alcanzar, por lo que el enfoque de ClickHouse es centrarse siempre en los datos del disco y tener buenas capacidades de caché de IO. . En segundo lugar, volviendo a la granularidad del escaneo de datos, Elasticsearch tiene capacidades de índice secundario de columna completa. Estos índices generalmente se precalientan y cargan en la memoria con anticipación. Incluso bajo condiciones de consulta cambiantes, el costo de los resultados de la consulta de índice es muy bajo. resultados del índice, puede leer los datos fila por fila y realizar cálculos. El ClickHouse nativo no tiene la capacidad de indexación secundaria y solo puede escanear datos en lotes grandes para filtrar los resultados bajo condiciones de consulta cambiantes (Alibaba Cloud ClickHouse ya tiene la capacidad de indexación secundaria, lo que resuelve este problema y su nivel de rendimiento es el mismo que el de Elasticsearch) Bastante, los detalles se presentarán en la sección de evaluación de desempeño posterior). Pero si Elasticsearch tiene índices secundarios, ¿serán mejores sus capacidades de concurrencia? No necesariamente. Cuando el conjunto de resultados obtenido por la búsqueda de índice secundario es grande, la consulta seguirá acompañada de una gran cantidad de escaneos de IO y la alta concurrencia estará fuera de discusión a menos que la caché de datos de Elasticsearch sea lo suficientemente grande como para cargar. todos los datos originales en la memoria.

En resumen , Elasticsearch solo puede mostrar sus ventajas de concurrencia en un escenario de búsqueda completo (donde el número de registros después del filtrado es pequeño) y en un entorno operativo con suficiente memoria. En escenarios de análisis (donde la cantidad de registros después del filtrado es grande), ClickHouse logrará un mejor rendimiento de concurrencia con su almacenamiento de columnas definitivo y cálculos vectorizados. Los dos tienen enfoques diferentes: al mismo tiempo, las capacidades de procesamiento concurrente de ClickHouse se basan en el rendimiento del disco, mientras que las capacidades de procesamiento concurrente de Elasticsearch se basan en la memoria caché. ClickHouse es más adecuado para escenarios de análisis de gran volumen y bajo costo y puede aprovechar al máximo las capacidades del ancho de banda del disco.

Pruebas de rendimiento

casa de clics	búsqueda elástica	Número de nodos
CPU: 8 núcleos Memoria: 32 GB Almacenamiento: ESSD PL1 1500 GB	CPU: 8 núcleos Memoria: 32 GB Almacenamiento: ESSD PL1 1500 GB	4

Escenario de análisis de registros

En el escenario de análisis de registros, se seleccionaron dos escenarios de consulta representativos para pruebas comparativas y los resultados son los siguientes. Del análisis de resultados se puede ver que la brecha de rendimiento entre ClickHouse y Elasicsearch en los dos escenarios se expande a medida que aumenta el número de registros filtrados por la condición donde aumenta. En el escenario trace_log con una mayor cantidad de datos, la brecha de rendimiento de la consulta de análisis entre los dos es claro de un vistazo. Descargue la versión completa de consultas y declaraciones de creación de tablas de Elasticsearch y ClickHouse: escenario de análisis de registros

access_log (volumen de datos 197921836)

La declaración de creación de la tabla en ClickHouse es la siguiente:

CREATE TABLE access_log_local on cluster default
(
  `sql` String, 
  `schema` String, 
  `type` String, 
  `access_ip` String, 
  `conn_id` UInt32, 
  `process_id` String, 
  `logic_ins_id` UInt32, 
  `accept_time` UInt64, 
  `_date` DateTime, 
  `total_time` UInt32, 
  `succeed` String, 
  `inst_name` String
) 
ENGINE = MergeTree()
PARTITION BY toYYYYMMDD(_date)
ORDER BY (logic_ins_id, accept_time);

CREATE TABLE access_log on cluster default as access_log_local
engine = Distributed(default, default, access_log_local, rand());

La declaración de consulta en ClickHouse es la siguiente:

--Q1
select _date, accept_time, access_ip, type, total_time, concat(toString(total_time),'ms') as total_time_ms, sql,schema,succeed,process_id,inst_name from access_log where _date >= '2020-12-27 00:38:31' and _date <= '2020-12-28 00:38:31' and logic_ins_id = 502680264 and accept_time <= 1609087111000 and accept_time >= 1609000711000 and positionCaseInsensitive(sql, 'select') > 0 order by accept_time desc limit 50,50;
--Q2
select 
case 
when total_time <=100 then 1 
when total_time > 100 and total_time <= 500 then 2 
when total_time > 500 and total_time <= 1000 then 3 
when total_time > 1000 and total_time <= 3000 then 4 
when total_time > 3000 and total_time <= 10000 then 5 
when total_time > 10000 and total_time <= 30000 then 6 
else 7 
end as reorder, 
case 
when total_time <=100 then '0~100ms' 
when total_time > 100 and total_time <= 500 then '100ms~500ms' 
when total_time > 500 and total_time <= 1000 then '500ms~1s' 
when total_time > 1000 and total_time <= 3000 then '1s~3s' 
when total_time > 3000 and total_time <= 10000 then '3s~10s' 
when total_time > 10000 and total_time <= 30000 then '10s~30s' 
else '30s以上' 
end as label, 
case 
when total_time <= 100 then '0~100' 
when total_time > 100 and total_time <= 500 then '100~500' 
when total_time > 500 and total_time <= 1000 then '500~1000' 
when total_time > 1000 and total_time <= 3000 then '1000~3000' 
when total_time > 3000 and total_time <= 10000 then '3000~10000' 
when total_time > 10000 and total_time <= 30000 then '10000~30000' 
else '30000~10000000000' 
end as vlabel, 
count() as value
from access_log
where logic_ins_id = 502867976 and _date >= '2020-12-27 00:38:31' and _date <= '2020-12-28 00:38:31' and accept_time <= 1609087111000 and accept_time >= 1609000711000 
group by label,vlabel,reorder 
order by reorder;
--Q3
select toStartOfMinute(_date) as time, count() as value 
from access_log 
where logic_ins_id = 500152868 and accept_time <= 1609087111000 and accept_time >= 1609000711000  
group by time 
order by time;
--Q4
select count(*) as c from (
  select _date, accept_time, access_ip, type, total_time, concat(toString(total_time),'ms') as total_time_ms, sql, schema, succeed, process_id, inst_name 
  from access_log 
  where logic_ins_id = 501422856 and _date >= '2020-12-27 00:38:31' and _date <= '2020-12-28 00:38:31' and accept_time <= 1609087111000 and accept_time >= 1609000711000
);

La comparación de rendimiento es la siguiente:

trace_log (volumen de datos 569816761)

La declaración de creación de la tabla en ClickHouse es la siguiente:

CREATE TABLE trace_local on cluster default
(
  `serviceName` LowCardinality(String), 
  `host` LowCardinality(String), 
  `ip` String, 
  `spanName` String, 
  `spanId` String, 
  `pid` LowCardinality(String), 
  `parentSpanId` String, 
  `ppid` String, 
  `duration` Int64, 
  `rpcType` Int32, 
  `startTime` Int64, 
  `traceId` String, 
  `tags.k` Array(String), 
  `tags.v` Array(String), 
  `events` String,
  KEY trace_idx traceId TYPE range
) ENGINE = MergeTree() 
PARTITION BY intDiv(startTime, toInt64(7200000000)) 
PRIMARY KEY (serviceName, host, ip, pid, spanName) 
ORDER BY (serviceName, host, ip, pid, spanName, tags.k);

CREATE TABLE trace on cluster default as trace_local
engine = Distributed(default, default, trace_local, rand());

La declaración de consulta en ClickHouse es la siguiente:

--Q1
select *
from trace
prewhere
traceId ='ccc6084420b76183'
where startTime > 1597968000300000  and startTime <  1598054399099000 settings max_threads = 1;
--Q2
select count(*) count, spanName as name from trace
where serviceName ='conan-dean-user-period'
and startTime > 1597968000300000  and startTime <  1598054399099000
group by spanName
order by count desc limit 1000;
--Q3
select host as name, count(*) count
from trace
where serviceName ='conan-dean-user-period'
and startTime > 1597968000300000  and startTime <  1598054399099000
group by host;
--Q4
select count(*) count, tags.k as name  from trace
array join tags.k
where serviceName ='conan-dean-user-period'
and startTime > 1597968000300000  and startTime <  1598054399099000
group by tags.k;
--Q5
select count(*) spancount, 
sum(duration) as sumDuration, intDiv(startTime, 1440000000) as timeSel
from trace
where serviceName ='conan-dean-user-period'
and startTime > 1597968000300000  and startTime <  1598054399099000
group by timeSel;
--Q6
select count(*) spanCount, 
countIf(duration  <=1000000), countIf(duration > 1000000),  countIf(duration > 3000000)
from trace
where serviceName ='conan-dean-user-period'
and startTime > 1597968000300000  and startTime <  1598054399099000;
--Q7
select  host, startTime,traceId,spanName,duration,tags.k,tags.v
from trace
where serviceName ='conan-dean-user-period'
and startTime > 1597968000300000  and startTime <  1598054399099000 limit 1000000;

La comparación de rendimiento es la siguiente:

Conjunto de prueba oficial Ontime

El conjunto de pruebas Ontime es un punto de referencia de consultas analíticas recomendado en el sitio web oficial de ClickHouse para comparar las diferencias de rendimiento entre ClickHouse y Elasticsearch en consultas analíticas de una manera más justa y abierta. El autor también presentó este conjunto de datos para prueba y comparación. Los resultados son los siguientes: ClickHouse tiene una gran ventaja de rendimiento en escenarios de consultas puramente analíticas. Descargue la versión completa de consultas y declaraciones de creación de tablas de Elasticsearch y ClickHouse: escenario de análisis de agregación

Escenario de retrato de usuario (volumen de datos 262933269)

El escenario de retrato de usuario también es un escenario típico en el que es difícil para los usuarios elegir entre usar Elasticsearch o ClickHouse. Las características específicas de este escenario son tablas ultragrandes, grandes actualizaciones y escrituras por lotes, grandes cantidades de datos devueltos por consultas, y condiciones de filtrado complejas y cambiantes. Hay dos dificultades principales que encuentran los usuarios al utilizar Elasticsearch: los datos no se pueden escribir y la importación es lenta; los datos no se pueden extraer y la devolución de datos detallados a gran escala es muy lenta. En respuesta a este escenario, el autor se burló de una tabla grande y ancha con casi 150 columnas basadas en escenarios comerciales de usuarios reales para realizar pruebas de consultas relacionadas. Las consultas específicas son las siguientes. El conjunto de resultados devuelto por cada consulta oscila entre 100.000 y 1 millón de filas. .nivel. Descargue la versión completa de las declaraciones y consultas de creación de tablas de Elasticsearch y ClickHouse: escenario de retrato de usuario

La declaración de consulta en ClickHouse es la siguiente:

--Q1
select user_id
from person_tag
where mock3d_like > 8 and mock3d_consume_content_cnt > 8 and mock_10_day_product_avg_amt < 1 settings append_squashing_after_filter = 1;
--Q2
select user_id
from person_tag
where mock_7_day_receive_cnt > 8 and like_fitness = 1 and mock14d_share_cnt > 8 settings append_squashing_after_filter = 1;
--Q3
select user_id
from person_tag
where home_perfer_mock_score > 8 and mock7d_access_homepage_cnt > 8 settings append_squashing_after_filter = 1;
--Q4
select user_id
from person_tag
where is_send_register_coupon > 8 and mock1d_like > 8 settings append_squashing_after_filter = 1;
--Q5
select user_id
from person_tag
where like_sports = 1 and like_3c = 1 and sex = 1 and like_dance = 1 and mock1d_share_cnt > 6 settings append_squashing_after_filter = 1;
--Q6
select user_id
from person_tag
where mock14d_access_homepage_cnt > 8 and like_anime = 1 settings append_squashing_after_filter = 1;
--Q7
select user_id,offline_ver,is_visitor,mock1d_comment_like,reg_days,mock14d_share_cnt,mock_30_order_avg_delivery_time_cnt,mock7d_comment_cnt,performance_rate,mock3d_valid_user_follow_cnt,mock30d_consume_content_cnt,like_cnt,like_photo,ls90_day_access_days,mock3d_release_trend_cnt,mock14d_access_homepage_range,qutdoor_perfer_mock_score,mock3d_access_homepage_cnt,mock_15_order_avg_delivery_time_cnt,mock7d_release_trend_cnt,like_food,mock30d_follow_topic_cnt,mock7d_is_access_topic,like_music,mock3d_interactive_cnt,mock14d_valid_user_follow_cnt,reg_platform,mock_7_day_lottery_participate_cnt,pre_churn_users,etl_time,like_anime,mock14d_access_homepage_cnt,mock14d_consume_content_cnt,like_travel,like_watches,mock14d_comment_like,ls30_day_access_days,mock14d_release_trend_cnt,ftooeawr_perfer_mock_score,mock7d_valid_user_follow_cnt,beauty_perfer_mock_score
from person_tag
where mock3d_like > 8 and mock3d_consume_content_cnt > 8 and mock_10_day_product_avg_amt < 1 settings append_squashing_after_filter = 1;

La comparación de los resultados del rendimiento de la consulta es la siguiente. Se puede ver que Elasticsearch funciona muy bien en escenarios donde se escanea y exporta una gran cantidad de datos de resultados. Cuanto mayor es el conjunto de resultados devuelto, más lento es. La Q5 es un caso de comparación en el que el conjunto de resultados de aciertos de la consulta es muy pequeño.

Escenario de enumeración del índice secundario (volumen de datos 1000000000)

En el escenario empresarial de análisis y consultas, los usuarios inevitablemente tendrán varios casos de consultas detalladas, como consultar información detallada basada en el log traceId. Debido a que ClickHouse de código abierto no tiene capacidades de indexación secundaria, cuando se encuentra esta situación, el rendimiento de la consulta queda completamente por detrás de Elasticsearch. Alibaba Cloud ClickHouse ha desarrollado sus propias capacidades de indexación secundaria para compensar sus deficiencias. El autor ha agregado especialmente aquí un escenario de verificación de índice secundario para pruebas de comparación de rendimiento. Descargue la versión completa de consultas y declaraciones de creación de tablas de Elasticsearch y ClickHouse: escenario de verificación de índice secundario

La declaración de creación de la tabla en ClickHouse es la siguiente:

CREATE TABLE point_search_test_local on cluster default (
 `PRI_KEY` String, 
 `SED_KEY` String,  
 `INT_0` UInt32, 
 `INT_1` UInt32, 
 `INT_2` UInt32, 
 `INT_3` UInt32, 
 `INT_4` UInt32, 
 `LONG_0` UInt64, 
 `LONG_1` UInt64, 
 `LONG_2` UInt64, 
 `LONG_3` UInt64, 
 `LONG_4` UInt64, 
 `STR_0` String, 
 `STR_1` String, 
 `STR_2` String, 
 `STR_3` String, 
 `STR_4` String, 
 `FIXSTR_0` FixedString(16), 
 `FIXSTR_1` FixedString(16), 
 `FIXSTR_2` FixedString(16), 
 `FIXSTR_3` FixedString(16), 
 `FIXSTR_4` FixedString(16), 
 KEY SED_KEY_IDX SED_KEY Type range
) ENGINE = MergeTree ORDER BY PRI_KEY 
SETTINGS index_granularity_bytes = 4096, secondary_key_segment_min_rows = 1000000000, min_rows_for_wide_part = 2000000000;

CREATE TABLE point_search_test on cluster default as point_search_test_local
engine = Distributed(default, default, point_search_test_local, rand());

La declaración de la plantilla de consulta en ClickHouse es la siguiente:

select * from point_search_test where SED_KEY = 'XXX' settings max_threads = 1;

La comparación final del rendimiento de la consulta es la siguiente: después de que Alibaba Cloud ClickHouse tiene capacidades de indexación secundaria, sus capacidades de consulta no son más débiles que Elasticsearch, y el almacenamiento admite de forma nativa capacidades de indexación secundaria y tiene el máximo rendimiento. (Documento de índice secundario de Alibaba Cloud ClickHouse)

Comparación del rendimiento de la importación de datos

Para todos los conjuntos de datos enumerados anteriormente, el autor utilizó el método de importación de archivos locales ESSD para probar y comparar el rendimiento de importación de Elasticsearch y ClickHouse. ClickHouse puede usar ClickHouse-Client directamente para leer archivos locales en varios formatos para importar, mientras que Elasticsearch configura las tareas de Logstash. Los resultados específicos que requieren mucho tiempo son los siguientes:

Conclusión

Lo que Elasticsearch hace mejor es principalmente el escenario de búsqueda completa (donde la cantidad de registros después del filtrado es pequeña) y puede mostrar excelentes capacidades de consulta simultánea en un entorno operativo rico en memoria. Sin embargo, en escenarios de análisis de datos a gran escala (donde la cantidad de registros después del filtrado es grande), ClickHouse tendrá un mejor rendimiento de concurrencia debido a su almacenamiento de columnas definitivo y cálculos vectorizados, y el soporte de consultas también es más completo. Las capacidades de procesamiento concurrente de ClickHouse se basan en el rendimiento del disco, mientras que las capacidades de procesamiento concurrente de Elasticsearch se basan en la memoria caché, lo que hace que el rango de costos de los dos sea muy diferente. ClickHouse es más adecuado para escenarios de análisis de gran volumen y bajo costo, y puede Aproveche al máximo las capacidades de ancho de banda del disco. En términos de costos de importación y almacenamiento de datos, ClickHouse tiene una ventaja absoluta.

ventaja

ClickHouse tiene un alto rendimiento de escritura, con un volumen de escritura de registros de un solo servidor que oscila entre 50 MB y 200 MB/s, y más de 600.000 registros escritos por segundo, que es más de 5 veces mayor que ES.
La velocidad de consulta es rápida. Oficialmente, la velocidad de consulta de un solo servidor es de aproximadamente 2-30 GB/s cuando los datos están en el caché de página; cuando los datos no están en el caché de página, la velocidad de consulta depende de la velocidad de lectura del disco y del tasa de compresión de datos. .
ClickHouse cuesta menos que ES Server. Por un lado, ClickHouse tiene una relación de compresión de datos más alta que ES, y el espacio en disco ocupado por los mismos datos es solo de 1/3 a 1/30 de ES, lo que ahorra espacio en disco y también puede reducir efectivamente la E/S del disco; Por otro lado, ClickHouse ocupa más espacio que ES y menos memoria consume menos recursos de CPU. .
En comparación con ES, ClickHouse tiene mayor estabilidad y menores costos de operación y mantenimiento. La carga de diferentes grupos en ES está desequilibrada. Algunos grupos tienen una carga alta, lo que provocará problemas como escrituras rechazadas, lo que requerirá la migración manual de índices. En ClickHouse, a través de la estrategia de clúster y Shard, el método de escritura de sondeo puede hacer que los datos distribuidos más uniformemente a todos los nodos. Una consulta grande en ES puede causar problemas de OOM; ClickHouse fallará la consulta a través de las restricciones de consulta preestablecidas sin afectar la estabilidad general. ES necesita separar los datos fríos y calientes. ClickHouse particiona según el talento. Generalmente, no es necesario considerar la separación fría y caliente. En escenarios especiales, los usuarios necesitan separar los datos fríos y calientes, y la cantidad de datos será mucho Más pequeño El propio mecanismo de separación de frío y calor de ClickHouse puede fácilmente ser una buena solución.
ClickHouse utiliza la sintaxis SQL, que es más simple que el DSL de ES y tiene menores costos de aprendizaje.

defecto

Debido a que es una base de datos en columnas, no puede proporcionar funciones de búsqueda de texto completo como ES.
Los campos no se pueden agregar dinámicamente y el esquema de la tabla debe definirse con anticipación.
Los registros no se pueden guardar durante mucho tiempo y los datos históricos deben limpiarse y desconectarse con regularidad. Si es necesario guardar datos históricos, es necesario migrarlos mediante ClickHouse_copier o copiar los datos.
ClickHouse tiene una velocidad de consulta rápida y puede hacer un uso completo de los recursos del clúster, pero no puede admitir consultas muy concurrentes. La configuración predeterminada qps es 100.
Clickhouse no es adecuado para la inserción de alta frecuencia de muchos datos pequeños y habrá un cierto retraso en la escritura de registros por lotes.

El mismo tipo de registros de Ctrip ocupa espacio en disco en ES y ClickHouse

Ctrip mismo tipo de tiempo de consulta de registro en ES y ClickHouse

Solución factible para reemplazar ES con ClickHouse

1. Implementación de recuperación ante desastres y planificación de clústeres

Utilizando múltiples fragmentos y 2 réplicas, se realiza una copia de seguridad de los servidores entre sí a través de Zookeeper, lo que permite que un fragmento y un servidor estén inactivos sin perder datos. Para acceder a registros de diferentes tamaños, se pueden establecer varios clústeres según el tipo y el volumen de registro.

2. Datos de consumo a ClickHouse usando la herramienta gohangout

a) Utilice el sondeo para escribir en todos los servidores del clúster de ClickHouse para garantizar que los datos se distribuyan básicamente de manera uniforme.

b) Grandes lotes de escrituras de baja frecuencia reducen la cantidad de partes, reducen la fusión del servidor y evitan excepciones de demasiadas partes. La cantidad y frecuencia de la escritura de datos se controla a través de dos umbrales: los registros que superan los 10 W se escriben una vez o cada 30 segundos.

3. Diseño de estructura de mesa.

Cree diferentes tablas locales según los tipos de registro. Los campos no estándar se pueden configurar según el tipo de mapa. Si hay un valor, rellénelo con valor. Si no hay ningún valor, rellénelo directamente con N.

Al crear una tabla, considere la configuración de las particiones y divida las particiones según sus talentos.

4. Visualización de datos

Tabix, la interfaz web que viene con Clickhouse.

Se pueden conectar interfaces visuales de terceros a Grafana y kibana

Link de referencia

https://zhuanlan.zhihu.com/p/368193306

https://www.cnblogs.com/xionggeclub/p/15100707.html