Este é um artigo traduzido originalmente publicado dia 24/04/2023 pelo Jack Vanlightly no post: "Kafka vs Redpanda Performance - Do the claims add up?". Siga o Jack no LinkedIn para se manter atualizado com novas publicações.
O Apache Kafka tem sido o sistema de streaming de eventos de código aberto mais popular por muitos anos e continua a crescer em popularidade. Dentro do ecossistema mais amplo, existem outros concorrentes de código aberto e disponíveis para Kafka, como Apache Pulsar, NATS Streaming, Redis Streams, RabbitMQ e, mais recentemente, Redpanda (entre outros).
Redpanda é um clone Kafka disponível em fonte escrito em C++ usando a estrutura Seastar do ScyllaDB, um banco de dados de wide-columns. Ele usa o popular protocolo de consenso Raft para replicação e toda a lógica de consenso distribuído. A Redpanda tem se esforçado muito para explicar que seu desempenho é superior ao Apache Kafka devido à sua arquitetura thread-per-core, uso de C++ e seu design de armazenamento que pode levar as unidades NVMe de alto desempenho aos seus limites.
Eles afirmam ser o estágio mais recente na evolução dos sistemas de registro distribuído, pintando uma imagem de Kafka e outros sistemas como sendo projetados para uma era passada do disco giratório cuja hora chegou. Eles apresentam um argumento convincente não apenas para um melhor desempenho, mas também para um custo total de propriedade (TCO) mais baixo, e seus benchmarks parecem respaldar tudo isso.
O interessante sobre Redpanda e Kafka é que ambos são sistemas de log distribuídos e apenas anexados que normalmente têm um fator de replicação de 3, são baseados em líder-seguidor e usam o mesmo protocolo de cliente. Além disso, ambos optaram por mapear uma partição para um arquivo de segmento ativo em vez de usar um modelo de armazenamento de log compartilhado, como Apache Pulsar e Pravega. Para a mesma taxa de transferência, eles gravam a mesma quantidade de dados no disco (para o mesmo número de arquivos) e transmitem a mesma quantidade de dados pela rede. Portanto, com relação às reivindicações de taxa de transferência superior, a questão é: dado que normalmente dimensionamos nossas instâncias de nuvem com base nos recursos de E/S de rede e disco, um broker com CPU otimizada fará uma grande diferença no custo? Ou será que o Redpanda pode simplesmente gravar dados no disco mais rápido que o Kafka? Quando se trata de latência, a arquitetura thread-per-core fará diferença? As estruturas de dados concorrentes, baseadas em bloqueios, no Kafka representam uma parte considerável da latência de ponta a ponta? Essas são algumas das perguntas que eu tinha quando comecei.
O Redpanda afirma
De acordo com o benchmark Redpanda vs Kafka e sua análise de custo total de propriedade , se você tiver uma carga de trabalho de 1 GB/s, você só precisa de três instâncias i3en.6xlarge com Redpanda, enquanto o Apache Kafka precisa de nove e ainda tem baixo desempenho. Eles são um conjunto ousado de reivindicações e parecem plausíveis. Construído em C++ para hardware moderno com uma arquitetura de thread por núcleo soa atraente e parece lógico que as afirmações sejam verdadeiras. Mas eles são?
Desde que ingressei na comunidade Apache Kafka em fevereiro de 2022, não vi nenhum interesse da comunidade em verificar essas alegações do Redpanda de desempenho superior. Até o ChatGPT parece pensar que o Redpanda tem desempenho superior ao Kafka porque basicamente ninguém realmente testou se é verdade. Então eu decidi colocar o Redpanda à prova e ver se tudo resiste a um exame minucioso. Não testei clusters Kafka de 9 nós - todos os testes foram com 3 corretores e sempre no i3en.6xlarge .
Sou um engenheiro de sistemas distribuídos com grande experiência em benchmarking e já contribuí para o projeto OpenMessagingBenchmark. Passei meses da minha vida fazendo benchmarking de filas de quorum do RabbitMQ e streams do RabbitMQ enquanto estava na VMware. Enquanto estava na Splunk, passei um tempo significativo comparando o Apache BookKeeper como parte do meu trabalho de desempenho e observabilidade como um committer do BookKeeper. Agora trabalho na Confluent, com foco no Apache Kafka e nosso serviço de nuvem. Estou bastante acostumado com esse tipo de projeto e o melhor é que o OpenMessagingBenchmark facilita bastante a execução.
O que eu encontrei?
Corri benchmarks contra Redpanda e Kafka em hardware idêntico : três i3en.6xlarge, mesmas configurações de cliente e ambos com ou sem TLS.
Posso dizer, agora que concluí meu trabalho de benchmarking, que as afirmações de Redpanda sobre Kafka e até mesmo sobre seu próprio desempenho são muito exageradas. Isso provavelmente não é surpresa, já que tudo isso é realmente apenas marketing de referência, mas, como afirmei antes, se ninguém realmente testar essas coisas e escrever sobre isso, as pessoas simplesmente começarão a acreditar. Precisamos de uma verificação da realidade.
Como você verá nesta análise, ninguém deve usar três i3en.6xlarge para uma carga de trabalho de 1 GB/s. O Redpanda o gerencia com as contagens de partições e clientes fornecidas, mas não o gerencia rapidamente quando você começa a fazer pequenas modificações nessa carga de trabalho.
Comecei a testar o Redpanda em março e tenho feito os mesmos testes contra Kafka e Redpanda desde então. Algumas descobertas notáveis são:
O benchmark de 1 GB/s não é generalizável, pois o desempenho do Redpanda se deteriorou significativamente com pequenos ajustes na carga de trabalho, como executá-lo com 50 produtores em vez de 4.
O desempenho do Redpanda durante seu benchmark de 1 GB/s deteriorou-se significativamente quando executado por mais de 12 horas.
A latência de ponta a ponta da Redpanda de seu benchmark de 1 GB/s aumentou muito quando os corretores atingiram seu limite de retenção de dados e começaram a excluir arquivos de segmento. Os benchmarks atuais são baseados no desempenho da unidade vazia.
Redpanda lutou quando os produtores definiram chaves de registro, fazendo com que as mensagens fossem despachadas para partições com base nessas chaves, resultando em lotes de mensagens menores e mais numerosos.
Redpanda não conseguiu empurrar as unidades NVMe para seu limite de taxa de transferência de 2 GB/s com acks=1, mas Kafka foi.
O Kafka foi capaz de drenar grandes acúmulos sob constante carga de produtor de 800 MB/s ou 1 GB/s, mas o Redpanda não. Seus pedidos em atraso continuaram a crescer ou entraram em um equilíbrio estável, onde o estoque foi drenado parcialmente, mas nunca totalmente.
Em todos os casos acima, o Kafka geralmente superou o Redpanda em grande medida, alcançando maior rendimento e menor latência de ponta a ponta, até mesmo as latências de cauda - em hardware idêntico . Em outros testes que executei, Redpanda superou Kafka (embora nunca em taxa de transferência) - então, sim, Redpanda “pode” ser “mais rápido” que Kafka, mas o inverso também é verdadeiro.
Vou explicar brevemente essas descobertas abaixo com dados. Também publicarei blogs mais deep dive que exploram os resultados com mais profundidade e, se possível, discutem as possíveis razões subjacentes por trás de cada descoberta.
Espero que você tenha uma nova percepção de que existem compensações, não há almoço grátis, apesar da linguagem de implementação ou dos algoritmos usados. As otimizações existem, mas você não pode otimizar tudo. Em sistemas distribuídos você não encontrará empresas ou projetos que afirmam que otimizaram para CAP no teorema CAP. Da mesma forma, não podemos otimizar para alto rendimento, baixa latência, baixo custo, alta disponibilidade e alta durabilidade, tudo ao mesmo tempo. Como construtores de sistemas, temos que escolher nossos trade-offs, aquela arquitetura única de bala de prata ainda está por aí, ainda não a encontramos.
Primeiro, uma auditoria do código de referência
Comecei com o repositório OpenMessagingBenchmark do Redpanda, pois ele não existe no repositório OMB oficial. Antes de começar, fiz uma auditoria do código para garantir que tudo parecia bem. Infelizmente para Kafka, ele foi configurado incorretamente com alguns problemas.
O problema nº 1 é que no arquivo server.properties do Kafka há a linha log.flush.interval.messages=1que força o Kafka a fsync em cada lote de mensagens. Portanto, todos os testes, mesmo aqueles em que isso não está configurado no arquivo de carga de trabalho, obterão esse comportamento fsync. Eu escrevi anteriormente sobre como o Kafka usa a recuperação em vez do fsync por segurança . Definir essa linha degradará o desempenho do Kafka e é relativamente incomum que as pessoas a definam. Portanto, removi isso do arquivo server.properties. Redpanda afirma incorretamente que Kafka não é seguro porque não faz fsync - isso não é verdade.
O problema nº 2 é que o Java 11 ainda é usado. Para ser justo, é assim no repositório OMB upstream e no fork do Confluent. No entanto, o Java 11 já tem 5 anos e o Kafka funciona bem com o Java 17. O Kafka se beneficia especialmente do Java 17 com TLS. Então, atualizei o script Ansible para instalar o Java 17 nos clientes (Redpanda incluído) e no servidor Kafka.
O problema nº 3 é que o driver Redpanda (os clientes) é codificado para confirmar compensações de forma assíncrona a cada 5 segundos. O driver Kafka, por outro lado, por padrão, confirma de forma assíncrona em cada votação. Então, atualizei o produtor no driver Redpanda para corresponder ao driver Kafka, onde o comportamento de confirmação é controlado por configurações e garanti que correspondam.
Fiz minha própria cópia do repositório onde todas essas alterações existem.
Correções de bugs críticos para OMB
Ao longo do meu tempo comparando Kafka e Redpanda, encontrei alguns bugs com o código de referência ao longo do caminho. O pior foi um bug que encontrei algumas vezes que causou a perda da maioria dos dados de latência, fazendo com que os resultados de alto percentil fossem significativamente menores. A causa principal era que, quando o código de referência tenta coletar histogramas de todas as máquinas clientes, se houver um erro, ele tenta novamente. O problema é que, a cada chamada para obter o histograma, o histograma original retorna uma cópia, mas se redefine. Portanto, quando ocorre a segunda tentativa, o histograma original possui apenas alguns segundos de dados, causando resultados ruins. Só descobri isso ao fazer uma análise estatística de alguns resultados que pareciam estranhos. Enviarei uma correção para isso no repositório OMB upstream.
Encontrando 1 - 500 MB/s e 1 GB/s, 4 contra 50 produtores
Executei o benchmark Redpanda 1 GB/s em 6 taxas de transferência diferentes: 500, 600, 700, 800, 900 e 1000 MB/s. Também executei com os 4 produtores e consumidores originais, depois com 50 produtores e consumidores. O resultado foi uma degradação significativa do desempenho com 50 produtores para Redpanda. O outro resultado digno de nota foi que o Redpanda não conseguiu atingir 1000 MB/s com TLS, o que entra em conflito com os benchmarks do Redpanda.
Não consegui levar o Redpanda a 1000 MB/s com TLS, mesmo com o ponto ideal de 4 produtores. Eu executei isso três vezes e o gráfico abaixo mostra o melhor resultado do Redpanda.
Veja Kafka vs Redpanda Performance - Parte 1 - 4 vs 50 produtores para mais detalhes e como executar este benchmark.
Descoberta 2 - Deterioração do desempenho em testes de longa duração
Executei o benchmark de 1 GB/s, 288 partições, 4 produtores/consumidores por 24 e 36 horas.
Após cerca de 12 horas, as latências de ponta a ponta do Redpanda aumentaram.
O aumento nas latências da cauda foi enorme.
A latência de ponta a ponta aumentou significativamente nos percentis mais altos. As medições do p99 atingem 3,5s, enquanto o p99,99 chega a 26s.
O culpado acabou sendo as unidades NVMe, que começaram a exibir latências de gravação muito altas após 12 horas de carga constante. Isso se manifestou nas métricas do Redpanda como “tempo gasto morrendo de fome de disco”.
O tempo de E/S de gravação e leitura aumentou na marca de 12 horas.
Consegui reproduzir isso em três das três implantações, executando a carga de trabalho de 1 GB/s. Estou satisfeito por isso ser reproduzível por qualquer pessoa.
Enquanto Redpanda se deteriorou com o tempo, vi que Kafka realmente melhorou com o tempo.
Incluindo as latências da cauda.
A degradação da unidade NVMe para Redpanda se resumia a como os SSDs funcionam sob o capô e à natureza aleatória de E/S do Redpanda. Ele grava dados em pequenos blocos de 16 KB que, quando combinados com 288 partições, cada uma com um arquivo de segmento ativo, resulta em um padrão de acesso IO que se situa na extremidade IO aleatória do espectro. IO aleatório coloca uma carga maior nas unidades SSD devido à amplificação de gravação que ocorre como resultado de blocos de dados reescritos pelo GC da unidade - causando latência extra. Este é um exemplo de um sistema atingindo o gargalo GC da unidade NVMe.
Eu entro em mais detalhes sobre isso em Kafka vs Redpanda Performance Parte 2 - Testes de longa duração .
Descoberta 3 - A latência do Redpanda dispara ao atingir o limite de retenção
Existem limites de retenção em sistemas de streaming de eventos, pois sem eles, os discos ficariam cheios e os servidores travariam. Mesmo ao usar armazenamento em camadas, precisamos ter um limite de retenção local.
Quando executei os testes do Redpanda por tempo suficiente para atingir o limite de retenção, vi um estranho aumento gradual na latência de ponta a ponta. O tamanho da etapa parecia ser afetado pela quantidade de disco usada e pela taxa de transferência do teste. Os testes de baixo throughput não apresentaram o comportamento, mas os de médio e alto throughput sim.
No caso abaixo, o limite de retenção foi atingido pouco antes das 22h.
Isso é reproduzível em todos os testes de rendimento médio a alto que executei. É improvável que um sistema de produção veja todas as partições atingirem seus limites de retenção de uma só vez, portanto, você pode ver apenas esse aumento gradual em um benchmark - mas a penalidade de desempenho do limite de retenção ainda existirá, apenas será mais difícil de detectar.
Infelizmente para mim, a maioria dos meus resultados foram obtidos antes de eu fazer essa descoberta. No entanto, executei novamente o benchmark Redpanda de 1 GB/s, permitindo que o período de aquecimento fosse longo o suficiente para preencher os discos e atingir o limite de retenção e obtive resultados muito diferentes para o Redpanda.
A carga extra de exclusão de arquivos de segmento tem um grande impacto na latência de ponta a ponta. Esse efeito se manifestou nos testes de throughput mais alto e nem sempre foi exibido em cargas de trabalho de throughput mais baixo (<100 MB/s). Se você está pensando em executar benchmarks Kafka vs Redpanda, lembre-se de medir o desempenho em um cluster que já atingiu seu limite de retenção.
Veja mais detalhes em Kafka vs Redpanda Performance - Parte 3 - Atingindo o limite de retenção onde também explico como reproduzir isso.
Descoberta 4 - O impacto das chaves de registro
O uso de chaves de registro é muito comum, pois nos permite obter a ordem das mensagens. As mensagens são despachadas para as partições com base no hash da chave de registro - uma técnica de distribuição de dados bastante padrão. A desvantagem é que normalmente é mais difícil para os corretores, pois resulta em lotes de mensagens menores e mais numerosos, o que cria mais trabalho.
Descobri que, com as chaves de registro, o Redpanda não conseguia igualar o Kafka na taxa de transferência ao tentar atingir 1 GB/s e 500 MB/s usando o benchmark de 288 partições como base.
Mudei de tática e projetei uma carga de trabalho um pouco mais comum do que um único tópico com centenas de partições. Com 40 e 80 tópicos, de 10 partições cada, o Kafka alcançou latências ponta a ponta mais baixas, mesmo nos percentuais altos.
O padrão é que, à medida que a taxa de lote de mensagens aumenta, mas o tamanho do lote diminui, a vantagem do Redpanda diminui ou até desaparece completamente. A taxa fsync é normalmente muito alta (> 200 K/s) para partições altas e comparações de taxa de lote de mensagens altas, mesmo para o teste de 50 MB/s, o que pode explicar as latências mais altas.
Consulte Desempenho de Kafka vs Redpanda - Parte 4 - Impacto das chaves de registro para obter mais detalhes.
Descoberta 5 - Redpanda não conseguiu atingir o limite da unidade NVMe com acks=1
Peguei o benchmark Redpanda 1 GB/s e modifiquei para começar em 1 GB/s e ir incrementando em passos até atingir 2 GB/s, com 10 produtores e acks=1.
O resultado foi que o Kafka atingiu um pico de taxa de transferência de 1900 MB/s, mas na verdade atingiu o limite físico da unidade NVMe de 2 GB/s.
Parece irônico que, de fato, apenas Kafka pudesse utilizar totalmente as unidades NVMe no final.
Consulte Desempenho de Kafka vs Redpanda - Parte 5 - Atingindo o limite de unidade NVMe para obter detalhes.
Descoberta 6 - Redpanda incapaz de drenar backlogs sob carga de produtor de 1 GB/s
Executei um conjunto de testes com a taxa do produtor de 800 MB/s ou 1 GB/s e pausei os consumidores para criar um backlog. Em seguida, retomei os consumidores e medi o tempo para os consumidores drenarem o backlog e retornarem à latência de ponta a ponta abaixo do segundo - tudo sob carga constante do produtor.
A Redpanda não conseguiu drenar nenhum dos pedidos em atraso, com os pedidos em atraso continuando a crescer após a retomada dos consumidores ou o pedido em atraso para drenar parcialmente com os corretores e consumidores entrando em um estado de equilíbrio onde um pedido em atraso estável permaneceu. Kafka foi capaz de drenar os atrasos em todos os casos.
Equilibrar a taxa do produtor versus consumidor pode ser um desafio para os construtores de sistemas. Para cargas estressantes, você prioriza consumidores ou produtores ou apenas permite um comportamento emergente baseado na competição por recursos dentro dos corretores? Se você priorizar os produtores, os consumidores podem ficar tão para trás que os dados acabam sendo perdidos. Se você priorizar os consumidores, os produtores podem acabar vendo muita pressão de retorno e os dados vitais que você precisa inserir no sistema não são capazes de fazê-lo. Não há uma resposta fácil, mas para uma organização que implanta esses sistemas, é melhor descobrir como o tamanho de cluster escolhido pode lidar com coisas como atrasos após interrupções do consumidor. Um cluster Redpanda de três i3en.6xlarge claramente não vai funcionar neste caso.
Consulte Desempenho de Kafka vs Redpanda - Parte 6 - Drenando atrasos para obter os detalhes.
Conclusões
Todos esses testes foram executados em hardware idêntico (três i3en.6xlarge), com as mesmas configurações de cliente e configurações de TLS.
É claro que os benchmarks do Redpanda não são generalizáveis e existe uma grande variedade de cargas de trabalho em que ele tem um desempenho significativamente pior do que o Apache Kafka.
Para resumir o que encontrei nesses testes:
Manter a taxa de transferência a mesma, mas simplesmente alterar a contagem de produtores e consumidores de 4 para 50, fez com que o desempenho do Redpanda caísse significativamente abaixo do Kafka.
A execução do benchmark Redpanda por 24 horas com carga constante fez com que as unidades NVMe nos corretores Redpanda diminuíssem devido ao GC interno da unidade, resultando em grandes latências - mesmo com o superprovisionamento recomendado de 10% das unidades pela AWS. Essa lentidão não ocorreu com o Kafka devido ao seu padrão de acesso IO mais sequencial.
A execução dos benchmarks e a medição da latência após o limite de retenção ter sido atingido mostraram latências de ponta a ponta muito mais altas para o Redpanda, sem alteração para o Kafka. Os resultados de latência de ponta a ponta para Redpanda são realmente válidos apenas quando o tamanho da retenção é atingido.
O uso de chaves de registro reduziu a taxa de transferência do Redpanda e aumentou significativamente as latências. Kafka venceu Redpanda confortavelmente nos testes de recorde. Lotes menores e mais numerosos fazem com que o Redpanda engasgue em muitas tarefas pequenas e altas taxas de fsync em muitos arquivos.
Somente Kafka foi capaz de utilizar totalmente a taxa de transferência de 2 GB/s das unidades NVMe usando acks=1.
Enquanto sob carga constante do produtor, os consumidores só conseguiram drenar as pendências com o Kafka.
Voltando à análise de TCO original afirma que você só precisa de três corretores Redpanda em instâncias i3en.6xlarge para uma carga de trabalho de 1 GB/s, mas você precisa de nove instâncias para Kafka: parece claro que não é o caso. A verdade é que um cluster de produção provisionado corretamente teria mais capacidade do que essas três instâncias para uma carga de trabalho de 1 GB/s, independentemente de você escolher Kafka ou Redpanda. O fato de o Redpanda não poder drenar um backlog enquanto está abaixo de 1 GB/s de carga do produtor nessa quantidade de hardware é uma indicação clara de que três i3en.6xlarge não é um bom dimensionamento. Se você derrubar um corretor Redpanda, ele também não conseguirá manter a carga de 1 GB/s. Na verdade, se você ler os documentos do Redpanda sobre dimensionamento, eles dizem para executar cinco i3en.12xlarge para esta carga de trabalho, o que nos leva de um sistema de 72 núcleos de CPU para um sistema de 240 núcleos!
Esses testes são facilmente executados por você mesmo, cada postagem do blog explica como. Eu recomendo executar o Kafka por meio do meu repositório OMB em vez do Redpanda OMB, pois tenho o Kafka configurado corretamente e com o Java 17.
Algumas reflexões
Depois de passar um bom tempo comparando os dois, eu diria que, quando o Redpanda obtém a carga de trabalho certa, ele pode realmente brilhar - o problema é que há muitas cargas de trabalho onde isso não acontece. Seu desempenho é um pouco mais precário que o Apache Kafka. Os tamanhos dos lotes não devem ser muito pequenos, a taxa de transferência não deve ser muito alta em altas cargas de trabalho de partição e as unidades precisam ser adequadamente provisionadas com espaço vazio suficiente para permitir a natureza aleatória de E/S de sua camada de armazenamento. A baixa taxa de transferência é onde o Redpanda tem seus resultados de latência de ponta a ponta mais robustos; à medida que você aumenta a taxa de transferência, as especificidades da carga de trabalho podem ter um impacto desproporcional no desempenho. Também é extremamente sensível à latência do drive.
Kafka também tem seus problemas. O cache da página é uma faca de dois gumes. É ótimo para um desempenho robusto em uma ampla variedade de cargas de trabalho, mas pode causar picos de latência de ponta a ponta que podem afetar as latências de cauda. Como eu disse antes, cada sistema escolheu suas compensações. Para aqueles que são extremamente sensíveis à latência de ponta a ponta, um robusto cluster Redpanda pode ser o que você deseja. Deve ser robusto porque você realmente não quer que o Redpanda comece a estressar o hardware porque muitas de suas vantagens parecem desaparecer. Você também pode precisar adaptar sua carga de trabalho para corresponder ao Redpanda - algumas cargas de trabalho de chave de registro podem simplesmente não funcionar.
O que realmente significa construído para hardware moderno?
Redpanda diz que eles são o próximo estágio na evolução dos sistemas de log distribuídos… mas isso é verdade? Eles afirmam que Kafka agora está desatualizado, mas é? O argumento parece se resumir a ser “construído para hardware moderno”.
A questão sobre a qual estou refletindo é o que “construído para hardware moderno” realmente significa para um sistema de log somente anexado distribuído? O Redpanda usa uma arquitetura thread-per-core, mas é para a CPU que um sistema de log apenas anexado deve ser otimizado?
A afirmação de Redpanda sobre ser construída para unidades NVMe modernas é verdadeira. Todo o design baseia-se em aproveitar o fato de que as unidades NVMe podem lidar com E/S aleatórias com muito mais eficiência do que discos giratórios. Mas só porque essas unidades podem lidar com mais IO aleatório do que o HDD não significa que seja uma arquitetura melhor. Como escrevi recentemente no blog , IO sequencial está longe de morrer quando se trata de unidades NVMe, é tão importante como sempre.
Na verdade, não acredito que a arquitetura de armazenamento do Redpanda seja ideal para um sistema de log e provavelmente seja sua maior fraqueza. Com o Redpanda, a partição é tanto uma abstração voltada para o usuário quanto uma abstração de replicação e armazenamento. Ele mapeia uma partição para um cluster Raft, que grava em seu próprio log físico no disco. Esta é uma escolha de design óbvia, mas que talvez esteja perdendo onde a inovação pode realmente ser encontrada para um sistema de armazenamento de log distribuído. Mapear uma partição para um arquivo de segmento ativo e executar fsyncs sobre um grande número de arquivos individuais tem um custo - mesmo com unidades NVMe de alto desempenho. Eu vi 200K fsyncs por segundo e uma utilização de CPU auto-relatada muito alta com uma taxa de transferência de 50 MB/s devido a uma alta contagem de partições e um pequeno tamanho de lote.
O Kafka também usa esse modelo de uma partição e um arquivo ativo, mas foi criado para atenuar as desvantagens dessa arquitetura e, ao mesmo tempo, se beneficiar de seus pontos fortes. Ele depende do sistema operacional para liberar o cache da página com um padrão de E/S mais sequencial e evita fsyncs usando a recuperação em seu protocolo de replicação. O benefício dessa abordagem é o desempenho robusto na maioria das cargas de trabalho. As vantagens e desvantagens são que as latências percentuais altas podem ser maiores do que um sistema que está constantemente executando liberações menores e, para melhor durabilidade, precisamos de vários domínios de falha.
Existem outras opções em que o modelo de log lógico e o modelo de log físico são dissociados, o que apresenta alguns benefícios (e desafios). Se você deseja padrões de gravação mais sequenciais, deseja que a abstração de armazenamento seja mais granular do que a abstração voltada para o usuário (por exemplo, um log compartilhado que armazena gravações de muitas partições). O Apache BookKeeper (usado pelo Apache Pulsar e Pravega) é um exemplo disso, ele separa os logs lógicos dos logs físicos, adotando a abordagem de log compartilhado para seu mecanismo de armazenamento, o que fornece um padrão de E/S de disco puramente sequencial, independentemente de quantas partições do Pulsar. deve apoiar. Isso permite que o BookKeeper separe o desempenho da contagem de partições em grande medida. A desvantagem é que todos os dados são gravados duas vezes: o WAL otimizado para gravação e o armazenamento de razão de longo prazo otimizado para leitura, mas sempre sequencialmente.
Pessoalmente, sou um grande fã do design de log compartilhado na camada de armazenamento, apesar de seus outros problemas, como a necessidade de mais índices para leituras e mais unidades. Sua escolha de compensações pode proporcionar um bom desempenho em uma ampla gama de cargas de trabalho e em SSDs ou HDDs. O Apache Kafka fica no meio desse continuum IO sequencial/aleatório, com compensações em algum lugar entre BookKeeper e Redpanda.
Quando se trata de logs distribuídos, eu argumentaria que, para cargas de trabalho baseadas em log, “ criado para hardware moderno ” significa basicamente o mesmo de sempre - usando E/S sequencial que tem melhor compatibilidade mecânica mesmo para SSDs modernos. Dado que o produto é um log, por que não aproveitá-lo em sua arquitetura de armazenamento? O Kafka e o BookKeeper não precisam reservar grandes quantidades de espaço na unidade NVMe para superprovisionamento por um motivo.
O Redpanda merece sentar-se no ápice do design de toras distribuídas? Acho que não. Mas também não está atrás. Vemos sistemas de armazenamento de logs distribuídos de todas as formas e tamanhos, cada um fazendo diferentes compensações e todos se beneficiando e pagando o preço por essas decisões - o Redpanda não é diferente.
O Apache Kafka tem pedigree por um motivo, não é antiquado ou desatualizado, apesar do que os concorrentes possam querer que você acredite. Seu design é tão relevante hoje, com drives NVMe, quanto era quando foi concebido. Isso não quer dizer que não tenha verrugas, mas a comunidade Kafka não parou de melhorar o corretor (como adicionar filas para Kafka ) - Kafka está vivo e bem em 2023.
Então, qual é mais rápido? <piada>
O Redpanda pode mostrar benchmarks onde o Redpanda tem melhor desempenho. Posso mostrar benchmarks onde o Kafka tem melhor desempenho simplesmente ajustando ligeiramente as cargas de trabalho ou usando coisas como chaves de registro. O ponto é que os benchmarks são realmente úteis apenas quando você os executa e para sua própria carga de trabalho específica.
A concorrência é boa, mas as falsas narrativas não ajudam ninguém. O que é mais rápido? Como sempre a realidade é que “depende”.
Links da série:
Performance Kafka vs Redpanda - Parte 1 - 4 vs 50 produtores
Desempenho de Kafka vs Redpanda - Parte 2 - Testes de longa duração
Performance de Kafka vs Redpanda - Parte 3 - Atingindo o limite de retenção
Desempenho de Kafka vs Redpanda - Parte 4 - O impacto das chaves de registro
Desempenho de Kafka vs Redpanda - Parte 5 - Atingindo o limite de unidade NVMe
Desempenho de Kafka vs Redpanda - Parte 6 - Drenando atrasos
Comments