Lançamento do OpenSearch 3.0 - grande reforço no desempenho de banco de dados vetorial e na infraestrutura de busca com IA

• O OpenSearch 3.0 foi lançado oficialmente e oferece desempenho 9,5 vezes superior em relação ao OpenSearch 1.3
• Foram adicionados diversos recursos inovadores para busca vetorial, como aceleração por GPU, integração com agentes de IA e otimização de armazenamento
• gRPC, streaming com Kafka e identificação automática de índices aumentam a eficiência e a flexibilidade no processamento de dados
• Do lado da infraestrutura de busca, a adoção de Lucene 10, Java 21 e arquitetura modular melhora a escalabilidade futura e a manutenção
• Consolida-se como uma plataforma de busca de próxima geração baseada em comunidade open source, atendendo ao aumento da demanda por buscas com IA e baseadas em RAG

---

Lançamento oficial do OpenSearch 3.0: busca vetorial otimizada para a era da IA

• A OpenSearch Software Foundation anunciou a versão oficial do OpenSearch 3.0, informando um ganho de desempenho de 9,5 vezes em comparação com o OpenSearch 1.3
• Melhorias no desempenho de processamento de grandes volumes de dados vetoriais exigido por busca com IA, sistemas de recomendação e RAG

Inovação no mecanismo vetorial: desempenho e eficiência de custo ao mesmo tempo

• Aceleração por GPU (baseada em NVIDIA cuVS): tempo de construção de índice reduzido em até 9,3 vezes, com suporte a cargas de trabalho de alto desempenho
• Suporte ao Model Context Protocol (MCP): permite criar soluções de busca flexíveis por meio da integração com agentes de IA
• Recurso Derived Source: reduz o uso de armazenamento em 1/3 ao eliminar dados vetoriais duplicados

Recursos de gerenciamento de dados: mais flexibilidade e escalabilidade

• Suporte a gRPC: acelera a transferência de dados entre nós e entre cliente e servidor (experimental)
• Coleta de dados baseada em pull: adota uma estrutura em que o OpenSearch busca os dados diretamente de sistemas externos de streaming como Kafka e Kinesis
• Separação entre Reader e Writer: separa busca e indexação para garantir estabilidade e desempenho em cada tarefa
• Integração com Apache Calcite: oferece um construtor de consultas intuitivo em SQL/PPL
• Detecção do tipo de índice: identifica automaticamente índices de log e fornece opções adequadas de análise

Melhorias na infraestrutura de busca e no núcleo da plataforma

• Upgrade para Lucene 10: melhora o desempenho de tarefas paralelas e aprimora os recursos de busca
• Java 21 como runtime mínimo suportado: permite aproveitar recursos modernos da linguagem e ganhos de desempenho
• Adoção do sistema de módulos do Java: transforma a estrutura monolítica em uma base orientada a bibliotecas, melhorando a manutenção

Inovação sustentável centrada na comunidade aberta

• O OpenSearch é uma plataforma open source de busca baseada em uma comunidade independente sob a Linux Foundation
• Participação de grandes empresas como AWS, SAP e Uber, além de milhares de contribuidores
• Destaca escalabilidade para a era dos bancos de dados vetoriais e uma governança transparente, com foco em um ecossistema aberto à participação de qualquer pessoa
• Mais detalhes sobre o lançamento podem ser vistos no blog oficial e nas notas de versão

[kaydash]

Como o Elasticsearch é AGPL, fico receoso de usar, então continuo usando só o OpenSearch on-premises.

[GN⁺]

Opiniões no Hacker News

