Lanzamiento de OpenSearch 3.0: gran mejora en rendimiento de base de datos vectorial e infraestructura de búsqueda impulsada por IA

 (opensearch.org)
12 puntos por GN⁺ 2025-05-09 | 3 comentarios | Compartir por WhatsApp
  • Se lanzó oficialmente OpenSearch 3.0, con un rendimiento 9.5 veces superior al de OpenSearch 1.3
  • Se agregaron múltiples funciones innovadoras para la búsqueda vectorial, como aceleración por GPU, integración con agentes de IA y optimización de almacenamiento
  • Con gRPC, streaming con Kafka e identificación automática de índices, se refuerzan la eficiencia y la flexibilidad del procesamiento de datos
  • En la infraestructura de búsqueda, se aplicaron Lucene 10, Java 21 y una arquitectura modular para mejorar la escalabilidad futura y la mantenibilidad
  • Se consolida como una plataforma de búsqueda de próxima generación basada en una comunidad open source que responde al aumento de la demanda de búsquedas basadas en IA y RAG

Lanzamiento oficial de OpenSearch 3.0: búsqueda vectorial optimizada para la era de la IA

  • OpenSearch Software Foundation presentó la versión oficial de OpenSearch 3.0 y anunció una mejora de rendimiento de 9.5 veces frente a OpenSearch 1.3
  • Se mejoró el rendimiento para el procesamiento de datos vectoriales a gran escala requerido en búsqueda con IA, sistemas de recomendación y RAG

Innovación en el motor vectorial: rendimiento y eficiencia de costos al mismo tiempo

  • Aceleración por GPU (basada en NVIDIA cuVS): hasta 9.3 veces menos tiempo de construcción de índices y capacidad para manejar cargas de trabajo de alto rendimiento
  • Compatibilidad con Model Context Protocol (MCP): permite crear soluciones de búsqueda flexibles mediante integración con agentes de IA
  • Función Derived Source: reduce en un tercio el uso de almacenamiento al eliminar datos vectoriales duplicados

Funciones de gestión de datos: más flexibilidad y escalabilidad

  • Compatibilidad con gRPC: acelera la transferencia de datos entre nodos y entre cliente y servidor (experimental)
  • Ingesta de datos basada en Pull: aplica una estructura en la que OpenSearch obtiene directamente los datos desde sistemas externos de streaming como Kafka y Kinesis
  • Separación Reader-Writer: separa la búsqueda y la indexación para asegurar la estabilidad y el rendimiento de cada tarea
  • Integración con Apache Calcite: ofrece una función de constructor de consultas intuitivo en SQL/PPL
  • Detección de tipo de índice: identifica automáticamente los índices de logs y ofrece opciones de análisis adecuadas

Mejoras en la infraestructura de búsqueda y el núcleo de la plataforma

  • Actualización a Lucene 10: mejora el rendimiento de trabajos en paralelo y amplía las capacidades de búsqueda
  • Java 21 como runtime mínimo compatible: permite aprovechar funciones y rendimiento del lenguaje más recientes
  • Adopción del sistema de módulos de Java: transforma la estructura monolítica en una basada en bibliotecas para mejorar la mantenibilidad

Innovación sostenible centrada en la comunidad abierta

  • OpenSearch es una plataforma de búsqueda open source basada en una comunidad independiente bajo la Linux Foundation
  • Participan grandes empresas como AWS, SAP y Uber, junto con miles de colaboradores
  • Enfatiza la escalabilidad para la era de las bases de datos vectoriales y una gobernanza transparente, con una visión de ecosistema abierto a la participación de cualquiera
  • Más información sobre el lanzamiento está disponible en el blog oficial y las notas de la versión

Lecturas relacionadas

3 comentarios

 
kaydash 2025-05-12

Como Elasticsearch está bajo AGPL, me da cosa usarlo, así que sigo usando solo OpenSearch on-premise.
 
