es un sistema de gestión de bases de datos en columnas de código abierto para el procesamiento de consultas analíticas en línea (OLAP) creado por Yandex. Lo utilizan Yandex, CloudFlare, VK.com, Badoo y otros servicios de todo el mundo para almacenar cantidades realmente grandes de datos (inserción de miles de filas por segundo o petabytes de datos almacenados en el disco).
En un DBMS normal de "cadena", ejemplos de los cuales son MySQL, Postgres, MS SQL Server, los datos se almacenan en este orden:
En este caso, los valores relacionados con una fila se almacenan físicamente uno al lado del otro. En el DBMS de columnas, los valores de diferentes columnas se almacenan por separado y los datos de una columna se almacenan juntos:
Ejemplos de DBMS columnares son Vertica, Paraccel (Actian Matrix, Amazon Redshift), Sybase IQ, Exasol, Infobright, InfiniDB, MonetDB (VectorWise, Actian Vector), LucidDB, SAP HANA, Google Dremel, Google PowerDrill, Druid, kdb+.
La empresa es un reenviador de correo. Comencé a usar Clickhouse en 2018 para generar informes y quedé muy impresionado con su simplicidad, escalabilidad, compatibilidad con SQL y velocidad. La velocidad de este DBMS rayaba en la magia.
Facilidad
Clickhouse se instala en Ubuntu con un solo comando. Si conoce SQL, puede comenzar a utilizar Clickhouse inmediatamente para sus necesidades. Sin embargo, esto no significa que pueda "mostrar creación de tabla" en MySQL y copiar y pegar SQL en Clickhouse.
En comparación con MySQL, existen diferencias importantes en los tipos de datos en las definiciones de esquemas de tablas en este DBMS, por lo que aún necesita algo de tiempo para cambiar las definiciones de esquemas de tablas y aprender los motores de tablas para sentirse cómodo.
Clickhouse funciona muy bien sin ningún software adicional, pero si desea utilizar la replicación deberá instalar ZooKeeper. El análisis del rendimiento de las consultas muestra excelentes resultados: las tablas del sistema contienen toda la información y todos los datos se pueden obtener utilizando SQL antiguo y aburrido.
Rendimiento
- Comparaciones de Clickhouse versus Vertica y MySQL en el servidor de configuración: CPU Intel® Xeon® E5-2650 v2 de dos sockets a 2.60 GHz; 128 GB de RAM; md RAID-5 en 8 discos duros SATA de 6 TB, ext4.
- Comparación de Clickhouse con el almacenamiento en la nube de Amazon RedShift.
- Extractos de blogs :
La base de datos de ClickHouse tiene un diseño muy simple: todos los nodos del clúster tienen la misma funcionalidad y utilizan únicamente ZooKeeper para la coordinación. Construimos un pequeño grupo de varios nodos y realizamos pruebas, durante las cuales descubrimos que el sistema tiene un rendimiento bastante impresionante, que corresponde a las ventajas declaradas en los puntos de referencia analíticos de DBMS. Decidimos analizar más de cerca el concepto detrás de ClickHouse. El primer obstáculo para la investigación fue la falta de herramientas y la pequeña comunidad de ClickHouse, por lo que profundizamos en el diseño de este DBMS para entender cómo funciona.
ClickHouse no admite la recepción de datos directamente desde Kafka, ya que es solo una base de datos, por lo que escribimos nuestro propio servicio de adaptador en Go. Leyó mensajes codificados de Cap'n Proto de Kafka, los convirtió a TSV y los insertó en ClickHouse en lotes a través de la interfaz HTTP. Posteriormente reescribimos este servicio para utilizar la biblioteca Go junto con nuestra propia interfaz ClickHouse para mejorar el rendimiento. Al evaluar el rendimiento de la recepción de paquetes, descubrimos algo importante: resultó que para ClickHouse este rendimiento depende en gran medida del tamaño del paquete, es decir, del número de filas insertadas al mismo tiempo. Para entender por qué sucede esto, estudiamos cómo ClickHouse almacena datos.
El motor principal, o mejor dicho, una familia de motores de tablas utilizados por ClickHouse para almacenar datos, es MergeTree. Este motor es conceptualmente similar al algoritmo LSM utilizado en Google BigTable o Apache Cassandra, pero evita crear una tabla de memoria intermedia y escribe datos directamente en el disco. Esto le brinda un excelente rendimiento de escritura, ya que cada paquete insertado solo se ordena por la clave primaria de "clave primaria", se comprime y se escribe en el disco para formar un segmento.
La ausencia de una tabla de memoria o de cualquier concepto de “actualización” de los datos también significa que solo se pueden agregar, el sistema no admite cambios ni eliminación. A partir de hoy, la única forma de eliminar datos es eliminarlos por mes calendario, ya que los segmentos nunca cruzan el límite de un mes. El equipo de ClickHouse está trabajando activamente para que esta función sea personalizable. Por otro lado, hace que escribir y fusionar segmentos esté libre de conflictos, por lo que el rendimiento de recepción aumenta linealmente con el número de inserciones paralelas hasta que las E/S o los núcleos se saturen.
Sin embargo, esta circunstancia también significa que el sistema no es adecuado para paquetes pequeños, por lo que se utilizan servicios e insertadores de Kafka para el almacenamiento en búfer. Además, ClickHouse en segundo plano continúa fusionando segmentos continuamente, de modo que muchos pequeños fragmentos de información se combinarán y grabarán más veces, aumentando así la intensidad de la grabación. Sin embargo, demasiadas piezas no relacionadas provocarán una limitación agresiva de las inserciones mientras continúe la fusión. Hemos descubierto que el mejor compromiso entre la ingesta de datos en tiempo real y el rendimiento de la ingesta es aceptar una cantidad limitada de inserciones por segundo en la tabla.
La clave para el rendimiento de lectura de tablas es la indexación y ubicación de los datos en el disco. No importa qué tan rápido sea el procesamiento, cuando el motor necesita escanear terabytes de datos del disco y solo usar una fracción de ellos, llevará tiempo. ClickHouse es un almacén de columnas, por lo que cada segmento contiene un archivo para cada columna (columna) con valores ordenados para cada fila. Por lo tanto, primero se pueden omitir columnas enteras que no están presentes en la consulta y luego se pueden procesar varias celdas en paralelo con la ejecución vectorizada. Para evitar un análisis completo, cada segmento tiene un pequeño archivo de índice.
Dado que todas las columnas están ordenadas por la "clave principal", el archivo de índice solo contiene las etiquetas (filas capturadas) de cada enésima fila, para poder mantenerlas en la memoria incluso para tablas muy grandes. Por ejemplo, puede establecer la configuración predeterminada para "marcar cada fila 8192" y luego una indexación "escasa" de una tabla con 1 billón. Las líneas que caben fácilmente en la memoria sólo ocuparían 122 caracteres.
Desarrollo del sistema
El desarrollo y mejora de Clickhouse se puede rastrear en y asegurarse de que el proceso de “crecer” se desarrolle a un ritmo impresionante.
Popularidad
Parece que la popularidad de Clickhouse está creciendo exponencialmente, especialmente en la comunidad de habla rusa. La conferencia High load 2018 del año pasado (Moscú, 8 y 9 de noviembre de 2018) mostró que monstruos como vk.com y Badoo utilizan Clickhouse, que inserta datos (por ejemplo, registros) de decenas de miles de servidores simultáneamente. En un vídeo de 40 minutos . Pronto publicaremos la transcripción en Habr para facilitar el trabajo con el material.
Aplicaciones
Después de pasar un tiempo investigando, creo que hay áreas en las que ClickHouse puede ser útil o capaz de reemplazar por completo otras soluciones más tradicionales y populares como MySQL, PostgreSQL, ELK, Google Big Query, Amazon RedShift, TimescaleDB, Hadoop, MapReduce, Pinot y Druida. Los siguientes son los detalles del uso de ClickHouse para actualizar o reemplazar completamente el DBMS anterior.
Ampliando MySQL y PostgreSQL
Más recientemente, reemplazamos parcialmente MySQL con ClickHouse para la plataforma de boletines. . El problema fue que MySQL, debido a un diseño mal concebido, registró cada correo electrónico enviado y cada enlace en ese correo electrónico con un hash base64, creando una enorme tabla MySQL (email_stats). Después de enviar sólo 10 millones de correos electrónicos a los suscriptores del servicio, esta tabla ocupaba 150 GB de espacio de archivos y MySQL comenzó a ser "estúpido" en consultas simples. Para solucionar el problema del espacio de archivos, utilizamos con éxito la compresión de tablas InnoDB, que lo redujo en un factor de 4. Sin embargo, todavía no tiene sentido almacenar más de 20 a 30 millones de correos electrónicos en MySQL solo por leer el historial, ya que cualquier consulta simple que por alguna razón tenga que realizar un escaneo completo resulta en intercambio y E/S pesadas. gastos generales, sobre los cuales recibimos periódicamente advertencias de Zabbix.
Clickhouse utiliza dos algoritmos de compresión que reducen la cantidad de datos en aproximadamente , pero en este caso particular, los datos eran especialmente "comprimibles".
Reemplazo de ELK
Según mi propia experiencia, la pila ELK (ElasticSearch, Logstash y Kibana, en este caso particular ElasticSearch) requiere muchos más recursos para ejecutarse que los necesarios para almacenar registros. ElasticSearch es un gran motor si desea una buena búsqueda de registros de texto completo (que no creo que realmente necesite), pero me pregunto por qué se ha convertido en el motor de registro estándar de facto. Su rendimiento de ingesta, combinado con Logstash, nos dio problemas incluso con cargas de trabajo bastante livianas y requirió agregar cada vez más RAM y espacio en disco. Como base de datos, Clickhouse es mejor que ElasticSearch por las siguientes razones:
- soporte de dialecto SQL;
- El mejor grado de compresión de los datos almacenados;
- Soporte para búsqueda Regex en lugar de búsqueda de texto completo;
- Programación de consultas mejorada y mejor rendimiento general.
Actualmente, el mayor problema que surge al comparar ClickHouse con ELK es la falta de soluciones para la carga de registros, así como la falta de documentación y tutoriales sobre este tema. Al mismo tiempo, cada usuario puede configurar ELK utilizando el manual de Digital Ocean, lo cual es muy importante para la rápida implementación de dichas tecnologías. Aquí hay un motor de base de datos, pero todavía no existe Filebeat para ClickHouse. Sí hay y un sistema para trabajar con registros , hay una herramienta para ingresar datos del archivo de registro en ClickHouse, pero todo esto lleva más tiempo. Sin embargo, ClickHouse sigue liderando el camino debido a su simplicidad, por lo que incluso los principiantes pueden instalarlo fácilmente y comenzar a usarlo completamente en solo 10 minutos.
Prefiriendo soluciones minimalistas, intenté usar FluentBit, una herramienta de carga de registros con muy poca memoria, con ClickHouse mientras intentaba evitar el uso de Kafka. Sin embargo, es necesario abordar incompatibilidades menores, como antes de poder hacerlo sin la capa proxy que convierte los datos de FluentBit a ClickHouse.
Como alternativa a Kibana, puedes utilizar ClickHouse como backend. . Hasta donde tengo entendido, esto puede causar problemas de rendimiento al representar una gran cantidad de puntos de datos, especialmente con versiones anteriores de Grafana. En Qwintry aún no lo hemos probado, pero de vez en cuando aparecen quejas al respecto en el canal de soporte de ClickHouse en Telegram.
Reemplazo de Google Big Query y Amazon RedShift (solución para grandes empresas)
El caso de uso ideal para BigQuery es cargar 1 TB de datos JSON y ejecutar consultas analíticas en ellos. Big Query es un gran producto cuya escalabilidad es difícil de sobreestimar. Este es un software mucho más complejo que ClickHouse que se ejecuta en un clúster interno, pero desde el punto de vista del cliente, tiene mucho en común con ClickHouse. BigQuery puede "aumentar el precio" rápidamente una vez que comienzas a pagar por cada SELECT, por lo que es una solución SaaS real con todos sus pros y contras.
ClickHouse es la mejor opción cuando ejecuta muchas consultas computacionalmente costosas. Cuantas más consultas SELECT ejecute todos los días, más sentido tendrá reemplazar Big Query con ClickHouse, porque dicho reemplazo le ahorrará miles de dólares cuando se trata de procesar muchos terabytes de datos. Esto no se aplica a los datos almacenados, cuyo procesamiento en Big Query es bastante económico.
En un artículo de Alexander Zaitsev, cofundador de Altinity describe los beneficios de dicha migración de DBMS.
Reemplazo de escala de tiempo DB
TimescaleDB es una extensión de PostgreSQL que optimiza el trabajo con series temporales en una base de datos normal (, ).
Aunque ClickHouse no es un competidor serio en el nicho de series de tiempo, en términos de estructura de columnas y ejecución de consultas vectoriales, es mucho más rápido que TimescaleDB en la mayoría de los casos de procesamiento de consultas analíticas. Al mismo tiempo, el rendimiento de la recepción de datos en paquetes de ClickHouse es aproximadamente 3 veces mayor y, además, utiliza 20 veces menos espacio en disco, lo cual es realmente importante para procesar grandes volúmenes de datos históricos: .
A diferencia de ClickHouse, la única forma de ahorrar espacio en disco en TimescaleDB es utilizar ZFS o sistemas de archivos similares.
Es probable que las próximas actualizaciones de ClickHouse introduzcan la compresión delta, lo que lo hará aún más adecuado para procesar y almacenar datos de series temporales. TimescaleDB puede ser una mejor opción que ClickHouse en los siguientes casos:
- instalaciones pequeñas con muy poca RAM (<3 GB);
- una gran cantidad de INSERT pequeños que no desea almacenar en fragmentos grandes;
- mejores requisitos de consistencia, uniformidad y ACID;
- Soporte PostGIS;
- fusionarse con tablas PostgreSQL existentes, ya que Timescale DB es esencialmente PostgreSQL.
Competencia con los sistemas Hadoop y MapReduce
Hadoop y otros productos MapReduce pueden realizar muchos cálculos complejos, pero tienden a ejecutarse con una latencia enorme. ClickHouse soluciona este problema procesando terabytes de datos y produciendo resultados casi instantáneamente. Por lo tanto, ClickHouse es mucho más eficiente para realizar investigaciones analíticas rápidas e interactivas, lo que debería ser de interés para los científicos de datos.
Competencia con Pinot y Druida
Los competidores más cercanos de ClickHouse son los productos de código abierto linealmente escalables Pinot y Druid. Un excelente trabajo comparando estos sistemas está publicado en el artículo. 1 febrero 2018
Este artículo debe actualizarse: dice que ClickHouse no admite las operaciones ACTUALIZAR y ELIMINAR, lo cual no es del todo cierto en relación con las últimas versiones.
No tenemos mucha experiencia con estos DBMS, pero no me gusta la complejidad de la infraestructura subyacente que se requiere para ejecutar Druid y Pinot: es un montón de "partes móviles" rodeadas de Java por todos lados.
Druid y Pinot son proyectos de incubadora de Apache, que Apache cubre en detalle en sus páginas de proyectos de GitHub. Pinot apareció en la incubadora en octubre de 2018 y Druid nació 8 meses antes, en febrero.
La falta de información sobre cómo funciona AFS me plantea algunas preguntas, quizás estúpidas. Me pregunto si los autores de Pinot se dieron cuenta de que la Fundación Apache está más dispuesta hacia Druid, y ¿esa actitud hacia un competidor les provocó un sentimiento de envidia? ¿Se ralentizará el desarrollo de Druid y se acelerará el de Pinot si los patrocinadores que apoyan al primero se interesan repentinamente por el segundo?
Desventajas de ClickHouse
Inmadurez: Evidentemente, sigue siendo una tecnología aburrida, pero en cualquier caso, no se ve nada parecido en otros DBMS columnares.
Las inserciones pequeñas no funcionan bien a alta velocidad: las inserciones deben dividirse en partes grandes porque el rendimiento de las inserciones pequeñas se degrada en proporción al número de columnas en cada fila. Así es como ClickHouse almacena datos en el disco: cada columna significa 1 archivo o más, por lo que para insertar 1 fila que contenga 100 columnas, debe abrir y escribir al menos 100 archivos. Es por eso que el almacenamiento en búfer de inserción requiere un intermediario (a menos que el propio cliente proporcione el almacenamiento en búfer), generalmente Kafka o algún tipo de sistema de cola. También puede utilizar el motor de tablas Buffer para copiar posteriormente grandes cantidades de datos en tablas MergeTree.
Las uniones de tablas están limitadas por la RAM del servidor, ¡pero al menos están ahí! Por ejemplo, Druid y Pinot no tienen ninguna conexión de este tipo, ya que son difíciles de implementar directamente en sistemas distribuidos que no admiten el movimiento de grandes cantidades de datos entre nodos.
Hallazgos
En los próximos años, planeamos hacer un uso extensivo de ClickHouse en Qwintry, ya que este DBMS proporciona un excelente equilibrio entre rendimiento, baja sobrecarga, escalabilidad y simplicidad. Estoy bastante seguro de que se extenderá rápidamente una vez que la comunidad de ClickHouse encuentre más formas de usarlo en instalaciones pequeñas y medianas.
Algunos anuncios 🙂
Gracias por estar con nosotros. ¿Te gustan nuestros artículos? ¿Quieres ver más contenido interesante? Apóyanos haciendo un pedido o recomendándonos a amigos, , un análogo único de servidores de nivel de entrada, que fue inventado por nosotros para usted: (disponible con RAID1 y RAID10, hasta 24 núcleos y hasta 40GB DDR4).
Dell R730xd 2 veces más barato en el centro de datos Equinix Tier IV en Amsterdam? Solo aqui ¡en los Paises Bajos! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - ¡desde $99! Leer acerca de
Fuente: habr.com