é un sistema de xestión de bases de datos en columnas de código aberto para o procesamento de consultas analíticas en liña (OLAP), creado por Yandex. Utilízao Yandex, CloudFlare, VK.com, Badoo e outros servizos de todo o mundo para almacenar cantidades realmente grandes de datos (inseríndo miles de filas por segundo ou petabytes de datos almacenados no disco).
Nun DBMS normal de "cadea", exemplos dos cales son MySQL, Postgres, MS SQL Server, os datos almacénanse na seguinte orde:
Neste caso, os valores relacionados cunha fila almacénanse fisicamente preto. Nos DBMS en columnas, os valores de diferentes columnas gárdanse por separado e os datos dunha columna gárdanse xuntos:
Exemplos 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+.
Empresa de reenvío de correo comezou a usar Clickhouse en 2018 para informar e quedou moi impresionado coa súa sinxeleza, escalabilidade, compatibilidade con SQL e velocidade. A velocidade deste DBMS rozaba a maxia.
Simplicidade
Clickhouse está instalado en Ubuntu cun só comando. Se coñeces SQL, podes comezar inmediatamente a usar Clickhouse para as túas necesidades. Non obstante, isto non significa que poidas facer "mostrar a táboa de creación" en MySQL e copiar e pegar o SQL en Clickhouse.
En comparación con MySQL, hai importantes diferenzas de tipo de datos nas definicións do esquema de táboas, polo que aínda necesitarás algún tempo para cambiar as definicións do esquema de táboas e aprender os motores de táboas para sentirte cómodo.
Clickhouse funciona moi ben sen ningún software adicional, pero se queres usar a replicación, terás que instalar ZooKeeper. A análise do rendemento das consultas mostra excelentes resultados: as táboas do sistema conteñen toda a información e todos os datos pódense recuperar usando SQL antigo e aburrido.
Produtividade
- comparacións de Clickhouse con Vertica e MySQL na configuración do servidor: dous sockets Intel® Xeon® CPU E5-2650 v2 @ 2.60GHz; 128 GiB de RAM; md RAID-5 en 8 HDD SATA de 6 TB, ext4.
- comparación de Clickhouse co almacenamento na nube de Amazon RedShift.
- Fragmentos do blog :
A base de datos ClickHouse ten un deseño moi sinxelo: todos os nodos do clúster teñen a mesma funcionalidade e só usan ZooKeeper para a coordinación. Construímos un pequeno clúster de varios nodos e realizamos probas, durante as cales descubrimos que o sistema ten un rendemento bastante impresionante, o que corresponde ás vantaxes indicadas nos benchmarks analíticos de DBMS. Decidimos analizar o concepto detrás de ClickHouse. O primeiro obstáculo para a investigación foi a falta de ferramentas e a pequena comunidade ClickHouse, polo que afondamos no deseño deste DBMS para entender como funciona.
ClickHouse non admite a recepción de datos directamente de Kafka xa que é só unha base de datos, polo que escribimos o noso propio servizo de adaptadores en Go. Leu mensaxes codificadas de Cap'n Proto de Kafka, converteuas a TSV e inseriunas en ClickHouse por lotes a través da interface HTTP. Máis tarde reescribimos este servizo para usar a biblioteca Go xunto coa propia interface de ClickHouse para mellorar o rendemento. Ao avaliar o rendemento da recepción de paquetes, descubrimos unha cousa importante: resultou que para ClickHouse este rendemento depende moito do tamaño do paquete, é dicir, do número de filas inseridas simultáneamente. Para entender por que ocorre isto, analizamos como almacena os datos ClickHouse.
O motor principal, ou máis ben a familia de motores de táboas, usado por ClickHouse para almacenar datos é MergeTree. Este motor é conceptualmente similar ao algoritmo LSM usado en Google BigTable ou Apache Cassandra, pero evita construír unha táboa de memoria intermedia e escribe datos directamente no disco. Isto dálle un excelente rendemento de escritura, xa que cada paquete inserido é ordenado só pola clave principal, comprimido e escrito no disco para formar un segmento.
A ausencia dunha táboa de memoria ou calquera concepto de "frescura" dos datos tamén significa que só se poden engadir; o sistema non admite o cambio nin a eliminación. Actualmente, a única forma de eliminar datos é eliminalos por mes natural, xa que os segmentos nunca cruzan o límite dun mes. O equipo de ClickHouse está a traballar activamente para que esta función sexa personalizable. Por outra banda, permite escribir e fusionar segmentos sen conflitos, polo que recibe escalas de rendemento linealmente co número de insercións simultáneas ata que se produza a saturación de E/S ou núcleo.
Non obstante, isto tamén significa que o sistema non é adecuado para paquetes pequenos, polo que os servizos e insertadores de Kafka utilízanse para almacenar en búfer. A continuación, ClickHouse en segundo plano segue realizando constantemente a fusión de segmentos, polo que moitas pequenas pezas de información combinaranse e gravaranse máis veces, aumentando así a intensidade da gravación. Non obstante, demasiadas pezas sen conexión provocarán unha limitación agresiva das insercións mentres continúe a fusión. Descubrimos que o mellor compromiso entre a inxestión en tempo real e o rendemento da inxestión é inxerir un número limitado de insercións por segundo na táboa.
A clave para o rendemento da lectura de táboas é a indexación e a localización dos datos no disco. Non importa o rápido que sexa o procesamento, cando o motor necesite escanear terabytes de datos do disco e usar só unha parte dos mesmos, levará tempo. ClickHouse é unha tenda de columnas, polo que cada segmento contén un ficheiro para cada columna (columna) con valores ordenados para cada fila. Deste xeito, pódense omitir primeiro as columnas enteiras que faltan na consulta e despois pódense procesar varias celas en paralelo coa execución vectorizada. Para evitar unha exploración completa, cada segmento ten un pequeno ficheiro de índice.
Dado que todas as columnas están ordenadas pola "chave primaria", o ficheiro índice só contén as etiquetas (filas capturadas) de cada fila enésima para poder mantelas na memoria incluso para táboas moi grandes. Por exemplo, pode configurar a configuración predeterminada para "marcar cada fila 8192" e, a continuación, a indexación "escasa" dunha táboa con 1 billón. liñas que encaixan facilmente na memoria levarán só 122 caracteres.
Desenvolvemento do sistema
O desenvolvemento e mellora de Clickhouse pódese rastrexar en e asegúrate de que o proceso de "crecer" ocorre a un ritmo impresionante.
Popularidade
A popularidade de Clickhouse parece estar crecendo exponencialmente, especialmente na comunidade de fala rusa. A conferencia High load 2018 do ano pasado (Moscova, do 8 ao 9 de novembro de 2018) mostrou que monstros como vk.com e Badoo usan Clickhouse, co que introducen datos (por exemplo, rexistros) de decenas de miles de servidores simultaneamente. Nun vídeo de 40 minutos . En breve publicaremos a transcrición en Habr para facilitar o traballo co material.
Áreas de aplicación
Despois de pasar un tempo investigando, creo que hai áreas nas que ClickHouse podería ser útil ou podería substituír completamente outras solucións máis tradicionais e populares como MySQL, PostgreSQL, ELK, Google Big Query, Amazon RedShift, TimescaleDB, Hadoop, MapReduce, Pinot e Druida. A continuación descríbense os detalles do uso de ClickHouse para modernizar ou substituír completamente o DBMS anterior.
Ampliación das capacidades de MySQL e PostgreSQL
Recentemente substituímos parcialmente MySQL por ClickHouse para a nosa plataforma de boletíns . O problema foi que MySQL, debido a un deseño deficiente, rexistraba cada correo electrónico enviado e cada ligazón dese correo electrónico cun hash base64, creando unha enorme táboa MySQL (email_stats). Despois de enviar só 10 millóns de correos electrónicos aos subscritores do servizo, esta táboa ocupaba 150 GB de espazo de ficheiros e MySQL comezou a ser "estúpido" en consultas sinxelas. Para solucionar o problema de espazo de ficheiros, usamos con éxito a compresión da táboa InnoDB, que a reduciu nun factor de 4. Non obstante, aínda non ten sentido almacenar máis de 20-30 millóns de correos electrónicos en MySQL só para ler o historial, xa que calquera consulta sinxela que por algún motivo necesite facer unha exploración completa resulta en intercambio e moitas /O carga, segundo a cal recibíamos regularmente avisos de Zabbix.
Clickhouse usa dous algoritmos de compresión que reducen aproximadamente o volume de datos , pero neste caso concreto os datos eran particularmente "comprimibles".
Substituíndo ELK
Segundo a miña propia experiencia, a pila ELK (ElasticSearch, Logstash e Kibana, neste caso particular ElasticSearch) require moitos máis recursos para executarse dos que son necesarios para almacenar rexistros. ElasticSearch é un gran motor se necesitas unha boa busca de rexistro de texto completo (que non creo que necesites), pero pregúntome por que se converteu no motor de rexistro estándar de facto. O seu rendemento de inxestión combinado con Logstash deunos problemas mesmo con cargas bastante lixeiras e requiriunos engadir máis e máis memoria RAM e espazo no disco. Como base de datos, Clickhouse é mellor que ElasticSearch polos seguintes motivos:
- Soporte dialecto SQL;
- O mellor grao de compresión dos datos almacenados;
- Soporte para buscas de expresións regulares Regex en lugar de buscas de texto completo;
- Mellora a programación de consultas e un maior rendemento xeral.
Actualmente, o maior problema que xorde ao comparar ClickHouse con ELK é a falta de solucións para a carga de rexistros, así como a falta de documentación e titoriais sobre o tema. Ademais, cada usuario pode configurar ELK usando o manual Digital Ocean, que é moi importante para a rápida implementación destas tecnoloxías. Hai un motor de base de datos, pero aínda non hai Filebeat para ClickHouse. Si, está aí e un sistema para traballar con rexistros , hai unha ferramenta para introducir datos do ficheiro de rexistro en ClickHouse, pero todo isto leva máis tempo. Non obstante, ClickHouse segue sendo o líder debido á súa sinxeleza, polo que incluso os principiantes poden instalalo facilmente e comezar a usalo de forma totalmente funcional en só 10 minutos.
Preferindo solucións minimalistas, intentei usar FluentBit, unha ferramenta para enviar rexistros con moi pouca memoria, xunto con ClickHouse, mentres intentaba evitar o uso de Kafka. Non obstante, hai que abordar pequenas incompatibilidades, como antes de que isto se poida facer sen a capa proxy que converte os datos de FluentBit a ClickHouse.
Como alternativa, Kibana pódese usar como backend de ClickHouse . Polo que entendo, isto pode causar problemas de rendemento ao renderizar un gran número de puntos de datos, especialmente con versións antigas de Grafana. Aínda non probamos isto en Qwintry, pero as queixas sobre isto aparecen de cando en vez na canle de asistencia de ClickHouse en Telegram.
Substitución de Google Big Query e Amazon RedShift (solución para grandes empresas)
O caso de uso ideal de BigQuery é cargar 1 TB de datos JSON e realizar consultas analíticas nel. Big Query é un excelente produto cuxa escalabilidade non se pode exagerar. Trátase dun software moito máis complexo que ClickHouse, que se executa nun clúster interno, pero desde o punto de vista do cliente ten moito en común con ClickHouse. BigQuery pode encarecerse rapidamente unha vez que comeces a pagar por SELECT, polo que é unha verdadeira solución SaaS con todos os seus pros e contras.
ClickHouse é a mellor opción cando estás executando moitas consultas computacionalmente custosas. Cantas máis consultas SELECT executes todos os días, máis sentido terá substituír Big Query por ClickHouse, porque esa substitución pode aforrarche miles de dólares cando se trata de procesar moitos terabytes de datos. Isto non se aplica aos datos almacenados, que son bastante baratos de procesar en Big Query.
Nun artigo do cofundador de Altinity, Alexander Zaitsev fala sobre os beneficios de tal migración de DBMS.
Substitución de TimescaleDB
TimescaleDB é unha extensión de PostgreSQL que optimiza o traballo con series temporais nunha base de datos normal (, ).
Aínda que ClickHouse non é un competidor serio no nicho das series temporais, senón a estrutura de columnas e a execución de consultas vectoriales, é moito máis rápido que TimescaleDB na maioría dos casos de procesamento de consultas analíticas. Ao mesmo tempo, o rendemento de recibir datos por lotes de ClickHouse é aproximadamente 3 veces maior e tamén usa 20 veces menos espazo en disco, o que é realmente importante para procesar grandes volumes de datos históricos: .
A diferenza de ClickHouse, a única forma de aforrar espazo no disco en TimescaleDB é usar ZFS ou sistemas de ficheiros similares.
As próximas actualizacións de ClickHouse probablemente introducirán a compresión delta, o que o fará aínda máis axeitado para procesar e almacenar datos de series temporais. TimescaleDB pode ser unha mellor opción que ClickHouse nua nos seguintes casos:
- pequenas instalacións con moi pouca memoria RAM (<3 GB);
- un gran número de pequenos INSERT que non quere almacenar en grandes fragmentos;
- mellores requisitos de consistencia, uniformidade e ACID;
- soporte PostGIS;
- unirse a táboas PostgreSQL existentes, xa que Timescale DB é esencialmente PostgreSQL.
Competencia cos sistemas Hadoop e MapReduce
Hadoop e outros produtos MapReduce poden realizar moitos cálculos complexos, pero adoitan executarse con grandes latencias. ClickHouse soluciona este problema procesando terabytes de datos e producindo resultados case ao instante. Así, ClickHouse é moito máis eficaz para realizar investigacións analíticas rápidas e interactivas, que deberían ser de interese para os científicos de datos.
Competición con Pinot e Druid
Os competidores máis próximos de ClickHouse son produtos de código aberto en columnas e escalables linealmente Pinot e Druid. No artigo publícase un excelente traballo comparando estes sistemas do 1 de febreiro de 2018
Este artigo cómpre actualizar: di que ClickHouse non admite as operacións de ACTUALIZACIÓN e ELIMINACIÓN, o que non é totalmente certo para as versións máis recentes.
Non temos moita experiencia con estas bases de datos, pero non me gusta moito a complexidade da infraestrutura que se require para executar Druid e Pinot: é un montón de pezas móbiles rodeadas de Java por todos os lados.
Druid e Pinot son proxectos de incubadoras de Apache, cuxo progreso é tratado en detalle por Apache nas súas páxinas do proxecto GitHub. Pinot apareceu na incubadora en outubro de 2018 e Druid naceu 8 meses antes, en febreiro.
A falta de información sobre como funciona AFS suscita algunhas preguntas, e quizais estúpidas, para min. Pregúntome se os autores de Pinot notaron que a Fundación Apache é máis favorable a Druid, e se esta actitude cara ao competidor provocou un sentimento de envexa. Ralentizarase o desenvolvemento de Druid e acelerarase o desenvolvemento de Pinot se os patrocinadores do primeiro se interesan de súpeto polo segundo?
Desvantaxes de ClickHouse
Inmadurez: Obviamente, esta aínda non é unha tecnoloxía aburrida, pero en calquera caso, nada como isto se observa noutros DBMS columnares.
As insercións pequenas non funcionan ben a alta velocidade: as insercións deben dividirse en anacos máis grandes porque o rendemento das insercións pequenas degrada en proporción ao número de columnas de cada fila. Así é como ClickHouse almacena os datos no disco: cada columna representa 1 ficheiro ou máis, polo que para inserir 1 fila que conteña 100 columnas, cómpre abrir e escribir polo menos 100 ficheiros. É por iso que as insercións de búfer requiren un intermediario (a non ser que o propio cliente proporcione búfer), normalmente Kafka ou algún tipo de sistema de xestión de filas. Tamén pode usar o motor de táboas de memoria intermedia para posteriormente copiar grandes anacos de datos nas táboas MergeTree.
As unións á táboa están limitadas pola memoria RAM do servidor, pero polo menos están aí! Por exemplo, Druid e Pinot non teñen este tipo de conexións, xa que son difíciles de implementar directamente en sistemas distribuídos que non admiten mover grandes anacos de datos entre nodos.
Descubrimentos
Planeamos utilizar amplamente ClickHouse en Qwintry nos próximos anos, xa que este DBMS ofrece un excelente equilibrio de rendemento, baixo custo, escalabilidade e sinxeleza. Estou bastante seguro de que comezará a estenderse rapidamente unha vez que a comunidade ClickHouse dea máis formas de usalo en instalacións pequenas e medianas.
Algúns anuncios 🙂
Grazas por estar connosco. Gústanche os nosos artigos? Queres ver máis contido interesante? Apóyanos facendo un pedido ou recomendando a amigos, , un análogo único de servidores de nivel de entrada, que inventamos nós para ti: (dispoñible con RAID1 e RAID10, ata 24 núcleos e ata 40 GB DDR4).
Dell R730xd 2 veces máis barato no centro de datos Equinix Tier IV en Amsterdam? Só aquí nos Países Baixos! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - desde $ 99! Ler sobre
Fonte: www.habr.com