有什么不同? Elastic 数据层和 Amazon OpenSearch Service 层

作者:来自 Elastic Ugo Sangiorgi

了解 Elastic 和 Amazon OpenSearch Service 数据层之间的主要差异,以实现更智能、经济高效的数据管理。

在数据管理领域,在讨论如何在不同的性能要求下提供和/或保留数据时,经常会出现 "热 (hot)"、"温 (warm)" 和 "冷 (cold)" 等术语。

在将 Elastic® 的数据层与 Amazon OpenSearch Service 层进行比较时,还存在另一个挑战 - 相同的术语并不意味着相同的事情。 通过此解释,我们试图消除有关 Elastic 和 Amazon OpenSearch Service 之间类似数据层术语的任何误解。 借助此处提供的见解,你将处于战略性管理数据的有利位置,最大限度地提高性能,同时最大限度地降低成本。 这张图表是一个方便的总结:

什么是数据层? 从根本上讲,数据层是不同的存储级别,它们根据访问频率、成本效率和性能需求等标准对数据进行分类。 它们可以优化数据组织,并可以通过使存储费用与信息的长期价值保持一致来帮助降低成本。

层级有何不同

数据层的概念存在于大多数数据平台中,特别是那些处理可观察性和/或安全工具的平台。 这些工具收集的数据量通常非常大,每秒处理数千/数百万个事件,并可用于搜索、仪表板和警报。 可观察性和安全性也有一个共同的特征:最新的数据也是最有价值的,因为管理这些工具的团队依靠收集到的信号在出现问题时立即采取行动。

因此,使用尽可能快的硬件来摄取和存储数据,并随着时间的推移 "向下" 移动到更便宜、功能更弱的硬件是有意义的。

Elastic 中的数据旅程

Elastic 有五层,可以根据你的具体用例独立或集体使用:

  • (hot):你的数据总是首先到达这里,并且它具有高实时性、可扩展性,并提供尽可能最佳的性能(假设遵循最佳实践)。 这是你保存需要经常访问和操作的数据的地方。
  • (warm):此层可以实现更具成本效益的硬件利用率,可以驻留不立即需要(但仍然相对重要)的数据。 你可以将数据移至此层并对其进行优化(例如通过强制合并分段),以便搜索尽可能快。 该层中的数据仍然可以通过副本进行扩展,就像在热层中一样,以便在需要时满足搜索需求。
  • (cold):这里确保至少一份数据副本始终分配给节点并且在任何给定时刻都可搜索。 冷层使用存储桶来帮助在出现故障或需要更改集群拓扑时恢复数据。
  • (frozen):在这一层中,数据访问频率较低,并且可以节省成本,因为它利用成本最低的存储并减少计算资源。 数据是可搜索的,但必须将其恢复到可搜索状态,这是通过 Elasticsearch® 的可搜索快照自动且透明地完成的。
  • 快照 (snapshot):快照本质上是数据备份 ------ 索引的时间点副本。 它们可用于各种目的,例如丢失时的数据恢复、为测试或临时环境创建索引克隆,或在集群之间迁移数据。 快照存储在存储库中,该存储库可以位于不同的存储系统上,例如本地文件系统或存储桶存储(例如 GCS、S3),并且必须手动恢复才能搜索数据。

等等,什么是 "shard (分片)"?

在 Elasticsearch(因此也是 OpenSearch)中,"分片" 本质上是一个独立的索引,它保存一部分数据,允许跨多个节点(服务器)分布大型数据集,以提高性能和可扩展性。

分片有两种类型:主分片 (primary shards) 和副本分片 (replica shards)。 主分片是首先存储数据的主要容器; 每条记录仅存储在一个主分片中。 副本分片是主分片的副本,可在发生故障时提供冗余,并且还允许系统通过跨副本的负载平衡搜索查询来处理更多读取请求。 对于新手来说,你可以将分片视为一本书的各个章节; 虽然每一章(碎片)包含故事的不同部分(数据),但多个印刷副本(副本)确保即使丢失,仍然可以完整阅读故事。

更多关于 shard 方面的知识,请阅读文章 "Elasticsearch 中的一些重要概念: cluster, node, index, document, shards 及 replica"。

Amazon OpenSearch Service 中的数据旅程

Amazon OpenSearch Service 有四个层级:

  • Hot:你的数据总是首先到达这里,并且它具有高度实时可用性、可扩展性,并提供尽可能最佳的性能(假设遵循最佳实践)。
  • OR1 :数据既可读又可写,因为 OR1 具有永久的计算能力,但没有副本。 发生故障时,数据会从存储桶中恢复。
  • UltraWarm:此层专为经济高效的存储和查询访问频率较低的大数据量而设计。 Amazon OpenSearch Service 中的 UltraWarm 节点提供辅助存储层,以保持数据可查询。
  • Cold:OpenSearch 冷层中的数据通常会产生较低的存储成本,但不能直接搜索。 访问冷数据通常涉及手动将数据恢复到较热的层,然后使其可搜索。

并排比较

现在我们可以从数据访问能力方面来比较各层:数据可以读写还是只读? 是否需要手动恢复或者 "解冻" 过程是自动的? 以下是每个 "波段" 代表的含义:

Read + Write