• Acabei de conhecer o OpenSearch, um projeto que foi bifurcado em 2021 após a mudança de licença do Elasticsearch; fiquei curioso para saber se ele ainda pode ser usado como substituto do Elasticsearch e como se comparam em desempenho e funcionalidades.

  • Mantenho um cliente em Kotlin para Elasticsearch e OpenSearch (kt-search).

    • Na maioria dos recursos usados com frequência, a API ainda é compatível.

    • Recursos adicionados após o fork, como busca vetorial, são exceções.

    • Algumas funcionalidades, como search_after, funcionam de forma diferente entre os dois, e o cliente compensa isso.

    • Ambos têm suporte a consultas SQL, mas implementam isso de maneiras diferentes.

    • Em termos de funcionalidades, a Elastic ainda está à frente, especialmente porque o Kibana tem mais recursos do que o fork da Amazon.

    • Em agregações, a Elastic também focou bastante em otimizações e melhorias nos últimos anos.

    • O desempenho depende do caso de uso; ambos os produtos são baseados no Lucene (biblioteca open source de busca).

    • O Elastic Cloud é um pouco melhor do que o OpenSearch na AWS.

    • Ao fazer hospedagem própria e ajuste fino, os dois ficam muito parecidos.

    • Tanto o Elastic 9.0 quanto o OpenSearch 3.0 usam versões novas do Lucene, e o cliente oferece suporte a ambos.

    • Entre clientes de consultoria, muitos passaram a preferir o OpenSearch por causa da licença open source e do suporte da AWS.

    • Para migrar de um Elasticsearch legado para OpenSearch, é preciso reindexar todos os dados, e talvez também trocar bibliotecas; isso é bem trabalhoso, e foi por isso que criei o kt-search.

    • Temos muitos bancos de dados antigos do Elasticsearch 2.3, então subimos o OpenSearch em paralelo para cada banco e fizemos a cópia em lote dos dados ao iniciar o serviço; até agora, estamos em geral satisfeitos com o OpenSearch.

    • Obrigado pela explicação detalhada, foi muito útil.

  • Uma limitação recente do OpenSearch que me incomodou foi a ausência do recurso enrich processors (link para a documentação fornecido).

    • Se você usa apenas os recursos padrão de ingestão e busca de documentos, a compatibilidade em geral se mantém.
    • Recursos avançados que eram oferecidos na versão paga muitas vezes não são compatíveis ou estão ausentes.

  • O Elasticsearch evoluiu para a versão 9.0 ou superior e tem 27 mil commits a mais que o OpenSearch.

    • Nesse ponto, já é difícil chamá-lo de drop-in replacement.
    • Não sei quantos desses commits são de funcionalidades centrais, mas dá para ver o quanto os dois projetos já se distanciaram.

  • Desde setembro de 2024, o Elasticsearch voltou a usar uma licença totalmente open source (AGPLv3).

    • Comentário em tom de quem lembra de já ter sido enganado antes sobre isso.

    • Ainda assim, o Elastic Search continua sendo open core; funcionalidades "enterprise" nunca serão incluídas na versão open source, enquanto o OpenSearch não tem essa limitação.

  • O OpenSearch não é um substituto "completo", mas é quase compatível; a versão 1.x é compatível com o Elasticsearch 7.10.

  • No mesmo hardware, o OpenSearch é um pouco mais lento; se você precisa de UI, é bom tomar cuidado, porque o fork do Kibana é lento e cheio de bugs.

    • Na prática, a situação é um pouco mais complexa; ambos os produtos têm fluxos de trabalho em que se destacam.
    • A empresa fez um benchmark abrangente dos dois produtos; se tiver curiosidade sobre os resultados, vale ver a postagem no blog mencionada.

  • O nome OpenSearch originalmente veio de um serviço de agregação de resultados de busca pessoal desenvolvido pela A9, subsidiária da Amazon.

    • O mesmo nome pode ter vários significados.

• Lamento pelo projeto OpenSearch.

  • Foi um projeto reativo criado junto com a AWS em resposta à mudança de licença do Elasticsearch.

  • A comunidade parece um jogo multiplayer abandonado, sem a energia que é essencial para um projeto open source.

  • Nunca ouvi falar de empresas ou clientes corporativos substituindo o Elastic Search por ele; ainda não foi suficientemente validado e não inspira confiança para compromissos de longo prazo.

  • Cada plataforma SIEM está criando sua própria plataforma de busca.

  • A Elastic também lançou sua plataforma SIEM (Elastic Security).

  • Mesmo com a Elastic dizendo de novo que é open source, a diretoria não vai querer bancar o custo de migrar para um fork ainda não comprovado, e o propósito do projeto fica incerto.

    • Não quero voltar a usar a Elastic; já usei diretamente Lucene–Solr–uma versão estendida customizada, e o Elastic Search só era necessário quando eu usava AWS. Mesmo assim, depois da migração para o OpenSearch, estou usando sem grandes problemas.

    • Acho que a Elastic sofreu impacto econômico por muito tempo por causa do OpenSearch e da AWS.

