Wie ElasticSearch-Indizes zu entwerfen

Question

Ich habe einen Dokumentspeicher mit mehreren Typen. Jeder Dokumententyp hat einige grundlegende Metadaten, wie uuid, und ein einzelnes "entity" -Feld, das einen stringifizierten json mit dem eigentlichen Inhalt enthält. Dies liegt daran, dass das Dokument, das Ereignis, obwohl es einen Typ hat, kein strenges Schema hat und jeder Benutzer Daten in jeder Struktur bereitstellen kann.

Ich muss in der Lage sein, diese Dokumente zu durchsuchen, zu filtern und zu durchsuchen, also werde ich sie in ElasticSearch einfügen.

Meine Frage ist: Wie sollte ich die ES strukturieren? Ich habe gelesen, dass zu viele Indizes nicht gut für ES sind und dass es besser ist, möglichst wenige Indizes zu haben. Aber ES mag es auch nicht, wenn Dokumente des gleichen Typs eine unterschiedliche Struktur haben (Mapping) + Sie können das Mapping für bestehende Felder nicht ändern, sondern nur an neue anhängen.

Das "Schema" ist für jeden Dokumenttyp und Benutzer festgelegt, so dass ich einen neuen Index für jeden Benutzer mit dem gleichen Typ (en) erstellen konnte, aber wie ich bereits erwähnt habe, ist eine Vielzahl von Indizes schlecht.

Was ist das empfohlene Design in diesem Fall?

Das mag sich verrückt anhören, aber wäre es möglich, das Dokument in ein Schlüssel/Wert-Format zu zerlegen, in dem der Schlüssel der Eigenschaftspfad wäre? Die einzigen Probleme, die ich hier sehe, sind, dass alles als Volltext eingestellt werden müsste, was nicht nach einer guten Idee klingt.

Edit: scheint wie ES macht dies allein https://www.elastic.co/guide/en/elasticsearch/reference/current/object.html, aber ich bin mir immer noch nicht sicher, was zu tun ist.

Answer 1

Was Sie tun können, ist eine Reihe von nested Objekttypen haben mit key und value Felder, dh Ihre Mapping wie

"entity": { 
    "type": "nested", 
    "properties": { 
     "key": { 
     "type": "keyword" 
     }, 
     "value": { 
     "type": "text", 
     "fields": { 
      "keyword": { 
      "type": "keyword" 
      } 
     } 
     } 
    } 
} 

so aussehen würden Sie so ziemlich alles speichern, können Sie in der entity wollen Feld ohne eine Mapping-Typen Explosion zu riskieren, zum Beispiel

{ 
    "uuid": "", 
    "entity": [ 
    {"key": "myfield1", "value": "Some value"}, 
    {"key": "myfield2", "value": "Some value"}, 
    {"key": "myfield3", "value": "Some value"} 
    ] 
} 

Dann werden Sie Ihre Daten müssen sicherstellen, nested Abfragen zu verwenden, wenn die Abfrage aber es ist definitiv machbar.