Elasticsearch: Update API: Update per Abfrage

Erstellt am 12. Jan. 2012  ·  160Kommentare  ·  Quelle: elastic/elasticsearch

1583 ermöglicht die Aktualisierung einzelner Dokumente. Die Aktualisierung per Abfrage reduziert die Netzwerk-Roundtrips radikal, wenn Sie eine Reihe von Dokumenten aktualisieren und Arbeit vom Client auf ES übertragen möchten.

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

Hilfreichster Kommentar

Update per Abfrage ist in 2.3.0 und 5.0.0-alpha-1 live. Die Dokumente sind hier .

Alle 160 Kommentare

Würde diese Funktion auch sehr lieben!

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

Ich brauche diese Funktion wirklich

:+1:

Während ich darauf warte, dass dieses Feature offiziell fertiggestellt und freigegeben wird, habe ich den Pull-Request #2231 als Plugin gepackt :
Habe Spaß.

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

:+1: :beten:

+1

+1

Gibt es eine Möglichkeit, die Bewertung der Abfrage als Parameter an das Aktualisierungsskript zu übergeben? Ich muss Einträge mit Bewertungen aktualisieren, die basierend auf den Feldern der untergeordneten Elemente aktualisiert wurden.

+1

+1

+1

@scottc52 Hast du es geschafft? Ich suche auch nach einer Möglichkeit, dies zu tun.

+1

@gboivin Nein. Ich mache eine has_child-Abfrage und sende eine separate Update-Anfrage, aber es ist langsam.

warte auch auf diese Funktion..

+1

+1

+1

+1

+1

+1

+1

Habe nur ein kleines Drehbuch geschrieben, um auf etwas zu warten... mehr "Produktionsfertig" ;-)

https://github.com/YannBrrd/esNodeUpdater

Gerne kommentieren/aktualisieren...

+1

Gibt es einen offiziellen Status zu dieser Funktion vom Entwicklerteam? Ich sehe keine Eingaben von ihnen. Gibt es Pläne, diese Funktion zum Kern hinzuzufügen, oder wird es bevorzugt, dass Benutzer ein Plugin wie das oben aufgeführte verwenden ?

Wir planen, zu diesem Thema zurückzukehren. Der Hauptgrund, warum wir dies auf Eis legen, ist, dass wir eine Möglichkeit haben müssen, vorhandene Aktualisierungen durch Abfragen zu stoppen, da sie versehentlich für eine große Datenmenge ausgeführt werden können, was zu Problemen führt. .

+1. Danke für das Update und die Arbeit daran.

+1

+1

+1

+1

+1, hört sich nützlich an

+1

+1

+1

+1

+1

+1

+1

+1

+2

+1

+10

+1

+1

+1

Haben Sie schon einmal daran gedacht, diese Funktion mit einem doppelten HTTP-Aufruf zu implementieren. Ich denke an Wärmer, die die Möglichkeit bieten, die Abfrage zu speichern und dann auszuführen (es ist nicht wirklich dasselbe, aber es bringt mich zum Nachdenken).

@kimchy Sie sagen, dass Sie eine Möglichkeit finden, das Update zu stoppen, wenn es versehentlich mit einer großen Datenmenge gestartet wurde. Wenn Sie es stoppen, befinden sich möglicherweise indizierte Daten in einem ungültigen Zustand (vielleicht ist ein Rollback möglich ...?). Vielleicht ist ein besserer Ansatz, Fehler zu vermeiden.

Wenn Sie zwei HTTP-Aufrufe benötigen, bevor Sie das eigentliche Massenupdate auslösen (1 zum Vorbereiten und 1 zum wirklichen Auslösen mit einer Transaktions-ID dazwischen) und dann einen Update-Statushandler (wie den dataimporthandler in SolR), um zu wissen, wann die Abfrage wirklich abgeschlossen ist.

Ich bin mir nicht sicher, ob es wirklich klar ist, aber ich denke, es kann eine Lösung sein, um Fehlanrufe zu vermeiden...

+1

+1

