You are right, I suggest to use different indices for tenant 1 and 2, this is also good for separating other concerns (like index term statistics, scoring, field faceting, deleting docs, etc.)
As a matter of fact it is not Lucene that stands in the way. Internally, ES keeps a hash map of field names across types, i.e. correct field name lookup is a challenge if a field name denotes two different field specifications in an index. Jörg On Fri, Mar 13, 2015 at 9:47 PM, <[email protected]> wrote: > I have detailed my question on stackoverflow here: > > http://stackoverflow.com/questions/29041509/field-names-with-the-same-name-across-types-having-different-index-type-in-elast > > Briefing it here as well : > > I have been reading a lot on mappings in Elasticsearch and here's > something interesting that I found > > Field names with the same name across types are highly recommended to have > the same type and same mapping characteristics (analysis settings for > example). There is an effort to allow to explicitly "choose" which field to > use by using type prefix (my_type.my_field), but it’s not complete, and there > are places where it will never work (like faceting on the field). > > I found the above quote from the documentation here > <http://www.elastic.co/guide/en/elasticsearch/reference/current/mapping.html> > > Now my use case is exactly that .. Here's an example. Suppose that some > field in tenant1 has to have the following mapping (for a given entity > user): > > { > "tenantId1_user": { > "properties": { > "someField": { > "type": "string", > "index":"analyzed" > } > } > } > } > > Now, for the same field in a different tenant (for the same entity type, > lets say user), the type has to change like this: > > { > "tenantId2_user": { > "properties": { > "someField": { > "type": "int", > "index":"analyzed" > } > } > } > } > > Now from what I understand from the above quote, it means that technically > even though I can provide this mapping, it is not recommended because deep > down Lucene handles them in the same way. > > My questions are: > > 1) How can I handle my usecase ? Should I just separate out each tenant in > a different index so I don't have to worry about this mapping ? > > 2) Is there any other workaround ? Considering the fact that if I have too > many tenants that means I will have too many indices? > > 3) What's the recommended way for this usecase? > > All help appreciated! > > -- > 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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/elasticsearch/0264dafc-82e9-44fb-8193-b2661e8225a6%40googlegroups.com > <https://groups.google.com/d/msgid/elasticsearch/0264dafc-82e9-44fb-8193-b2661e8225a6%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/CAKdsXoFg0Pe7wkeJPmVCRuPS0Pjvch59RVv5NVoDH5aheF7D%2Bg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
