We recently have had a thread discussing the fact that in ElasticSearch 6.0 multiple types per index would not be allowed anymore. The thread was closed but without a real answer whether this will effectively be implemented or not. Since this impacts so many users I think we have the right to know upfront if this has been firmly decided. I'm sure this would cause major headaches and force major rewrites of existing software.
I still hope this "feature" will not see the light of day. In case it does I have one request: make it invisible for the developer. This could be done by not letting the developer work with physical indices directly anymore but a sort of virtual compound index (= a combination of indices each containing one type) and let Elasticsearch do the heavy lifting of accessing the correct physical index to store and retrieve data. That way nothing changes for a developer perspective but underlyingly a single index per type is used. Maybe this is the best of both worlds?
The concept of physical indices and virtual compound indices are already implemented by index aliases mechanism.
Not sure why there must a "major rewrite"? All fields in an index must already be non-conflicting, no matter how many mappings are used.
For example, from the early days of Elasticsearch I was convinced by the "Book/CD" example, that field mappings must be non-conflicting and additive, for index types should be useful for "search views" on an index. This kind of separation is already controlled by my application, e.g. by a search filter. Search filters are more dynamic than an index type. So I decided to implement custom search filter fields, and ignored the index type mechanism.
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.