¡Realmente me encantaría esta función también!

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

Realmente necesito esta característica

: +1:

Mientras esperaba que esta función se terminara y se lanzara oficialmente, empaqueté la solicitud de extracción # 2231 como un complemento: yakaz / elasticsearch-action-updatebyquery .
Divertirse.

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

: +1:: rezar:

+1

+1

¿Hay alguna forma de pasar la puntuación de la consulta como parámetro al script de actualización? Necesito actualizar las entradas con puntuaciones actualizadas en función de los campos de sus hijos.

+1

+1

+1

@ scottc52 ¿

+1

@gboivin Nop . Estoy haciendo una consulta has_child y enviando una solicitud de actualización separada, pero es lenta.

esperando esta función también ...

+1

+1

+1

+1

+1

+1

+1

Solo escribí un pequeño guión para ayudar a esperar algo ... más "listo para producción" ;-)

https://github.com/YannBrrd/esNodeUpdater

No dude en comentar / actualizar ...

+1

¿Existe un estado oficial de esta función por parte del equipo de desarrollo? No veo ninguna entrada de ellos. ¿Hay planes para agregar esta función al núcleo o es preferible que los usuarios usen un complemento como el mencionado anteriormente ?

Planeamos volver a esto, la razón principal por la que lo dejamos en espera es que necesitamos tener una forma de detener la actualización existente mediante consultas, ya que pueden ejecutarse por error en una gran cantidad de datos, causando problemas. .

+1. Gracias por la actualización y por trabajar en esto.

+1

+1

+1

+1

+1, suena útil

+1

+1

+1

+1

+1

+1

+1

+1

+2

+1

+10

+1

+1

+1

¿Alguna vez ha pensado en implementar con una doble llamada HTTP esta función? Pienso en warmers que dan la posibilidad de almacenar la consulta y luego ejecutar la consulta (no es realmente lo mismo pero me hace pensar).

@kimchy dices que piensas en una manera de detener la actualización si se lanzó por error en una gran cantidad de datos. Si lo detiene, tal vez los datos indexados estén en un estado no válido (¿tal vez sea posible revertir ...?). Quizás un mejor enfoque sea evitar errores.

Si necesita dos llamadas HTTP antes de activar la actualización masiva real (1 para preparar y 1 para activarla realmente con un ID de transición entre) y luego un controlador de estado de actualización (como el controlador de importación de datos en SolR) para saber cuándo se realiza realmente la consulta.

No estoy seguro de ser muy claro, pero creo que puede ser una solución para evitar llamadas erróneas ...

+1

+1

También me gustaría votar a favor de esto.

+1

@kimchy : Perfomance no puede ser la pregunta: actualmente estoy ejecutando miles de consultas para buscar datos (por ejemplo, búsqueda de direcciones de índice OSM para ubicaciones GPS; las búsquedas son rápidas, ¡hey obtuve ElasticSearch!) y actualizo cada documento en otro índice (por ejemplo, para agregar una dirección de texto sin cifrar). Mis actualizaciones agregan nuevos campos. Una actualización masiva dentro de ES debe ser más eficiente que 10.000 consultas de búsqueda + 10.000 solicitudes de actualización (también usando actualizaciones masivas ...). Desde el punto de vista de la codificación y el tiempo de ejecución, sería más eficiente, por ejemplo, el archivo de actualización masiva obtiene 20.000 líneas y solo podría tener 2 con la nueva función: todos los datos se mueven a través de la red y hacen que ES esté ocupado leyendo archivos de actualización masiva ...

Tal vez acepte agregar límites para la operación de actualización, por ejemplo, _update / _query = some_conditions & size = 1000 de esa manera se evita actualizar un millón de documentos, y nosotros, como desarrolladores, podemos decidir si ejecutamos 1000 * 1000 actualizaciones para actualizar un millón de registros ... debería devolver el número de documentos actualizados para dar cierto control si se requiere otra llamada de actualización.

+1

Para mi escenario (enriquecer los registros después de las búsquedas en otros índices), podría hacerlo de otra manera: inserte los datos primero en mongoDb, realice búsquedas en ElasticSearch actualice los registros en Mongo, use mongo river para obtener los resultados finales en ElasticSearch para mostrarlos en la GUI (build encima de ES). ¿Alguien ha experimentado con tales escenarios? Esperaba poder ir de la única manera ES ... hasta ahora, rechacé el uso de una base de datos en mi proyecto.

Hola,

simplemente puede usar Couchbase + Elasticsearch para esto, ya que Couchbase
ofrece una interfaz con Elasticsearch

Cordialidad,
Yann Barraud

2014-02-03 seti123 [email protected] :

Para mi escenario (enriquecer registros después de búsquedas en otros índices) podría
hazlo de otra manera: inserta datos primero en mongoDb, haz búsquedas en
ElasticSearch actualiza los registros en Mongo, usa el río mongo para obtener los resultados finales
en ElasticSearch para mostrarlo en GUI (construido sobre ES). Tiene alguien
experimentado con tales escenarios? Esperaba poder seguir el único camino de ES ... hasta que
ahora, rechacé el uso de una base de datos en mi proyecto.

