Yeah, dynamic:false. That'll let you manually configure all the fields that
you want indexed and the other fields are just stored in the source. They
can be fetched but that is it.
Letting users create whatever fields they want is problematic for two
reason:
- Type clashes. You can resolve that by naming fields after their type so
they done clash. Like phone_number_string. Sure, it is lame but you are
working around inconsistent user data. - Too many fields and it's corallary, sparse fields. This is trouble. Each
field has an overhead in the index and in the mapping. Adding a field is a
cluster state change event too. Sparse fields don't store well either in
doc values.
Both of these things you can work around but they are certainly "advanced"
use cases.