Viele zu viele Beziehungen in elasticsearch

Question

Ich weiß, dass in elasticsearch, können wir child/parent relationships zwischen Dokumenten haben.

Und dann, wenn die Indizierung, kann ich die Eltern-ID übergeben, so dass das Kind und Eltern Dokumente verknüpft sind:

$ curl -XPUT localhost:9200/blogs/blog_tag/1122?parent=1111 -d '{ "tag" : "something"}' 

Gibt es trotzdem eine viele zu viele Beziehung in Elasticsearch zu modellieren?

Daten ist residiert in einer MySQL-Datenbank mit dem folgenden Schema:

account 
======== 
id 
name 
some_property 

group 
======== 
id 
name 
description 

account_group 
============= 
account_id 
group_id 
primary_group //This is 1 or 0 depending on whether the group is the primary group for that account. 

Dies ist derzeit mein Mapping für account (bitte die Array-Schreibweise entschuldigen, ich Elastica in PHP bin mit meinem Elasticsearch Server zu sprechen) :

**Mapping for account** 

'name' => array(
    'type' => 'string'), 

'some_property' => array(
    'type' => 'string'), 

'groups' => array(
    'properties' => array(
    'id'  => array('type' => 'integer'), 
    'primary' => array('type' => 'boolean') 
    ) 
), 

**Mapping for group** 

'name' => array(
     'type' => 'string'), 

'description'=> array(
     'type' => 'string') 

Das Problem bei diesem Ansatz ist, dass, wenn eine Gruppe aus dem Index gelöscht wird, muß ich durch jedes Konto gehen und die Gruppen-ID von jedem Konto löschen. Das scheint mir ein bisschen ineffizient zu sein. Ich nehme auch an, dass dies kein Problem wäre, wenn man die Kind/Eltern-Beziehungen von elasticsearch verwendet.

Gibt es sowieso eine Möglichkeit, viele-zu-viele-Beziehungen in elasticsearch zu modellieren?

Answer 1

Es gibt keine Möglichkeit, Viele-zu-Viele-Beziehungen zu modellieren.

Der einzige Weg ist, die ID jeder Gruppe in jedem Konto wie oben gespeichert zu speichern.

Elasticsearch ist ziemlich effizient, so oft, Reindexing ist eine akzeptable Lösung. Auch hat elasticsearch die Vorstellung von Dokumenten und ist kein relationales Speichersystem, so dass viele-zu-viele-Beziehungen wahrscheinlich niemals implementiert werden würden.

Answer 2

Wenn Sie an Effizienz denken, müssen Sie die Schreib- und Lesezeit-Effizienz berücksichtigen. Relationale Datenbanken bevorzugen Schreibzeit-Effizienz, während NoSQL Lesezeit-Effizienz bevorzugt.

Sie müssen das Verhältnis von Lesen und Schreiben in Ihrer Anwendung sorgfältig abwägen und bestimmen, was insgesamt effizienter ist. Am Ende muss etwas getan werden, um alle Beziehungen zu verbinden, entweder wenn die Daten geschrieben werden oder wenn die Daten gelesen werden.