# Index design for very dynamic Form/Fields

**URL:** <https://discuss.elastic.co/t/index-design-for-very-dynamic-form-fields/19877>\
**Category:** Elasticsearch\
**Created:** [September 19, 2014, 3:31am UTC](https://discuss.elastic.co/t/index-design-for-very-dynamic-form-fields/19877 "2014-09-19T03:31:33Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![Michael\_Chen](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/michael_chen/32/1273_2.png) [@Michael\_Chen](https://discuss.elastic.co/u/Michael_Chen)\
**Post date:** [September 19, 2014, 3:31am UTC](https://discuss.elastic.co/t/index-design-for-very-dynamic-form-fields/19877/1 "2014-09-19T03:31:33Z")

</div>

Hi,

We have a system very much like Google Forms, which allow users to design  
their own forms with various fields (single line text, paragraph, number,  
address etc, you can imagine that.) Without any doubt, it's running on top  
of MongoDB. Now it has 120K forms with nearly 10 million entries.

Recently we found a performance bottleneck on the query. After we have done  
every possible performance tuning on mongoDB side, we decide to index the  
form entries into elastic search. And there is a trouble:

Given there is a Form A, has field\_1 as string type, field\_2 as number, the  
data entry might look like: { field\_1: "hello", field\_2: 100}

Form B could be field\_1 as number, field\_2 as number, the date entry will  
look like { field\_1: 100, field\_2: "hello form"}

We have successfully create an index "entries" in ES, and can index the  
first entry successfully. But the second one failed for an obvious reason:  
type mismatch.

I am not sure how to deal with this problem. I definitely don't want to  
create 120K indices for every single form. And I am not sure it's doable to  
write custom transform script to change the index type identical across all  
entries.

Any suggestion? Much appreciate any response.

--  
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/4a6d47d7-ae0e-44f5-bd3a-756ea94e3899%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/4a6d47d7-ae0e-44f5-bd3a-756ea94e3899%40googlegroups.com).  
For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).

---

<div class="post-metadata">

