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
david.pilato@elasticsearch.com
@dadoonet | @elasticsearchfr | @scrutmydocs
Le 19 septembre 2014 à 08:27:19, Michael Chen (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 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
david.pilato@elasticsearch.com
@dadoonet | @elasticsearchfr | @scrutmydocs
Le 19 septembre 2014 à 05:31:38, Michael Chen (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.
To view this discussion on the web visit 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.
--
Michael Chen
Blog: 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.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/CAAzF%2BWj0jFb642x_hgko%2Bs9mfM3MCNqeS5Jr7TxtWq5XXAPvXg%40mail.gmail.com.
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 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.
For more options, visit https://groups.google.com/d/optout.