- Newest
- Most votes
- Most comments
Performance of Cold to UltraWarm Migration:
Performance Characteristics:
🙄 The performance of such a migration can vary significantly based on data volume, network conditions, and hardware performance. Since there is no detailed public benchmark specifically for this migration scenario, it is best to perform a controlled test in your environment.
High-Level Time Estimates:
ℹ️ There are no standard time estimates for Cold to UltraWarm migrations as it heavily depends on the specific conditions mentioned above. Generally, moving data to UltraWarm is faster than to Cold because UltraWarm is optimized for faster read access.
Measuring True Migration Time:
💡 You can try to simulate a non-cached scenario by accessing different data that was not recently accessed to ensure that the cache does not influence your results. OpenSearch does not explicitly offer a manual cache eviction feature for UltraWarm storage, but accessing large amounts of other data can help 'push out' the cached data.
ISM Operations:
Defining start_time
and end_time
:
ℹ️ OpenSearch ISM policies do not natively support using the min(@timestamp) and max(@timestamp) as start and end times directly. However, you can write custom scripts or use external automation tools to update ISM policies dynamically based on query results that determine the earliest and latest timestamps in an index.
Adjusting ISM Policy for Migrated Indices:
💡 For indices that have been migrated and thus have a new creation time, consider modifying the ISM policy to base the retention period on a timestamp field within the documents rather than the index creation date. This approach requires custom scripting or adjustments in your ISM policy definition.
Relevant content
- asked a year ago
- asked a year ago
- AWS OFFICIALUpdated a year ago
- AWS OFFICIALUpdated 2 years ago
- AWS OFFICIALUpdated a year ago
- AWS OFFICIALUpdated 3 years ago
Is there a reference document the describes the index states and example that describes how to custom manage ISM policy to base the retention period on a timestamp field when migrating from Elastic to OpenSearch using Logstash approach?