**Author:** ![dadoonet](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/dadoonet/32/137187_2.png) [@dadoonet](https://discuss.elastic.co/u/dadoonet)\
**Post date:** [September 19, 2014, 6:15am UTC](https://discuss.elastic.co/t/index-design-for-very-dynamic-form-fields/19877/2 "2014-09-19T06:15:25Z")

</div>

You could have one type per form although the cluster state will be very big.  
But you should test that option.

Or if you don't really search for numbers as numbers (I mean with Range queries/filters), you could force each field to be a String and do the transformation at a client level.

My 2 cents

--  
David Pilato | Technical Advocate | [elasticsearch.com](http://elasticsearch.com)  
[david.pilato@elasticsearch.com](mailto:david.pilato@elasticsearch.com)  
@dadoonet | @elasticsearchfr | @scrutmydocs

Le 19 septembre 2014 à 05:31:38, Michael Chen ([mechiland@gmail.com](mailto:mechiland@gmail.com)) a écrit:

Hi,

We have a system very much like Google Forms, which allow users to design their own forms with various fields (single line text, paragraph, number, address etc, you can imagine that.) Without any doubt, it's running on top of MongoDB. Now it has 120K forms with nearly 10 million entries.

Recently we found a performance bottleneck on the query. After we have done every possible performance tuning on mongoDB side, we decide to index the form entries into elastic search. And there is a trouble:

Given there is a Form A, has field\_1 as string type, field\_2 as number, the data entry might look like: { field\_1: "hello", field\_2: 100}

Form B could be field\_1 as number, field\_2 as number, the date entry will look like { field\_1: 100, field\_2: "hello form"}

We have successfully create an index "entries" in ES, and can index the first entry successfully. But the second one failed for an obvious reason: type mismatch.

I am not sure how to deal with this problem. I definitely don't want to create 120K indices for every single form. And I am not sure it's doable to write custom transform script to change the index type identical across all entries.

## Any suggestion? Much appreciate any response.

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/4a6d47d7-ae0e-44f5-bd3a-756ea94e3899%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/4a6d47d7-ae0e-44f5-bd3a-756ea94e3899%40googlegroups.com).  
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/etPan.541bc9fd.66334873.18d1%40MacBook-Air-de-David.local](https://groups.google.com/d/msgid/elasticsearch/etPan.541bc9fd.66334873.18d1%40MacBook-Air-de-David.local).  
For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).

---

<div class="post-metadata">

**Author:** ![Michael\_Chen](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/michael_chen/32/1273_2.png) [@Michael\_Chen](https://discuss.elastic.co/u/Michael_Chen)\
**Post date:** [September 19, 2014, 6:27am UTC](https://discuss.elastic.co/t/index-design-for-very-dynamic-form-fields/19877/3 "2014-09-19T06:27:15Z")

</div>

Thanks David. Based on the system behavior, having all type as string is  
fine for queries. But for the aggregation level it might be trouble. For  
example a type of address is a complex JSON object:

{ field\_1: { country: "US", province: "CA", city: "New York", address:  
"Street Address"} }

If we transform this type into any form of string, and trying to aggregate  
based on country/state, it will be VERY hard even not possible.

On Fri, Sep 19, 2014 at 2:15 PM, David Pilato [david@pilato.fr](mailto:david@pilato.fr) wrote:

> You could have one type per form although the cluster state will be very  
> big.  
> But you should test that option.
> 
> Or if you don't really search for numbers as numbers (I mean with Range  
> queries/filters), you could force each field to be a String and do the  
> transformation at a client level.
> 
> My 2 cents
> 
> --  
> _David Pilato_ | Technical Advocate | _[elasticsearch.com](http://elasticsearch.com)  
> [http://elasticsearch.com](http://elasticsearch.com)_  
> [david.pilato@elasticsearch.com](mailto:david.pilato@elasticsearch.com)  
> @dadoonet [https://twitter.com/dadoonet](https://twitter.com/dadoonet) | @elasticsearchfr  
> [https://twitter.com/elasticsearchfr](https://twitter.com/elasticsearchfr) | @scrutmydocs  
> [http://twitter.com/scrutmydocs](http://twitter.com/scrutmydocs)  
> [https://twitter.com/scrutmydocs](https://twitter.com/scrutmydocs)
> 
> Le 19 septembre 2014 à 05:31:38, Michael Chen ([mechiland@gmail.com](mailto:mechiland@gmail.com)) a  
> écrit:
> 
> Hi,
> 
> We have a system very much like Google Forms, which allow users to design  
> their own forms with various fields (single line text, paragraph, number,  
> address etc, you can imagine that.) Without any doubt, it's running on top  
> of MongoDB. Now it has 120K forms with nearly 10 million entries.
> 
> Recently we found a performance bottleneck on the query. After we have  
> done every possible performance tuning on mongoDB side, we decide to index  
> the form entries into Elasticsearch. And there is a trouble:
> 
> Given there is a Form A, has field\_1 as string type, field\_2 as number,  
> the data entry might look like: { field\_1: "hello", field\_2: 100}
> 
> Form B could be field\_1 as number, field\_2 as number, the date entry will  
> look like { field\_1: 100, field\_2: "hello form"}
> 
> We have successfully create an index "entries" in ES, and can index the  
> first entry successfully. But the second one failed for an obvious reason:  
> type mismatch.
> 
> I am not sure how to deal with this problem. I definitely don't want to  
> create 120K indices for every single form. And I am not sure it's doable to  
> write custom transform script to change the index type identical across all  
> entries.
> 
> ## Any suggestion? Much appreciate any response.
> 
> 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/4a6d47d7-ae0e-44f5-bd3a-756ea94e3899%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/4a6d47d7-ae0e-44f5-bd3a-756ea94e3899%40googlegroups.com)  
> [https://groups.google.com/d/msgid/elasticsearch/4a6d47d7-ae0e-44f5-bd3a-756ea94e3899%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/4a6d47d7-ae0e-44f5-bd3a-756ea94e3899%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/etPan.541bc9fd.66334873.18d1%40MacBook-Air-de-David.local](https://groups.google.com/d/msgid/elasticsearch/etPan.541bc9fd.66334873.18d1%40MacBook-Air-de-David.local)  
> [https://groups.google.com/d/msgid/elasticsearch/etPan.541bc9fd.66334873.18d1%40MacBook-Air-de-David.local?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/etPan.541bc9fd.66334873.18d1%40MacBook-Air-de-David.local?utm_medium=email&utm_source=footer)  
> .
> 
> For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).

## -- Michael Chen

Blog: [http://michael.nona.name](http://michael.nona.name)  
GTalk/Twitter/Facebook/Yahoo/Skype: mechiland

--  
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/CAAzF%2BWj0jFb642x\_hgko%2Bs9mfM3MCNqeS5Jr7TxtWq5XXAPvXg%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAAzF%2BWj0jFb642x_hgko%2Bs9mfM3MCNqeS5Jr7TxtWq5XXAPvXg%40mail.gmail.com).  
For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).

---

<div class="post-metadata">

**Author:** ![dadoonet](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/dadoonet/32/137187_2.png) [@dadoonet](https://discuss.elastic.co/u/dadoonet)\
**Post date:** [September 19, 2014, 9:50am UTC](https://discuss.elastic.co/t/index-design-for-very-dynamic-form-fields/19877/4 "2014-09-19T09:50:06Z")

</div>

I don't get it.

If field\_1.country is a String why you can not aggregate on it?

--  
David Pilato | Technical Advocate | [elasticsearch.com](http://elasticsearch.com)  
[david.pilato@elasticsearch.com](mailto:david.pilato@elasticsearch.com)  
@dadoonet | @elasticsearchfr | @scrutmydocs

Le 19 septembre 2014 à 08:27:19, Michael Chen ([mechiland@gmail.com](mailto:mechiland@gmail.com)) a écrit:

Thanks David. Based on the system behavior, having all type as string is fine for queries. But for the aggregation level it might be trouble. For example a type of address is a complex JSON object:

{ field\_1: { country: "US", province: "CA", city: "New York", address: "Street Address"} }

If we transform this type into any form of string, and trying to aggregate based on country/state, it will be VERY hard even not possible.

On Fri, Sep 19, 2014 at 2:15 PM, David Pilato [david@pilato.fr](mailto:david@pilato.fr) wrote:  
You could have one type per form although the cluster state will be very big.  
But you should test that option.

Or if you don't really search for numbers as numbers (I mean with Range queries/filters), you could force each field to be a String and do the transformation at a client level.

My 2 cents

--  
David Pilato | Technical Advocate | [elasticsearch.com](http://elasticsearch.com)  
[david.pilato@elasticsearch.com](mailto:david.pilato@elasticsearch.com)  
@dadoonet | @elasticsearchfr | @scrutmydocs

Le 19 septembre 2014 à 05:31:38, Michael Chen ([mechiland@gmail.com](mailto:mechiland@gmail.com)) a écrit:

Hi,

We have a system very much like Google Forms, which allow users to design their own forms with various fields (single line text, paragraph, number, address etc, you can imagine that.) Without any doubt, it's running on top of MongoDB. Now it has 120K forms with nearly 10 million entries.

Recently we found a performance bottleneck on the query. After we have done every possible performance tuning on mongoDB side, we decide to index the form entries into elastic search. And there is a trouble:

Given there is a Form A, has field\_1 as string type, field\_2 as number, the data entry might look like: { field\_1: "hello", field\_2: 100}

Form B could be field\_1 as number, field\_2 as number, the date entry will look like { field\_1: 100, field\_2: "hello form"}

We have successfully create an index "entries" in ES, and can index the first entry successfully. But the second one failed for an obvious reason: type mismatch.

I am not sure how to deal with this problem. I definitely don't want to create 120K indices for every single form. And I am not sure it's doable to write custom transform script to change the index type identical across all entries.

## Any suggestion? Much appreciate any response.

## 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/4a6d47d7-ae0e-44f5-bd3a-756ea94e3899%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/4a6d47d7-ae0e-44f5-bd3a-756ea94e3899%40googlegroups.com). 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/etPan.541bc9fd.66334873.18d1%40MacBook-Air-de-David.local](https://groups.google.com/d/msgid/elasticsearch/etPan.541bc9fd.66334873.18d1%40MacBook-Air-de-David.local).

For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).

## -- Michael Chen

## Blog: [http://michael.nona.name](http://michael.nona.name) GTalk/Twitter/Facebook/Yahoo/Skype: mechiland

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/CAAzF%2BWj0jFb642x\_hgko%2Bs9mfM3MCNqeS5Jr7TxtWq5XXAPvXg%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAAzF%2BWj0jFb642x_hgko%2Bs9mfM3MCNqeS5Jr7TxtWq5XXAPvXg%40mail.gmail.com).  
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/etPan.541bfc4e.1f16e9e8.18d1%40MacBook-Air-de-David.local](https://groups.google.com/d/msgid/elasticsearch/etPan.541bfc4e.1f16e9e8.18d1%40MacBook-Air-de-David.local).  
For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).

---

<div class="post-metadata">

**Author:** ![Michael\_Chen](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/michael_chen/32/1273_2.png) [@Michael\_Chen](https://discuss.elastic.co/u/Michael_Chen)\
**Post date:** [September 19, 2014, 10:01am UTC](https://discuss.elastic.co/t/index-design-for-very-dynamic-form-fields/19877/5 "2014-09-19T10:01:16Z")

</div>

We cannot guarantee that field\_1 is always address. In Form 1, field\_1  
might be address while in another form it might be string or number  
whatever. Thinking about designing the storage for Google Forms and it's  
data entries.

Re "you could force each field to be a String and do the transformation at  
a client level."

Forcing means serialize all data into a string right? In the example JSON  
mentioned in previous email, it will transformed to something like

{ field\_1: "{country: "US", province: "CA", city: "New York",  
address: "Street Address"}" }

Then not able to do the aggregation.

On Fri, Sep 19, 2014 at 5:50 PM, David Pilato [david@pilato.fr](mailto:david@pilato.fr) wrote:

> I don't get it.
> 
> If field\_1.country is a String why you can not aggregate on it?
> 
> --  
> _David Pilato_ | Technical Advocate | _[elasticsearch.com](http://elasticsearch.com)  
> [http://elasticsearch.com](http://elasticsearch.com)_  
> [david.pilato@elasticsearch.com](mailto:david.pilato@elasticsearch.com)  
> @dadoonet [https://twitter.com/dadoonet](https://twitter.com/dadoonet) | @elasticsearchfr  
> [https://twitter.com/elasticsearchfr](https://twitter.com/elasticsearchfr) | @scrutmydocs  
> [http://twitter.com/scrutmydocs](http://twitter.com/scrutmydocs)  
> [https://twitter.com/scrutmydocs](https://twitter.com/scrutmydocs)
> 
> Le 19 septembre 2014 à 08:27:19, Michael Chen ([mechiland@gmail.com](mailto:mechiland@gmail.com)) a  
> écrit:
> 
> Thanks David. Based on the system behavior, having all type as string is  
> fine for queries. But for the aggregation level it might be trouble. For  
> example a type of address is a complex JSON object:
> 
> { field\_1: { country: "US", province: "CA", city: "New York", address:  
> "Street Address"} }
> 
> If we transform this type into any form of string, and trying to aggregate  
> based on country/state, it will be VERY hard even not possible.
> 
> On Fri, Sep 19, 2014 at 2:15 PM, David Pilato [david@pilato.fr](mailto:david@pilato.fr) wrote:
> 
> > You could have one type per form although the cluster state will be  
> > very big.  
> > But you should test that option.
> > 
> > Or if you don't really search for numbers as numbers (I mean with Range  
> > queries/filters), you could force each field to be a String and do the  
> > transformation at a client level.
> > 
> > My 2 cents
> > 
> > --
> > 
> > - David Pilato\* | Technical Advocate | _[elasticsearch.com](http://elasticsearch.com)  
> > [http://elasticsearch.com](http://elasticsearch.com)_  
> > [david.pilato@elasticsearch.com](mailto:david.pilato@elasticsearch.com)  
> > @dadoonet [https://twitter.com/dadoonet](https://twitter.com/dadoonet) | @elasticsearchfr  
> > [https://twitter.com/elasticsearchfr](https://twitter.com/elasticsearchfr) | @scrutmydocs  
> > [http://twitter.com/scrutmydocs](http://twitter.com/scrutmydocs)  
> > [https://twitter.com/scrutmydocs](https://twitter.com/scrutmydocs)
> > 
> > Le 19 septembre 2014 à 05:31:38, Michael Chen ([mechiland@gmail.com](mailto:mechiland@gmail.com)) a  
> > écrit:
> > 
> > Hi,
> > 
> > We have a system very much like Google Forms, which allow users to design  
> > their own forms with various fields (single line text, paragraph, number,  
> > address etc, you can imagine that.) Without any doubt, it's running on top  
> > of MongoDB. Now it has 120K forms with nearly 10 million entries.
> > 
> > Recently we found a performance bottleneck on the query. After we have  
> > done every possible performance tuning on mongoDB side, we decide to index  
> > the form entries into Elasticsearch. And there is a trouble:
> > 
> > Given there is a Form A, has field\_1 as string type, field\_2 as number,  
> > the data entry might look like: { field\_1: "hello", field\_2: 100}
> > 
> > Form B could be field\_1 as number, field\_2 as number, the date entry will  
> > look like { field\_1: 100, field\_2: "hello form"}
> > 
> > We have successfully create an index "entries" in ES, and can index the  
> > first entry successfully. But the second one failed for an obvious reason:  
> > type mismatch.
> > 
> > I am not sure how to deal with this problem. I definitely don't want to  
> > create 120K indices for every single form. And I am not sure it's doable to  
> > write custom transform script to change the index type identical across all  
> > entries.
> > 
> > ## Any suggestion? Much appreciate any response.
> > 
> > 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/4a6d47d7-ae0e-44f5-bd3a-756ea94e3899%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/4a6d47d7-ae0e-44f5-bd3a-756ea94e3899%40googlegroups.com)  
> > [https://groups.google.com/d/msgid/elasticsearch/4a6d47d7-ae0e-44f5-bd3a-756ea94e3899%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/4a6d47d7-ae0e-44f5-bd3a-756ea94e3899%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/etPan.541bc9fd.66334873.18d1%40MacBook-Air-de-David.local](https://groups.google.com/d/msgid/elasticsearch/etPan.541bc9fd.66334873.18d1%40MacBook-Air-de-David.local)  
> > [https://groups.google.com/d/msgid/elasticsearch/etPan.541bc9fd.66334873.18d1%40MacBook-Air-de-David.local?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/etPan.541bc9fd.66334873.18d1%40MacBook-Air-de-David.local?utm_medium=email&utm_source=footer).
> > 
> > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).
> 
> ## -- Michael Chen
> 
> ## Blog: [http://michael.nona.name](http://michael.nona.name) GTalk/Twitter/Facebook/Yahoo/Skype: mechiland
> 
> 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/CAAzF%2BWj0jFb642x\_hgko%2Bs9mfM3MCNqeS5Jr7TxtWq5XXAPvXg%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAAzF%2BWj0jFb642x_hgko%2Bs9mfM3MCNqeS5Jr7TxtWq5XXAPvXg%40mail.gmail.com)  
> [https://groups.google.com/d/msgid/elasticsearch/CAAzF%2BWj0jFb642x\_hgko%2Bs9mfM3MCNqeS5Jr7TxtWq5XXAPvXg%40mail.gmail.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/CAAzF%2BWj0jFb642x_hgko%2Bs9mfM3MCNqeS5Jr7TxtWq5XXAPvXg%40mail.gmail.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/etPan.541bfc4e.1f16e9e8.18d1%40MacBook-Air-de-David.local](https://groups.google.com/d/msgid/elasticsearch/etPan.541bfc4e.1f16e9e8.18d1%40MacBook-Air-de-David.local)  
> [https://groups.google.com/d/msgid/elasticsearch/etPan.541bfc4e.1f16e9e8.18d1%40MacBook-Air-de-David.local?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/etPan.541bfc4e.1f16e9e8.18d1%40MacBook-Air-de-David.local?utm_medium=email&utm_source=footer)  
> .
> 
> For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).

## -- Michael Chen

Blog: [http://michael.nona.name](http://michael.nona.name)  
GTalk/Twitter/Facebook/Yahoo/Skype: mechiland

--  
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/CAAzF%2BWjYweFv5RtR5diezwE4pfuCEd1%2BGKf%3DpH-JfUMmSjeKrw%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAAzF%2BWjYweFv5RtR5diezwE4pfuCEd1%2BGKf%3DpH-JfUMmSjeKrw%40mail.gmail.com).  
For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).

---

<div class="post-metadata">

**Author:** ![Michael\_Chen](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/michael_chen/32/1273_2.png) [@Michael\_Chen](https://discuss.elastic.co/u/Michael_Chen)\
**Post date:** [September 19, 2014, 10:21am UTC](https://discuss.elastic.co/t/index-design-for-very-dynamic-form-fields/19877/6 "2014-09-19T10:21:03Z")

</div>

Let me make the question more clear. The challenge we have now, is how to  
index a EAV[1] model database.

Let's take Google Form as an example. Every user can create a form. They  
can choose from various field types including text, number, choice etc.  
They construct one form like this:

Form 1: a survery

- field\_1: type=text
- field\_2: type=number
- field\_3: type=choice

And people submit data entry into this form with data like:

{  
field\_1: "hello",  
field\_2: 20,  
field\_3: ["red"]  
}

And you can imagine that all this data entries saved into one single mongo  
collection "entries".

Well, the second user might create another form like this:

Form 2: a questionare

- field\_1: type=number
- field\_2: type=text
- field\_3: type=number
- field\_4: type=text

the data submission might like this:

{  
field\_1: 100,  
field\_2: "hello questionare",  
field\_3: 20,  
field\_4: "this is my answer"  
}

Indexing the second data entry while we have the first one in ES will throw  
NumberFormatException because field\_2 was guessed by ES it should be  
number. Then the transforming all value into string make sense but...

Any thoughts?

[1]EAV: Entity–attribute–value model,

> **[Entity–attribute–value model](https://en.wikipedia.org/wiki/Entity%E2%80%93attribute%E2%80%93value_model)**
>
> An entity–attribute–value model (EAV) is a data model optimized for the space-efficient storage of sparse—or ad-hoc—property or data values, intended for situations where runtime usage patterns are arbitrary, subject to user variation, or otherwise unforeseeable using a fixed design. The use-case targets applications which offer a large or rich system of defined property types, which are in turn appropriate to a wide set of entities, but where typically only a small, specific selection of these ...

On Fri, Sep 19, 2014 at 6:01 PM, Michael Chen [mechiland@gmail.com](mailto:mechiland@gmail.com) wrote:

> We cannot guarantee that field\_1 is always address. In Form 1, field\_1  
> might be address while in another form it might be string or number  
> whatever. Thinking about designing the storage for Google Forms and it's  
> data entries.
> 
> Re "you could force each field to be a String and do the transformation  
> at a client level."
> 
> Forcing means serialize all data into a string right? In the example JSON  
> mentioned in previous email, it will transformed to something like
> 
> { field\_1: "{country: "US", province: "CA", city: "New York",  
> address: "Street Address"}" }
> 
> Then not able to do the aggregation.
> 
> On Fri, Sep 19, 2014 at 5:50 PM, David Pilato [david@pilato.fr](mailto:david@pilato.fr) wrote:
> 
> > I don't get it.
> > 
> > If field\_1.country is a String why you can not aggregate on it?
> > 
> > --  
> > _David Pilato_ | Technical Advocate | _[elasticsearch.com](http://elasticsearch.com)  
> > [http://elasticsearch.com](http://elasticsearch.com)_  
> > [david.pilato@elasticsearch.com](mailto:david.pilato@elasticsearch.com)  
> > @dadoonet [https://twitter.com/dadoonet](https://twitter.com/dadoonet) | @elasticsearchfr  
> > [https://twitter.com/elasticsearchfr](https://twitter.com/elasticsearchfr) | @scrutmydocs  
> > [http://twitter.com/scrutmydocs](http://twitter.com/scrutmydocs)  
> > [https://twitter.com/scrutmydocs](https://twitter.com/scrutmydocs)
> > 
> > Le 19 septembre 2014 à 08:27:19, Michael Chen ([mechiland@gmail.com](mailto:mechiland@gmail.com)) a  
> > écrit:
> > 
> > Thanks David. Based on the system behavior, having all type as string is  
> > fine for queries. But for the aggregation level it might be trouble. For  
> > example a type of address is a complex JSON object:
> > 
> > { field\_1: { country: "US", province: "CA", city: "New York", address:  
> > "Street Address"} }
> > 
> > If we transform this type into any form of string, and trying to  
> > aggregate based on country/state, it will be VERY hard even not possible.
> > 
> > On Fri, Sep 19, 2014 at 2:15 PM, David Pilato [david@pilato.fr](mailto:david@pilato.fr) wrote:
> > 
> > > You could have one type per form although the cluster state will be  
> > > very big.  
> > > But you should test that option.
> > > 
> > > Or if you don't really search for numbers as numbers (I mean with Range  
> > > queries/filters), you could force each field to be a String and do the  
> > > transformation at a client level.
> > > 
> > > My 2 cents
> > > 
> > > --
> > > 
> > > - David Pilato\* | Technical Advocate | _[elasticsearch.com](http://elasticsearch.com)  
> > > [http://elasticsearch.com](http://elasticsearch.com)_  
> > > [david.pilato@elasticsearch.com](mailto:david.pilato@elasticsearch.com)  
> > > @dadoonet [https://twitter.com/dadoonet](https://twitter.com/dadoonet) | @elasticsearchfr  
> > > [https://twitter.com/elasticsearchfr](https://twitter.com/elasticsearchfr) | @scrutmydocs  
> > > [http://twitter.com/scrutmydocs](http://twitter.com/scrutmydocs)  
> > > [https://twitter.com/scrutmydocs](https://twitter.com/scrutmydocs)
> > > 
> > > Le 19 septembre 2014 à 05:31:38, Michael Chen ([mechiland@gmail.com](mailto:mechiland@gmail.com)) a  
> > > écrit:
> > > 
> > > Hi,
> > > 
> > > We have a system very much like Google Forms, which allow users to  
> > > design their own forms with various fields (single line text, paragraph,  
> > > number, address etc, you can imagine that.) Without any doubt, it's running  
> > > on top of MongoDB. Now it has 120K forms with nearly 10 million entries.
> > > 
> > > Recently we found a performance bottleneck on the query. After we have  
> > > done every possible performance tuning on mongoDB side, we decide to index  
> > > the form entries into Elasticsearch. And there is a trouble:
> > > 
> > > Given there is a Form A, has field\_1 as string type, field\_2 as number,  
> > > the data entry might look like: { field\_1: "hello", field\_2: 100}
> > > 
> > > Form B could be field\_1 as number, field\_2 as number, the date entry  
> > > will look like { field\_1: 100, field\_2: "hello form"}
> > > 
> > > We have successfully create an index "entries" in ES, and can index the  
> > > first entry successfully. But the second one failed for an obvious reason:  
> > > type mismatch.
> > > 
> > > I am not sure how to deal with this problem. I definitely don't want to  
> > > create 120K indices for every single form. And I am not sure it's doable to  
> > > write custom transform script to change the index type identical across all  
> > > entries.
> > > 
> > > ## Any suggestion? Much appreciate any response.
> > > 
> > > 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/4a6d47d7-ae0e-44f5-bd3a-756ea94e3899%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/4a6d47d7-ae0e-44f5-bd3a-756ea94e3899%40googlegroups.com)  
> > > [https://groups.google.com/d/msgid/elasticsearch/4a6d47d7-ae0e-44f5-bd3a-756ea94e3899%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/4a6d47d7-ae0e-44f5-bd3a-756ea94e3899%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/etPan.541bc9fd.66334873.18d1%40MacBook-Air-de-David.local](https://groups.google.com/d/msgid/elasticsearch/etPan.541bc9fd.66334873.18d1%40MacBook-Air-de-David.local)  
> > > [https://groups.google.com/d/msgid/elasticsearch/etPan.541bc9fd.66334873.18d1%40MacBook-Air-de-David.local?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/etPan.541bc9fd.66334873.18d1%40MacBook-Air-de-David.local?utm_medium=email&utm_source=footer).
> > > 
> > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).
> > 
> > ## -- Michael Chen
> > 
> > ## Blog: [http://michael.nona.name](http://michael.nona.name) GTalk/Twitter/Facebook/Yahoo/Skype: mechiland
> > 
> > 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/CAAzF%2BWj0jFb642x\_hgko%2Bs9mfM3MCNqeS5Jr7TxtWq5XXAPvXg%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAAzF%2BWj0jFb642x_hgko%2Bs9mfM3MCNqeS5Jr7TxtWq5XXAPvXg%40mail.gmail.com)  
> > [https://groups.google.com/d/msgid/elasticsearch/CAAzF%2BWj0jFb642x\_hgko%2Bs9mfM3MCNqeS5Jr7TxtWq5XXAPvXg%40mail.gmail.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/CAAzF%2BWj0jFb642x_hgko%2Bs9mfM3MCNqeS5Jr7TxtWq5XXAPvXg%40mail.gmail.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/etPan.541bfc4e.1f16e9e8.18d1%40MacBook-Air-de-David.local](https://groups.google.com/d/msgid/elasticsearch/etPan.541bfc4e.1f16e9e8.18d1%40MacBook-Air-de-David.local)  
> > [https://groups.google.com/d/msgid/elasticsearch/etPan.541bfc4e.1f16e9e8.18d1%40MacBook-Air-de-David.local?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/etPan.541bfc4e.1f16e9e8.18d1%40MacBook-Air-de-David.local?utm_medium=email&utm_source=footer)  
> > .
> > 
> > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).
> 
> ## -- Michael Chen
> 
> Blog: [http://michael.nona.name](http://michael.nona.name)  
> GTalk/Twitter/Facebook/Yahoo/Skype: mechiland

## -- Michael Chen

Blog: [http://michael.nona.name](http://michael.nona.name)  
GTalk/Twitter/Facebook/Yahoo/Skype: mechiland

--  
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/CAAzF%2BWiB3Z%3D\_wtzrqtqRObPLucp\_SULNjYeOVPbFs8pb-tPETg%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAAzF%2BWiB3Z%3D_wtzrqtqRObPLucp_SULNjYeOVPbFs8pb-tPETg%40mail.gmail.com).  
For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).

---

<div class="post-metadata">

**Author:** ![scamire](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/scamire/32/1077_2.png) [@scamire](https://discuss.elastic.co/u/scamire)\
**Post date:** [November 13, 2014, 4:22pm UTC](https://discuss.elastic.co/t/index-design-for-very-dynamic-form-fields/19877/7 "2014-11-13T16:22:52Z")

</div>

Michael, did you ever solve this? I'm about to encounter this very same  
issue and I'm looking into what solutions are available to me.

On Friday, September 19, 2014 6:21:32 AM UTC-4, Michael Chen wrote:

> Let me make the question more clear. The challenge we have now, is how to  
> index a EAV[1] model database.
> 
> Let's take Google Form as an example. Every user can create a form. They  
> can choose from various field types including text, number, choice etc.  
> They construct one form like this:
> 
> Form 1: a survery
> 
> - field\_1: type=text
> - field\_2: type=number
> - field\_3: type=choice
> 
> And people submit data entry into this form with data like:
> 
> {  
> field\_1: "hello",  
> field\_2: 20,  
> field\_3: ["red"]  
> }
> 
> And you can imagine that all this data entries saved into one single mongo  
> collection "entries".
> 
> Well, the second user might create another form like this:
> 
> Form 2: a questionare
> 
> - field\_1: type=number
> - field\_2: type=text
> - field\_3: type=number
> - field\_4: type=text
> 
> the data submission might like this:
> 
> {  
> field\_1: 100,  
> field\_2: "hello questionare",  
> field\_3: 20,  
> field\_4: "this is my answer"  
> }
> 
> Indexing the second data entry while we have the first one in ES will  
> throw NumberFormatException because field\_2 was guessed by ES it should be  
> number. Then the transforming all value into string make sense but...
> 
> Any thoughts?
> 
> [1]EAV: Entity–attribute–value model,  
> [Entity–attribute–value model - Wikipedia](http://en.wikipedia.org/wiki/Entity%E2%80%93attribute%E2%80%93value_model)
> 
> On Fri, Sep 19, 2014 at 6:01 PM, Michael Chen \<[mech...@gmail.com](mailto:mech...@gmail.com)  
> \<javascript:\>\> wrote:
> 
> > We cannot guarantee that field\_1 is always address. In Form 1, field\_1  
> > might be address while in another form it might be string or number  
> > whatever. Thinking about designing the storage for Google Forms and it's  
> > data entries.
> > 
> > Re "you could force each field to be a String and do the transformation  
> > at a client level."
> > 
> > Forcing means serialize all data into a string right? In the example JSON  
> > mentioned in previous email, it will transformed to something like
> > 
> > { field\_1: "{country: "US", province: "CA", city: "New York",  
> > address: "Street Address"}" }
> > 
> > Then not able to do the aggregation.
> > 
> > On Fri, Sep 19, 2014 at 5:50 PM, David Pilato \<[da...@pilato.fr](mailto:da...@pilato.fr)  
> > \<javascript:\>\> wrote:
> > 
> > > I don't get it.
> > > 
> > > If field\_1.country is a String why you can not aggregate on it?
> > > 
> > > --  
> > > _David Pilato_ | Technical Advocate | _[elasticsearch.com](http://elasticsearch.com)  
> > > [http://elasticsearch.com](http://elasticsearch.com)_  
> > > [david....@elasticsearch.com](mailto:david....@elasticsearch.com) \<javascript:\>  
> > > @dadoonet [https://twitter.com/dadoonet](https://twitter.com/dadoonet) | @elasticsearchfr  
> > > [https://twitter.com/elasticsearchfr](https://twitter.com/elasticsearchfr) | @scrutmydocs  
> > > [http://twitter.com/scrutmydocs](http://twitter.com/scrutmydocs)  
> > > [https://twitter.com/scrutmydocs](https://twitter.com/scrutmydocs)
> > > 
> > > Le 19 septembre 2014 à 08:27:19, Michael Chen ([mech...@gmail.com](mailto:mech...@gmail.com)  
> > > \<javascript:\>) a écrit:
> > > 
> > > Thanks David. Based on the system behavior, having all type as string is  
> > > fine for queries. But for the aggregation level it might be trouble. For  
> > > example a type of address is a complex JSON object:
> > > 
> > > { field\_1: { country: "US", province: "CA", city: "New York", address:  
> > > "Street Address"} }
> > > 
> > > If we transform this type into any form of string, and trying to  
> > > aggregate based on country/state, it will be VERY hard even not possible.
> > > 
> > > On Fri, Sep 19, 2014 at 2:15 PM, David Pilato \<[da...@pilato.fr](mailto:da...@pilato.fr)  
> > > \<javascript:\>\> wrote:
> > > 
> > > > You could have one type per form although the cluster state will be  
> > > > very big.  
> > > > But you should test that option.
> > > > 
> > > > Or if you don't really search for numbers as numbers (I mean with  
> > > > Range queries/filters), you could force each field to be a String and do  
> > > > the transformation at a client level.
> > > > 
> > > > My 2 cents
> > > > 
> > > > --
> > > > 
> > > > - David Pilato\* | Technical Advocate | _[elasticsearch.com](http://elasticsearch.com)  
> > > > [http://elasticsearch.com](http://elasticsearch.com)_  
> > > > [david....@elasticsearch.com](mailto:david....@elasticsearch.com) \<javascript:\>  
> > > > @dadoonet [https://twitter.com/dadoonet](https://twitter.com/dadoonet) | @elasticsearchfr  
> > > > [https://twitter.com/elasticsearchfr](https://twitter.com/elasticsearchfr) | @scrutmydocs  
> > > > [http://twitter.com/scrutmydocs](http://twitter.com/scrutmydocs)  
> > > > [https://twitter.com/scrutmydocs](https://twitter.com/scrutmydocs)
> > > > 
> > > > Le 19 septembre 2014 à 05:31:38, Michael Chen ([mech...@gmail.com](mailto:mech...@gmail.com)  
> > > > \<javascript:\>) a écrit:
> > > > 
> > > > Hi,
> > > > 
> > > > We have a system very much like Google Forms, which allow users to  
> > > > design their own forms with various fields (single line text, paragraph,  
> > > > number, address etc, you can imagine that.) Without any doubt, it's running  
> > > > on top of MongoDB. Now it has 120K forms with nearly 10 million entries.
> > > > 
> > > > Recently we found a performance bottleneck on the query. After we have  
> > > > done every possible performance tuning on mongoDB side, we decide to index  
> > > > the form entries into Elasticsearch. And there is a trouble:
> > > > 
> > > > Given there is a Form A, has field\_1 as string type, field\_2 as number,  
> > > > the data entry might look like: { field\_1: "hello", field\_2: 100}
> > > > 
> > > > Form B could be field\_1 as number, field\_2 as number, the date entry  
> > > > will look like { field\_1: 100, field\_2: "hello form"}
> > > > 
> > > > We have successfully create an index "entries" in ES, and can index the  
> > > > first entry successfully. But the second one failed for an obvious reason:  
> > > > type mismatch.
> > > > 
> > > > I am not sure how to deal with this problem. I definitely don't want to  
> > > > create 120K indices for every single form. And I am not sure it's doable to  
> > > > write custom transform script to change the index type identical across all  
> > > > entries.
> > > > 
> > > > ## Any suggestion? Much appreciate any response.
> > > > 
> > > > 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/4a6d47d7-ae0e-44f5-bd3a-756ea94e3899%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/4a6d47d7-ae0e-44f5-bd3a-756ea94e3899%40googlegroups.com)  
> > > > [https://groups.google.com/d/msgid/elasticsearch/4a6d47d7-ae0e-44f5-bd3a-756ea94e3899%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/4a6d47d7-ae0e-44f5-bd3a-756ea94e3899%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 [elasticsearc...@googlegroups.com](mailto:elasticsearc...@googlegroups.com) \<javascript:\>.  
> > > > To view this discussion on the web visit  
> > > > [https://groups.google.com/d/msgid/elasticsearch/etPan.541bc9fd.66334873.18d1%40MacBook-Air-de-David.local](https://groups.google.com/d/msgid/elasticsearch/etPan.541bc9fd.66334873.18d1%40MacBook-Air-de-David.local)  
> > > > [https://groups.google.com/d/msgid/elasticsearch/etPan.541bc9fd.66334873.18d1%40MacBook-Air-de-David.local?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/etPan.541bc9fd.66334873.18d1%40MacBook-Air-de-David.local?utm_medium=email&utm_source=footer).
> > > > 
> > > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).
> > > 
> > > ## -- Michael Chen
> > > 
> > > ## Blog: [http://michael.nona.name](http://michael.nona.name) GTalk/Twitter/Facebook/Yahoo/Skype: mechiland
> > > 
> > > 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/CAAzF%2BWj0jFb642x\_hgko%2Bs9mfM3MCNqeS5Jr7TxtWq5XXAPvXg%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAAzF%2BWj0jFb642x_hgko%2Bs9mfM3MCNqeS5Jr7TxtWq5XXAPvXg%40mail.gmail.com)  
> > > [https://groups.google.com/d/msgid/elasticsearch/CAAzF%2BWj0jFb642x\_hgko%2Bs9mfM3MCNqeS5Jr7TxtWq5XXAPvXg%40mail.gmail.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/CAAzF%2BWj0jFb642x_hgko%2Bs9mfM3MCNqeS5Jr7TxtWq5XXAPvXg%40mail.gmail.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 [elasticsearc...@googlegroups.com](mailto:elasticsearc...@googlegroups.com) \<javascript:\>.  
> > > To view this discussion on the web visit  
> > > [https://groups.google.com/d/msgid/elasticsearch/etPan.541bfc4e.1f16e9e8.18d1%40MacBook-Air-de-David.local](https://groups.google.com/d/msgid/elasticsearch/etPan.541bfc4e.1f16e9e8.18d1%40MacBook-Air-de-David.local)  
> > > [https://groups.google.com/d/msgid/elasticsearch/etPan.541bfc4e.1f16e9e8.18d1%40MacBook-Air-de-David.local?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/etPan.541bfc4e.1f16e9e8.18d1%40MacBook-Air-de-David.local?utm_medium=email&utm_source=footer)  
> > > .
> > > 
> > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).
> > 
> > ## -- Michael Chen
> > 
> > Blog: [http://michael.nona.name](http://michael.nona.name)  
> > GTalk/Twitter/Facebook/Yahoo/Skype: mechiland
> 
> ## -- Michael Chen
> 
> Blog: [http://michael.nona.name](http://michael.nona.name)  
> GTalk/Twitter/Facebook/Yahoo/Skype: mechiland

--  
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/0c7013de-7549-4717-a83c-17cc7b496f16%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/0c7013de-7549-4717-a83c-17cc7b496f16%40googlegroups.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:50am UTC](https://discuss.elastic.co/t/index-design-for-very-dynamic-form-fields/19877/8 "2017-07-06T00:50:12Z")

</div>