Should mappings keep using CopyOnWriteHashMap?

[jpountz]

CopyOnWriteHashMap was introduced for mappings at a time when some Logging use-cases would introduce many (as in several thousands) fields dynamically and applying mapping updates would be the bottleneck due to the time it would take to apply mapping updates.

However several things changed since then:

• Mapping updates are now applied on the master node before indexing the document, which makes dynamic mapping updates slow by nature (mapping updates used to be performed locally first, and then asynchronously propagated to the master node, which would cause big issues when different shards of the same index would make different decisions).
• We introduced a soft limit of 1,000 fields per index.
• ECS introduced standardization of field names, making it less likely to have different documents use different field names for the same information.

This CopyOnWriteHashMap optimizes for mapping updates to the detriment of lookups, which can be slower than with regular hash maps, especially in case of hash collisions. We should look into moving back to regular maps that we would fully copy upon mapping updates.

[elasticmachine]

Pinging @elastic/es-search (Team:Search)

[dakrone]

@jpountz any ideas for the best way to test something like this performance-wise? Do we have a Rally track that tests a large number of mapping updates?

[jpountz]

We don't. This is in-part due to the fact that we moved away from folding everything into the same index / data stream. While in the past you could have 10s of different data types that would end up in the same index and you would get dynamic mapping updates everytime a new type of data would be indexed for the first time, nowadays dynamic mappings are usually set on the first document that gets indexed and then almost never get modified.

I'd suggest running an artificial benchmark that triggers the worst-case scenario, such as indexing 1,000 documents that all introduce a new field, to make sure that index requests do not become absurdly slow.

[romseygeek]

We no longer use CopyOnWriteHashMap in mappers after #81449. In fact we have only one place in the codebase that uses it now, in AutoFollowCoordinator and I'm not sure that it's necessary there either so we may be able to remove it entirely.

[romseygeek]

Fixed by #83040