GN⁺ 2025-05-09
Opiniones de Hacker News

  • Recién me enteré de OpenSearch; es un proyecto que se bifurcó en 2021 después del cambio de licencia de Elasticsearch. Tengo curiosidad por saber si todavía puede usarse como sustituto de Elasticsearch y cómo se comparan en rendimiento y funcionalidades.

    • Mantengo un cliente en Kotlin para Elasticsearch y OpenSearch (kt-search)

      • En la mayoría de las funciones de uso frecuente, la API sigue siendo compatible

      • Las funciones agregadas después del fork, como la búsqueda vectorial, son una excepción

      • Algunas funciones como search_after se comportan distinto entre ambos, y el cliente compensa eso

      • Ambos productos tienen consultas SQL, pero las implementan de forma diferente

      • En funcionalidades, Elastic todavía va por delante, especialmente porque Kibana tiene más capacidades que el fork de Amazon

      • También en agregaciones, Elastic se ha enfocado mucho en optimizaciones y mejoras en los últimos años

      • El rendimiento depende del caso de uso; ambos productos están basados en Lucene, una biblioteca de búsqueda de código abierto

      • Elastic Cloud es un poco mejor que OpenSearch en AWS

      • Si se autohospedan y afinan bien, ambos productos terminan siendo muy parecidos

      • Elastic 9.0 y OpenSearch 3.0 usan versiones nuevas de Lucene, y el cliente soporta ambas

      • Entre clientes de consultoría, cada vez más prefieren OpenSearch por la licencia open source y el soporte de AWS

      • Para migrar de un Elasticsearch legacy a OpenSearch, hay que reindexar todos los datos y quizá también cambiar bibliotecas; es bastante engorroso, y por eso terminé creando kt-search

      • Tenemos muchas bases de datos antiguas de Elasticsearch 2.3, así que levantamos OpenSearch en paralelo para cada base y copiamos los datos en lote al iniciar el servicio; hasta ahora estamos bastante satisfechos con OpenSearch

      • Gracias por la explicación tan detallada; fue muy útil

    • Algo que me decepcionó recientemente en OpenSearch es la ausencia de la funcionalidad de enrich processors (se comparte enlace a la documentación)

      • Si solo usas funciones estándar de ingesta y búsqueda de documentos, casi todo es compatible
      • Las funciones avanzadas que estaban en la versión de pago a menudo no son compatibles o directamente faltan

    • Elasticsearch ya avanzó hasta la versión 9.0 o superior y tiene 27,000 commits más que OpenSearch

      • A estas alturas ya es difícil verlo como un drop-in replacement
      • No sé cuántos de esos cambios son funciones centrales, pero sí muestra cuánto se han diferenciado ambos proyectos

    • Desde septiembre de 2024, Elasticsearch volvió a una licencia totalmente open source (AGPLv3)

      • Comentario recordando, con tono escéptico, que antes ya los engañaron con esto

      • Elastic Search sigue siendo open core; las funciones "enterprise" nunca van a estar incluidas en la versión open source, mientras que OpenSearch no tiene esa limitación

    • OpenSearch no es un reemplazo "completo", pero sí es casi compatible; la serie 1.x es compatible con Elasticsearch 7.10

    • En el mismo hardware, OpenSearch es algo más lento; si necesitas UI, conviene tener cuidado, porque el fork de Kibana es lento y tiene muchos bugs

      • En realidad es un poco más complejo; ambos productos tienen flujos de trabajo en los que destacan
      • En la empresa hicimos benchmarks amplios de ambos productos; si te interesa el resultado, recomiendan ver esa publicación del blog

    • El nombre OpenSearch originalmente viene de un servicio de agregación de resultados de búsqueda personal desarrollado por A9, una subsidiaria de Amazon

      • Se menciona que el mismo nombre puede tener varios significados

  • Expresan cierta lástima por el proyecto OpenSearch

    • Fue un proyecto reactivo creado junto con AWS como respuesta al cambio de licencia de Elasticsearch

    • La comunidad se siente como un juego multijugador inactivo, sin la vitalidad indispensable para un proyecto open source

    • Nunca han oído de una empresa o cliente enterprise que realmente haya reemplazado Elastic Search con OpenSearch; todavía se percibe como no probado y sin mucha confianza en su compromiso de largo plazo

    • Cada plataforma SIEM está terminando por construir su propia plataforma de búsqueda

    • Elastic también lanzó su plataforma SIEM (Elastic Security)

    • Aunque Elastic volvió a declararse open source, la gerencia no va a gastar en migrar a un fork no probado, así que el propósito del proyecto queda difuso

      • No quiero volver a usar Elastic; he usado directamente Lucene, luego Solr, luego extensiones personalizadas, y Elastic Search solo me hacía falta cuando usaba AWS; aun así, después de migrar a OpenSearch, lo he estado usando sin problemas

      • Creo que Elastic ha sido golpeado económicamente durante mucho tiempo por OpenSearch y AWS

  • Preguntan si alguien usa las funciones knn y vectoriales de OpenSearch, y cómo se comportan en operaciones reales a gran escala

    • No conozco la implementación de OpenSearch, pero comparto que implementé yo mismo un conjunto vectorial para Redis con estructura HNSW

      • Si HNSW está bien implementado, funciona bastante bien incluso a gran escala
      • La velocidad de inserción en un solo HNSW está en el orden de miles por segundo, y la lectura es mucho más rápida, sobre todo en entornos multinúcleo
      • La inserción masiva inicial puede ser muy lenta, aunque se puede paralelizar
      • La parte ineficiente de HNSW es el uso elevado de memoria; si se guarda en disco, aparecen búsquedas aleatorias
      • Para vectores de alta dimensionalidad, como 1024 dimensiones, la quantization es indispensable

    • Cuando la dimensionalidad de los embeddings es alta, recomiendan más una búsqueda aproximada de vecinos más cercanos como HNSW que knn puro

      • Yo lo uso en OpenSearch para búsqueda híbrida basada en embeddings de texto, multimodales y metadatos
      • Aún no estamos en operación totalmente a gran escala, pero por ser OpenSearch tengo expectativas positivas sobre su escalabilidad

    • En mi experiencia, se usa todo el tiempo; el rendimiento depende del modelo de embeddings y la afinación del índice es clave

      • Si usas Lucene HNSW, consume mucha Java Heap RAM
      • Si usas plugins de FAISS o nmslib, también hay que vigilar la RAM de JNI
      • Escalar fácilmente ANN a más de 100 millones de vectores no es sencillo; requiere apoyo enfocado del equipo

    • Hay una salvedad bien conocida: el rendimiento de búsqueda en millones de documentos es bueno, pero para búsquedas KNN hay que subir todo el grafo de embeddings a RAM, así que la gestión de memoria es la clave

      • La calidad de los resultados al final depende de la calidad de los embeddings

  • Quiero una herramienta simple de ingesta de logs que haga parsing de syslog y permita graficar/buscar campos, pero la configuración de OpenSearch o ELK me resultó demasiado complicada

    • Me sorprendió que tanto Elastic como OpenSearch sean inesperadamente difíciles incluso para este tipo de configuración básica

      • Todo está centrado en configuración, así que hay que armar uno mismo las recetas

      • Hay herramientas útiles como OpenTelemetry, pero aun así sigue siendo incómodo

      • Si solo sigues las guías oficiales de cualquiera de las dos herramientas, puedes ponerlas a funcionar rápido; el problema aparece cuando necesitas lógica personalizada

      • Para requisitos simples, incluso se puede prescindir de Logstash

      • Elastic y OpenSearch no son ideales para métricas de aplicaciones; para eso recomiendan prometheus y grafana

      • Si inviertes en el ecosistema de Elastic (beats, logstash, etc.), puedes configurar varias plantillas de índice y pipelines

      • Hoy, gracias al dynamic field mapping, meter y sacar datos de Elasticsearch se ha vuelto muy fácil

      • La preocupación mayor es mantener el rendimiento

    • Preguntan si ya probaste Graylog; en su trabajo lo usan bastante bien
 
davidayo 2025-05-11

OpenSearch surgió en 2021 tras el cambio de licencia de Elasticsearch, con el objetivo de ser un reemplazo compatible. Aunque es en gran medida compatible, especialmente la versión 1.x con Elasticsearch 7.10, no es una solución completamente plug-and-play. Elasticsearch ha evolucionado más y ofrece más funciones y optimizaciones, en particular en Kibana y las agregaciones. El rendimiento depende de la aplicación, ya que ambos están construidos sobre Lucene. Algunos usuarios consideran que OpenSearch es más lento y que sus forks de Kibana tienen errores. A pesar de que Elasticsearch volvió al código abierto (AGPLv3) en septiembre de 2024, algunos prefieren OpenSearch por su naturaleza verdaderamente de código abierto y el soporte de AWS. Aunque la búsqueda vectorial es un diferenciador clave, las implementaciones a gran escala requieren una gestión cuidadosa de la RAM. En última instancia, la elección depende de las necesidades específicas, y ambos tienen fortalezas y debilidades. Estoy trabajando en OpenSearch con Davidayo https://www.davidayo.com, una potente herramienta de IA, "AskPromptAI" https://askpromptai.com.