# Field names with the same name across types having different index/type in Elasticsearch

**URL:** <https://discuss.elastic.co/t/field-names-with-the-same-name-across-types-having-different-index-type-in-elasticsearch/22663>\
**Category:** Elasticsearch\
**Created:** [March 13, 2015, 8:47pm UTC](https://discuss.elastic.co/t/field-names-with-the-same-name-across-types-having-different-index-type-in-elasticsearch/22663 "2015-03-13T20:47:15Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![shahshi15](https://avatars.discourse-cdn.com/v4/letter/s/f08c70/32.png) [@shahshi15](https://discuss.elastic.co/u/shahshi15)\
**Post date:** [March 13, 2015, 8:47pm UTC](https://discuss.elastic.co/t/field-names-with-the-same-name-across-types-having-different-index-type-in-elasticsearch/22663/1 "2015-03-13T20:47:15Z")

</div>

I have detailed my question on stackoverflow here:

> <https://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](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 [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com).  
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).  
For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).

---

<div class="post-metadata">

**Author:** ![jprante](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/jprante/32/44941_2.png) [@jprante](https://discuss.elastic.co/u/jprante)\
**Post date:** [March 14, 2015, 5:48pm UTC](https://discuss.elastic.co/t/field-names-with-the-same-name-across-types-having-different-index-type-in-elasticsearch/22663/2 "2015-03-14T17:48:22Z")

</div>

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, [shahshi15@gmail.com](mailto:shahshi15@gmail.com) wrote:

> I have detailed my question on stackoverflow here:
> 
> [lucene - Field names with the same name across types having different index/type in Elasticsearch - Stack Overflow](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](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 [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com).  
> 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)  
> [https://groups.google.com/d/msgid/elasticsearch/0264dafc-82e9-44fb-8193-b2661e8225a6%40googlegroups.com?utm\_medium=email&utm\_source=footer](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](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 [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com).  
To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/CAKdsXoFg0Pe7wkeJPmVCRuPS0Pjvch59RVv5NVoDH5aheF7D%2Bg%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAKdsXoFg0Pe7wkeJPmVCRuPS0Pjvch59RVv5NVoDH5aheF7D%2Bg%40mail.gmail.com).  
For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).

---

<div class="post-metadata">

**Author:** ![shahshi15](https://avatars.discourse-cdn.com/v4/letter/s/f08c70/32.png) [@shahshi15](https://discuss.elastic.co/u/shahshi15)\
**Post date:** [March 14, 2015, 6:38pm UTC](https://discuss.elastic.co/t/field-names-with-the-same-name-across-types-having-different-index-type-in-elasticsearch/22663/3 "2015-03-14T18:38:01Z")

</div>

Wouldn't that be a bit too much though ? I mean if we have thousands of  
customers (tenants) we will have to create index for each of them ?  
Wouldn't it affect performance and wouldn't maintaining those many indexes  
in the cluster a bit too much ?

On Saturday, March 14, 2015 at 10:48:35 AM UTC-7, Jörg Prante wrote:

> 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, \<[shah...@gmail.com](mailto:shah...@gmail.com) \<javascript:\>\> wrote:
> 
> > I have detailed my question on stackoverflow here:
> > 
> > [lucene - Field names with the same name across types having different index/type in Elasticsearch - Stack Overflow](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](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 [elasticsearc...@googlegroups.com](mailto:elasticsearc...@googlegroups.com) \<javascript:\>.  
> > 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)  
> > [https://groups.google.com/d/msgid/elasticsearch/0264dafc-82e9-44fb-8193-b2661e8225a6%40googlegroups.com?utm\_medium=email&utm\_source=footer](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](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 [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com).  
To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/d41800b1-22ab-46ec-b4ee-a85ff298d50c%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/d41800b1-22ab-46ec-b4ee-a85ff298d50c%40googlegroups.com).  
For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).

---

<div class="post-metadata">

**Author:** ![jprante](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/jprante/32/44941_2.png) [@jprante](https://discuss.elastic.co/u/jprante)\
**Post date:** [March 14, 2015, 7:30pm UTC](https://discuss.elastic.co/t/field-names-with-the-same-name-across-types-having-different-index-type-in-elasticsearch/22663/4 "2015-03-14T19:30:32Z")

</div>

If you have thousands of tenants with thousands of potentially overlapping  
mappings that should operate independently, the hardware sizing of a  
cluster is a challenge, yes.

OTOH you can play tricks at your search/index front end API if you can hide  
ES internals from the customers, e.g. prefixing field names with the tenant  
ID so field names become unique. This should not be a recommended method,  
though - because ES should be able to handle overlapping mappings in a more  
feasible way.

Jörg

On Sat, Mar 14, 2015 at 7:38 PM, [shahshi15@gmail.com](mailto:shahshi15@gmail.com) wrote:

> Wouldn't that be a bit too much though ? I mean if we have thousands of  
> customers (tenants) we will have to create index for each of them ?  
> Wouldn't it affect performance and wouldn't maintaining those many indexes  
> in the cluster a bit too much ?
> 
> On Saturday, March 14, 2015 at 10:48:35 AM UTC-7, Jörg Prante wrote:
> 
> > 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, [shah...@gmail.com](mailto:shah...@gmail.com) wrote:
> > 
> > > I have detailed my question on stackoverflow here:  
> > > [lucene - Field names with the same name across types having different index/type in Elasticsearch - Stack Overflow](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](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 [elasticsearc...@googlegroups.com](mailto:elasticsearc...@googlegroups.com).  
> > > To view this discussion on the web visit [https://groups.google.com/d/](https://groups.google.com/d/)  
> > > msgid/elasticsearch/0264dafc-82e9-44fb-8193-b2661e8225a6%  
> > > [40googlegroups.com](http://40googlegroups.com)  
> > > [https://groups.google.com/d/msgid/elasticsearch/0264dafc-82e9-44fb-8193-b2661e8225a6%40googlegroups.com?utm\_medium=email&utm\_source=footer](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](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 [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com).  
> > To view this discussion on the web visit  
> > [https://groups.google.com/d/msgid/elasticsearch/d41800b1-22ab-46ec-b4ee-a85ff298d50c%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/d41800b1-22ab-46ec-b4ee-a85ff298d50c%40googlegroups.com)  
> > [https://groups.google.com/d/msgid/elasticsearch/d41800b1-22ab-46ec-b4ee-a85ff298d50c%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/d41800b1-22ab-46ec-b4ee-a85ff298d50c%40googlegroups.com?utm_medium=email&utm_source=footer)  
> > .
> 
> For more options, visit [https://groups.google.com/d/optout](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 [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com).  
To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/CAKdsXoHj%2B%2BMmPQ1KUHYUTifek48rOCRM2TLLsvijpGP5k56SPg%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAKdsXoHj%2B%2BMmPQ1KUHYUTifek48rOCRM2TLLsvijpGP5k56SPg%40mail.gmail.com).  
For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\
**Post date:** [July 6, 2017, 12:26am UTC](https://discuss.elastic.co/t/field-names-with-the-same-name-across-types-having-different-index-type-in-elasticsearch/22663/5 "2017-07-06T00:26:43Z")

</div>