OpenStore is an elastic, high-performance, and cost-effective storage engine developed by the Alibaba Cloud Elasticsearch team for use cases such as log analysis and search.
Engine architecture
The OpenStore architecture uses a tiered storage design and exposes a unified, high-performance file system service to upper-layer components:
-
Primary shard/replica shard: In the OpenStore architecture, the primary shard builds indexes and uploads the generated segment files to shared storage. Replica shards do not build indexes independently; instead, they sync data directly from shared storage.
-
NameNode: The distributed metadata management center for OpenStore. It manages distributed metadata like cluster topology and the global namespace, and provides task scheduling for operations like data replication to ensure cluster-wide consistency.
-
Native Metadata Manager (NMM): The local metadata management center. It manages local file metadata, such as file length, update time, and persistence status. It also provides access to the underlying file system (UFS) for atomic operations like loading and persisting files.
-
Shared Data Service: A remote service that provides massive shared storage.
Benefits
-
Storage-compute separation: Compute resources (such as Elasticsearch nodes) and storage resources (such as remote shared storage) scale independently. You can add nodes without migrating data when compute demand increases, and leverage remote shared storage when storage needs grow.
-
Data consistency: A Raft-based hybrid protocol ensures data consistency between the local cache and remote shared storage, providing applications with a unified, reliable data view.
-
Ease of use: Fully automated index lifecycle management. Configure a simple index lifecycle policy, and the engine handles the entire process from data tiering to migrating data to OpenStore storage.
-
High availability: Multiple replicas share a single data copy at no extra storage cost. The underlying service delivers up to 99.9999999999% (12 nines) data durability.
Storage types and use cases
|
Storage type |
|
|
Access latency (local cache hit) |
0.2 ms |
|
Access latency (local cache miss) |
50 ms to 400 ms |
|
Access throughput (local cache hit) |
1 GB/s |
|
Access throughput (local cache miss) |
750 MB/s |
|
Use case |
Infrequently accessed data, such as monitoring logs, historical orders, and archived data |
The access latency values listed above refer to storage-level latency only, not end-to-end latency.