Das möchte ich auch gerne bestätigen.

+1

@kimchy : Leistung kann nicht die Frage sein: Derzeit führe ich Tausende von Abfragen durch, um Daten nachzuschlagen (z (zB um Klartextadresse hinzuzufügen). Meine Updates fügen neue Felder hinzu. Ein Bulk-Update innerhalb von ES muss effizienter sein als 10.000 Lookup-Abfragen + 10.000 Update-Anfragen (auch unter Verwendung von Bulk-Updates ...). Aus der Sicht der Codierung und der Laufzeit wäre es effizienter, zB die Bulk-Update-Datei bekommt 20.000 Zeilen und könnte mit der neuen Funktion nur 2 haben - alle Daten werden über das Netzwerk verschoben und ES ist damit beschäftigt, Bulk-Update-Dateien zu lesen ...

Vielleicht stimmen Sie zu, dem Update-Vorgang Grenzen hinzuzufügen, z. B. _update/_query=some_conditions&size=1000 auf diese Weise wird vermieden, dass eine Million Dokumente aktualisiert werden - und wir als Entwickler können entscheiden, ob wir 1000 * 1000 Updates ausführen, um eine Million Datensätze zu aktualisieren ... Es sollte die Anzahl der aktualisierten Dokumente zurückgeben, um eine gewisse Kontrolle zu haben, wenn ein weiterer Update-Aufruf erforderlich ist.

+1

Für mein Szenario (Records nach Lookups in anderen Indizes anreichern) könnte ich es anders machen: Daten zuerst in mongoDb einfügen, Lookups in ElasticSearch durchführen, Datensätze in Mongo aktualisieren, mongo river verwenden, um endgültige Ergebnisse in ElasticSearch zu erhalten, um sie in der GUI anzuzeigen (build auf ES). Hat jemand Erfahrung mit solchen Szenarien? Ich hoffte, ich könnte nur ES gehen ... bis jetzt habe ich die Verwendung einer DB in meinem Projekt abgelehnt.

Hallo,

du könntest dafür einfach Couchbase + Elasticsearch verwenden, als Couchbase
bietet eine Schnittstelle zu Elasticsearch

Herzliche Grüße,
Yann Barraud

2014-02-03 seti123 [email protected] :

Für mein Szenario (Anreicherung von Datensätzen nach Suchen in anderen Indizes) könnte ich
Machen Sie es anders: Fügen Sie zuerst Daten in mongoDb ein, suchen Sie in
ElasticSearch aktualisiert Datensätze in Mongo, verwenden Sie Mongo River, um endgültige Ergebnisse zu erhalten
in ElasticSearch, um es in der GUI anzuzeigen (auf ES aufbauen). Hat jemand
Erfahrung mit solchen Szenarien? Ich hoffte, ich könnte nur ES gehen ... bis
jetzt habe ich die Verwendung einer DB in meinem Projekt abgelehnt.

Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf Gi tHub anhttps://github.com/elasticsearch/elasticsearch/issues/1607#issuecomment -33917801
.

+1

+100

+1

+1

Gibt es in ElasticSearch eine Alternative, zB ein Skript auszulösen, das eine Aktion ausführt, wenn neue Daten eingefügt oder aktualisiert werden? Eine Art Index-Trigger konnte mir helfen, die Vorverarbeitungskette zu entfernen (wir haben jetzt Message Ques mit REDIS- und 0MQ-Verarbeitungskette gemacht, bevor wir Daten in ES einfügen - all das kostet Netzwerkbandbreite, um Daten für die parallele Verarbeitung zu mischen ... )

Ich würde gerne ... sehen
http://localhost :9200/index/type/_preprocessBeforeIndex?script=myDataAnalysisScript
http://localhost :9200/index/type/_preprocessBeforeUpdate?script=myDataAnalysisScript
Das Skript muss in der Lage sein, dem aktuellen Datensatz neue Felder hinzuzufügen, bevor ES ihn speichert/indiziert (um eine doppelte Indexaktion nach Änderungen zu vermeiden). Da wir viel mit node.js arbeiten, sollten die Skripte in der gewünschten Sprache (in unserem Fall JavaScript) funktionieren.

Noch besser, wenn wir das Script im MAPPING pro Datentyp definieren könnten, anstatt auf einem generierten Indizes.
Gibt es ein Plug-In, das solche Skripte auslösen kann? Irgendeine Dokumentation zur Verwendung der ES API in Skripten?

+1

+1

+1

+1

+1

+1

+1

+1

+1

Warte auf diese Funktion... (+1)

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

Ist diese Funktion überhaupt in Entwicklung?
Dies würde so viele Probleme lösen, die derzeit auf Anwendungsebene kaum zuverlässig zu bewältigen sind.

+1

+1

+1

Nur um Sie daran zu erinnern, dass ich seit Mitte Februar 2013 den "offiziellen Pull-Request" #2231 über den Zweig von @martijnvg als Plugin gepackt und gepflegt habe:

+1

+1

+1

+1

+1
Wie ist es möglich, dass dieses Feature seit Februar 2013 immer noch nicht zum Master zusammengeführt wurde?

+1
Dito auf

+1

Wir haben dieses Problem vor einigen Monaten bekommen (siehe meine Beiträge als @seti123 Januar/Februar ) und ich möchte unsere Ergebnisse teilen - nachdem wir DB+ES River aufgegeben hatten (zu viele Sorgen über Versionsabhängigkeiten) haben wir unseren Anwendungsfall erfolgreich mit evaluiert Crate Data (das ES als Bibliothek verwendet und eine SQL-Schnittstelle für Mapping und Abfrage hinzufügt, einschließlich "Update by Query" https://crate.io/docs/stable/sql/dml.html#updating-data ).
Ein guter Ausgangspunkt, um über Ähnlichkeiten und Unterschiede zu lesen: https://crate.io/blog/crate_data_elasticsearch

Geschlossen zu Gunsten von #2230

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

wird durch Abfrageunterstützung setPostFilter aktualisiert?
Ausgabe # 12295

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

kann das jemand überprüfen und Feedback geben.
https://discuss.elastic.co/t/updatebyqueryresponse-throwing-timeout/29176

Aktualisierung durch Abfrage schlägt fehl, während mehr als 20+ Millionen Datensätze aktualisiert werden.

@ Praveen82 Sie verwenden ein Drittanbieter-Plugin. Dies ist nicht der richtige Ort, um Support anzufordern. Sie sollten dies als Problem im Repository dieses Plugins veröffentlichen.

https://github.com/elastic/elasticsearch/pull/15125 implementiert eine Syntax, die ein wenig so aussieht

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

Der Grund, warum dies so lange ins Stocken geraten war

Wie auch immer, #15125 und alle Folge-PRs sind der richtige Ort, um nach dieser Funktion zu suchen.

+1

+1

+1

+1

+1

Update per Abfrage ist in 2.3.0 und 5.0.0-alpha-1 live. Die Dokumente sind hier .

Unterstützt das Update per Abfrage in 2.3.+ oder 5.+ das Javascript-Plugin?

Unterstützt das Update per Abfrage in 2.3.+ oder 5.+ das Javascript-Plugin?

Wenn du es wirklich willst, klar. In 2.3+ testen wir Update-by-Query gegen groovy und in 5.+ testen wir gegen schmerzlos. Wir haben früher gegen groovy getestet und es hat auch dort funktioniert. Ich gehe davon aus, dass Javascript gut funktioniert.

JS-Unterstützung wäre ziemlich glatt.

JS-Unterstützung wäre ziemlich glatt.

Wie gesagt, es existiert, man muss nur das Plugin installieren.

Das Problem bei all diesen Sprachen besteht darin, dass ihre Implementierung in der JVM nicht richtig auf die Einbettung ausgerichtet ist. Aus diesem Grund nehmen wir es nicht standardmäßig auf.

Wie auch immer, wenn Sie mehr darüber sprechen möchten, denke ich, dass diskussion.elastic.co der geeignetere Ort dafür ist.

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen