Hi Jörg, The assumptions you've made on my use case are correct.
The nightly update could definitely work, but I think even live updates could work as the data is quite static in nature. A few more questions: * You're talking about recreation of the index, with this you mean update I presume?; * The terms you're using: "inferring triples", "materialization", "dynamic materialization", to what paradigm do they belong? Lots of reading for me to do! Thank you for your comments and hints. Best regards, Peter In our case there is no big problem in nightly recreation of the index and on the other hand there aren't many mutations. 2014-02-11 16:05 GMT+01:00 joergpra...@gmail.com <joergpra...@gmail.com>: > I'm not sure, and I try hard to understand your use case. > > I assume you want a single query that can filter attributes of both the > entity "1" and for attributes of related entities "2" and "3". > > As you have noticed, in a single query, this is not possible unless you > had "bubbled up" the relevant attributes into one big document that holds > all attributes of "1", "2", and "3" you want to filter for. > > If you are willing to execute multiple queries in a sequence, the > following might work: either "top down" (first search the entity "1", > filter for attributes, and expand from there all related entities with a > second filter query) or "bottom up" (first search the entities "2" and "3" > for their attributes, and then go up to entities like "1" and filter them > for their attributes). > > It depends how much IDs you want to handle, because, in a single multi > term query, there is a limit of 1024 clauses. So if you have many thousands > of hits, you have to iterate over several search results and concatenate > the IDs into a result set. > > If you are not able to invest into query side, you have to expand the > attributes on the index side. This can be expensive if you want a "live" > index with many updates in real time. But if you can afford to recreate the > index only occasionally (daily at night for example), the index expansion > strategy is worth it. For expansion, you have two options: write the > expansion logic into your indexing client, or let an ES plugin expand the > documents automatically (with some caution, because the order in which > documents are indexed is important.) > > Just a hint for expansion in the index: you could also maintain two > instances of your documents, one version with IDs, and one with expanded > IDs (this is also called "inferring triples" and "materialization"). So > whatever index is best for a task, you could choose between them. A program > logic could also work dynamically on the documents that arrive for update, > find inconsistencies in the materialized ones, and fix them instantly (this > is called "dynamic materialization"). > > Jörg > > -- > You received this message because you are subscribed to a topic in the > Google Groups "elasticsearch" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/elasticsearch/AR80CGriVFQ/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > elasticsearch+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/elasticsearch/CAKdsXoHV6YJ5HriJLij%2BaVNqmmTiqHckzk2P5Nr5QNWj1oJsmg%40mail.gmail.com > . > > For more options, visit https://groups.google.com/groups/opt_out. > -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/CAC%3DvprA8pohCt%2BEbGfk2_AmPrXMvyehi1X%3DayX-Oa_SQ%3DY7Rkg%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
