文章目录
3月23号，Elastic又发布了最新的7.12版本。在这个版本中，最重要的一个更新是frozen tier的发布。相比于之前版本的cold tier（关于cold tier的细节，可以查看之前的博文： Elastic Searchable snapshot功能初探、 Elastic Searchable snapshot功能初探 二 （hot phase）），其最大的不同是我们可以直接在对象存储里面进行数据的搜索，即我们能够保持对象存储里面的快照数据一直 在线可查，通过构建一个小规模的，只带基础存储的计算集群，就可以查阅保存在快照中的海量数据！做到真正的计算和存储分离，并且极大的降低查阅庞大的历史冷冻数据的所需的成本和提高查询效能。（可参考官方博客： 使用新的冻结层直接搜索S3）
前方高能图片：
单节点"挂载"1PB数据，本地磁盘使用率1.7%，只需很少的计算资源和本地存储资源就可以查询海量数据。
要做到这点，有几个前提：
- 需要有Elastic的Enterprise级别的订阅
- 已经有可用的对象存储用于快照仓库
演示思路
在本博文中，我们来给大家简单展示一下，如何通过Searchable snapshot + Frozen Tier来做到直接在快照中进行数据搜索，这里的个中要点是——通过构建一个小规模的，只带基础存储的计算集群，就可以查阅保存在快照中的海量数据！因此，我们需要至少准备两个集群，一个数据集群用于生成快照，我们可以将其抽象为我们生产环境中会大量产生日志的其他集群，对于那些已经转冷，甚至是要归档的数据，我们都放在snapshot里面。而另一个是我们的让归档级数据保持在线可查的计算集群，通过mount的方式，将snapshot挂载为本地可查，但又不占据存储空间的searchable snapshot index。
- 以上的
default-deployment就是我们提到的“数据集群” - 而
frozen tier就是我们提到的“计算集群”
为了使用到frozen tier的功能，我们需要对计算集群（frozen tier集群）做特定的配置 —— xpack.searchable.snapshot.shared_cache.size: 8GB:
注意，该版本上已经可以使用
autoscaling功能
准备数据
我们以esrally的标准数据作为本次测试数据集，选择的是noaa数据，包含33,659,481个文档，原始大小为9.0GB
____ ____
/ __ \____ _/ / /_ __
/ /_/ / __ `/ / / / / /
/ _, _/ /_/ / / / /_/ /
/_/ |_|\__,_/_/_/\__, /
/____/
Available tracks:
Name Description Documents Compressed Size Uncompressed Size Default Challenge All Challenges
------------- --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- ----------- ----------------- ------------------- ----------------------- ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
noaa Global daily weather measurements from NOAA 33,659,481 949.4 MB 9.0 GB append-no-conflicts append-no-conflicts,append-no-conflicts-index-only,top_metrics,aggs
http_logs HTTP server log data 247,249,096 1.2 GB 31.1 GB append-no-conflicts append-no-conflicts,runtime-fields,append-no-conflicts-index-only,append-sorted-no-conflicts,append-index-only-with-ingest-pipeline,update,append-no-conflicts-index-reindex-only
metricbeat Metricbeat data 1,079,600 87.7 MB 1.2 GB append-no-conflicts append-no-conflicts
so Indexing benchmark using up to questions and answers from * 36,062,278 8.9 GB 33.1 GB append-no-conflicts append-no-conflicts
geonames POIs from Geonames 11,396,503 252.9 MB 3.3 GB append-no-conflicts append-no-conflicts,append-no-conflicts-index-only,append-sorted-no-conflicts,append-fast-with-conflicts
eql EQL benchmarks based on endgame index of SIEM demo cluster 60,782,211 4.5 GB 109.2 GB default default
eventdata This benchmark indexes HTTP access logs generated based sample logs from the elastic.co website using the generator available in https://github.com/elastic/rally-eventdata-track 20,000,000 756.0 MB 15.3 GB append-no-conflicts append-no-conflicts,transform
geoshape Shapes from PlanetOSM 60,523,283 13.4 GB 45.4 GB append-no-conflicts append-no-conflicts
geopointshape Point coordinates from PlanetOSM indexed as geoshapes 60,844,404 470.8 MB 2.6 GB append-no-conflicts append-no-conflicts,append-no-conflicts-index-only,append-fast-with-conflicts
nyc_taxis Taxi rides in New York in 2015 165,346,692 4.5 GB 74.3 GB append-no-conflicts append-no-conflicts,append-no-conflicts-index-only,append-sorted-no-conflicts-index-only,update,append-ml,date-histogram
nested * Q&A stored as nested docs 11,203,029 663.3 MB 3.4 GB nested-search-challenge nested-search-challenge,index-only
geopoint Point coordinates from PlanetOSM 60,844,404 482.1 MB 2.3 GB append-no-conflicts append-no-conflicts,append-no-conflicts-index-only,append-fast-with-conflicts
pmc Full text benchmark with academic papers from PMC 574,199 5.5 GB 21.7 GB append-no-conflicts append-no-conflicts,append-no-conflicts-index-only,append-sorted-no-conflicts,append-fast-with-conflicts
percolator Percolator benchmark based on AOL queries 2,000,000 121.1 kB 104.9 MB append-no-conflicts append-no-conflicts
通过esrally写入数据集群（default-deployment集群）中：
esrally race --track=noaa --pipeline=benchmark-only --offline --user-tag="ece:7.12.0" \
--challenge="append-no-conflicts-index-only" \
--target-hosts="https://cb0ac8df156242eeb422394c6b872c00.35.241.87.19.ip.es.io:9243" \
--client-options="use_ssl:true,verify_certs:false,basic_auth_user:'elastic',basic_auth_password:'your-pass-word'"
默认索引名为weather-data-2016， 大小为5.7gb：
创建快照仓库与快照
我们以GCP上的GCS作为对象存储的快照仓库。(可以参加上一篇文章Elastic Cloud Enterprise的快照管理，了解如何在ECE上创建和管理快照仓库）
在gcs上创建一个名为shared-repository的快照仓库，注意这里的 base_path，下一步的计算集群需要使用相同的 base_path 才能读到数据集群所创建的数据快照
PUT /_snapshot/shared-repository
{
"type": "gcs",
"settings": {
"bucket": "lex-demo-bucket",
"client": "my_alternate_client",
"base_path": "searchable_snapshot",
"client_name": "cloud-gcs"
}
}
将weather-data-2016索引写入快照，这里，我把快照命名为searchable_snapshot:
PUT /_snapshot/shared-repository/searchable_snapshot?wait_for_completion=true
{
"indices": "weather-data-2016",
"ignore_unavailable": true,
"include_global_state": false,
"metadata": {
"taken_by": "lex",
"taken_because": "for demo"
}
}
关联快照仓库与快照
在计算集群（forzen tier集群）中，以同样的base_path创建仓库：
PUT /_snapshot/shared-repository
{
"type": "gcs",
"settings": {
"bucket": "lex-demo-bucket",
"client": "my_alternate_client",
"base_path": "searchable_snapshot",
"client_name": "cloud-gcs"
}
}
这时，可以从中看到由数据集群打上来的快照
mount searchable snapshot
通常，您可以通过ILM管理可搜索快照。当可搜索快照操作到达cold或 frozen阶段时，它将自动将常规索引转换为可搜索快照索引。但目前可搜索快照的frozen tier功能还处于pre-beta阶段，还没有把它做到ILM当中，因此，我们需要手动调用API的方式，做挂载。
挂载选项
要搜索快照，必须首先在本地将其挂载为索引。通常，ILM将自动执行此操作，但是您也可以自己调用 安装快照API。挂载快照有两个选项，每个选项具有不同的性能特征和本地存储空间：
full_copy
将快照索引的分片的完整副本加载到群集内的节点本地存储中。这是默认的安装选项。ILM在hot和cold阶段默认使用此选项。这也是我们之前提到的Cold tier的功能。
由于几乎不需要访问快照存储库，因此全副本可搜索快照索引的搜索性能通常与常规索引相当。在恢复过程中，搜索性能可能会比常规索引慢，因为搜索可能需要一些尚未检索到本地副本中的数据。如果发生这种情况，Elasticsearch将仅检索完成搜索所需的数据，同时并行的进行恢复。
在本例中：
POST /_snapshot/shared-repository/searchable_snapshot/_mount?wait_for_completion=true&storage=full_copy
{
"index": "weather-data-2016",
"renamed_index": "weather-data-2016",
"index_settings": {
"index.number_of_replicas": 0
},
"ignored_index_settings": [ "index.refresh_interval" ]
}
加载后，与原大小相当，但默认是为0副本，并且可自动恢复
shared_cache
此功能是试验性的，也是本文演示的内容，但它在将来的版本中可能会完全更改或删除。这点请大家注意
其功能为：使用仅包含快照索引数据的最近搜索部分的本地缓存。默认情况下，ILM在frozen阶段和相应的冻结层中使用此选项。
如果搜索需要的数据不在缓存中，Elasticsearch将从快照存储库中获取丢失的数据。需要进行这些提取的搜索速度较慢，但是将提取的数据存储在缓存中，以便将来可以更快地提供类似的搜索服务。Elasticsearch将从缓存中逐出不常使用的数据，以释放空间。
尽管比完整的本地副本或常规索引要慢，但共享缓存的可搜索快照索引仍然快速返回搜索结果，即使对于大型数据集也是如此，因为存储库中的数据布局已针对搜索进行了优化。在返回结果之前，许多搜索将仅需要检索总分片数据的一小部分。
要使用共享的高速缓存装入选项装入可搜索的快照索引，必须配置此xpack.searchable.snapshot.shared_cache.size设置以为一个或多个节点上的高速缓存保留空间。使用shared_cache挂载选项来加载的索引仅分配给配置了此设置的节点
在本例中：
POST /_snapshot/shared-repository/searchable_snapshot/_mount?wait_for_completion=true&storage=shared_cache
{
"index": "weather-data-2016",
"renamed_index": "weather-data-2016",
"index_settings": {
"index.number_of_replicas": 0
},
"ignored_index_settings": [ "index.refresh_interval" ]
}
加载后，本地磁盘占用空间为0！
测试可搜索快照
在shared_cache模式下挂载上来的索引，其第一次访问时，会有一个数据下载的时间，但可以看到因为只下载特定数据（这里是聚合所需的doc value）, 因此，12秒内能完成一个6gb大小的索引的聚合操作
第二次执行，因为有缓存，会快上很多（12048 vs 2002）
但相对于原始数据集群上的速度，还是稍微有点差距（2002 vs 1358）
总结
最新release的这个可搜索快照的冷冻层，让我们做到真正的计算和存储分离。冻结层不在本地存储数据，直接搜索存储在对象存储中的数据，而无需首先对其进行restore操作。本地缓存存储最近查询的数据，以便在重复搜索时获得最佳性能。结果，存储成本显着下降-在热层或热层中高达90％，在冷层中高达80％。数据的全自动生命周期现已完成：从热到热再到冷再到冻结，同时确保以最低的存储成本获得所需的访问和搜索性能。
无论是出于可观察性，安全性还是企业搜索目的，您的IT数据都可以保持指数级增长。组织每天摄取和搜索数TB数据是很平常的事。这些数据不仅对于日常成功至关重要，而且对于历史参考也至关重要。无限制地回顾安全性调查，钻探多年的APM数据以进行趋势识别，或偶尔发现法规遵从性都是所需关键案例，会要求你的数据长期保存和访问。而冻结层的出现，为你打开了所有这些用例的大门，还等什么，赶快试用吧！