Introdução Gerenciar dados de streaming de um sistema de origem, como PostgreSQL, MongoDB ou DynamoDB, para um sistema downstream para pesquisa e análise em tempo real é um desafio para muitas equipes. O fluxo de dados geralmente envolve ferramentas ETL complexas, bem como integrações de autogerenciamento para garantir que gravações de alto volume, incluindo atualizações e exclusões, não acumulem CPU ou afetem o desempenho do aplicativo final. Para um sistema como , os engenheiros precisam ter conhecimento profundo da arquitetura subjacente para . O Elasticsearch foi projetado para análise de logs onde os dados não mudam com frequência, apresentando desafios adicionais ao lidar com dados transacionais. o Elasticsearch ingerir dados de streaming com eficiência Rockset, por outro lado, é um banco de dados nativo da nuvem, eliminando muitas ferramentas e despesas gerais necessárias para inserir dados no sistema. Como o Rockset foi desenvolvido especificamente para pesquisa e análise em tempo real, ele também foi projetado para , diminuindo a CPU necessária para processar inserções, atualizações e exclusões. mutabilidade em nível de campo Neste blog, compararemos como lidam com a ingestão de dados, bem como forneceremos técnicas práticas para usar esses sistemas para análises em tempo real. o Elasticsearch e o Rockset Elasticsearch Ingestão de dados no Elasticsearch Embora existam muitas maneiras de ingerir dados no Elasticsearch, abordamos três métodos comuns para pesquisa e análise em tempo real: Ingerir dados de um banco de dados relacional no Elasticsearch usando o plugin de entrada Logstash JDBC Ingerir dados do Kafka no Elasticsearch usando o Kafka Elasticsearch Service Sink Connector Ingerir dados diretamente do aplicativo no Elasticsearch usando a API REST e bibliotecas de cliente O plug-in de entrada Logstash JDBC pode ser usado para descarregar dados de um banco de dados relacional como PostgreSQL ou MySQL para Elasticsearch para pesquisa e análise. Ingira dados de um banco de dados relacional no Elasticsearch usando o plugin de entrada Logstash JDBC. Logstash é um pipeline de processamento de eventos que ingere e transforma dados antes de enviá-los ao Elasticsearch. Logstash oferece um que pesquisa um banco de dados relacional, como PostgreSQL ou MySQL, para inserções e atualizações periodicamente. Para usar este serviço, seu banco de dados relacional precisa fornecer registros com carimbo de data/hora que possam ser lidos pelo Logstash para determinar quais alterações ocorreram. plugin de entrada JDBC Esta abordagem de ingestão funciona bem para inserções e atualizações, mas são necessárias considerações adicionais para exclusões. Isso ocorre porque não é possível para o Logstash determinar o que foi excluído do seu banco de dados OLTP. Os usuários podem contornar essa limitação implementando exclusões suaves, onde um sinalizador é aplicado ao registro excluído e é usado para filtrar dados no momento da consulta. Ou podem verificar periodicamente seu banco de dados relacional para obter acesso aos registros mais atualizados e reindexar os dados no Elasticsearch. . Também é comum usar uma plataforma de streaming de eventos como o Kafka para enviar dados de sistemas de origem para o Elasticsearch para pesquisa e análise em tempo real. Ingira dados do Kafka no Elasticsearch usando o Kafka Elasticsearch Sink Connector A Confluent e a Elastic fizeram parceria no lançamento do , disponível para empresas que usam as ofertas gerenciadas Confluent Kafka e Elastic Elasticsearch. O conector requer instalação e gerenciamento de ferramentas adicionais, Kafka Connect. Kafka Elasticsearch Service Sink Connector Usando o conector, você pode mapear cada tópico no Kafka para um único tipo de índice no Elasticsearch. Se a digitação dinâmica for usada como tipo de índice, o Elasticsearch oferece suporte a algumas alterações de esquema, como adição de campos, remoção de campos e alteração de tipos. Um dos desafios que surge ao usar o Kafka é a necessidade de reindexar os dados no Elasticsearch quando você deseja modificar o analisador, o tokenizer ou os campos indexados. Isso ocorre porque o mapeamento não pode ser alterado depois de já estar definido. Para executar uma reindexação dos dados, você precisará gravar duas vezes no índice original e no novo índice, mover os dados do índice original para o novo índice e, em seguida, interromper o trabalho do conector original. Se você não usa serviços gerenciados do Confluent ou Elastic, você pode usar o para Logstash para enviar dados ao Elasticsearch. plugin Kafka de código aberto O Elasticsearch oferece a capacidade de usar incluindo Java, Javascript, Ruby, Go, Python e muito mais, para ingerir dados por meio da API REST diretamente do seu aplicativo. Um dos desafios de usar uma biblioteca cliente é que ela precisa ser configurada para funcionar com caso o Elasticsearch não consiga lidar com a carga de ingestão. Sem um sistema de filas instalado, existe o potencial de perda de dados no Elasticsearch. Ingerir dados diretamente do aplicativo no Elasticsearch usando a API REST e bibliotecas de cliente bibliotecas de cliente compatíveis, enfileiramento e contrapressão Atualizações, inserções e exclusões no Elasticsearch Elasticsearch possui uma que pode ser usada para processar atualizações e exclusões. A API de atualização reduz o número de viagens à rede e o potencial de conflitos de versão. A API de atualização recupera o documento existente do índice, processa a alteração e indexa os dados novamente. Dito isso, o Elasticsearch não oferece atualizações ou exclusões locais. Portanto, todo o documento ainda deve ser reindexado, uma operação que exige muito da CPU. API de atualização Nos bastidores, os dados do Elasticsearch são armazenados em um índice Lucene e esse índice é dividido em segmentos menores. Cada segmento é imutável, portanto os documentos não podem ser alterados. Quando uma atualização é feita, o documento antigo é marcado para exclusão e um novo documento é mesclado para formar um novo segmento. Para usar o documento atualizado, todos os analisadores precisam ser executados, o que também pode aumentar o uso da CPU. É comum que clientes com dados em constante mudança vejam as mesclagens de índices consumirem uma quantidade considerável de sua conta geral de computação do Elasticsearch. Dada a quantidade de recursos necessários, a Elastic recomenda limitar o número de atualizações no Elasticsearch. Um cliente de referência do Elasticsearch, , usou o Elasticsearch para pesquisa de sites como parte de sua plataforma de comércio eletrônico. Bol.com teve cerca de 700 mil atualizações por dia em suas ofertas, incluindo alterações de conteúdo, preços e disponibilidade. Originalmente, eles queriam uma solução que permanecesse sincronizada com quaisquer alterações que ocorressem. Porém, dado o impacto das atualizações no desempenho do sistema Elasticsearch, eles optaram por permitir atrasos de 15 a 20 minutos. O agrupamento de documentos em lote no Elasticsearch garantiu um desempenho de consulta consistente. Bol.com Desafios de exclusões e mesclagem de segmentos no Elasticsearch No Elasticsearch, pode haver desafios relacionados à e à recuperação de espaço. exclusão de documentos antigos O Elasticsearch conclui uma em segundo plano quando há um grande número de segmentos em um índice ou muitos documentos em um segmento marcados para exclusão. Uma mesclagem de segmentos ocorre quando os documentos são copiados de segmentos existentes para um segmento recém-formado e os segmentos restantes são excluídos. Infelizmente, Lucene não é bom em dimensionar os segmentos que precisam ser mesclados, criando potencialmente segmentos desiguais que impactam o desempenho e a estabilidade. mesclagem de segmentos Isso ocorre porque o Elasticsearch pressupõe que todos os documentos tenham e toma decisões de mesclagem com base no número de documentos excluídos. Ao lidar com tamanhos de documentos heterogêneos, como costuma acontecer em aplicativos multilocatários, alguns segmentos crescerão mais rapidamente do que outros, diminuindo o desempenho dos maiores clientes do aplicativo. Nestes casos, a única solução é reindexar uma grande quantidade de dados. tamanhos uniformes Desafios de réplica no Elasticsearch Elasticsearch usa um para replicação. A réplica primária processa uma operação de gravação recebida e depois encaminha a operação para suas réplicas. Cada réplica recebe esta operação e reindexa os dados localmente novamente. Isso significa que cada réplica gasta recursos computacionais dispendiosos de forma independente para reindexar o mesmo documento repetidamente. Se houver n réplicas, a Elastic gastaria n vezes a CPU para indexar o mesmo documento. Isso pode agravar a quantidade de dados que precisam ser quando ocorre uma atualização ou inserção. modelo de backup primário reindexados API em massa e desafios de fila no Elasticsearch Embora você possa usar a API Update no Elasticsearch, geralmente é recomendado agrupar alterações frequentes em lote usando a . Ao usar a API em massa, as equipes de engenharia geralmente precisarão criar e gerenciar uma fila para agilizar as atualizações no sistema. API em massa Uma fila é independente do Elasticsearch e precisará ser configurada e gerenciada. A fila consolidará as inserções, atualizações e exclusões no sistema dentro de um intervalo de tempo específico, digamos 15 minutos, para limitar o impacto no Elasticsearch. O sistema de filas também aplicará um acelerador quando a taxa de inserção for alta para garantir a estabilidade da aplicação. Embora as filas sejam úteis para atualizações, elas não são boas para determinar quando há muitas alterações de dados que exigem uma reindexação completa dos dados. Isso pode ocorrer a qualquer momento se houver muitas atualizações no sistema. É comum que as equipes que executam a Elastic em escala tenham membros de operações dedicados gerenciando e ajustando suas filas diariamente. Reindexando no Elasticsearch Conforme mencionado na seção anterior, quando há uma série de atualizações ou você precisa alterar os mapeamentos de índice, ocorre uma reindexação dos dados. é propensa a erros e tem o potencial de derrubar um cluster. O que é ainda mais assustador é que a reindexação pode acontecer a qualquer momento. A reindexação Se quiser alterar seus mapeamentos, você terá mais controle sobre o tempo em que a reindexação ocorre. O Elasticsearch possui uma API de reindexação para criar um novo índice e uma para garantir que não haja tempo de inatividade quando um novo índice estiver sendo criado. Com uma API de alias, as consultas são roteadas para o alias ou para o índice antigo, à medida que o novo índice é criado. Quando o novo índice estiver pronto, a API de aliases será convertida para ler dados do novo índice. API de Aliases Com a API de aliases, ainda é complicado manter o novo índice sincronizado com os dados mais recentes. Isso ocorre porque o Elasticsearch só pode gravar dados em um índice. Portanto, você precisará configurar o upstream do pipeline de dados para gravar duas vezes no índice novo e no antigo. Conjunto de foguetes Ingestão de dados no Rockset Rockset usa conectores integrados para manter seus dados sincronizados com os sistemas de origem. Os conectores gerenciados do Rockset são ajustados para cada tipo de fonte de dados para que os dados possam ser ingeridos e consultados em 2 segundos. Isso evita pipelines manuais que adicionam latência ou só podem ingerir dados em microlotes, digamos, a cada 15 minutos. Em alto nível, o Rockset oferece conectores integrados para bancos de dados OLTP, fluxos de dados e data lakes e armazéns. Veja como eles funcionam: O Rockset faz uma varredura inicial de suas tabelas em seu banco de dados OLTP e, em seguida, usa para permanecer sincronizado com os dados mais recentes, com os dados sendo disponibilizados para consulta dentro de 2 segundos a partir de quando foram gerados pelo sistema de origem. Conectores integrados para bancos de dados OLTP fluxos CDC Com fluxos de dados como ou Kinesis, o Rockset ingere continuamente quaisquer novos tópicos usando uma integração baseada em pull que não requer ajuste no Kafka ou Kinesis. Conectores integrados para fluxos de dados Kafka O Rockset monitora constantemente atualizações e ingere quaisquer novos objetos de data lakes, como buckets S3. Geralmente descobrimos que as equipes desejam unir fluxos em tempo real com dados de seus data lakes para análises em tempo real. Conectores integrados para data lakes e armazéns Atualizações, inserções e exclusões no Rockset Rockset possui uma arquitetura distribuída otimizada para indexar dados de forma eficiente em paralelo em várias máquinas. Rockset é um , portanto ele grava documentos inteiros em uma única máquina, em vez de dividi-los e enviar os diferentes campos para máquinas diferentes. Por causa disso, é rápido adicionar novos documentos para inserções ou localizar documentos existentes, com base na chave primária _id para atualizações e exclusões. banco de dados fragmentado de documentos Semelhante ao Elasticsearch, o Rockset usa índices para recuperar dados de forma rápida e eficiente quando eles são consultados. Ao contrário de outros bancos de dados ou mecanismos de pesquisa, o Rockset indexa os dados no momento da ingestão em um , um índice que combina um armazenamento de colunas, um índice de pesquisa e um armazenamento de linhas. O Índice Convergente armazena todos os valores nos campos como uma série de pares de valores-chave. No exemplo abaixo você pode ver um documento e como ele está armazenado no Rockset. Índice Convergente Nos bastidores, , um armazenamento de valores-chave de alto desempenho que torna as mutações triviais. RocksDB suporta gravações e exclusões atômicas em chaves diferentes. Se ocorrer uma atualização no campo de um documento, exatamente 3 chaves precisarão ser atualizadas, uma por índice. Os índices de outros campos do documento não são afetados, o que significa que o Rockset pode processar atualizações com eficiência, em vez de desperdiçar ciclos atualizando índices de documentos inteiros todas as vezes. o Rockset usa RocksDB name Documentos e matrizes aninhados também são tipos de dados de primeira classe no Rockset, o que significa que o mesmo processo de atualização se aplica a eles também, tornando o Rockset adequado para atualizações de dados armazenados em formatos modernos como JSON e Avro. A equipe da Rockset também construiu várias extensões personalizadas para RocksDB para lidar com altas gravações e leituras pesadas, um padrão comum em cargas de trabalho de análise em tempo real. Uma dessas extensões são , que introduzem uma separação clara entre computação de consulta e computação de indexação no RocksDB Cloud. Isso permite que o Rockset evite que gravações interfiram nas leituras. Devido a essas melhorias, a Rockset pode dimensionar suas gravações de acordo com as necessidades dos clientes e disponibilizar novos dados para consulta, mesmo quando ocorrem mutações em segundo plano. as compactações remotas Atualizações, inserções e exclusões usando a API Rockset Os usuários do Rockset podem usar o campo _id padrão ou especificar um campo específico para ser a chave primária. Este campo permite que um documento ou parte de um documento seja sobrescrito. A diferença entre Rockset e Elasticsearch é que Rockset pode atualizar o valor de um campo individual sem exigir a reindexação de um documento inteiro. Para atualizar documentos existentes em uma coleção usando a API Rockset, você pode fazer solicitações ao endpoint Patch Documents. Para cada documento existente que você deseja atualizar, basta especificar o campo _id e uma lista de operações de patch a serem aplicadas ao documento. A API Rockset também expõe um endpoint Add Documents para que você possa inserir dados diretamente em suas coleções a partir do código do seu aplicativo. Para excluir documentos existentes, basta especificar os campos _id dos documentos que você deseja remover e fazer uma solicitação ao endpoint Excluir Documentos da API Rockset. Manipulação de réplicas no Rockset Ao contrário do Elasticsearch, apenas uma réplica no Rockset faz a indexação e compactação usando compactações remotas RocksDB. Isso reduz a quantidade de CPU necessária para indexação, especialmente quando diversas réplicas estão sendo usadas para durabilidade. Reindexando no Rockset No momento da ingestão no Rockset, você pode usar uma transformação de ingestão para especificar as transformações de dados desejadas para aplicar nos dados de origem brutos. Se desejar alterar a transformação de ingestão posteriormente, você precisará reindexar seus dados. Dito isso, o Rockset permite e digita dinamicamente os valores de cada campo de dados. Se o tamanho e a forma dos dados ou consultas mudarem, o Rockset continuará a ter desempenho e não exigirá que os dados sejam reindexados. a ingestão sem esquema O Rockset pode ser dimensionado para centenas de terabytes de dados sem precisar ser reindexado. Isso remonta à estratégia de fragmentação do Rockset. Quando a computação que um cliente aloca em sua Instância Virtual aumenta, um subconjunto de fragmentos é embaralhado para obter uma melhor distribuição no cluster, permitindo indexação e execução de consultas mais paralelizadas e mais rápidas. Como resultado, a reindexação não precisa ocorrer nesses cenários. Conclusão O Elasticsearch foi projetado para análise de log onde os dados não são atualizados, inseridos ou excluídos com frequência. Com o tempo, as equipes expandiram o uso do Elasticsearch, muitas vezes usando o Elasticsearch como armazenamento de dados secundário e mecanismo de indexação para análises em tempo real de dados transacionais em constante mudança. Isso pode ser um empreendimento caro, especialmente para equipes que estão otimizando a ingestão de dados em tempo real, além de envolver uma quantidade considerável de sobrecarga de gerenciamento. O Rockset, por outro lado, foi projetado para análises em tempo real e para disponibilizar novos dados para consulta dentro de 2 segundos após sua geração. Para resolver esse caso de uso, o Rockset oferece suporte a inserções, atualizações e exclusões no local, economizando computação e limitando o uso de reindexação de documentos. A Rockset também reconhece a sobrecarga de gerenciamento de conectores e ingestão e adota uma abordagem de plataforma, incorporando conectores em tempo real em sua oferta de nuvem. No geral, vimos empresas que para análises em tempo real economizarem 44% apenas na conta de computação. Junte-se à onda de equipes de engenharia que mudam do Elasticsearch para o Rockset em poucos dias. Comece seu hoje. migraram do Elasticsearch para o Rockset teste gratuito
