O Elastic Stack 7.0.0 chegou

O 7.0 chegou! A versão representa mais de 10.000 pull requests de 861 committers, por isso, antes de mais nada, o nosso muito obrigado aos nossos funcionários e à comunidade.

Se quiser ficar por dentro da nova versão com quem fez o código, vamos ter um evento de lançamento virtual ao vivo dia 25 de abril de 2019, às 8h PDT. Venha ver demonstrações da versão 7.0, um AMA com engenheiros da Elastic do mundo todo e muito mais.

O Elastic Stack 7.0 já está disponível para download e você também pode conferir a nova versão no Elasticsearch Service](https://www.elastic.co/pt/cloud/elasticsearch-service) na Elastic Cloud, a única solução hospedada a oferecer novas versões do Elastic Stack no dia do lançamento.

Com tantas novidades boas, é difícil saber por onde começar, então não vamos perder empo.

Kibana 7.0: novo design e navegação... e o modo escuro!

No design do Kibana 7.0, decidimos colocar o foco no conteúdo, por isso você verá que a interface do usuário tem um jeito mais minimalista e leve. A mudança mais visível é a troca para uma navegação global, que introduz um cabeçalho constante para alternar os espaços do Kibana, exibir breadcrumbs e iniciar ações do usuário como alterar senha ou sair. Para conseguir isso e aumentar a coerência, criamos o Elastic UI Framework. Ao longo do último ano, convertemos quase todo o Kibana para usar esses componentes. Com esses componentes e muito trabalho de nossas equipes de design e engenharia, também fizemos grandes simplificações na forma como os estilos e as folhas de estilos são aplicadas.

A maior coerência e as melhorias na folha de estilo nos permitiram realizar um dos maiores pedidos para o Kibana, o modo escuro em toda a plataforma. Outro benefício desta mudança é que agora os painéis do Kibana têm um design responsivo, que é a primeira etapa para melhorar de forma dramática a usabilidade nos dispositivos móveis.

Uma nova era para a coordenação de cluster no Elasticsearch

Desde o começo, nosso foco foi criar um Elasticsearch fácil de ser ampliada e resiliente a falhas. Para isso, utilizamos diversas abordagens, desde tornar os nós individuais mais ampliáveis e confiáveis até a melhoria contínua de nossa camada de coordenação de cluster conhecida como Zen Discovery. No 7.0, estamos introduzindo grandes melhorias nas duas áreas novamente.

Há uma camada de coordenação de cluster completamente nova para o Elasticsearch, que é mais rápida, mais segura e mais fácil de usar. Para alcançar isso, começamos a nos concentrar na correção teórica de nosso novo algoritmo de consenso distribuído usando modelos formais para validar o design. Embora já existam algoritmos de consenso bem conhecidos, como Paxos, Raft, Zab e Viewstamped Replication (VR), as demandas de um cluster do Elasticsearch exigem uma possibilidade maior de mudanças no cluster, o suporte para aumentar ou diminuir um cluster de forma fácil e uma estratégia de upgrade simplificada que permita que os clusters do 6.7 usem os recursos do 7.0 que esses algoritmos de referência não conseguiram prover. A nova camada de coordenação de cluster também inclui uma série de alterações que reduzem a probabilidade de erro humano e oferecem escolhas mais claras em caso de necessidade de recuperação de falha catastrófica. Não é fácil aumentar a confiabilidade, a performance e a experiência do usuário, tudo ao mesmo tempo, especialmente em um componente tão central. Estamos muito orgulhosos da nova camada de coordenação de cluster e do processo até chegarmos nela. Para saber mais, leia o blog.

Nós individuais no Elasticsearch são criados com resiliência em mente. Se você enviar muitas solicitações para um nó ou suas solicitações forem muito longas, o nó será enviado de volta. Alcançamos isso com disjuntores no Elasticsearch, que determinam que o nó não suportará uma determinada solicitação e respondem imediatamente pedindo que o cliente tente novamente em outro nó. Para nós com JVM heap sizes menores, que estão se tornando mais comuns conforme os usuários passam a usar um modelo cluster-per-tenant em vez de um cluster multitenant grande, isso é ainda mais importante. No 7.0, introduzimos o real memory circuit breaker, que detecta com muito mais precisão solicitações impossíveis e impede que elas causem a instabilidade de um nó. Leia o blog para saber mais sobre como essa mudança melhora a confiabilidade geral do nó e do cluster.

Uma forcinha para a relevância e a velocidade em diversos casos

Relevância e velocidade são as coisas mais importantes para uma boa experiência de pesquisa. E o Elasticsearch 7.0 apresenta diversos recursos de base que melhoram as duas coisas.

• Consultas top k mais rápidas: em diversos casos, visualizar os resultados top k (digamos 20) de uma consulta importa mais para o usuário do que a contagem exata (ou seja, o número total de resultados para uma consulta). Por exemplo, se alguém estiver pesquisando um produto em um site de e-commerce, estará muito mais interessado nos 10 resultados mais relevantes do que nos outros 120.897 que correspondem à busca. O Elasticsearch 7.0 (e o Lucene 8.0) implementam um novo algoritmo (Block-Max WAND) que aumenta muito a velocidade para se obter os top hits.
• Intervals queries:* alguns casos de busca, por exemplo, jurídico e patentes, trazem a necessidade de encontrar registros nos quais palavras ou frases estejam a uma certa distância umas das outras. As intervals queries no Elasticsearch 7.0 trazem uma nova forma de estruturar tais consultas e são significativamente mais simples de usar e definir comparadas ao método anterior (span queries). Elas são mais resilientes com casos limítrofes se comparadas às span queries.
• Function score 2.0: pontuação customizada é a coisa mais importante dos casos de uso avançados em que o usuário quer um controle mais fino sobre a relevância e o ranking de resultados. O Elasticsearch oferece essa possibilidade desde o começo. A versão 7.0 introduz a próxima geração de pontuação de função que oferece uma forma mais simples, modular e flexível de gerar uma pontuação de ranking por registro. Com a nova estrutura modular, os usuários conseguem misturar como quiserem uma série de funções aritméticas e de distância para calcular pontuações como quiserem e ter mais controle sobre como os resultados são pontuados e classificados.

Smooth Zoom no Elastic Maps com geotile grid

Ao longo dos anos, fomos melhorando nosso suporte aos geodados. Desde o começo, quando adicionamos o suporte aos dados geográficos no Elasticsearch até a introdução da estrutura de dados Bkd-Tree no Lucene e o uso deles para melhorar o desempenho de consultas de geoshape em 25x para o serviço do Elastic Maps que alimentam o mapa de base global no Kibana.

Com o 7.0, continuamos este investimento apresentando uma nova agregação no Elasticsearch para lidar com blocos de mapas (geo) de forma que o usuário consiga dar zoom no mapa sem mudar a forma dos dados de resultado. A nova agregação geotilegrid agrupa os geopoints em baldes que representam as células em uma grade, com cada célula sendo correspondente a um bloco no mapa. Antes dessa alteração, as bordas do formato podiam mudar um pouco com a mudança do nível do zoom, porque os blocos retangulares mudariam de orientação em diferentes níveis de zoom. O Elastic Maps no 7.0 já está usando esta nova agregação para garantir que sua visão permaneça estável durante o zoom. Este nível de precisão é importante seja para proteger a rede de ataques, investigar tempo de resposta alto em locais específicos ou acompanhar a trilha do seu irmão na Pacific Crest Trail.

Fortalecimento das séries de tempo com suporte a precisão e nanosegundos

Seja para métricas de infraestrutura, registros de auditoria de sistema, tráfego de rede ou um veículo em Marte, os dados de série de tempo são muito importantes para diversos usos no Elastic Stack. Poder ordenar e correlacionar eventos de forma precisa em diversos sistemas e serviços é muito importante.

Até agora, o Elasticsearch só armazenou timestamps com precisão de milissegundos. O 7.0 adiciona alguns zeros e traz a precisão dos nanosegundos, que permite que usuários que coletem dados com alta frequência tenham a precisão necessária para armazenar e sequenciar esses dados. Essa mudança foi possível com a migração da biblioteca JODA para o Java time API oficial no JDK 8.