I'd like to store elements related to a grid which consist of physical entities (mapped to an individual document in my model), and those entities follows a tree structure (A is a parent of B which is a parent of C...) that can have an important depth (let's say to the hundreds). Therefore, fully denormalize would be a little cost prohibitive.
I've read about parent join as well as terms queries : Assuming I'd like to get the parent/child (potentially list of ancestors/descendants) of a given entity/set of entity, what should I use?
I am able to make it using terms query, by storing the id of the parent (or all the ancestors) in each document and making a direct request/terms request to find either parent of children.
I would be able to make it defining a joining query as well, but I've seen it is not recommanded. However, I don't really get why, and what is the use case of those joins if its possible to make it as simply using the terms query.
So my question is more about the impact of each solution (performance-wise, "querying capability"-wise), as I don't know enough about ElasticSearch's internals to compare the two options.
I would encode the path from the root of the tree into the documents and then use the path-hierarchy tokenizer to index the path field. This way you can retrieve sub-trees easily.
However, I struggle to get documents above document 4 (i.e document 5, or documents 4 and 5). How would you proceed? (We might assume that the path is composed of the documents IDs if that helps, as it would be true in my case)
Your last query is an example of a terms lookup query, where the actual value is retrieved by querying the content of a document in an Elasticsearch index.
If you wanted to retrieve all documents where the path starts with /one, you'd simply use
Note, that in this case you would just pass the value (or if using a terms query, an array of values). Your example was reading the value /one/two from path in document 4.
I got what that query does, I've used the terms lookup since in my case I will know the ID but not necessarily the full path.
Assuming I have Country/Region/City/Street kind of tree, I would know only the city name (hence the lookup) and then be able to fetch all the streets within the city, which is the sub-tree. So far so good.
But knowing that city, I'd also like to have a different query to directly access the documents representing the Region and the Country. This is where I struggle : How do I get only the ancestors (the branch from the root up to the city) but not the descendants.
In my case above, it translates in how to return only document 4 and 5.
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.