ElasticSearch Update mit Upsert

Multivitamin

Heya,

ich habe vor kurzem ein wenig mit ElasticSearch angefangen und nun folgendes Problem:

Ich konvertiere wieder Steam64IDs zu Battleye GUIDS, um platz auf der fesplatte zu sparen gehe ich nun her und nimm die letzten 4 charactere des Battleye ID und füge hinten die möglichen steamids an, würde dann so aussehen

{g: "85e8", i: [76561198032854208, 76561198032893719, 765611980328512748, .....]}
{g: "j71s", i: [76561198032891651, 76561198032899164, 765611980328511851, .....]}

das Problem dass ich nun beim inserten habe ist dass wenn ich _update nutze muss ich bereits die ID wissen die ich jedoch nicht habe Update API
| Elasticsearch Reference [5.x]
| Elastic

Wenn ich updateByQuery nutze kann ich keinen Upsert nutzen Update By Query API
| Elasticsearch Reference [5.x]
| Elastic

Derzeit sieht mein Update so aus, das Problem hierbei ist dass ich kein upsert nutzen kann, wie kann ich also die "ROW" erstellen wenn diese noch nicht vorhanden ist?

JavaScript

elastic.updateByQuery({
      index: "battleye_steam",
      type: "conv",
      body: {
        scripted_upsert:true,
        script: {
          inline: "ctx.ids += params.id",
          lang: "painless",
          params: {
            id: be[0]
          }
        },
        query: {
          match: {
            g: be[1].substr(be[1].length - 4)
          }
        },
        upsert: {
          g: be[1].substr(be[1].length - 4),
          i: be[0]
        }
      }
    })
    .then(console.log)
    .catch(console.log)

Alles anzeigen

Finch

Hey,

ist leider nicht die Antwort auf deine Frage. Dazu müsste ich jetzt selbst nachlesen da mein Elastic trotz Benutzung im TechStack etwas rostig ist.

Aber wenn es dir ums speicher sparen geht, mach dir nen einfachen Table eine Spalte (bzw. 2) also ID(0-x) und Battleye ID.

Dann kannst du einfach nach der GUID suchen und anhand der Zeile/ID dann die SteamID errechnen. Gibt es einen bestimmten Grund für Elastic in deinem Fall?

Der Ansatz der bei uns aktuell verfolgt wird ist sogar noch "primitiver" aber um so effizienter.

Man unterteilt die GUIDS in Cluster. Sagen wir mal C1, C2, C3 und C4. Diese Cluster sind im Grunde nur Dateien in denen in jeder Zeile eine GUID steht. Die Zeilennummer ist wie vorher erklärt die ID. Nun muss nur noch eine kleine Anwendung (am besten permanent) die Cluster durchlaufen. Das können auch viele Threads machen. Und du gibst der Anwendung die GUID die du umrechnen möchtest, sobald ein Reader nun die GUID findet, kann er sich aus der ClusterID und der Zeile die SteamID errechnen. Das System ist je nach Anzahl der Reader vielleicht langsamer, aber im Moment ist es für uns weniger Kritisch die GUID schnell umrechnen zu können. Der Vorteil ist, dass kein Overhead von MySQL oder einer anderen DB erzeugt wird, die für komplexere Aufgaben gedacht sind, sowie auch die verhältnismäßig kleine Belastung für HDD und RAM. Die Files müssen nicht im Arbeitsspeicher liegen und je nach Bedarf kann die Zahl an Readern automatisch verändert werden.

Dieses System wird OpenSource veröffentlicht sobald es fertig ist. Wenn du an der Idee Interesse hast, können wir auch gerne mal quatschen.

Man kann das System auch in jede Richtung komplizierter machen und dadurch optimieren.

Und zu deiner eigentlichen Frage doch nochmal:

Was mir noch einfallen würde, wäre beim Einfügen aus den SteamIDs schon die GUID zu errechnen und dann den String zu kürzen, damit hast du deine ID. Wenn sie schon da ist, füg sie an. Oder habe ich dein Problem falsch verstanden?

Grüße,

Finch

Multivitamin

Ich habe bereits eine Lösung für meinen Fall gefunden,

in meinem Fall teile ich die Daten auf 10 Shards auf

JavaScript

bulk.push({
          update: {
              _index: "battleye_steam",
              _type: "conv",
              _id: be[1].substr(be[1].length - 6)
          }
        }, {
          script: {
            inline: "ctx._source.i.add(params.i)",
            lang: "painless",
            params: {
              i: be[0]
            }
          },
          upsert: {
            i: [be[0]]
          }
        })

Alles anzeigen

Ich habe selber bemerkt dass die ID bei elasticsearch nicht nur aus zahlen bestehen muss^,

um Platz zu sparen wird derzeit auch nur die ID indexiert und ich rufe die Datensätze auch nur über die ID auf

für die Zukunft von einer Milliarde IDs sollte ich auf nicht mehr als 100 Millionen Einträge kommen, das wären dann ca 10 Millionen Einträge pro Shard

Finch

Auch eine schöne Lösung.

Die Idee mit der kurzen GUID ist ein echt interessanter Ansatz.

Benutzer online in diesem Thema