Molte a molte relazioni in elasticsearch

Question

So che in elasticsearch, possiamo avere child/parent relationships tra i documenti.

E poi, durante l'indicizzazione, posso passare l'ID genitore in modo che i documenti secondari e principali sono legate:

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

Esiste un modo per modellare una relazione molti a molti in elasticsearch?

dati è risiede in un database MySQL con il seguente 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. 

Questa è attualmente la mia mappatura per account (scusate la notazione di matrice, io sto usando Elastica in PHP per parlare con il mio server elasticsearch) :

**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') 

il problema di questo approccio è che se un gruppo viene eliminato dall'indice, ho bisogno di passare attraverso ogni account e cancellare l'ID del gruppo da ogni account. Questo sembra essere un po 'inefficiente per me. Presumo anche che questo non sarebbe un problema quando si usano le relazioni figlio/genitore di elasticsearch.

Esiste comunque la possibilità di modellare relazioni molti-a-molti in elasticsearch?

Answer 1

Non c'è modo di modellare le relazioni molti-a-molti.

L'unico modo è quello di memorizzare l'ID di ciascun gruppo in ogni account come ho fatto in precedenza.

Elasticsearch è abbastanza efficiente, così spesso, la reindicizzazione è una soluzione accettabile. Inoltre, elasticsearch ha la nozione di documenti e non è un sistema di archiviazione relazionale, quindi le relazioni molti-a-molti probabilmente non verranno mai implementate.

Answer 2

Quando si pensa all'efficienza, ciò che è necessario considerare è l'efficienza in fase di scrittura rispetto alla lettura. I database relazionali favoriscono l'efficienza in fase di scrittura, mentre NoSQL favorisce l'efficienza in fase di lettura.

È necessario considerare attentamente il rapporto tra lettura e scrittura nell'applicazione e determinare quale sarà nel complesso più efficiente. Alla fine, qualcosa deve fare il lavoro di unire tutte le relazioni, sia quando i dati sono scritti, sia quando i dati vengono letti.