该波段将 Elastic 和 OpenSearch 中的 Hot 视为最快的级别。 由于它们应该是等效的,因此我们在本博客中比较了它们的性能。

下一层,Elastic 中的 Warm 和 Amazon OpenSearch Service 中的 OR1 都允许更新数据,但在可扩展性方面存在差异 - Elastic 的 Warm 允许副本并允许你扩展以满足搜索需求,而 OR1 则不允许,因为只有主分片可用于搜索。

Read-Only

该波段不允许数据更新(写入); 它只允许从其他层迁移数据。 该组中的所有层都有存储桶存储备份,但没有副本。

Elastic 中的 Frozen 层和 Amazon OpenSearch Service 中的 UltraWarm 层都将数据作为快照存储在存储桶存储中,并在任何涉及的索引中发出搜索时检索此数据。 只有这样,数据才可用,然后缓存以供后续搜索。 然而,UltraWarm 节点目前只有两种配置:一种可以处理 1.5TB 的快照数据,另一种可以处理 20TB 的快照数据。 这意味着,如果我们想要存储价值 100TB 的数据,则 Amazon OpenSearch Service 中需要 5 个 UltraWarm 节点,而 Elastic 中只需要 2 个 Frozen 节点,Elastic 具有不同的硬件配置文件以及不同的 vCPU、RAM 和 NVMe 存储组合。

此外,在 Elastic 中,ColdFrozen 都依赖于可搜索快照功能,该功能允许搜索 5.0 之前的快照(早在 2016 年就发布了!),而无需恢复到活动集群 --- 这对于治理非常有用 合规性、安全调查和历史回顾,无论你使用哪个 Elasticsearch 版本。

Archive

快照存储在存储库中,该存储库可以位于不同的存储系统上,例如本地文件系统或存储桶存储(例如 GCS、S3),并且必须手动恢复才能搜索数据。

硬件配置文件

另一个需要考虑的重要方面是每个层中使用的实例类型。 还需要注意的是,Elastic Cloud 支持三个主要的云提供商(AWS、Google Cloud 和 Microsoft Azure),每个提供商都有不同的硬件配置文件。 Amazon OpenSearch Service 的方法为其服务指定特定实例(例如 OR1 和 Im4gn),并具有特定的软件版本要求和 EBS 卷支持限制。

Amazon OpenSearch Service 和 Elastic Cloud on AWS 都使用基于 Graviton2 的实例,这表明对 AWS 基于 ARM 的芯片组的性能提升和成本效率的共同偏好。 AWS 上的 Elastic Cloud 对其实例的确切用例的规定较少,提供的选择包括具有快速存储的高计算能力(Graviton2 实例)和各种更传统的选择(例如 C5d、M5d 等)。

为什么这很重要?

命名约定可能会产生误导,在尝试将业务需求与提供商之间的数据存储选项保持一致时,会造成可以理解的混乱。 掌握这些层的实际功能可以帮助你在数据管理方面做出更明智且更具成本效益的决策。

此细分旨在消除因 Elastic 和 Amazon OpenSearch Service 之间的数据层命名重叠而带来的误解。 通过数据层的描述,你将能够更好地战略性地组织数据,以获得性能和成本效益。 超越名称并了解每一层的底层机制至关重要,以确保你的数据策略既稳健又高效。

另请参阅以下研究:Elasticsearch 在成本效率方面超越 OpenSearch,以及 Elasticsearch 如何在使用更少资源的情况下超越 OpenSearch

本文中描述的任何特性或功能的发布和时间安排均由 Elastic 自行决定。 当前不可用的任何特性或功能可能无法按时交付或根本无法交付。

原文:What's the difference? Elastic data tiers and Amazon OpenSearch Service tiers | Elastic Blog

相关推荐
Elastic 中国社区官方博客39 分钟前
如何将数据从 AWS S3 导入到 Elastic Cloud - 第 3 部分:Elastic S3 连接器
大数据·elasticsearch·搜索引擎·云计算·全文检索·可用性测试·aws
掘金-我是哪吒1 小时前
微服务mysql,redis,elasticsearch, kibana,cassandra,mongodb, kafka
redis·mysql·mongodb·elasticsearch·微服务
研究是为了理解2 小时前
Git Bash 常用命令
git·elasticsearch·bash
晨欣6 小时前
Elasticsearch和Lucene之间是什么关系?(ChatGPT回答)
elasticsearch·chatgpt·lucene
筱源源12 小时前
Elasticsearch-linux环境部署
linux·elasticsearch
Elastic 中国社区官方博客1 天前
释放专利力量:Patently 如何利用向量搜索和 NLP 简化协作
大数据·数据库·人工智能·elasticsearch·搜索引擎·自然语言处理
Shenqi Lotus1 天前
ELK-ELK基本概念_ElasticSearch的配置
elk·elasticsearch
yeye198912241 天前
10-Query & Filtering 与多字符串多字段查询
elasticsearch
Narutolxy1 天前
精准优化Elasticsearch:磁盘空间管理与性能提升技巧20241106
大数据·elasticsearch·jenkins
谢小涛2 天前
ES管理工具Cerebro 0.8.5 Windows版本安装及启动
elasticsearch·es·cerebro