Responda a este correo electrónico directamente o véalo en Gi
.

+1

+100

+1

+1

¿Existe una alternativa en ElasticSearch, por ejemplo, activar un script que realiza una acción cuando se insertan o actualizan nuevos datos? Algún tipo de antes de Index-Trigger podría ayudarme a eliminar la cadena de preprocesamiento (ahora hicimos Message Ques con REDIS y la cadena de procesamiento 0MQ antes de insertar Datos en ES; todo cuesta ancho de banda de la red para mezclar los datos para el preprocesamiento paralelo ... )

Me gustaría ver
http: // localhost : 9200 / index / type / _preprocessBeforeIndex? script = myDataAnalysisScript
http: // localhost : 9200 / index / type / _preprocessBeforeUpdate? script = myDataAnalysisScript
El script debe poder agregar nuevos campos al registro actual antes de que ES lo almacene / indexe (para evitar la acción de doble índice después de los cambios). Como trabajamos mucho con node.js, los scripts deberían funcionar en el idioma requerido (en nuestro caso JavaScript).

Aún mejor si pudiéramos definir el script en el MAPEO por tipo de datos en lugar de los índices generados.
¿Algún complemento disponible que pueda activar dichos scripts? ¿Alguna documentación sobre el uso de la API de ES en Scripts?

+1

+1

+1

+1

+1

+1

+1

+1

+1

Esperando esta función ... (+1)

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

¿Está esta característica en desarrollo?
Esto resolvería tantos problemas que son casi imposibles de manejar de manera confiable a nivel de aplicación en este momento.

+1

+1

+1

Solo para recordarles que desde mediados de febrero de 2013 he empaquetado, y mantenido desde entonces, la "solicitud de extracción oficial" # 2231 a través de la rama de @martijnvg como complemento: yakaz / elasticsearch-action-updatebyquery .

+1

+1

+1

+1

+1
¿Cómo es posible que esta función desde febrero de 2013 aún no se haya fusionado con el maestro?

+1
Lo mismo ocurre con el comentario de

+1

Recibimos este problema hace varios meses (vea mis publicaciones como @ seti123 enero / febrero) y me gustaría compartir nuestros resultados; después de renunciar a DB + ES River (demasiadas preocupaciones sobre las dependencias de la versión) evaluamos nuestro caso de uso con éxito con Crate Data (que usa ES como biblioteca y agrega una interfaz SQL para mapeo y consulta que incluye "actualización por consulta" https://crate.io/docs/stable/sql/dml.html#updating-data).
Un buen punto de partida para leer sobre similitudes y diferencias: https://crate.io/blog/crate_data_elasticsearch

Cerrado a favor de # 2230

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

¿Se actualizará mediante el soporte de consultas setPostFilter?
edición # 12295

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

¿Alguien puede revisar esto y dar su opinión?
https://discuss.elastic.co/t/updatebyqueryresponse-throwing-timeout/29176

La actualización por consulta falla mientras actualiza más de 20 millones de registros.

@ Praveen82 está utilizando un complemento de terceros. Este no es el lugar adecuado para solicitar soporte, debería publicarlo como un problema en el repositorio de ese complemento.

https://github.com/elastic/elasticsearch/pull/15125 está implementando una sintaxis que se verá un poco como

curl -XPOST localhost:9200/index/type/_update_by_query -d '{
    "query" : { "term" : { "counter" : 0 } },
    "script" : {
      "inline": "ctx._source.counter += count",
      "params" : {
          "count" : 4
      }
  }
}'

La razón por la que esto se estancó durante tanto tiempo es por esos tiempos de espera: hasta ahora ha habido una manera de lanzar trabajos de larga duración en Elasticsearch e informar sobre su estado y cosas. Con la api de administración de tareas (# 15347) eminente, tomé la antorcha en las cosas de estilo "reindexar" y "actualizar por consulta" y las comencé de nuevo con la intención de integrarlas con la administración de tareas lo antes posible.

De todos modos, # 15125 y cualquier PR de seguimiento son el lugar para buscar esta característica.

+1

+1

+1

+1

+1

La actualización por consulta está disponible en 2.3.0 y 5.0.0-alpha-1. Los doctores están aquí .

¿La actualización por consulta en 2.3. + O 5. + es compatible con el complemento javascript?

¿La actualización por consulta en 2.3. + O 5. + es compatible con el complemento javascript?

Si realmente lo quieres, seguro. En 2.3+ probamos actualización por consulta contra groovy y en 5. + probamos contra indoloro. Solíamos probar contra groovy y también funcionó allí. Espero que javascript funcione bien.

El soporte de JS sería bastante hábil.

El soporte de JS sería bastante hábil.

Como dije, existe, solo debes instalar el complemento.

El problema con todos estos lenguajes es que su implementación en la JVM no está correctamente orientada para la incrustación. Por eso no lo incluimos por defecto.

De todos modos, si quieres hablar más al respecto, creo que discutir.elastic.co es un lugar más apropiado para ello.