Elasticsearch and OpenSearch may have different opinions and priorities, but something that all of us agree on is that older data should be searchable, but also cheaper to store than recent data.
Object storage is a cheap way to store data, but the challenge is retrieving this data to make it searchable in an acceptable amount of time. Luckily, the evidence is proving that object storage services like AWS S3 can be very performant on this task, and both Elasticsearch and OpenSearch are using this service as an ally for the same purpose: reducing costs.
AWS UltraWarm is an AWS OpenSearch service feature that provides a cost-effective way to store large amounts of time-based data (immutable) using smart caching technologies to improve performance. UltraWarm instances will not have the OS disk overhead, or replicas disk need (as S3 has high availability features under the hood). This means that every GB you get, you can use for storing primary shards.
AWS OpenSearch service also offers a Cold Storage feature, backed by S3 to make the oldest data available on demand to make it searchable. Cold storage doesn’t have resources like CPU or RAM associated, only S3 disk space, so if you want to search or visualize your data, you must mount it to a Warm instance.
Elasticsearch Searchable snapshots
Elasticsearch leverages snapshots, making those searchable by partially or fully mounting them from an object storage to a local cluster. It is worth noting that Elasticsearch doesn’t require you to use S3. You are free to use any other object storage, such as GCP or Azure.
On the cold tier, the indices are retrieved from the object storage and fully mounted in the local node storage, allowing us to remove the replicas from the local nodes, thereby reducing storage.
On the frozen tier, the indices are partially mounted in a local node cache, and the rest of the data resides in the object storage and is fetched only if necessary. That local node storage is a Least Recently Used (LRU) cache based on search activity, and contains a subset of the shards that are mapped to that node in the cluster state routing table.
You can learn more about searchable snapshots in our articles:
- Elasticsearch Multi-Tier Architecture | Hot, Warm, Cold & Frozen (opster.com)
- Elastic Pricing Calculator – How to Use the Pricing Calculator (opster.com)
- Elasticsearch Index Lifecycle Policy and Management – Important Tips (opster.com)
Summary comparison table
As you can see, the strategies are different: OpenSearch allows you to move indices to special UltraWarm instances, and Elasticsearch mounts snapshots from the object storage. The final purpose though is the same: Detach storage from computing, keeping storage expense as low as possible at acceptable response times. It is worth noting that decoupling storage from compute as well as separating the indexing and search tiers is the target architecture that Elastic tends to with their recent Serverless effort.
The following table summarizes the differences between AWS UltraWarm/Cold and Elasticsearch Searchable Snapshots:
|Elastic Cold/Frozen tiers
|How does it work?
|Backed by AWS Object Storage (S3), indices are moved to UltraWarm instances
|Backed by Object Storage (S3, GCP, Azure, etc..) indices are mounted from snapshots
|How can you manage it automatically?
|Index State Management (ISM)
|Index Lifecycle Management (ILM)
|Can it be used on-prem/with a managed service?
|Only available in AWS OpenSearch service (Also available for Elasticsearch 7.9+)
|Available in Elastic Cloud and Elasticsearch on prem (Enterprise License required)
|How is it billed in managed services?
|Billed by hour + gb/month + data transfer
|Billed by hour + data transfer
|Long term data approach
|Cold Storage. Data needs to be moved back to UltraWarm nodes to be searchable
|Frozen tier. Partially cached data in local node, rest of the data in Object Repository
Both Elasticsearch and OpenSearch offer alternatives to save costs by moving older data to cheaper machines.
OpenSearch leverages the AWS UltraWarm feature, and Elasticsearch leverages the Searchable snapshots, moving some of the cluster’s data to object storage instead of keeping it on regular disk, more expensive storage.
In version 2.4.0 OpenSearch has released a technical preview of their own version of the Searchable Snapshot feature. That feature was made generally available in version 2.7.0.
We are sorry that this post was not useful for you!
Let us improve this post!
Tell us how we can improve this post?