[SO Migration] increasing performance by getting rid of the temporary index

[pgayvallet]

Given that

• we had to implement a client-side reindex for id rewrite in Rewriting SO id during migration #97222
• we no longer allow unknown types (e.g coming from disabled or uninstalled plugins) since SO migration v2: fail the migration early if unknown types are encountered #101351
• we’re going to get rid of the outdated document migration in the target index [SO Migration v2] Remove the OUTDATED_DOCUMENTS_* steps #103731

I think we don’t have any more reason to use a temporary index between the source and the target. We need some further investigation to confirm that this hypothesis is correct, but if so, we could just read batches of documents from the source, and index them in the target, then proceed with the mapping update as we’re already doing. It would allow us to get rid of the whole clone + refresh target operations.

Note that the time complexity would remain linear in that case, but it could still be a non-negligible improvement.

[elasticmachine]

Pinging @elastic/kibana-core (Team:Core)

[joshdover]

Worth noting that after #105213 merges, we will be continuing to allow unknown types to be migrated until 8.0. So we cannot make this change (or #103731) until that behavior changes.

[pgayvallet]

Yea. also given #105115 (comment), it's possible that we may need the temporary index anyway for some migration improvement.

That, plus the fact that the 'one index per type' approach is a better perf improvement anyway long-term, make me think that we could ignore this one.

[rudolf]

We need need the temporary index + clone steps to avoid lost deletes. Otherwise, one instance completes the migration, acknowledges a delete, and then the second instance reindexes the deleted document and restores it.

The alternative is to implement soft deletes so that the second instance's reindex will get a write conflict. I feel like there was some kind of gotcha which soft deletes didn't solve. But all-in-all I agree with the conclusion that migrations per type would be a better performance gain.

I'll close this for now. If we do one day identify the cloning step as a big performance cost, we could investigate soft deletes.