• Alguém aqui usa os recursos de knn e vetores do OpenSearch? Queria saber como isso funciona em operação real, em grande escala.

  • Não conheço a implementação do OpenSearch, mas compartilho minha experiência de ter implementado diretamente uma estrutura HNSW para conjuntos vetoriais no Redis.

    • Quando o HNSW é bem implementado, funciona bem mesmo em escala considerável.
    • A velocidade de inserção em um único HNSW fica na casa de milhares por segundo; a leitura é muito mais rápida (em ambiente multicore).
    • A inserção inicial em massa pode ser muito lenta, mas dá para paralelizar.
    • O ponto fraco do HNSW é o uso elevado de memória; ao armazenar em disco, surgem acessos aleatórios.
    • Para vetores de alta dimensionalidade, como 1024 dimensões, quantization é essencial.

  • Quando a dimensionalidade dos embeddings vetoriais é alta, recomendo busca aproximada por vizinhos mais próximos, como HNSW, em vez de knn puro.

    • Eu mesmo uso o OpenSearch para busca híbrida baseada em texto, embeddings multimodais e metadados.
    • Ainda não está em operação totalmente em larga escala, mas por ser OpenSearch, tenho expectativas positivas quanto à escalabilidade.

  • Na minha experiência, uso isso o tempo todo; o desempenho depende do modelo de embeddings, e o ajuste fino do índice é importante.

    • Ao usar Lucene HNSW, ele consome bastante Java Heap RAM.
    • Ao usar plugins FAISS ou nmslib, também é preciso prestar atenção na RAM do JNI.
    • Não é fácil escalar ANN em grande porte, com mais de 100 milhões de vetores; isso exige suporte focado da equipe.

  • Existe um caveat já bem conhecido: o desempenho de busca em milhões de documentos é bom, mas na busca KNN é preciso manter todo o grafo de embeddings na RAM, então gerenciar memória é o ponto-chave.

    • A qualidade do resultado, no fim das contas, depende da qualidade dos embeddings.

• Eu queria uma ferramenta simples de ingestão de logs que fizesse parsing de syslog e permitisse criar gráficos e pesquisar campos, mas configurar OpenSearch ou ELK foi complicado demais.

  • Fiquei surpreso como até essa configuração básica é inesperadamente difícil tanto no Elastic quanto no OpenSearch.

    • Tudo gira em torno de configuração, então você precisa montar suas próprias receitas.

    • Existem ferramentas úteis, como o OpenTelemetry, mas ainda assim continua incômodo.

    • Em ambos os casos, se você seguir só as diretrizes oficiais, dá para começar a usar rapidamente; o problema aparece quando você precisa de lógica customizada.

    • Para requisitos simples, dá até para fazer sem o Logstash.

    • Elastic e OpenSearch não são ideais para métricas de aplicação; nesse caso, o recomendado é Prometheus e Grafana.

    • Se você investir no ecossistema Elastic (beats, logstash etc.), dá para montar vários templates de índice e pipelines.

    • Hoje, graças ao dynamic field mapping, ficou muito fácil enviar e ler dados no Elasticsearch.

    • O maior desafio é manter o desempenho.

  • Já tentou o Graylog? No meu trabalho, usamos e funciona bastante bem.

[davidayo]

O OpenSearch surgiu em 2021 após a mudança de licença do Elasticsearch, com o objetivo de ser um substituto compatível. Embora seja amplamente compatível, especialmente a versão 1.x com o Elasticsearch 7.10, não é uma solução totalmente plug-and-play. O Elasticsearch evoluiu mais e conta com mais recursos e otimizações, especialmente no Kibana e nas agregações. O desempenho depende da aplicação, já que ambos são construídos sobre o Lucene. Alguns usuários consideram o OpenSearch mais lento e os forks do Kibana com bugs. Apesar de o Elasticsearch ter voltado ao código aberto (AGPLv3) em setembro de 2024, alguns preferem o OpenSearch por sua natureza verdadeiramente open source e pelo suporte da AWS. Embora a busca vetorial seja um diferencial importante, implementações em larga escala exigem um gerenciamento cuidadoso de RAM. No fim, a escolha depende das necessidades específicas, e ambos têm pontos fortes e fracos. Estou trabalhando no OpenSearch com a Davidayo https://www.davidayo.com, uma poderosa ferramenta de IA, "AskPromptAI" https://askpromptai.com.