从7.10开始，Elastic官方发布了可搜索快照的公测版，替代了我们常用的存储介质（比如 AWS S3、Microsoft Azure Storage、Google Cloud Storage 或同等产品），可搜索快照实现了在"低存储沉本、大数据、高性能“之间的权衡。降低成本一直以来都是企业孜孜追求的目标，借助可搜索快照，您现在可以将这类存储也用于存储和搜索数据。
我们将使用可搜索快照为两个新的一流数据层提供支持：cold phase 和之后的frozen phase 。通常我们一直支持通过多个数据层来进行数据生命周期管理：hot phase 用于提供较高的处理速度，warm phase 则用于降低成本，但性能也较低。由可搜索快照提供支持的新cold phase 可将数据的冗余副本卸载到低成本的对象存储中，这可以提高只读数据的本地存储密度，最多可将您的存储成本降低达 50%。既能实现将数据完全存储在低成本对象存储中，同时又可保持其完全可搜索性，另外，还具有本地缓存，可对频繁访问的数据进行快速查询。而且，像我们构建的所有功能一样，有些 API 可直接控制可搜索快照从对象存储中加载、管理和搜索数据的方式。利用这些新功能，我们可以轻松在 Elastic 中管理不断增长的数据量且成本低廉，进而能够经济高效地满足数据存储需求。
可搜索快照发展历程
时序数据随处可见。数据可以是日志、指标、跟踪、安全事件。数据是安全性和可观测性用例等的基础。发布以来，官方为此做出了大量的优化和提升，以保证能够更快速及高效地管理和扩展此类数据，因为时序数据增长性非常快，比如，如果您每天收集 1 TB 的数据，则每周需要收集 7 TB。数年之后，数据量便会轻松达至 PB 级。用户需要一种方法，该方法既能管理这种指数级的存储增长，又能够对数据进行搜索。
一般解决此问题的方法是管理数据的生命周期（ILM）。首次采集数据时，很可能要对其进行大量搜索。例如，在调查事件时，为识别和解决问题，您需要快速访问所有相关数据。当攻击者入侵主机或应用程序时，您快速响应的能力通常决定了入侵的影响。但是，根据来源或类型，也可以将数据分类为不同的使用级别。某些数据可能仅仅为了保证对法律的可追溯性而保存，或者出于对比目的而偶尔需要回溯。因此，用户需要不同级别的存储和处理能力来满足这些不同级别的需求，而无论其年龄、数据源或其他条件。
每位企业的管理者包括我们开发者都希望能够在成本、性能和功能之间取得平衡，从而满足自身的需求。ES解决此问题方法的核心支柱是数据层——管理数据的生命周期。这并非什么新概念，并且其在 Elasticsearch 的最早版本中就已经存在了。索引生命周期管理 (ILM) 可提供一些约定，以便轻松管理跨hot（具有 SSD 的快速机器）和warm节点（可能具有旋转磁盘的低成本机器）之间的数据，并且官方已在 Elastic Cloud 中支持它长达多年了。快照生命周期管理 (SLM) 可更加轻松简单地使用来自 AWS、Google、Azure 和本地部署存储供应商的低成本对象存储，进而执行和存储备份。尽管这些快照是许多部署的关键部分，但它们并不是数据分层案例的有效部分。为什么会这样？因为无法搜索快照。不过，随着可搜索快照的使用，这一切已然改变。现在，我们能够创建新的、更便宜的数据层，从而利用这些低成本的对象存储，并且高效存储数据的备份。
推出可搜索快照
可搜索快照的发布简直是上呈天意，下应民心，因为它可以让我们以全新的方式使用 S3 和其他对象存储。虽然目前仍然可以继续使用对象存储来将备份数据存储为快照，不过现在借助 Elasticsearch 可以直接搜索快照的数据，这样对象存储更加高效，而且该功能始终在线可用。官方对产品的所有配套库都进行了更改——从 Kibana 到 Elasticsearch，然后一直到 Lucene。利用可搜索快照，可以完全无缝且快速地从 S3 或其他对象存储中的快照支持的索引中恢复或检索数据，而且我们还能开发新的数据层，从而以较低的成本为您提供更多价值。
Cold Phase
cold phase 与warm phase 相比，集群存储减少了多达 50%。它可保持与热层和温层相同的可靠性和冗余级别，并且全面支持从任何节点上的硬件故障中自动恢复。这样一来，就可以更经济高效地询问数据问题，例如“与上个月相比，这一峰值如何？”，或者“该用户在最近 6 个月内是否登录过受限系统？”
这一点是如何做到的呢？在hot phase 和warm phase 中，一半的磁盘可用于存储副本分片。这些冗余副本可确保快速一致的查询性能，并在机器发生故障时为您提供可伸缩性。如果发生这种情况，副本将无缝接任为Primary，并且索引和搜索也将会继续进行。
图片
不过，只要把数据变为只读状态，就可以轻松卸载冗余。快照存储库非常适合此操作，因为在 S3 中存储数据要比在本地 SSD 或旋转磁盘上便宜得多。因此，在cold phase 中，副本分片可作为快照存储在 S3 中。因此，冷节点的可用容量增加了一倍，而成本却与之前的相同，即对查询性能并没有太大的影响。
如果cold phase 中存在本地节点或磁盘故障，可以使用可搜索快照进行自动恢复，即使用 S3 中存储为快照的副本索引，使这些索引可用于提供搜索请求且所需时间要比常规快照还原短得多。这就是它们的协同合作原理。
Frozen Phase（冷冻索引）
想象一下，如果可以在安全性调查进行无限制地回顾，或者可以深入研究 APM 的原始数据，进而查看过去两年客户行为的变化情况。这就是cold phase 的意义所在，而之前使用 Elasticsearch 的做法并未对成本做出很多考虑。可搜索 S3 的概念对您的业务目标的作用有多强劲。我们现在正在积极开发冻结层，通过冻结层，您可以直接搜索 S3 中存储的数据或您选择的对象存储。使用冻结层时，根本就不需要在本地存储任何数据——它们都可作为快照存储在 S3 中。
在cold phase 中，能够按需搜索几乎无限量的数据，而其成本接近在 S3 上存储该数据的成本。数据的全自动生命周期已趋近完整——从hot、warm、cold，然后再到frozen，同时还可确保以尽可能用最低的存储成本获得所需的访问和搜索性能。
用户体验的提升
可搜索快照的在“新功能”上简直令人哇塞，不过另一个关键因素是确保其他所有功能可与这些新功能完美协同以达到最高的用户体验。
•简化的数据层配置：ES新版本提供了data_hot、data_warm、data_cold这些新角色，非常方便用于管理索引的生命周期，在使用索引生命周期管理时，ES会在自动把数据分配至适当的phase，从而大大简化和精简设置数据层和配置 ILM 策略的方式。
•异步搜索：S3的开挖掘潜力已经不大了，为了更好的用户体验。官方在 Elasticsearch 中开发了异步搜索机制，该机制可显著增强 Kibana 关于长期运行查询的体验。现在可以异步执行搜索请求。并且可以监测请求的进度并在整个阶段检索结果。而且整个阶段都可以提前查询部分结果。
•查询效率：官方推出了一系列的改进功能，以跳过运行搜索时不匹配甚至不需要的搜索索引。比如，可以根据时间或数据中的其他属性进行预先筛选，进而自动跳过已知的没有任何匹配的索引。搜索也尽可能提前结束：使用 block-max WAND 进行文本搜索，已排序查询会对我们已搜索的分片进行排序，在我们有足够的匹配项时停止搜索等等。
