更多精彩内容，欢迎观看：
《Elastic（中国）产品应用实战》——五、10分钟内查询一个PB级的云存储（上）：https://developer.aliyun.com/article/1220936?spm=a2c6h.13148508.setting.18.653f4f0eDDVBOB
6. 简单词条查询
让我们从简单的词条查询开始。这里主要的观察结果是，冻结层在几秒钟内返回4TB 数据集上的结果（5个匹配文档）只下载数据集的很小一部分来寻找匹配的元素。 这突显了 Lucene中的索引结构功能强大，可实现快速查找。
重复运行查询后，所有层展示出相似的性能，因为现在可以在冻结层中提供来自于 本地磁盘上LFU缓存的数据。Elasticsearch的内存中结果缓存在这里不起作用，因 为这种类型的查询不会被缓存。在页面缓存中提供数据会影响在热/温层和冷层中重 复运行的性能。
当使用默认索引存储类型hybridfs而不是niofs时，热/温层的性能在首次运行时会 略低（285毫秒而不是92毫秒）详细信息将在下一节中介绍。
7. Kibana 仪表板
我们对Kibana仪表板重复同样的流程。这里主要观察结果是，冻结层在5分钟内 基于相同的4TB数据集返回仪表板，而在具有本地数据访问途径的其他层中计算仪 表板需要20秒。尽管仪表板使用时间范围筛选聚合了超过75%的数据集，但由于 索引结构，它仍然只需要下载存储库中的一小部分数据（在本例中约为3%，下文将详细介绍）。
当Elasticsearch的结果缓存被禁用时，重复搜索的性能主要依赖于页面缓存，当查 询所需的数据部分完全纳入磁盘上的LFU缓存时，重复搜索的性能就与冻结层的性 能相当。值得注意的是，对于这个特定的工作负载，热/温层中的内存映射会导致页 面缓存"抖动”，当使用默认存储类型时，这会对热/温层的性能产生不良影响（与 使用niofs时的6.2秒相比，最多可慢三倍）。
对于冻结层，我们考虑了两种不同大小的LFU缓存的，以显示对重复搜索性能的影 响。磁盘上的LFU缓存大小首先被定为200GB，这只是4TB的一小部分（数据集大 小的5%），但仍然足以容纳为计算给定的仪表板而下载的所有数据（大约3%，或 120GB）。在第二次运行基准测试时，它的大小仅定为20GB （原始数据集大小的 0.5%），这不足以容纳给定仪表板需要的所有数据。
当启用Elasticsearch的内存中缓存时，重复搜索会更快，因为部分查询结果现在可 以直接在Elasticsearch节点上获得，而不需要重新计算。然而，目前冻结层并不使 用这些内存中的Elasticsearch缓存。
对于仅计算的仪表板略有不同并通过不同的国家/地区代码进行筛选的情况，我们也 进行了基准测试。在这种情况下，由于已经下载了与满足这个略有不同的查询相关 的数据的许多部分，冻结层可以从中受益，并且返回结果的速度几乎与其他层一样快。
为了在首次运行仪表板时显示在冻结层中下载了些什么，我们对请求的六个最大的 Lucene文件类型以及下载了多少量进行了可视化。虽然fdt （字段数据）文件消耗 了大部分空间（用于存储文档），但并未通过访问这些文件来计算聚合。正如预期的 那样，大多数访问都是在Lucene的dvd （每个文档的值）文件上完成的，它们是 用于计算聚合的文档值。
8. 快速访问大量对象存储
虽然在冻结层上的查询肯定会更慢，但它的主要优势体现在不经常访问上，使数据 无需解冻即可用于搜索。相比之下，即使禁用了恢复限制，在本地提供完整的数据 集也需要一个多小时，这比我们直接在冻结层上运行查询所花的时间要长得多。
9. 扩展到 PB 级
到目前为止，基准测试集中在层与层之间的性能比较上，不能展示冻结层的全部可 能性。该层比其他层具有更高的计算存储比。
我们采用了接近极致的做法，对相同的数据集进行了超过250次的挂载，每次都使 用不同的名称，以便将其作为单独的索引处理。然后，我们的单节点集群有12500 个80GB的分片，这相当于挂载了 1PB的数据。在完整的1PB （相当于100万GB） 数据集上运行简单的词条查询只花了不到10分钟的时间，表明这一实施过程可以 很好地扩展到更大的数据集。
在实践中，这可能不是一个理想的设置，因为单个节点上分片过多，本地磁盘缓存 与对象存储大小的比率极低。在这种规模下，数据集的存储成本远超冻结层节点的 计算成本，因此添加更多节点将显著提高性能，而对成本的影响可以忽略不计。
10. 调整磁盘上 LFU 缓存的大小
如前所述，为了在重复搜索中获得优良的性能,调整磁盘上的LFU缓存大小很重要。 在这里，正确的值在很大程度上取决于所运行的查询类型，特别是产生查询结果所 需访问的数据量。因此，挂载更大量的数据并不一定总是需要更大的磁盘缓存。 例如，在基于时间的索引背景中应用时间范围筛选可以减少需要查询的分片数量。 由于在数据访问模式中经常存在某种底层空间或时间局部性，冻结层将允许对非常 大的数据集进行有效查询。根据我们目前的观察结果，我们建议调整磁盘上LFU缓 存的大小，使其介于挂载的数据集大小的1%到10%之间。5%的比率也许是一个很 好的实验起点。
请注意，冻结层可以很好地支持垂直和水平扩展，因为计算具有非常相似的性质。 使用性能更好的机器类型或向集群添加更多节点就是提高冻结层查询性能的一种简单方法。
11. 结论
我们已经展示了冻结层可以以优异的性能响应两种不同类型的查询。使用 Elasticsearch的默认索引策略，冻结层的搜索性能要比扫描整个数据集快几个数量 级。在冻结层中的重复搜索将进一步受益于磁盘上的缓存，并提供与其他层相似的性能。
当以经济有效的存储搭配灵活的计算存储比为主要目标时，冻结层就会提供巨大的 价值。冻结层中的数据只是作为任何常规索引而访问，因此可以轻而易举地切换现 有设置，以利用这个令人兴奋的新功能。进行设置也并非难事，因为它再次利用了 已经用于备份目的的快照存储库，并与索引生命周期管理完全集成，以便将数据从 热层/温层/）令层转换到冻结层。Kibana的异步搜索集成在此基础上提供了扩展功 能，允许在后台计算运行缓慢的仪表板，并在可用时进行可视化。
注：冻结层既可用于自托管部署，也可用于Elastic Cloud,所以请查看这份文档, 进行尝试，并提供您的反馈意见吧。
