Durante os últimos anos, as bases de datos de series cronolóxicas pasaron dunha cousa estrafalaria (moi especializada utilizada tanto en sistemas de monitorización abertos (e vinculadas a solucións específicas) como en proxectos de Big Data) nun "produto de consumo". No territorio da Federación Rusa hai que darlle un agradecemento especial a Yandex e ClickHouse. Ata este punto, se necesitaba almacenar unha gran cantidade de datos de series temporais, tiña que aceptar a necesidade de construír unha pila de Hadoop monstruosa e mantela ou comunicarse con protocolos individuais para cada sistema.
Pode parecer que en 2019 un artigo sobre o que vale a pena usar TSDB constará dunha soa frase: "só usa ClickHouse". Pero... hai matices.
De feito, ClickHouse está a desenvolverse activamente, a base de usuarios está crecendo e o apoio é moi activo, pero convertémonos en reféns do éxito público de ClickHouse, que eclipsou outras solucións, quizais máis eficaces/fiables?
A principios do ano pasado, comezamos a reelaborar o noso propio sistema de seguimento, durante o cal xurdiu a cuestión de escoller unha base de datos adecuada para almacenar os datos. Quero falar aquí da historia desta elección.
Declaración de problemas
En primeiro lugar, un prefacio necesario. Por que necesitamos o noso propio sistema de vixilancia e como foi deseñado?
Comezamos a prestar servizos de apoio en 2008, e en 2010 quedou claro que se facía difícil agregar datos sobre os procesos que se producían na infraestrutura do cliente coas solucións que existían nese momento (falamos de, Deus me perdoe, Cacti, Zabbix). e o emerxente Grafito).
Os nosos principais requisitos foron:
- apoio (naquel momento - decenas, e no futuro - centos) de clientes dentro dun sistema e, ao mesmo tempo, a presenza dun sistema de xestión de alertas centralizado;
- flexibilidade na xestión do sistema de alertas (escalada de alertas entre os axentes de servizo, programación, base de coñecemento);
- a capacidade de detallar gráficos en profundidade (Zabbix naquel momento representaba gráficos en forma de imaxes);
- almacenamento a longo prazo dunha gran cantidade de datos (un ano ou máis) e a capacidade de recuperalos rapidamente.
Neste artigo interésanos o último punto.
Falando de almacenamento, os requisitos eran os seguintes:
- o sistema debe funcionar rapidamente;
- é desexable que o sistema teña unha interface SQL;
- o sistema debe ser estable e ter unha base de usuarios e soporte activos (unha vez nos enfrontamos á necesidade de soportar sistemas como MemcacheDB, que xa non estaba desenvolvido, ou o almacenamento distribuído MooseFS, cuxo rastreador de erros se gardaba en chinés: repetimos esta historia para o noso proxecto non quería);
- cumprimento do teorema CAP: Coherencia (obrigatorio) - os datos deben estar actualizados, non queremos que o sistema de xestión de alertas non reciba novos datos e cuspir alertas sobre a non chegada de datos para todos os proxectos; Tolerancia de partición (obrigatorio): non queremos obter un sistema Split Brain; Dispoñibilidade (non crítica, se hai unha réplica activa) - podemos cambiar nós mesmos ao sistema de copia de seguridade en caso de accidente, utilizando código.
Curiosamente, nese momento MySQL resultou ser a solución ideal para nós. A nosa estrutura de datos era moi sinxela: ID do servidor, ID do contador, marca de tempo e valor; A mostraxe rápida de datos quentes foi garantida por un gran grupo de memoria intermedia e a mostraxe de datos históricos foi garantida por SSD.
Así, conseguimos unha mostra de datos frescos de dúas semanas, con detalles ata un segundo 200 ms antes de que os datos fosen completamente representados, e vivimos neste sistema durante bastante tempo.
Mentres tanto, o tempo pasaba e a cantidade de datos medraba. En 2016, os volumes de datos alcanzaron decenas de terabytes, o que supuxo un gasto significativo no contexto do almacenamento SSD alugado.
Nese momento, as bases de datos en columnas xa se xeneralizaron activamente, o que comezamos a pensar activamente: nas bases de datos en columnas, os datos almacénanse, como podes entender, en columnas e, se miras os nosos datos, é fácil ver un gran número de duplicados que podería, en Se usa unha base de datos en columnas, comprimila mediante a compresión.
Non obstante, o sistema de claves da empresa continuou funcionando de forma estable e non quería experimentar con cambiar a outra cousa.
En 2017, na conferencia Percona Live en San José, os desenvolvedores de Clickhouse probablemente se anunciaron por primeira vez. A primeira vista, o sistema estaba listo para a produción (ben, Yandex.Metrica é un sistema de produción duro), o soporte era rápido e sinxelo e, o máis importante, o funcionamento era sinxelo. Dende 2018 comezamos o proceso de transición. Pero nese momento, había moitos sistemas TSDB "adultos" e probados no tempo, e decidimos dedicar un tempo considerable e comparar alternativas para asegurarnos de que non había solucións alternativas a Clickhouse, segundo os nosos requisitos.
Ademais dos requisitos de almacenamento xa especificados, apareceron outros novos:
- o novo sistema debería proporcionar polo menos o mesmo rendemento que MySQL na mesma cantidade de hardware;
- o almacenamento do novo sistema debería ocupar moito menos espazo;
- O DBMS aínda debe ser doado de xestionar;
- Quería cambiar a aplicación mínimamente ao cambiar o DBMS.
Que sistemas empezamos a considerar?
Apache Hive/Apache Impala
Unha pila de Hadoop antiga e probada en batalla. Esencialmente, é unha interface SQL construída sobre o almacenamento de datos en formatos nativos en HDFS.
Pros.
- Cun funcionamento estable, é moi sinxelo escalar os datos.
- Existen solucións de columnas para o almacenamento de datos (menos espazo).
- Execución moi rápida de tarefas paralelas cando hai recursos dispoñibles.
Contras.
- É Hadoop, e é difícil de usar. Se non estamos preparados para levar unha solución preparada na nube (e non estamos preparados en termos de custo), toda a pila terá que ser ensamblada e apoiada polas mans dos administradores, e realmente non queremos isto.
- Os datos son agregados .
Non obstante:
A velocidade conséguese escalando o número de servidores informáticos. En pocas palabras, se somos unha gran empresa dedicada á análise e é fundamental para a empresa agregar información o máis rápido posible (mesmo a costa de utilizar unha gran cantidade de recursos informáticos), esta pode ser a nosa elección. Pero non estabamos preparados para multiplicar a flota de hardware para acelerar as tarefas.
Druida/Pinot
Hai moito máis sobre TSDB en concreto, pero de novo, a pila de Hadoop.
Ten .
En poucas palabras: Druid/Pinot parecen mellor que Clickhouse nos casos en que:
- Tes unha natureza heteroxénea de datos (no noso caso, rexistramos só series temporais de métricas do servidor e, de feito, esta é unha táboa. Pero pode haber outros casos: series temporais de equipos, series temporais económicas, etc., cada unha con estrutura propia, que deben ser agregadas e procesadas).
- Ademais, hai moitos destes datos.
- Aparecen e desaparecen táboas e datos con series temporais (é dicir, chegou algún conxunto de datos, analizouse e eliminouse).
- Non hai un criterio claro polo cal se poidan dividir os datos.
En casos opostos, ClickHouse funciona mellor, e este é o noso caso.
clickhouse
- Tipo SQL
- Fácil de xestionar.
- A xente di que funciona.
Queda na lista final para probas.
InfluxDB
Unha alternativa estranxeira a ClickHouse. Dos inconvenientes: a alta dispoñibilidade só está presente na versión comercial, pero hai que comparala.
Queda na lista final para probas.
Cassandra
Por unha banda, sabemos que se utiliza para almacenar series cronolóxicas métricas mediante sistemas de monitorización como, por exemplo, ou OkMeter. Non obstante, hai detalles específicos.
Cassandra non é unha base de datos columnar no sentido tradicional. Parece máis unha vista de fila, pero cada liña pode ter un número diferente de columnas, o que facilita a organización dunha vista en columnas. Neste sentido, está claro que cun límite de 2 millóns de columnas, é posible almacenar algúns datos en columnas (e a mesma serie temporal). Por exemplo, en MySQL hai un límite de 4096 columnas e é fácil tropezar cun erro co código 1117 se tentas facer o mesmo.
O motor Cassandra céntrase en almacenar grandes cantidades de datos nun sistema distribuído sen mestre, e o teorema de Cassandra CAP mencionado anteriormente trata máis sobre AP, é dicir, sobre a dispoñibilidade de datos e a resistencia á partición. Así, esta ferramenta pode ser xenial se só precisa escribir nesta base de datos e raramente ler nela. E aquí é lóxico usar Cassandra como almacenamento "frío". É dicir, como un lugar fiable a longo prazo para almacenar grandes cantidades de datos históricos que raramente se necesitan, pero que se poden recuperar se é necesario. Non obstante, por motivos de integridade, tamén o probaremos. Pero, como dixen anteriormente, non hai ningún desexo de reescribir activamente o código para a solución de base de datos seleccionada, polo que probarémolo de forma algo limitada, sen adaptar a estrutura da base de datos ás especificidades de Cassandra.
Prometeu
Ben, por curiosidade, decidimos probar o rendemento do almacenamento Prometheus, só para entender se somos máis rápidos ou máis lentos que as solucións actuais e en canto.
Metodoloxía da proba e resultados
Entón, probamos 5 bases de datos nas seguintes 6 configuracións: ClickHouse (1 nodo), ClickHouse (táboa distribuída para 3 nodos), InfluxDB, Mysql 8, Cassandra (3 nodos) e Prometheus. O plan de proba é o seguinte:
- cargar datos históricos durante unha semana (840 millóns de valores por día; 208 mil métricas);
- xeramos unha carga de gravación (consideráronse 6 modos de carga, ver a continuación);
- Paralelamente á gravación, periodicamente realizamos seleccións, emulando as solicitudes dun usuario que traballa con gráficos. Para non complicar moito as cousas, seleccionamos datos para 10 métricas (esa é exactamente cantas hai no gráfico da CPU) durante unha semana.
Cargamos emulando o comportamento do noso axente de seguimento, que envía valores a cada métrica unha vez cada 15 segundos. Ao mesmo tempo, estamos interesados en variar:
- o número total de métricas nas que se escriben os datos;
- intervalo para enviar valores a unha métrica;
- tamaño do lote.
Sobre o tamaño do lote. Dado que non se recomenda cargar case todas as nosas bases de datos experimentais con insercións únicas, necesitaremos un relé que recolla as métricas entrantes e as agrupe en grupos e as escriba na base de datos como unha inserción por lotes.
Ademais, para comprender mellor como interpretar despois os datos recibidos, imaxinemos que non só estamos enviando unha morea de métricas, senón que as métricas están organizadas en servidores: 125 métricas por servidor. Aquí o servidor é simplemente unha entidade virtual, só para entender que, por exemplo, 10000 métricas corresponden a uns 80 servidores.
E aquí, tendo todo isto en conta, os nosos 6 modos de carga de escritura de bases de datos:
Aquí hai dous puntos. En primeiro lugar, para Cassandra estes tamaños de lote resultaron ser demasiado grandes, alí usamos valores de 50 ou 100. E en segundo lugar, xa que Prometheus funciona estrictamente en modo de extracción, é dicir. el mesmo vai e recolle datos de fontes de métricas (e mesmo pushgateway, a pesar do nome, non cambia fundamentalmente a situación), as cargas correspondentes foron implementadas mediante unha combinación de configuracións estáticas.
Os resultados das probas son os seguintes:
O que cabe destacar: mostras fantásticamente rápidas de Prometheus, mostras terriblemente lentas de Cassandra, mostras inaceptablemente lentas de InfluxDB; En canto á velocidade de gravación, ClickHouse gañou a todos, e Prometheus non participa na competición, porque fai insercións por si mesma e non medimos nada.
Como resultado,: ClickHouse e InfluxDB tiveron o mellor rendemento, pero un clúster de Influx só se pode construír a partir da versión Enterprise, que custa diñeiro, mentres que ClickHouse non custa nada e está feito en Rusia. É lóxico que nos EUA a elección sexa probablemente a favor de inInfluxDB, e no noso país é a favor de ClickHouse.
Fonte: www.habr.com