Elastic的新冻结数据层将计算与存储分离，并利用低成本的对象存储系统直接促进 搜索。它提供了无限的存储扩展，同时保留了高效查询数据的能力，无需首先对数 据进行解冻，使管理大规模数据变得更容易、更经济。
在这篇博文中，我们将比较新冻结层与现有Elasticsearch数据层的搜索性能，并展 示如何使用冻结层以较低的性能存储和搜索更大量的数据。
冻结层的主要亮点有：
• 如果数据没有缓存，在4TB数据集中返回简单词条查询的结果需要几秒钟。如 果有缓存，则搜索性能会以毫秒为单位，类似于温层或冷层；
• 如果数据没有缓存，在4TB数据集上计算一个复杂的Kibana仪表板所需时间 不到5分钟。如果有缓存，这一计算将在几秒钟内完成，类似于温层或冷层；
• 轻松将数据量扩展到1PB数据集。在无缓存的情况下，对简单词条查询的结果 将在10分钟内返回。
目前，冻结层在Elasticsearch 712和Elastic Cloud上以技术预览方式提供，很快就 可以普遍应用。
1. 数据层简介
数据层提供了优化的存储和处理能力，可实现基于不同需求（例如基于数据时间长 短、数据源或其他标准）的数据访问。
热层主要处理集群中新数据的所有索引，并保存查询最频繁的最近每日索引。由于 索引通常是一项I/O密集型活动，运行这些节点的硬件需要更强大，因此需要使用 SSD存储。温层可以处理大量查询频率较低的索引，因此可以使用延迟较长、成本 较低的存储设备，例如非常大的旋转磁盘，降低较长时期内保留数据的总体成本， 同时确保数据仍可用于查询。
最近引入的冷层和冻结层利用低成本的对象存储以具有成本效益的方式管理大量数 据，同时保留了对数据的搜索能力。
冷层无需副本，而是通过从快照中恢复数据的方式促成恢复事件。在热层和温层中， 有一半的磁盘空间通常用于存储副本分片。这些冗余副本可确保查询快速完成，性能一致，并能在机器故障时起复原作用（机器故障时，副本将成为新的主分片）。但是，一旦数据在其生命周期中变为只读，恢复就可以被卸载到快照。这意味着在冷层中，无需副本分片；当某个节点或磁盘故障时，系统会自动从快照中恢复数据， 从而在集群中重新创建完整副本，以便本地磁盘重新提供搜索服务。
快照存储库非常适合这种情况，因为在Blob存储中存储数据比在本地SSD或旋转 磁盘上存储数据要经济得多，而且在大多数情况下，为了备份目的，数据会在Blob 中存储。因此，冷层只需要温层一半的本地存储空间，就具有类似的查询性能，只 是可用性稍逊，但能比温层节省50%的成本。
冻结层更进一步，只在集群本地缓存少量但经常访问的数据部分，并根据搜索要求 基于搜索需求从对象存储中惰性地提取数据，从而将计算与存储分离。与到目前为 止使用Elasticsearch所实现的功能相比，这提供了更高的计算存储比。
当然，冻结层中的搜索可能比在热层、温层或冷层中慢得多，但对于不太频繁的搜 索（如运行或安全调查、法律搜索或历史性能比较）来说，这是可以接受的折衷。 Elasticsearch具有默认为所有内容建立索引的优势，这一功能非常强大，因为它避 免了在查询时对数据进行全面扫描，并且利用这些索引结构可以在非常庞大的数据 集上快速返回结果。
2. 冻结层的工作原理
冻结层中的节点不需为保存其所有索引的完整副本预留充足的磁盘空间。相反，我们引入了磁盘上的LFU （最少使用）缓存，它只缓存从Blob存储下载的索引数据的 一部分，以服务于给定的查询。磁盘缓存的工作原理类似于操作系统的页面缓存， 可以加速对Blob存储数据中经常请求部分的访问。在Lucene级别的读取请求会被 映射到此本地缓存上。
如果缓存丢失，可从Blob存储的Lucene文件中下载更大的部分（16MB的数据 块）供搜索用。到Lucene下一次访问文件的相同部分时，就可直接从本地缓存获取。
节点级共享缓存将基于"最少使用"策略对映射的文件部分进行逐出处理，因为我 们认为Lucene文件的某些部分的使用频率比其他部分更高。如果需要使用一个 Lucene文件的某些部分反复响应查询（比如@timestamp字段的范围查询），那么 该数据将保持缓存，而其他数据可能会被逐出。
虽然现在搜索需要下载正在访问的文件部分，但Lucene基于一组预先计算的索引 结构执行搜索的方式减少了有待扫描的数据量，使这个过程变得更快。为了进一步 减少这些分片的内存占用，我们只在有需要时，也就是说，在有活动搜索的时候才 打开Lucene索引。这使我们能够在一个冻结层节点上拥有大量索引。
3. 基准测试目标
对于每一层，我们在第一次访问时测量搜索性能（没有利用任何缓存，因为它们还 没有预热）并使用相同的查询重复搜索（缓存预热）。对于冻结层，当磁盘上的LFU 缓存不能容纳所有数据时，我们还会检查重复搜索性能。
对于这个基准测试，我们考虑了两种查询类型。
• 第一个代表安全调查，即在一个大数据集中找到一小组匹配的文档（犹如大海 捞针）
• 第二个代表Kibana仪表板，即对大量数据进行多次频繁聚合计算。
由于这些基准测试的目标是准确地比较不同层的查询性能，所以我们选择在所有层 上使用相同的机器类型；然而，在实际部署中，应该使用针对特定层的机器类型， 以权衡每一层的最佳成本和性能。
基准测试中的基线是热层，其中有常规的基于时间的Elasticsearch索引。温层访问 数据的方式与热层相同，并且为实现此基准测试的目的，我们对所有层使用相同的 机器类型，因此它等同于热层，没有单独列出。在冷层中，我们有从快照装载的相 同索引的完整副本。在冻结层中，我们使用磁盘上的LFU缓存从快照装载索引。
4. 基准测试设置
基准测试使用Elasticsearch712.1运行，并以一个基于事件的Web服务器日志数据 集为基础，Elastic使用该数据集对各种功能进行基准测试。磁盘上索引数据集的大 小为4TB （10个基于时间的索引和5个80GB的分片）。分片被强制合并为一个段， 这优化了读取性能，也是索引生命周期管理在将数据移动到冻结层时使用的默认值。 相同的（预先计算的）数据快照用于对每一层进行基准测试。恢复限制被禁用，以免人为限制性能。
我们进行基准测试的第一个搜索只是一个简单的词条查询，在一个给定的IP地址访 问Web服务器的数据集中，找到出现的情况：
"nginx.access.remote_ip": "1.0.4.230".
第二个搜索是Kibana仪表板，它包含五个视觉效果，用于分析带有404响应代码 的请求，例如，查找不再指向任何地方的链接。
在每个基准测试场景中，我们运行一些预备步骤以减少运行间的差异，包括删除操 作系统缓存和slab对象，以及修整SSD磁盘。
在热/温层，Elasticsearch默认使用hybridfs存储类型，这些内存映射了 Lucene的 一些文件类型。冷层和冻结层不使用内存映射。因为内存映射会通过预取页面对页 面缓存有影响，我们在热/温层进行两项测试并提供结果：使用内存映射，以及使用 "niofs"index.store.type来配置它（更接近于我们访问冷层和冻结层中本地文件的方 式）。
为了简单起见，我们这里只对单节点集群进行基准测试，但每一层也支持多节点集 群。单节点集群是一个N2D（n2d-custom-8vCPUs-64GB）实例，具有8个vCPU, 64GB RAM（Elasticsearch 将其中的 29GB 用于JVM 堆），以及 RAID-0 中 16x375GB 的本地暂存SSD磁盘，以便它可以在热/温层和冷层中完全容纳4TB数据集。它是 一个适合冻结的候选实例，因为它有应用于磁盘上LFU缓存的快速本地磁盘。
我们还针对冻结层中的磁盘上LFU缓存采用两种不同的缓存大小进行实验，以显示 其对重复搜索的重要性：200GB （数据集的5%）和20GB （数据集的0.5%）。
5. 结果
查询性能受到各种缓存机制的影响，从操作系统级页面缓存到应用程序级内存缓存, 例如分片请求缓存和Elasticsearch中的节点查询缓存。对于每个结果，我们都解释 了这些缓存是如何发挥作用的。显示的结果为五次运行的中位数，以减少运行间的 差异。
更多精彩内容，欢迎观看：
《Elastic（中国）产品应用实战》——五、10分钟内查询一个PB级的云存储（下）：https://developer.aliyun.com/article/1220928?spm=a2c6h.13148508.setting.14.653f4f0e9anOCu
