J'adorerais vraiment cette fonctionnalité aussi!

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

j'ai vraiment besoin de cette fonctionnalité

:+1:

En attendant que cette fonctionnalité soit officiellement terminée et publiée, j'ai empaqueté la pull request #2231 en tant que plugin : yakaz/elasticsearch-action-updatebyquery .
S'amuser.

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

:+1: :prie:

+1

+1

Existe-t-il un moyen de transmettre le score de la requête en paramètre au script de mise à jour ? J'ai besoin de mettre à jour les entrées avec les scores mis à jour en fonction des champs de ses enfants.

+1

+1

+1

@scottc52 Avez-vous réussi à le faire? Je cherche aussi un moyen de le faire.

+1

@gboivin Non. Je fais une requête has_child et j'envoie une demande de mise à jour séparée, mais c'est lent.

en attendant cette fonctionnalité aussi ..

+1

+1

+1

+1

+1

+1

+1

Je viens d'écrire un petit script pour aider à attendre quelque chose... plus "prêt pour la production" ;-)

https://github.com/YannBrrd/esNodeUpdater

N'hésitez pas à commenter/mettre à jour...

+1

Y a-t-il un statut officiel sur cette fonctionnalité de la part de l'équipe de développement ? Je ne vois aucune contribution de leur part. Est-il prévu d'ajouter cette fonctionnalité au noyau ou préférez-vous que les utilisateurs utilisent un plugin comme celui répertorié ci-dessus ?

Nous prévoyons de revenir sur celui-ci, la principale raison pour laquelle nous avons mis cela en attente est que nous devons avoir un moyen d'arrêter la mise à jour existante par les requêtes, car elles peuvent être exécutées par erreur sur une grande quantité de données, provoquant des problèmes. .

+1. Merci pour la mise à jour et le travail dessus.

+1

+1

+1

+1

+1, semble utile

+1

+1

+1

+1

+1

+1

+1

+1

+2

+1

+10

+1

+1

+1

Avez-vous déjà pensé à implémenter avec un double appel HTTP cette fonctionnalité. Je pense aux réchauffeurs qui donnent la possibilité de stocker la requête puis d'exécuter la requête (c'est pas vraiment la même chose mais ça me fait réfléchir).

@kimchy vous dites que vous pensez à un moyen d'arrêter la mise à jour si elle a été lancée par erreur sur une grande quantité de données. Si vous l'arrêtez, les données indexées seront peut-être dans un état invalide (il est peut-être possible de revenir en arrière...?). Peut-être qu'une meilleure approche sera d'éviter les erreurs.

Si vous avez besoin de deux appels HTTP avant de déclencher la mise à jour en masse réelle (1 pour préparer et 1 pour la déclencher réellement avec un identifiant de transaction entre), puis un gestionnaire de statut de mise à jour (comme le dataimporthandler dans SolR) pour savoir quand la requête est vraiment terminée.

Je ne suis pas sûr d'être vraiment clair mais je pense que cela peut être une solution pour éviter les erreurs d'appels...

+1

+1

J'aimerais également voter pour cela.

+1

@kimchy : Les performances ne peuvent pas être la question : actuellement, j'exécute des milliers de requêtes pour rechercher des données (par exemple, recherche d'adresses d'index OSM pour les emplacements GPS - les recherches sont rapides, hé, j'ai ElasticSearch !) et mets à jour chaque document dans un autre index (par exemple pour ajouter une adresse en texte clair). Mes mises à jour ajoutent de nouveaux champs. Une mise à jour en masse dans ES doit être plus efficace que 10.000 requêtes de recherche + 10.000 requêtes de mise à jour (utilisant également des mises à jour en masse...). Du point de vue du codage et de l'exécution, ce serait plus efficace, par exemple, le fichier de mise à jour en masse a 20 000 lignes et ne peut en avoir que 2 avec la nouvelle fonctionnalité - toutes les données sont déplacées sur le réseau et obligent ES à lire les fichiers de mise à jour en masse ...

Peut-être que vous acceptez d'ajouter des limites à l'opération de mise à jour, par exemple _update/_query=some_conditions&size=1000 de cette manière, cela évite de mettre à jour un million de documents - et nous, en tant que développeur, pouvons décider si nous exécutons 1000*1000 mises à jour pour mettre à jour un million d'enregistrements... Il devrait renvoyer le nombre de documents mis à jour pour donner un certain contrôle si un autre appel de mise à jour est requis.

+1

Pour mon scénario (enrichir les enregistrements après les recherches dans d'autres indices), je pourrais procéder d'une autre manière : insérer d'abord les données dans mongoDb, effectuer des recherches dans ElasticSearch mettre à jour les enregistrements dans Mongo, utiliser mongo river pour obtenir les résultats finaux dans ElasticSearch pour les afficher dans l'interface graphique (construire au-dessus de ES). Quelqu'un a-t-il connu de tels scénarios? J'espérais pouvoir utiliser ES uniquement... jusqu'à présent, j'ai refusé d'utiliser une base de données dans mon projet.

Salut,

vous pouvez simplement utiliser Couchbase + Elasticsearch pour cela, comme Couchbase
propose une interface avec Elasticsearch

Cordialement,
Yann Barraud

03-02-2014 seti123 [email protected] :

Pour mon scénario (enrichir les enregistrements après des recherches dans d'autres indices), je pourrais
faites-le d'une autre manière : insérez d'abord les données dans mongoDb, effectuez des recherches dans
ElasticSearch met à jour les enregistrements dans Mongo, utilisez la rivière mongo pour obtenir les résultats finaux
dans ElasticSearch pour l'afficher dans l'interface graphique (construit sur ES). Quelqu'un a-t-il
expérimenté avec de tels scénarios? J'espérais que je pourrais aller ES seule façon ... jusqu'à ce que
maintenant, j'ai rejeté l'utilisation d'une base de données dans mon projet.

Répondez directement à cet e-mail ou consultez-le sur Gi tHubhttps://github.com/elasticsearch/elasticsearch/issues/1607#issuecomment -33917801
.

+1

+100

+1

+1

Existe-t-il une alternative dans ElasticSearch, par exemple déclencher un script qui effectue une action lorsque de nouvelles données sont insérées ou mises à jour ? Une sorte d'avant Index-Trigger pourrait m'aider à supprimer la chaîne de pré-traitement (nous avons maintenant fait Message Ques avec REDIS et la chaîne de traitement 0MQ avant d'insérer des données dans ES - tout cela coûte la bande passante du réseau pour mélanger les données pour un traitement parallèle ... )

Je voudrais voir
http://localhost :9200/index/type/_preprocessBeforeIndex?script=myDataAnalysisScript
http://localhost :9200/index/type/_preprocessBeforeUpdate?script=myDataAnalysisScript
Le script doit pouvoir ajouter de nouveaux champs à l'enregistrement en cours avant que ES ne le stocke/l'indexe (pour éviter une double action d'indexation après les modifications). Comme nous travaillons beaucoup avec node.js, les scripts devraient fonctionner dans le langage requis (dans notre cas JavaScript).

Encore mieux si nous pouvions définir le script dans le MAPPING par type de données plutôt que sur un indice généré.
Existe-t-il un plug-in capable de déclencher de tels scripts ? Une documentation sur l'utilisation de l'API ES dans les scripts ?

+1

+1

+1

+1

+1

+1

+1

+1

+1

En attente de cette fonctionnalité... (+1)

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

Cette fonctionnalité est-elle en cours de développement ?
Cela résoudrait tant de problèmes qui sont presque impossibles à gérer de manière fiable au niveau de l'application en ce moment.

+1

+1

+1

Juste pour vous rappeler que depuis la mi-février 2013, j'ai empaqueté, et maintenu depuis, la "demande de tirage officielle" #2231 via la branche de @martijnvg en tant que plugin : yakaz/elasticsearch-action-updatebyquery .

+1

+1

+1

+1

+1
Comment est-il possible que cette fonctionnalité depuis février 2013 ne soit toujours pas fusionnée à master ?

+1
Idem sur le commentaire de @KrzysztofWilczek . Pourquoi le PR a-t-il stagné au cours de la dernière année sans aucune mise à jour ? C'est de loin la question la plus commentée.

+1

Nous avons eu ce problème il y a plusieurs mois (voir mes messages comme @seti123 janvier/février) et j'aimerais partager nos résultats - après avoir abandonné DB+ES River (trop de soucis concernant les dépendances de version), nous avons évalué notre cas d'utilisation avec succès avec Crate Data (qui utilise ES comme bibliothèque et ajoute une interface SQL pour le mappage et la requête, y compris "mise à jour par requête" https://crate.io/docs/stable/sql/dml.html#updating-data ).
Un bon point de départ pour lire sur les similitudes et les différences : https://crate.io/blog/crate_data_elasticsearch

Fermé en faveur de #2230

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

mettra à jour par la prise en charge des requêtes setPostFilter ?
numéro n° 12295

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

quelqu'un peut-il examiner cela et donner son avis.
https://discuss.elastic.co/t/updatebyqueryresponse-throwing-timeout/29176

La mise à jour par requête échoue lors de la mise à jour de plus de 20 millions d'enregistrements.

@Praveen82, vous utilisez un plugin tiers. Ce n'est pas le bon endroit pour demander de l'aide, vous devriez publier cela en tant que problème sur le référentiel de ce plugin.

https://github.com/elastic/elasticsearch/pull/15125 implémente une syntaxe qui ressemblera un peu à

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

La raison pour laquelle cela a été bloqué pendant si longtemps est à cause de ces délais d'attente : jusqu'à présent, il existait un moyen de lancer un travail de longue durée dans Elasticsearch et de rendre compte de leur statut et de leurs éléments. Avec l'API de gestion des tâches (#15347) éminente, j'ai repris le flambeau des choses de style "réindexation" et "mise à jour par requête" et les ai recommencées avec l'intention de les intégrer à la gestion des tâches dès que possible.

Quoi qu'il en soit, #15125 et tout PR de suivi sont l'endroit idéal pour rechercher cette fonctionnalité.

+1

+1

+1

+1

+1

La mise à jour par requête est disponible dans les versions 2.3.0 et 5.0.0-alpha-1. Les docs sont ici .

La mise à jour par requête en 2.3.+ ou 5.+ prend-elle en charge le plugin javascript ?

La mise à jour par requête en 2.3.+ ou 5.+ prend-elle en charge le plugin javascript ?

Si vous le voulez vraiment, bien sûr. Dans 2.3+, nous testons la mise à jour par requête contre groovy et dans 5.+, nous testons contre indolore. Nous avions l'habitude de tester contre groovy et cela fonctionnait aussi là-bas. J'espère que javascript fonctionnera bien.

Le support JS serait plutôt simple.

Le support JS serait plutôt simple.

Comme je l'ai dit, il existe, il suffit d'installer le plugin.

Le problème avec tous ces langages est que leur implémentation sur la JVM n'est pas correctement orientée pour l'intégration. C'est pourquoi nous ne l'incluons pas par défaut.

Quoi qu'il en soit, si vous voulez en parler davantage, je pense que Discuter.elastic.co est un endroit plus approprié pour cela.